Start, pause, stop a workflow

Last update: June 4, 2025
  • Applies to:
  • Campaign v8
  • Campaign Classic v7

CREATED FOR:

  • Beginner
  • User
  • Admin

A workflow is always started manually. When started, it can however remain inactive depending on the information specified via a scheduler (see Scheduler) or activity scheduling.

Actions related to targeting workflow execution (launch, stop, pause, etc.) are asynchronous processes: the order is recorded and will be effective as soon as the server is available to apply it.

The toolbar allows you to start and track the execution of the workflow.

The list of options available in the Actions menu and the right-click menu are detailed below.

IMPORTANT
Keep in mind that, when an operator performs an action on a workflow (start, stop, pause, etc.), the action is not executed straightaway, but instead placed in a queue in order to be processed by the workflow module.

Actions toolbar

The Actions button of the toolbar lets you access to additional execution options on selected workflows. You can also use the File > Actions menu, or right-click a workflow and select Actions.

  • Start

    This action lets you start the execution of a workflow: a workflow that is Finished, Being edited or Paused changes status to Started. The workflow engine then handles the execution of this workflow. If the workflow was paused, it is resumed, otherwise the workflow is started from the beginning and the initial activities are activated.

    Starting is an asynchronous process: The request is saved and is processed as soon as possible by a workflow server.

  • Pause

    This action sets the status of the workflow to Paused. No activities are activated until the workflow is resumed; however the operations in progress are not paused.

  • Stop

    This action stops a workflow currently being executed. The status of the instance is set to Finished. Operations in progress are stopped, if possible. Imports and SQL queries are canceled immediately.

    IMPORTANT
    Stopping a workflow is an asynchronous process: The request is registered, then the workflow server or servers cancel operations in progress. Stopping a workflow instance can therefore take time, especially if the workflow is running on multiple servers, each one of which must take control to cancel the tasks in progress. To avoid any issue, wait for the stop operation to be completed and do not perform multiple stop requests on the same workflow.

  • Unconditional stop

    This option changes the workflow status to Finished. This action should only be used as a last resort if the normal stop process fails after several minutes. Only use the unconditional stop if you are sure there are no actual workflow jobs in progress.

    CAUTION
    Unconditional stop is restricted to Admin users.

  • Restart

    This action stops then restarts the workflow. In most cases, it makes it possible to restart faster. It is also useful to automate restarting when stopping takes a certain amount of time: this is because the ‘Stop’ command is not available when the workflow is being stopped.

    Note that the Restart action does not clear the workflow instance variables compared to Execution, Stop, and Start actions (the instance variables clearing happening upon Start action). When restarting a workflow, instance variables are still available for use with preserved values. To clear them, you can either:

    • Perform Stop and Start actions.

    • Add below javascript code at the end of your workflow execution:

      var wkf = xtk.workflow.load(instance.id)
wkf.variables='<variables/>'
wkf.save()

  • Purge history

    This action lets you purge the workflow history. For more on this, refer to Purging the logs.

  • Start in simulation mode

    This option lets you start the workflow in simulation mode as opposed to real mode. This means that when you enable this mode, only activities that do not impact the database or the file system are executed (e.g. Query, Union, Intersection, etc.). Activities that do have an impact (e.g. Export, Import, etc.) as well as those after them (in the same branch) are not executed.

  • Execute pending tasks now

    This action lets you start all pending tasks as soon as possible. To start a specific task, right-click its activity and select Execute pending task(s) now.

  • Save as template

    This action creates a new workflow template based on the selected workflow. You need to specify the folder where it will be saved (in the Folder field).

Workflow execution best practices

Improve your instance stability by implementing the following best practices:

  • Do not to schedule a workflow to run more than every 15 minutes because it may impede overall system performance and create blocks in the database.

  • Avoid leaving your workflows in a paused state. If you create a temporary workflow, make sure it will be able to finish correctly and not stay in a paused state. If it is paused, it would imply that you need to keep the temporary tables and thus increase the size of the database. Assign Workflow Supervisors under Workflow Properties to send an alert when a workflow fails or is paused by the system.

    To avoid having workflows in a paused state:

    • Check your workflows on a regular basis to ensure there are no unexpected errors.
    • Keep your workflows as simple as possible, for example by splitting large workflows in several different workflows. You can use External signal activities trigger their execution based on other workflows’ execution.
    • Avoid having disabled activities with flows in your workflows leaving threads open and leading to many temporary tables that can consume a lot of space. Do not keep activities in Do not enable or Enable but do not execute states in your workflows.

  • Stop unused workflows. Workflows that keep running maintain connections to the database.

  • Only use unconditional stop in the rarest cases. This option is restricted to Admin users. Do not use this action on a regular basis. Not performing a clean closure on connections generated by workflows to the database impacts performance.

  • Do not perform multiple stop requests on the same workflow. Stopping a workflow is an asynchronous process: The request is registered, then the workflow server or servers cancel operations in progress. Stopping a workflow instance can therefore take time, especially if the workflow is running on multiple servers, each one of which must take control to cancel the tasks in progress. To avoid any issue, wait for the stop operation to be completed and avoid stopping a workflow multiple times.