Lock workflow activity

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Lock workflow activity

    The Lock workflow activity in ServiceNow controls concurrent execution of multiple instances of the same workflow by preventing other instances from progressing past the lock point until the lock is released. This is particularly useful when workflows trigger multiple times due to successive record insertions or other events, helping to serialize critical sections of the workflow.

    Show full answer Show less

    A lock is obtained based on a unique key and can be explicitly released using the Unlock activity or automatically released when a maximum duration expires. The activity continuously attempts to acquire the lock up to a configured number of attempts with delays between attempts.

    Best Practices

    • It is recommended to place a one-second timer activity before the Lock activity. This ensures each workflow instance runs on a distinct execution thread, avoiding rare conditions where the lock cannot distinguish between instances.
    • Avoid inserting wait-type activities (e.g., Approval, Task, Timer, Wait for Condition, MID Server scripts) between Lock and Unlock activities to prevent locking delays and potential timeouts.

    Key Features

    • Lock Key: A unique mutex identifier used to acquire and release the lock.
    • Max Duration: Automatically releases the lock if held beyond this time.
    • Lock Attempts: Defines how many times and at what intervals the workflow retries obtaining the lock before failing.
    • Activity States: Includes Waiting (attempting to acquire lock), Finished (lock acquired), and Timeout (failed to acquire lock within attempts).

    Expected Outcomes

    • Success: Workflow instance obtains the lock and proceeds, blocking others from progressing past the lock.
    • Failure: Lock attempts exceed maximum without success, resulting in a timeout and failure state for the activity.

    By using the Lock activity effectively, ServiceNow customers can coordinate workflow instances to avoid race conditions and ensure serialized execution of critical workflow segments.

    The Lock activity prevents other instances of this workflow from continuing past this activity until the lock is released.

    Several instances of the same workflow may run concurrently. For example, if a workflow triggers when a record is added to a particular table. That workflow triggers multiple times if multiple records are added one after the other, once by each record insertion. You can use the lock activity to ensure that this instance of the workflow has finished one or more activities before any other instance of the workflow can proceed.

    A workflow can explicitly release a lock with the Unlock activity. The lock may also be released when the Max duration is reached.

    When an instance of the workflow reaches the Lock activity, it attempts to obtain a lock using the key specified in the lock activity. If another instance has already obtained the lock and has not yet released it, this lock attempt fails. The instance continues trying to obtain the lock until Max attempts has been reached.

    Note:

    We recommend placing a one-second timer activity before the lock activity. This helps prevent a rare condition in which the lock activity may not be able to distinguish one workflow instance from another. This condition can occur because the entity owning the lock is not the specific workflow instance, but rather the code-execution thread in which that instance is running. In most cases, each workflow instance runs on a different thread. Adding a timer activity ensures that this is the case.

    Figure 1. Example of Lock Activity Preceded by Timer Activity
    Workflow with timer activity before lock activity
    Since a Lock activity can only temporarily prevent processing of other workflow instances, do not add activities that cause the workflow to wait between a Lock and Unlock activity block. This may cause the Unlock activity to be unable to acquire the lock to release it and instead take 60 seconds to complete. Restricted wait activities include:
    • Approval activities
    • Task activities
    • Timer activities
    • Wait for condition activity
    • Wait for WF Event activity
    • MID server activities such as a PowerShell script

    Results

    Table 1. Lock activity results
    Result Description
    Success The activity successfully obtained a lock. This instance of the workflow can proceed past this point, but other instances cannot proceed until the lock is released.
    Failure After attempting to obtain the lock Max attempts times, the activity could not obtain the lock.

    Input variables

    Input variables determine the initial behavior of the activity.

    Table 2. Lock activity input variables
    Field Description
    Key A unique mutex key. The Unlock activity activity uses this key to release the lock.
    Duration
    Max. duration The maximum time the lock persists. The lock is released after it reaches this duration. Releasing a lock this way is equivalent to running the Unlock activity.
    Lock attempts

    Specify how the activity behaves if the lock attempt is denied. If the final lock attempt fails, the activity state is set to 'timeout' and the activity result is set to 'failed'.

    Max. attempts Specify the maximum number of times the activity may attempt to obtain the lock.
    Delay between attempts The amount of time required after a failed lock attempt before another lock attempt is allowed.

    States

    The activity state tells the workflow engine what to do with the activity.

    Table 3. Lock activity states
    State Description
    Waiting The workflow engine is waiting to obtain a lock.
    Finished The activity successfully obtained the lock.
    Timeout The activity could not obtain a lock within the number of attempts specified by the Max. attempts input variable.