dspConduct
Configure Workflow Messages Overview
Requests are workflow-enabled, meaning that each user assigned to a role in a request receives a notification when the tasks assigned to that role have work assigned.
Users can set whether or not they receive notifications and the form in which the notifications are sent (either via email or notifications from within dspConduct™, or both). An Administrator can configure these options for multiple users.
Refer to Set User Workflow Receipt Preferences for more information about receipt options.
By default, dspConduct™ sends workflow messages to users who have access to a request when a request is created, canceled, deleted, finished, rejected or reset. A user can view the default messages installed, but cannot update them. These default messages are used as a starting point for all dspConduct™ categories.
NOTE: A Designer must navigate to the Category Workflow Language Message page for workflow message definitions to be created for active Languages. If a Designer does not navigate to the Category Workflow Language Message page, no workflow message definitions will be available, and no workflows messages will be sent.
NOTE: Workflow Messages for SLA notifications are sent when a time constraint for completing tasks within a request role has passed. Refer to Setting up SLA notifications in dspConduct™ for more information.
If the notification text must use a language other than English, a user must Create Language-specific Workflow Messages for a Category.
A user can also View Default Workflow Messages or Edit Category Language-specific Messages.
NOTE: A user can create custom workflow message events at the category level. These events must have different names than the default events that were installed with dspConduct™. For example, a user cannot create a custom workflow message event with the name “Deleted.” The Content WebApp must provide the code to process these messages. They are not processed by dspConduct™.
The following table lists the type of workflow messages and the type of user that receives them.
Event |
Type of User that Receives Workflow |
All roles in a request are rejected. |
Users who have access to the initial application role |
A task for a request role is rejected. |
Users who have access to that role |
Request is canceled. |
Users who have access to the request |
Request is deleted. |
Users who have access to the request |
Role is reset. |
Users who have access to the role that was reset. Also users who have access to subsequent roles that depend on the role that was reset will receive a workflow notifying them that the role was reset; they will receive another workflow when it is time to reprocess their role. |
Role is finished. |
Users who have access to next role to be processed in the scenario |
Application role is finished and Review role is available. |
Users who belong to the Review role, if auditing is turned on in the Content WebApp and the tables that are used to add role data have been updated. Refer to View Changes for a Request During the Review Process for more information. |
Request is submitted (Role is made active and ready to be processed). |
Users who have access to the initial application role |
Request posts successfully. |
Users configured to receive these notifications at the scenario role or request role level. Refer to Send Workflow Notifications when a Post Fails or Succeeds for more information. |
Request fails to post. |
Users configured to receive these notifications at the scenario role or request role level. Refer to Send Workflow Notifications when a Post Fails or Succeeds for more information. |
Final Finish package is created but does not run successfully. |
Users who belong to the Final Finish Admin WebApp group receive these notifications. Refer to Send Workflow Notifications when a Final Finish Package Fails for more information. |