Start by confirming whether the contact or transaction met the criteria to enter the automation.
Was the correct tag applied or the right triggering event used?
Were all required fields present (such as an assigned loan officer, transaction type, or loan status)?
Did the data meet the entry conditions at the exact time the automation was set to trigger?
Tip: Use a filtered contact or transaction list to simulate your conditions and confirm who should qualify.
If the criteria were met, verify that the automation was actually assigned.
View the automation history on the contact or transaction record.
Check for any "Assigned Automation" activity in the timeline or activity log.
If the automation was assigned but the actions didn’t occur, inspect the specific steps.
For Email Steps:
Is the email published and active?
Does the contact have a valid email address?
Is the contact flagged as "Do Not Email" or unsubscribed?
Was the same email already sent previously and skipped due to deduplication rules?
For Tags, Status Updates, or Other Actions:
Is the automation applying a tag or status the record already has?
Is the transaction in a state that prevents updates, such as "closed" or "archived"?
Did the record exit the automation due to an exit condition being met?
Are there wait steps or delays that haven’t yet completed?
Was the automation paused, edited, or deactivated after assignment?
Some automations fail due to incomplete or incompatible data.
Is there an assigned loan officer, processor, or team member?
Is the transaction in an expected status or pipeline stage?
Are custom fields or required values present and correctly filled?
Use Internal Test Records: Always test automations on internal contacts or transactions before applying them to live accounts.
Label Steps Clearly: Use descriptive naming conventions for automation steps to make review and debugging easier.
Avoid Redundant Triggers: Ensure that overlapping automations or conditions don’t conflict with each other.
Define Exit Conditions Carefully: Review exit conditions to prevent early or accidental removal from automation.
Conduct Regular Audits: Check and validate automations on a recurring basis, especially for business-critical workflows.
This is a frequently reported issue. Here's how to break it down:
Contact met entry conditions and was assigned to the automation
Email step exists and is published
Email was not delivered
Troubleshooting checklist:
Is the contact's email address present and properly formatted?
Is the email action marked as "Skipped" in the automation history?
Has the contact unsubscribed or been flagged as "Do Not Email"?
Has the same email already been sent previously through another automation?
Possible resolution steps:
Re-publish the email if unpublished
Add a condition to check if the email has been sent before triggering it again
Reassign the contact to the automation or trigger a new one
Users are often hesitant to edit or pause live automations because they are unsure what happens to contacts already enrolled.
If a contact or transaction is currently enrolled in an automation (meaning the automation has not yet completed and still has pending steps), editing the automation may affect how the remaining actions run.
Whether the change affects the contact depends on which step they are currently on.
If the contact has not reached the step yet, the updated version of the action will run.
Example
Original automation:
Wait 3 days
Add Tag
Updated automation:
Wait 3 days
Update Contact Status
If the contact has not reached this step yet, the automation will perform the updated action and update the contact status instead of adding the tag.
If a contact already completed a step before it was modified, the update will not apply to that contact.
Example
Original automation:
Wait 2 days
Send Email
Later the step is updated to:
Wait 2 days
Send Email
Add Tag
Contacts who already passed this step will not receive the new tag because the action was already completed before the change.
If a new action is added between existing steps, whether it runs depends on where the contact currently is in the automation.
Original automation:
Wait 1 day
Send Email
Updated automation:
Wait 1 day
Add Tag
Send Email
If the contact has not yet completed the delay, the new Add Tag action will run.
Original automation:
Wait 1 day
Send Email
Wait 1 day
Updated automation:
Wait 1 day
Send Email
Add Tag
Wait 1 day
If the contact already received the email and moved into the next delay, the new tag will not run, because the automation already scheduled the next step.
However, if the new action is placed after the next delay, the action will run when that delay completes.
Automations cannot be paused, but they can be disabled.
Disabling an automation has the following effects:
The automation stops accepting new enrollments
Contacts or transactions currently in the automation are treated as if the automation was removed
The workflow will not continue from where it left off
If the automation is enabled again later:
Existing contacts will not automatically resume the automation
The system may not allow re-enrollment if the automation is configured to run only once per contact or transaction.
If major changes are required, a safer approach is to:
Duplicate the automation
Apply the necessary changes to the copy
Use the new automation moving forward
Keep in mind that the duplicated automation will start from the beginning of the workflow.
If you need to update an automation that is currently running:
✔ Avoid disabling the automation unless absolutely necessary.
Instead:
Edit the actions that need to be updated
Save the changes
This allows the automation to continue running for contacts already enrolled, while applying the updated steps to actions that have not yet executed.
Before modifying a live automation, it is important to review a few key details.
If the automation has already finished for a contact or transaction, updating the automation will not cause new steps to run retroactively.
In this case, creating a new automation may be the better option.
Review the automation timeline or activity log to determine:
Which step the record is currently on
Which steps have already completed
Which actions are still pending
This helps determine whether the changes will affect the record.
Entry and exit conditions are evaluated automatically by the system.
If these conditions are changed incorrectly:
The contact or transaction may exit the automation immediately
Once removed due to conditions, the automation cannot be re-added if it is configured to run only once.
For this reason, always review condition changes carefully before saving updates.
Please note that Exit Conditions are evaluated at the same time as entry conditions. If a contact or transaction meets both entry and exit conditions, it will not be added to the automation.
If a contact or transaction is already enrolled in an automation and the entry conditions are later changed, the system will re-evaluate those conditions.
If the record no longer meets the updated entry conditions, it will be automatically removed from the automation.