Who This Is For / When to Use
This article is for Kyrios users building or debugging workflows where tags, emails, updates, or assignments appear in execution logs but do not apply correctly to the contact record.
How to Tell If a Race Condition Is Affecting a Workflow
A race condition is likely when workflow actions show as executed in logs but do not reflect on the contact record.
Common Symptoms
A tag, note, or status update appears in Execution Logs but is missing on the contact.
Actions that depend on earlier steps do not trigger.
Contact data appears inconsistent or partially updated.
How to Confirm Using Execution Logs
Open the workflow.
Click Execution Logs.
Locate the affected contact and action.
Check the timestamp for each action.
If multiple actions (for example, Add Tag and Add to Workflow) executed at the exact same second, the workflow is experiencing a race condition.
What Causes Race Conditions in Workflows
Race conditions occur when two or more dependent actions execute at the same time and attempt to update the same contact record.
Common Causes
Multiple actions modifying contact data simultaneously
Actions relying on previous steps that have not fully completed
External processes updating the contact at the same moment
Example
A workflow triggers Add Tag and Send Email at the same second.
The email sends successfully, but the tag does not apply because another process modified the contact record at the same time.
How to Prevent Race Conditions Using a Wait Action
The most reliable way to prevent race conditions is to introduce a delay between critical workflow actions.
Step-by-Step Fix
Open the workflow in Builder.
Identify actions that execute at the same time and modify contact data.
Click Add Action.
Select Wait.
Set the wait time to 1 minute.
Place the wait step before the next critical action.
Save and test the workflow.
How to Optimize Wait Times Without Slowing Workflows
Wait times should be long enough to ensure sequential execution but short enough to maintain performance.
Recommended Guidelines
Start with 30–60 seconds for contact-modifying actions.
Use longer waits for:
Webhooks
API calls
External integrations
Reduce wait time gradually after confirming consistent execution order.
Additional Ways to Reduce Race Conditions
Race conditions can also be reduced through better workflow design.
Best Practices
Use Conditional Branching: Split logic paths instead of running actions simultaneously.
Sequence Actions Linearly: Ensure dependent actions are placed one after another.
Limit Concurrent External Calls: Avoid triggering multiple integrations at the same moment.
How to Verify the Issue Is Fully Resolved
A workflow is considered stable once actions execute in a predictable, sequential order.
Verification Checklist
Execution logs show different timestamps for each action.
Test contacts receive all intended tags, updates, and emails.
No actions appear executed without applying to the contact.
Triggers do not overlap or fire concurrently.
Using Internal Notifications to Detect Race Conditions
Internal notifications can reveal race conditions when they conflict with contact data.
If an internal notification confirms a workflow stage but the contact is missing the expected tag or status, a race condition likely occurred. Immediately review execution logs and compare timestamps.