A variety of Workflow Sub-Actions can be triggered when a Workflow Action is executed.
- Built-In Workflow Sub-Actions
- Execution Order
- Sub-Action Permissions
- Custom Sub-Actions
Built-In Workflow Sub-Actions
dotCMS includes all of the following built-in Sub-Actions. You may select any number of these Sub-Actions, and execute them in whatever order you wish, for each Workflow Action.
Sub-Actions with No Parameters
The following Sub-Actions do not require (or accept) parameters. These Sub-Actions always perform the same action on the content item the Workflow Action is executed on.
|Archive content||None||Archives the content item.|
|Copy Content||None||Creates a copy of the content item.
|Delete content||None||Deletes the content item.|
|Lock content||None||Locks the content item.|
|Publish content||None||Changes the state of the content item to Published.|
|Push Publish||None||Displays the Push Publishing popup to the user who initiated the Workflow Action.
|Reset Workflow||None||Resets the content item back to the initial Workflow step.
|Save||None||Saves changes to the content and creates a new version of the content.|
|Save as Draft||None||Saves changes to the content, and attempts to do so without creating a new version of the content.
|Unarchive content||None||Unarchives the content item (changing it from the Archived state to the Unpublished state).|
|Unlock content||None||Unlocks the content item.|
|Unpublish content||None||Unpublishes the content item (changing it from the Published state to the Unpublished state).|
Sub-Actions with Parameters
The following Sub-Actions each accept (and may require values for) one or more parameters. The values entered for the parameters change how these Sub-Actions work, so Workflow Actions with the same Sub-Actions may behave differently, depending on the values entered for the parameters. In the list below, all parameters listed are required, unless they are explicitly marked as (Optional).
To change the parameters for any Sub-Action in this list, click the Sub-Action name in the Sub-Actions section of the Workflow Action configuration.
||Requires that the specified number of users from among the list of specified users take the Workflow action.
||Adds a comment to the content item [Workflow Task](workflow-tasks).
||Uses the Link Checker to verify that any links found in the specieid fields are valid.
||Displays a popup message to the specified users.
||Notifies all assigned users that the Workflow Action was taken.
||Sends an email with the specified information and format to the specified users.|
||Push publishes the content item to the specified Push Publishing Environment.
||Reindexes the content the Workflow Action is executed on.
|Require Multiple Approvers||
||Requires that all of the specified users take the Workflow Action before the following Subactions are performed.
|Send an Email||
||Sends an email with the specified content to the specified list of users.
||Sets the value of the specified field in the content item to the specified value.
||Automatically translates all specified fields types of the content item to the specified languages using the Google Translation API.
||Executes the specified Velocity code.
When the Workflow Action is executed by a user, each of the Sub-Actions assigned to that Action are triggered, in the order the Sub-Actions are listed in the Action configuration.
This means, for example, that if a Sub-Action changes a value in the content item, that Sub-Action must be followed by a “Save content” or “Save Draft content” Sub-Action, or the changes made by the first Sub-Action will not be saved to the content item. Similarly, if a Push Publish Sub-Action comes before a Save Sub-Action in the Sub-Action list, then the old version of content will be pushed, before the changes to the content are saved.
Stopping Sub-Action Execution
If any of the Sub-Actions fails or encounters an error, execution of the Sub-Actions stops, and all Sub-Actions which follow the failed Sub-Action will not be executed. In addition, if any of the Sub-Actions fail, then the Next Step property of the Action will not be executed, and the Workflow Step of the content item will not be changed.
For example, when using the 'Four Eyes' Approval Sub-Action, this Sub-Action is specifically designed to stop execution of the Sub-Actions unless the required number of users has taken the action. This means that when using this Sub-Action, you can set the Next Step property of the Action, and add additional Sub-Actions after the 'Four Eyes' Approval Sub-Action, and none of those will be executed until all the required users have taken the action.
Permissions are always checked for all Sub-Actions. Specifically, the permissions of the user executing the Workflow Action are always checked, for all Sub-Actions that are part of the Action, in relation to the content item the Workflow Action is being executed against, and, if applicable, any other objects in the system that any of the Subactions may access (such as content or objects accessed via the Velocity Script Sub-Action).
This means that, regardless of which users are able to execute the Action (via the Action properties), the user's permission on the content item will still always be checked and enforced for each Sub-Action.
In addition to the built-in Sub-Actions, you may create Workflow Actions which have custom Sub-Actions in one of two ways:
- Implement custom behavior via the Velocity Script Sub-Action.
- Create your own custom Sub-Actions by using an OSGI plugin to create a Custom Workflow Actionlet.
Note that you may also add custom code and behavior to a Workflow Action using the Custom Code field in the Action properties. However code in this field is not executed in the same way as code within Sub-Actions; for more information on when and how different types of code is executed within a Workflow Action, please see the documentation.