A variety of Workflow sub-actions can be triggered when a Workflow Action is executed.
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||Archives the content item.|
|Auto-Tag Images (AWS)||Submits an image content item to the Amazon Rekognition image analyzer, and adds Tags to the Tag field of the content item based on the Amazon Rekognition results.
|Copy Contentlet||Creates a copy of the content item.
|Delete Content||Deletes the content item.
|Destroy Content||Deletes all language versions of the content item.
|Lock Content||Locks the content item.|
|Publish Content||Changes the state of the content item to Published.|
|Push Publish||Displays the Push Publishing popup to the user who initiated the Workflow Action.
|Reset Approvals||Resets the list of users who have approved the content using the Four Eyes Approval or Require Multiple Approvers Sub-Actions.
|Reset Workflow||Resets the content item back to the initial Workflow step.
|Save Content||Saves changes to the content and creates a new version of the content.|
|Save Draft Content||Saves changes to the content, and attempts to do so without creating a new version of the content.
|Unarchive Content||Unarchives the content item (changing it from the Archived state to the Unpublished state).|
|Unlock Content||Unlocks the content item.|
|Unpublish Content||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).
||Displays a large popup message to the specified users.
||Uses the Link Checker to verify that any links found in the specieid fields are valid.
||Displays a popup message to the specified users.
||Allows users to move content to a host or folder which they select or have defined in the default.|
||Notifies all assigned users that the Workflow Action was taken.
||Sends an email with the specified information and format to the specified dotCMS users. More information below.|
||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 sub-actions are performed.
|Send an Email||
||Sends an email with the specified content to the specified list of addresses.
|Send Form Email||
||This actionlet sends information submitted via form to the email addresses defined in the form. If the content is not a form, then this actionlet will do nothing.
||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.
|Twitter Status Update||
||Posts the value of a content item field or the Workflow comments to Twitter.
|Velocity Script Actionlet||
||Executes the specified Velocity code.
Emails: Notify Asignee vs. Notify User vs. Send an Email
Three of the above sub-actions involve sending an email, but they differ in parameters and purpose:
- Notify Asignee sends an email to dotCMS users who have just been assigned content, to notify them that they're now responsible for it. This is the narrowest of the three.
- Notify Users is slightly more general-purpose, sending a message to dotCMS users on the same system, irrespective of their assignment status on a given piece of content.
- Send an Email is the most generic of the three, which is intended for emailing anyone — including non-users. It provides the most control over the format and content of the email.
Additionally, there are three other sub-actions that involve email. One of these, Send Form Email, simply executes the emails that a given form is configured to send. The other two, related to approvals, are detailed in Multiple Approval Sub-Actions.
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 sub-actions 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.