Workflow and Service Hooks Trigger Best Practices
Workflows and service hooks are powerful tools for automating business processes in Conga. They act on your data dynamically, responding to record changes and events in real time. But this power comes with a responsibility: if triggers are not designed carefully, they can cause the system to enter an infinite feedback loop.
This topic explains how feedback loops occur, shows you what they look like in practice, and gives you clear, actionable guidance to prevent them.
Why Feedback Loops Happen
A feedback loop occurs when a workflow or service hook trigger is broad enough to fire not just on user-initiated actions, but also on the changes made by the workflow itself. The result is a self-sustaining cycle of executions that never stops on its own.
| Step | What happens |
| 1 | A user updates a record, for example, changing the Status field. |
| 2 | The platform detects the update and matches it to a workflow trigger condition. |
| 3 | The workflow runs and writes back to the same record, for example, updating a related field. |
| 4 | The platform sees this write-back as a new update and fires the workflow again. |
| 5 | The cycle repeats indefinitely until the platform intervenes. |
Common Loop Scenarios
Feedback loops can form in several ways. Understanding the most common patterns helps you spot potential problems before they occur.
Scenario 1: A Workflow That Triggers Itself
This is the most straightforward pattern. A workflow fires whenever an Agreement record is updated, and as part of its logic, it writes back to the same Agreement record. That write-back looks like a user update to the platform, so the workflow fires again, and again, indefinitely.
Scenario 2: Two Workflows That Trigger Each Other
This pattern is harder to spot because each workflow looks safe in isolation. The problem only appears when you look at how the two interact:
- Workflow A fires on an update to Agreement and writes to a related AgreementLineItem record.
- Workflow B fires on an update to AgreementLineItem and writes back to Agreement.
Workflow A triggers Workflow B, which triggers Workflow A, creating an endless loop between two objects. When designing workflows that span related objects, always map out what each workflow writes and check whether those writes could trigger another workflow in your system.
Scenario 3: Service Hooks and Workflows Triggering Each Other
How to Prevent Loops
The most effective way to prevent feedback loops is to design precise trigger conditions. A well-scoped trigger fires only when a specific business event occurs, not when an unrelated update or a workflow write-back happens on the same record.
| Dimension | What it controls | Example | Risk if ignored |
| Action type | Whether the trigger fires on Create, Update, or Delete | On Created rather than On Any Change | The trigger fires on every update, including write-backs from other workflows |
| Field specificity | Which field or fields must change for the trigger to fire | Status CHANGED | The trigger fires when any field changes, including internal system fields |
| Value transition | What value the field must change to | Status changed TO Approved | The trigger fires on any status change, not just the one you care about |
| Prior state guard | What the field value must have been before the change | Old Status was Pending AND Status changed to Approved | The trigger fires repeatedly, including on re-approvals and re-runs |
Putting It Into Practice: Compare these two versions of the same trigger:
- Without precise conditions
(unsafe):
Trigger: On Order Update Condition: None Result: Fires on every update to every Order record, including write-backs from other workflows. One execution causes another, indefinitely. - With precise conditions (safe):
Trigger: On Order Update Condition: ApprovalStatus CHANGED FROM Pending TO Approved Result: Fires only on this specific transition. A workflow writing to an unrelated field, or writing the same value again, will never match this condition.Note: Applying all four dimensions to a single trigger gives you a condition that maps to exactly one business event. This is the goal.
Platform Safety Mechanisms
Even with well-designed triggers, the Conga Advantage Platform includes built-in throttling to detect and stop runaway executions before they cause serious damage. This acts as a safeguard, not a replacement for proper trigger design.
| Setting | Default value | What it controls |
| Workflow execution limit per record | 20 | Maximum number of times a workflow can run for the same record within the throttle window |
| Workflow throttle window | 30 seconds | The time window within which the execution limit is tracked |
| Workflow cooldown period | 30 seconds | How long the platform waits before allowing the workflow to run again after hitting the limit |
| Service hooks execution limit per record | 20 | Maximum number of times service hooks custom code can run for the same record within the throttle window |
| Service hooks throttle window | 30 seconds | The time window within which the service hooks execution limit is tracked |
| Service hooks cooldown period | 30 seconds | How long the platform waits before allowing service hooks to run again after hitting the limit |