Flow Execution MutexesIssue A mutex is taken against sys_flow_context for every non-Quick flow execution and against a Quick (Quick API) context ID for quick flows. When a flow step execution time exceeds the value of the property set in 'com.glide.hub.flow_engine.mutex_expiration', this mutex will be expire, and the flow will be restarted from the last quiescence point. Quiescence point are points where a flow goes in to a waiting state. Common actions such as 'Wait for Duration', 'Wait for Condition' or 'Ask for Approval' can cause a flow quiesce. On mutex expiration, node logs with below message can be observed: WARNING *** WARNING *** Not releasing expired mutex sys_flow_context_mutex_{flow_context_id} System properties 'com.glide.hub.flow_engine.mutex_expiration' By default, system property 'com.glide.hub.flow_engine.mutex_expiration' is not visible on the 'sys_properties' tables. The default value of this system property by release version is as below: Vancouver - 900 secondsWashington DC - 3600 seconds *Default value in Washington DC has been increased to 3600 seconds from 900 seconds. To override the default value, create 'com.glide.hub.flow_engine.mutex_expiration' can be created on the 'sys_properties' tables, and the value can be edited accordingly. FAQ Is there any potential negative effect of extending the system property 'com.glide.hub.flow_engine.mutex_expiration' to a large value? There shouldn't be any issues with that Any other steps that can be taken to avoid mutex expiration? We generally do not recommend long running flows. We recommend breaking flows up in to smaller re-usable components. See more details Is the time configured in 'com.glide.hub.flow_engine.mutex_expiration' compared to the time from where the flow starts, or from where the last quiescence point is? It's from the time the mutex is taken - so it's when the flow starts or resumes from a quiescence pointFor example, if a flow consisted of an Ask For Approval action, the mutex expiration after the Approval is from when the Approval is completed rather than when the flow itself is started ResolutionWhen a flow is being affected by mutex expiration, consider the following actions: 1. Changing the default value of system property 'com.glide.hub.flow_engine.mutex_expiration' to ensure mutex does not expire. 2. Review the flow itself to cut down on the flow run times. Check the 'Design considerations for Flow Designer' documentation for details on best design practices.Design considerations for Flow Designer - https://docs.servicenow.com/csh?topicname=design-considerations-consolidated.html&version=latest