What are Waits and Timeouts?:
There are many reasons to create a wait within a workflow including waiting for a response from an email sent earlier in the workflow or setting a delay between actions taking place. When wanting to create a wait within a workflow, there are two main methods. The use of each depends on the purpose of the wait.
- Wait Condition - This is the standard option when adding a Wait action. From there, you can select to wait until a field on a record is set to a specific value or state.
- Process Timeout - This can be found by selecting "Local Values: Process" for the entity within the wait conditional. It can then be set to a specific static or dynamic date or duration.
Uses of Each:
- Wait Conditions are used for action/ status dependent waits. They are best used when there is a chain of actions that naturally progress but require a wait until an action or state change. For example, if you are promoting an event, you can send the event invitation and use a wait conditional on a registered field changing to yes before sending a confirmation email. Wait functions can be used similarly to Process Timeouts in some situations, however when those situations arise, it is generally better to use the Process Timeout as it is less resource heavy.
- Process Timeouts are used for date/ time dependent waits. They are best used when specific date or time range is meant to be reached. This can be a set duration, like 5 minutes or 24 days, a dynamic date, or a set time before or after a dynamic date. This could be a wait for a follow-up date saved on the Account to be reached. Occasionally, when working with workflows that contain plugins, a timeout may be needed to allow time for the rest of the process to catch up before the next step. If the field the Process Timeout is dependent on changes during the timeout, the process will update the date and the new value will be the date/time the timeout continues to. Note: The Process Timeout will default addition of days to trigger again at 12am. If a different time is needed be sure to use the Hours/Minutes before/after feature to progress at the appropriate time.
Best Practices:
- When creating a Wait or Timeout with a long delay, put the action to commence after the wait into its own child workflow.
- Why: Editability. When a workflow is started, the path is set for that record as it goes through the workflow. Any changes to a workflow will not affect system jobs that are already active and waiting in the process. Only new records that trigger after the changes to the workflow are made will experience the new actions after the wait. Having the actions in a separate child workflow allows for higher agility in making these sorts of changes.
- Example: you have a year wait in a workflow to send a Happy Birthday message to a customer. Halfway through the year, you realize that instead of sending a birthday email, you wanted to set a task for an account manager to reach out and tell them happy birthday personally. When the workflow is updated, only newly created system jobs for the workflow will have the instructions to create the task, while all of those currently in the wait will still receive the email. Meaning, all your actions would have a year delay before they go into effect. Alternatively, in the same situation if the task/email is in a child workflow. As soon as the update to the child workflow was made, everyone would receive the task instead of the email immediately following the change.
- Clear out old, "Waiting for timer" system jobs where the condition was never met.
- Why: System Performance. While waiting system jobs are not a large strain on the system, they can build up quickly if left unattended. Anytime a Wait Condition is contingent on the actions of a user, there is the possibility that the action is never taken. In these cases, a systemic cancelling procedure is recommended.
- Example: Assume you have a workflow where you send out a registration email. The workflow then waits until the registration is complete and a field in the CRM is marked noting it is completed before sending a follow up Thank you email. There is a chance that many of the contacts the registration email was sent to will never complete the registration. This leads to those system jobs remaining open indefinitely or until cancelled individually or through a bulk cancel.
- Alternatives: Occasionally, a wait can be avoided by creating a separate workflow that looks for the change that would have ended the wait in a wait condition. Times where this option would NOT work include:
- When a relationship with a record created in the original workflow is needed for the secondary workflow and cannot be established through lookups.
- The field that is the trigger changes so often with values other than the desired value for the conditional, cause many system jobs to run.