Avoid workflow getting cancelled due to reaching maximum activity count, usually found in a loop design involving a timer activity

• I have a loop in a workflow that sometimes is not completing. Workflow gets canceled after x iterations.
• Why avoid a looping design involving a timer activity
  
  

All

workflows have a maximum activity count, the default value is 100. Once the workflow executes this number of activities the workflow will be canceled.

• you can set the maximum activity count to a high number, found in the workflow properties under the "activities" tab
• however, this type of design should be avoided, this could potentially flood the scheduler if a lot of workflows are executing this looping design, another problem with this design is the amount of data being generated for tables [wf_history] & [wf_transition_history] if a lot of these workflows get generated and run for a long time
• the problem with the design is that the workflow does not know when to proceed hence the looping design
• usually, we find this design where a REST call is waiting for a particular response for the workflow to proceed
• ideally, the workflow should stop on a wait for condition activity, and then an external REST (Table API) call should be made to the platform updating the record the workflow is running against, moving the workflow forward
• If an external REST call to the platform can not be achieved, then perhaps a scheduled job running every so often that would handle a REST call to get the appropriate response and update ALL records where workflow is waiting

When the workflow reaches the maximum number of executing activities allowed by this setting, the workflow stops. The default maximum setting is 100. Use a setting that is at least 10% greater than the total number of executing activities you anticipate in your workflow.