Administering Workflows

Actions on workflows can only be undertaken if either:

• you are working with the admin account
• the account has been assigned to the default group workflow-users, which holds all the privileges necessary for your users to perform workflow actions.

Workflow models inherit a default access control list (ACL) for controlling how users can interact with workflows. To customize user access for a workflow, modify the Access Control List (ACL) for the workflow model node in the repository.

For information about using CRXDE Lite to configure ACLs, see Access Control. 

The following example restricts content authors from starting a workflow called mymodel. To restrict access, the Authors group is denied read access to the /etc/workflows/models/mymodel node.

The following diagram shows the default ACL for mymodel (the default ACL for all new models). The Authors group is a member of the contributor group, so Authors are allowed the jcr:read privilege for the node.

Because authors have read-access to the model, the workflow is available in Sidekick when authoring pages:

The following procedure adds an access list entry (ACE) that denies the jcr:read privilege for the content-author group.

A workflow can have one of the following status:

• RUNNING: The workflow instance is running.
• COMPLETED: The workflow instance has been successfully ended.
  
• SUSPENDED: The workflow instance has been suspended.
• ABORTED: The workflow instance has been terminated.
• STALE: Progression of the workflow instance requires that a background job executes, however the job cannot be found in the system. This situation can occur when an error occurs when executing the workflow.

To monitor the status of workflow instances, you can use the Instances or Archive tabs.

• Instances tab: Shows all running instances.
• Archive tab: Shows terminated workflow instances.Monitoring Workflows in progress

Note: When the execution of a Process Step results in errors, the step appears in the administrator's Inbox and the workflow status is RUNNING. 

From the Instances tab you can see the status of a Workflow in progress. A list of the active Models is shown; in this case RUNNING:

With the Instances tab you can take various actions (see Suspending, Resuming, and Terminating a Workflow instance) and also Open History to show the actions executed to date on the workflow instance:

Perform actions on running workflow instances when you need to intervene in the normal progression of a workflow instance:

• Suspend: Temporarily stops the execution of the workflow. Suspending is useful in exceptional cases when you do not want the workflow to proceed, for example for maintenance. Suspending changes the workflow state to Suspended.
• Resume: Restarts a suspended workflow at the same point of execution where it was suspended, using the same configuration. 
• Terminate: Ends the workflow execution and changes the state to ABORTED. An aborted workflow instance cannot be restarted.

The Instances tab is not only useful for taking action on running workflows, you can also use it to monitor workflow instances, without necessarily modifying them.

Workflow instances appear on the Failures tab of the Workflows console when the execution of a Process Step component results in errors. The Failures tab enables you to investigate the cause of the errors, and provides options for resuming execution when the causes are fixed:

After a Workflow instance has finished, for example after being terminated or after successful completion, it can (only) be seen in the Archive tab:

As the workflow has already completed, no further action can be taken on these instances. However, if you need further details of a completed workflow you can use Open History.