Configuring Object Workflows

Object workflows apply to a single object lifecycle and one or more records of a single object. To set up an object workflow, you’ll need to complete several steps:

Accessing Workflow Administration

You can create, edit, and view workflows from Admin > Configuration > Workflows.

About Envelope & Envelope Content Object Record Access

Object workflows create the raw Envelope and Envelope Content objects. While end users do not directly interact with these objects, access to these records should be carefully controlled. Because the objects are raw Vault objects, users with Workflow: Participate permission and access to Envelope or Envelope Content records through a custom object tab or Business Admin > Objects are able to view those records regardless of record-level permissions. In addition, if a record is in an active workflow, clicking on the Envelope record link may take the user to the workflow task page, even if the user is not a participant of that specific workflow.

How to Create Object Workflows

You can create an object workflow from scratch or copy an existing workflow using the Copy action.

Creating a New Object Workflow

To create a new workflow and outline its path using placeholder steps:

  1. Click Create from the Workflows page.
  2. Select Object Workflow from the drop-down list.
  3. Click Continue.
  4. Enter a Label. This value appears in various places throughout Vault, so it should be easily understood by users.
  5. Optional: Modify the Name. This value is primarily for referencing the workflow via the API.
  6. Select the Lifecycle related to the workflow. Workflows can only link to a single lifecycle and therefore a single object.
  7. Optional: Enter a Description for the workflow. This description is not visible to end users, but can help Admins understand various workflows and how they are configured.
  8. Optional: Deselect the Use workflow for single object record (selected by default) checkbox to allow users to send multiple object records of the same object type in the same workflow.
  9. Optional: Select the Workflow cancellation comment checkbox to require users who cancel the workflow to provide a comment.
  10. Optional: If you want to initiate this workflow automatically when an object record enters a specific lifecycle state, select the Allow auto-start from entry action and event action checkbox. Learn more in Configuring Auto-Start Object Workflows.
  11. Optional: Select Users in this workflow can only complete one task to prevent an individual participant from being able to complete multiple tasks in the workflow.
  12. Optional: Select a role to exclude from workflow tasks from the Role not allowed to complete tasks drop-down.
  13. Optional: Select an option from the Actions not allowed for the Workflow Owner picklist. You can select multiple workflow and task actions.
  14. Optional: Select an option from the Actions not allowed for all users except the Task Owner picklist. You can select multiple task actions.
  15. Select an option from the Actions not allowed for all users picklist. You can select multiple task actions.
  16. Click Save.

Copying an Existing Object Workflow

You can copy an existing workflow with the Copy action. The new workflow targets the same lifecycle as the source workflow. It also duplicates the description, steps, and variables of the source workflow. The copied workflow is created in configuration mode, and you will need to activate it.

To copy an existing object workflow:

  1. From the Actions menu of the workflow you want to duplicate, click Copy.
  2. Enter a Label. This value appears in various places throughout Vault, so it should be easily understood by users.
  3. Optional: Modify the Name. This value is primarily for referencing the workflow via the API.
  4. Click Copy.

You can now configure the workflow copy.

Deleting a Workflow

You can delete a workflow by selecting Delete from the Actions menu.

Workflow Version History

You can see a list of all activated versions of a workflow by selecting View Workflow Versions from the Actions menu. Click on a version of the workflow to view its details and steps. You cannot make changes to or copies of previous workflow versions.

Configuring Active Workflow Action Security

The object workflow configuration allows you to restrict workflow or task actions from participants or just the workflow owner. You can also exclude the task owner from any restrictions. For example, you can revoke the ability for the workflow owner to cancel the active workflow or allow task owners to cancel tasks they are assigned, but restrict this ability from everyone else.

Actions not allowed for the Workflow Owner will supersede the permission of granting workflow owners access to all workflow actions. Actions not allowed for all users and Actions not allowed for all users except the Task Owner will supersede any atomic security defaults or overrides for task actions and permission sets for workflow administrators.

When a user is the workflow owner and assigned a task, Vault will always revoke task actions for this user based on the configuration of Actions not allowed for the Workflow Owner. For example, if Cancel Workflow and Cancel Task are revoked from the workflow owner, and Cancel Task is revoked for all participants except the task owner, Vault revokes Cancel Workflow and Cancel Task on tasks assigned to the workflow owner.

Restricted Workflow Actions

You can restrict the following workflow actions from workflow owners:

  • Cancel Workflow
  • Email Participants
  • Update Participants
  • Update Workflow Due Date
  • Cancel Task
  • Reassign Task
  • Update Task Due Dates
  • Remove Content

Restricted Task Actions

You can restrict the following task actions:

  • Cancel Task
  • Reassign Task
  • Update Task Due Date

About Workflow Segregation of Duties

Vault provides two options on the Workflow Details page to configure the users allowed to complete tasks within a workflow:

  • Users in this workflow can only complete one task: If enabled, all participants in the workflow cannot accept, be assigned, or complete more than one workflow task. However, users can complete the same task multiple times in instances where verdicts on the task are rejected and looped back to them.
  • Role not allowed to complete tasks: If enabled, you can exclude a user role from completing any task in the workflow. Any participant in the user role cannot accept, be assigned, or complete tasks. You can select only one role per workflow.

These options are referred to as Segregation of Duties policies as they allow you to segregate users by workflow tasks. For example, to prevent users from approving their own content, use Role not allowed to complete tasks in the Approval workflow, and select the Owner role to prevent users from completing their own approval tasks.

Other example scenarios:

  • A workflow contains two different groups of individuals who are required to approve content separately, such as an engineering team and a quality assurance team. Anyone participating in the first group of approvals must not be allowed to participate in the second group of approvals. You can accomplish this by enabling Users in this workflow can only complete one task in the Approval workflow.
  • A workflow is configured to assign an approval task to the Approver role on the document’s sharing settings, but anyone with the Author role should not have access to complete the approval task.
  • A workflow is configured to require a two stage approval process. The workflow initiator can select participants for the first approval task. The second approval task is restricted to the Quality Assurance role. If Users in this workflow can only complete one task is enabled, any user who completes the first approval task should not receive or have access to complete the second approval task, even if the user is in the Quality Assurance role.
  • A workflow is configured with two tasks and proceeds to the second task only if the Compliance Impact document field is set to True. This is done through decision step branching and start step field prompts. Users in the Author role cannot accept, be assigned, or complete the first task. Any user who is assigned, has accepted, or completed the first task cannot receive, accept, or complete the second task.

Workflow Activation Validation

Vault will validate that both options are configured properly before activating a workflow. The workflow will fail to initiate in the following scenarios:

  • Multiple task steps use the same user role or workflow owner selected under Assign Task To while Users in this workflow can only complete one task is enabled
  • The role selected from the Role not allowed to complete tasks drop-down is configured as a role allowed to participate in the start step participant control and the participant control is assigned a task

Workflow Start Validation

When a workflow initiator starts the workflow, Vault will validate that the user is following the Segregation of Duty policies in place. If they do not follow the policy, Vault will fail to start the workflow. Possible scenarios include:

  • If Allow workflow initiator to select participants is selected in the start step and Users in this workflow can only complete one task is enabled, the workflow will fail to start if the workflow initiator adds a user to multiple participant groups with assigned tasks. An error message will display up to 10 users who are assigned multiple tasks.
  • If Allow workflow initiator to select participants is selected in the start step and a role is configured with Role not allowed to complete tasks, the workflow will fail to start if the workflow initiator assigns a user or user group with the restricted role to a participant group with assigned tasks.
  • If there are no users assigned to a participant group associated with the workflow’s first task, the workflow will fail to start.
  • If the first tasks in the workflow are parallel to each other, and each task contains different participant groups (for example, Approver is first task and Reviewer is second task), the workflow will fail to initiate if there are no users in one of the participant groups and Vault cannot assign a task to anyone.

Vault orders parallel tasks from right to left, which applies to how the tasks are created and assigned. Ensure users are assigned appropriately when Segregation of Duties policies are in place. For example, in the fourth bullet point above, group 2 contains the same members as group 1 and group 1 contains some additional members not in group 2. In that scenario, if group 2 is assigned to the Approver participant group (first task) and group 1 is assigned to the Reviewer group (second task), and Users in this workflow can only complete one task is enabled, the workflow will fail to initiate. This error happens because the users in group 1 would be assigned their task first before the users in group 2 and group 2 contains the same members as group 1. However, if the groups are reversed (group 1 assigned to Approver and group 2 assigned to Reviewer), the workflow will initiate because the additional users in group 1 did not receive the same task as the users in group 2.

Workflow Task Validation

The same Segregation of Duties policies apply during task assignment, reassignment, acceptance, and completion:

  • Task Assignment: The workflow will not assign multiple tasks to each user or user group or users with a restricted role upon activation.
  • Task Reassignment: You cannot reassign a task to a user who is already assigned or completed a task or configured with a restricted role. However, you can reassign a user continuing iterations of the same task if Users in this workflow can only complete one task is enabled.
  • Task Acceptance: Vault will prevent a user from accepting a task if they’ve already accepted, assigned, or completed another task or configured with a restricted role.
  • Task Completion: If Users in this workflow can only complete one task is enabled, users cannot move on to another task after completing the one they’re assigned. However, they can complete the same task again in situations where a verdict rejects the task completion.

A workflow may fail to continue if subsequent tasks are missing users in their participant groups due to Segregation of Duties policies in place. This can happen if a user is added to multiple participant groups, but can only complete one task. In this situation, Vault excludes the user from receiving the task and no one is assigned the task. Vault then returns to the last completed task.

Vault will display an error dialog to the user if they complete their task and the next task in the workflow is missing users from its participant group. The error dialog will allow users with the correct permission to add valid users to the participant group.

How to Outline Workflows with Placeholders

To create an outline of your workflow’s path using placeholders:

  1. Open the workflow from the Object Workflows page.
  2. Scroll down to Workflow Steps and make sure that you’re in flowchart view.
  3. Use the plus (+) icon between the Start and End steps and select Create Next Step.
  4. Enter a Label for the step that helps you identify it during workflow configuration.
  5. Clear the Edit step details on save checkbox.
  6. Click Save.
  7. Repeat until you’ve created all the steps.
  8. Click into the details for individual steps and change the Next Steps selections. This is necessary if your workflow should branch via a decision step, should merge two paths via a join step, or should include parallel steps.

At this point, your workflow includes an outline of all steps using the Placeholder step type. Later you’ll need to click into each step, select a type (workflow task, notification, etc.), and define details that are specific to the step type.

How to Define the Start Step

The Start step’s primary purpose is to control the dialog that users see when starting the workflow: workflow start dialog. From here, users can enter participant group assignments, task due dates, and new field values for the object record. Which of these options they see will depend on what “controls” you add to the Start step during workflow configuration.

  1. Open the workflow from the Workflows page.
  2. Click into the Start step.
  3. Click Edit.
  4. Click Add Control.
  5. Select a type of control and define type-specific details. Details for each control type are below.
  6. Add as many controls as needed using these steps.
  7. Rearrange the controls by clicking and dragging the upper left corner of each. The order you set is the order that users will see in the workflow start dialog.
  8. Click Save.

You can create a Start Step Rule to define a scenario in which the workflow owner should not see a particular control in the workflow start dialog.

Instructions Control

The Instructions control type lets you enter an explanation or instructions for the workflow owner. For example, provide guidelines for workflow owners on how they should select participants for the workflow. You can use tokens for field values to dynamically add relevant data to the instructions.

Participants Control

The Participants control allows you to create a participant group. All workflows include a single default participant: Workflow Owner. If your workflow needs to assign tasks to any other users, the Start step must include at least one participant control. Every participant group defined this way also appears as a possible recipient for notifications and task reminders. For example, create a participant control labeled Reviewers and assign a review task in the workflow to that participant group.

There are several ways to assign users to a participant group:

Allow workflow owner to select participants
The workflow owner will select users for each participant group when starting the workflow.
With this setting, you can choose to constrain users based on their object record role assignments at the time when the workflow owner starts the workflow. Use the Roles Allowed to Participate (not available for multi-record workflows) and Roles not Allowed to Participate picklists to select user roles to include and/or exclude from the workflow. The workflow owner cannot select users in the roles you select under Roles not Allowed to Participate.
If you select the Default users from sharing settings checkbox, Vault auto-populates role assignments in the start dialog with users and groups currently in those roles in the record sharing settings.
By default, the maximum number of participants that users can assign to any workflow participant control is 5,000. To configure a limit between 1 and 5,000, navigate to Admin > Settings and enable Limit workflow participants. Provide a Max number of participants per participant control. Users will encounter an error if they attempt to assign more participants than the configured limit.
Allow workflow initiator to select participants
The workflow initiator will select users for each participant group when starting the workflow.
With this setting, you can choose to constrain users based on their object record role assignments at the time when the workflow owner starts the workflow. Use the Roles Allowed to Participate picklist to select user roles to include from the workflow. This is available for both single record and multi-record object workflows.
Use roles as participants
Vault will look at the object roles selected under Roles Allowed to Participate and auto-assign any users already in those roles when the workflow starts. Vault automatically excludes roles selected under Roles not Allowed to Participate from the workflow. Users added to valid roles through manual assignment in Sharing Settings receive current workflow tasks and any future tasks associated with the role.
With this setting, Vault does not display the Participant control in the workflow start dialog or when users add participants to active workflows.
See Use Role as Participants for specific behaviors when using this option.
Use custom action to define participants
With this setting, Vault uses the selected custom action to determine participants. These actions are created by your organization with the Vault Java SDK to meet your specific business needs. Talk to your Vault Administrator to learn more about these actions. With this setting, users cannot add participants to active workflows.
If you’re interested in developing custom actions for your organization with the Vault Java SDK, you can learn more on the Developer Portal.

Selecting the Allow task instructions for these participants checkbox allows the workflow owner to provide instructions for each participant selection in the workflow start dialog. Adding instructions is optional by default, but you can make them mandatory by selecting the Required checkbox.

Use Role as Participants

In workflows with the Use Role as Participants option enabled in a Participants control, the behaviors described below determine the tasks which will appear in users’ My Tasks or Available Tasks views:

  • When a workflow encounters a task step, Vault assigns tasks to every user in the selected participant group. This participant group consists of all users and groups in that role on the record included in the workflow.
  • If, after the task has been created and assigned, you add a user to a group that was already part of the participant group, the new user will automatically receive the task assignment.
  • If, after the task has been created and assigned, a new user or group is added to the role on the record included in the workflow, these new users or groups receive the task if they were added to the role on the object record via manual assignment in Sharing Settings or an Update Sharing Settings workflow step. If the new users or groups were added via matching sharing rules, they do not automatically receive the task, and the new user or group must be added as task participants via the Add Participants action.
  • If an available task is accepted by a user or group and, subsequently, a new user or group is added via the Add Participants action, the new user or group can only accept the task once it is released by the previous user or group.

Date Control

The Date control lets you set up a date field that appears in the workflow start dialog. You can later use this date as a workflow task due date. You can also use a formula expression to set this date.

For example, create a date control labeled Review Due Date and place it under a participant control for Reviewer. When setting up the workflow task for reviewing, you can use this date control as the task due date.

You can configure a workflow due date by enabling the Set Workflow Due Date checkbox in the Date control. Once enabled, the workflow owner can enter the workflow’s due date in the start dialog. The workflow owner can also update the workflow due date in the Active Workflows and Timeline views (Actions Menu > Update Workflow Due Date). The Active Workflows home page (Home > Views > Active Workflows) displays indicators notifying users of the status of the workflow’s due date. If a task within the workflow is configured with the workflow due date, any updates to the workflow due date will update the task’s due date.

Prompt for Fields Control

This control inserts fields from the object record and allows the workflow owner to update field values. You can choose to make individual fields required if needed. Using field controls is particularly helpful when the workflow moves the record into a lifecycle state with entry criteria because you can ensure that the workflow owner fills in that information before the state change.

For example, in a Marketing Campaign workflow, create a field control that pulls the Agency Contact field into the workflow start dialog as a required field. Before users can start the workflow on a campaign, they’ll need to enter the agency contact person.

Variable Control

The Variable control allows the workflow owner to set the value for a workflow variable. The workflow configuration can then use the variable value as the basis for branching.

How to Add Variable Controls

Before adding a variable control, you must add a variable to the workflow. This happens from the Workflow Details page, in the Variables section.

To add a variable control:

  1. From within the Start step configuration, click + Add Control.
  2. Select Variable as the control type.
  3. Select a specific variable from the list.
  4. Optional: Select the Required checkbox if the workflow owner must make a selection.
  5. Optional: If you want to prompt for multiple variables, click the + Add variable link and repeat the steps for a second variable. To remove a variable, click the - (minus) icon.

Start Step Rule

Start step rules provide a way to conditionally modify the controls presented in a workflow start dialog. You can prevent the workflow owner from seeing unnecessary controls in the workflow start dialog, or make controls required under certain conditions. To do so, define a rule using Boolean (true/false) expressions as described below. Using this rule, you can hide or make required Participants, Prompt for Fields, or Variable controls.

Rules should only affect controls that are optional in their individual control configuration. Creating rules to hide required controls can lead to workflow errors. For Participants controls, the control is considered optional if all of the tasks in the workflow that the defined participant would take part in are optional.

To create a start step rule:

  1. From within the Start Step Rule section of Start step configuration, click Edit.
  2. Click Create Start Step Rule.
  3. Enter a Rule Label for the start step rule.
  4. Select a rule type from the Select Rule Type drop-down. This selection determines the effect of the rule when the expression returns True.
  5. From the Select Controls drop-down, select the control you want to affect with the rule.
  6. Enter a Boolean (true/false) expression in the If this expression is True box. You can use the Fields, Functions, and Operators tabs to search a list of options.
  7. Click Check Syntax.
  8. If there are no errors, click Save.

Start step rules expressions use Vault standard expression grammar and return true/false. Vault applies the rule’s effects to controls in the workflow start dialog when the expression returns true. Start step rules support all standard field types supported in Vault expression grammar and use the same syntax as formula fields, validation rules, and other expression-based features.

How to Define an Action Step

Action steps define actions that Vault will automatically complete on the object record. For example, an Action step could move the record into a new lifecycle state.

How to Set Up Action Steps

To define an action step:

  1. From the detail page for the workflow, click into a placeholder step.
  2. Set the Type to Action.
  3. Optional: Select Perform with conditions to add conditions to the action rule.
  4. Choose an action type: Change State, Update field, Update related record field, or Remove eSignature from items.
  5. Optional: Create more actions within the same rule by clicking Add action. If the rule is conditional, these actions share the same conditions.
  6. Click Save.

Change State Action

An Action step of the Change State type moves the object record from one lifecycle state to another. For example, when a record first enters a review and approval workflow, it could move to the In Review state. While in this state, workflow participants review and provide verdicts. After the decision step, the record would enter either Approved state or move back to Draft state, depending on the verdicts. This setup would require three (3) change state steps: one following the Start step and two following the Decision step.

To set up a Change State step:

  1. Within an Action step, select the Change State type.
  2. Select the Lifecycle State for the record to move to. If the new state has entry criteria, you should include a Prompt for Fields control on the Start step to populate required fields or use the Prompt for Fields setting on a workflow task that occurs before the state change.
  3. Click Save.

State changes performed within an Action step do not check entry criteria or trigger entry actions when the target state is the same as the existing state.

Update Field Action

An Action step of the Update field type allows you to automatically update fields using a formula. For example, a workflow to approve an object record could include a step to set an expiration date for the approval. You can create multiple update record steps in a single workflow. Formulas can use fields from the current object, an object to which it has an outbound relationship, or both. The formula builder includes a tab for the object referenced by the target field, which you can use to reference specific records in the formula.

To set up an Update field step:

  1. Within an Action step, select the Update field type.
  2. Select a field to update from the Fields drop-down.
  3. Click into the Set to value field. For Text, Long Text, Rich Text, Number, and Date fields, the Edit formula of [Field] dialog opens. For Yes/No and Picklist fields, select the applicable value.
  4. Create the formula.
  5. Click Save.

An Action step with the Update related record field type allows you to automatically update indicated fields on related object records. You can use this option to update Yes/No, Picklist, Number, Date, Text, Long Text, and Rich Text fields. For example, a workflow to add a participant to a study could include a step to automatically update the Status field on the related object Application, to Active. You can create multiple update related record steps in a single workflow. When using formulas to set values, formulas can use fields from the current object, an object to which it has an outbound relationship, or both. The formula builder includes a tab for the object referenced by the target field, which you can use to reference specific records in the formula.

To set up an Update related record field step:

  1. Within an Action step, select the Update related record field type.
  2. Select the object record from the Related Object drop-down.
  3. Choose which field to update from the Fields picklist.
  4. The Set to value field appears as either a picklist or formula field, depending on the field you selected to update. Choose the value or enter the formula that populates the indicated field.
  5. Click Save.

Automatically Remove Matching Items Action

The Automatically remove matching items action allows the workflow to remove records from the object workflow Envelope. For example, an approval workflow could include a step to remove records from an object workflow after they have received a Rejected verdict in a task that supports verdicts for individual records.

To define this action, select Perform with Conditions and specify one or more conditions. The action removes all records in the workflow that match the conditions. Select the Removed Items are moved to the Workflow Cancel State checkbox to change the lifecycle state of removed records to the state defined as the Workflow Cancel State in the object lifecycle.

This action will not remove any records from the object workflow if every record matches the conditions. Accordingly, we recommend configuring a Decision step prior to this to ensure that this action step does not occur if all records would be removed. If this situation occurs, it may be appropriate to cancel the workflow.

Remove eSignature from Items Action

An Action step with the Remove eSignature from items type allows you to automatically remove eSignatures from object records within a workflow. The action removes eSignatures that match the specified conditions, task, and verdicts. For example, you can configure the action to remove electronic signatures for the Approve verdict from a previous task within the workflow if it is later rejected.

To set up a Remove eSignature from items step:

  1. Within an Action step, select the Remove eSignature from items type.
  2. Select the task from the Task drop-down.
  3. Choose which Verdicts the action will apply for. Only eSignatures applied within the current workflow with the specified verdicts will be removed.
  4. Click Save.

Conditional Actions

Action step effects can be conditional. Using conditional actions, you can configure a workflow that will allow different outcomes based on record attributes and task verdicts.

How to Define Conditions

To define a condition:

  1. Set the rule to Perform with conditions.
  2. Select a Condition Type.
  3. Optional: Create additional conditions for a rule by clicking Add condition. A record must meet all of the conditions for a rule in order for Vault to perform the action.

Vault applies all rules in order and per record. Keep this order in mind when defining conditional rules.

Condition Types

  • Task references verdicts from a preceding Task step. For this condition type, you select the workflow step, operator, and verdict label.
  • Field references a field value on the document. For this condition type, you select the document field, operator, and field value.

How to Define a Task Step

A Task workflow step assigns a task to users in a specific participant group. Tasks can be simple (instructions to “Review and confirm”) or complex (verdict to select and fields to populate).

  1. Open the workflow from the Workflows page.
  2. Click into a Placeholder step.
  3. Set the Type to Workflow Task and apply Tags if needed.
  4. Enter a Task Label to identify the task.
  5. In Assign Task To, select Workflow Owner or a participant group. The available participant groups are defined in the workflow Start Step.
  6. Optional: If you selected a participant group, select either Assign to all users in participant group, Make available to all users in participant group, or Allow workflow initiator to select assign to all or make available.
  7. Enter Instructions for the task owner. These appear with the task in the Home tab and object record detail page. You can use tokens to dynamically add relevant data to the instructions.
  8. Select the Task Requirement. If the task is Required, the workflow owner must assign the task to the participant group when starting the workflow. If the task is Optional, the workflow owner may or may not select the participant group when starting the workflow.
  9. Optional: Select Do not allow workflow owner to receive this task. This option makes the task unavailable to the workflow owner even if the workflow owner is part of a group assigned to the task. This option does not appear if you selected Workflow Owner in Assign Task To.
  10. Optional: Select the Complete task without viewing the item checkbox to allow task participants to complete the task directly from the task view on their Home tab.
  11. Optional: Select one or more previous tasks in the workflow in the Display information about previous tasks drop-down to allow task participants to see information such as completion dates and verdicts on the task view on their Home tab.
  12. Optional: Select a Due Date. See due date details.
  13. Optional: Under Update Sharing Settings, define rules to add or remove users in roles to sharing settings based on triggering events in the task. See update sharing settings details below.
  14. Optional: Select Prompt for Comments and enter a label for the comment field. Select Required to indicate that the user cannot continue without adding a comment. This option inserts a text field (500 character limit) in the task completion dialog and allows the task owner to provide a comment.
  15. Optional: Select Prompt for Fields and an object field. This option inserts fields from the object record and allows the task owner to update field values while completing the task. Select Required to indicate that the user cannot continue without filling in the field. Click Add Field if you need additional field prompts.
  16. Optional: Select Prompt for eSignature if users completing this task need to electronically sign.
  17. Optional: Select Prompt for Verdicts. With this setting, the user completing the task must select a verdict. You can also configure verdicts to short circuit workflow tasks.
  18. Optional: Under Notification, select a Notification Template to use when sending an automatic notification to the task owner. You can select Include verdicts and comments from previous tasks and select one or more previous tasks in the Select Tasks field.
  19. Optional: Add Task Reminders. Task reminders allow you to configure notifications to send about open tasks. Learn more below.
  20. Optional: Under Custom Actions, select a custom action to execute on this task step. These actions are created by your organization with the Vault Java SDK to meet your specific business needs. Talk to your Vault Administrator to learn more about these actions. If you are interested in developing a custom action, you can learn more in the Developer Portal.
  21. Optional: Select Complete task asynchronously and then select an Alternate Next Step in the drop-down. See details about this step below.
  22. Click Save.

Short-Circuiting Workflow Tasks

You can short circuit workflow tasks to cut-down on extraneous task completion. When a user selects a verdict you have configured to short circuit, Vault cancels all other workflow tasks with the appropriate tags. For example, if only one user in a group of approvers needs to approve a document, Vault will cancel the approval task for all other users in the group after one of the users approves the document. To set this up:

  1. Apply Tags to the workflow task you want to short circuit under Details.
  2. Select Short-circuit tasks with the configured tags.
  3. Select/create the tags associated with the tasks you want to short circuit.
  4. Click Save.

Task Assignments

Selecting Assign to all users in a participant group will assign the task to every user in the participant group. All users in that group will be required to complete the task. If selecting groups in a participant control, the workflow owner sees an Assigned to every user label.

Selecting Make available to all users in the participant group will offer the task to any user in the participant group. All users in the group will be able to accept the task, but not all users are required to complete the task. If selecting groups in a participant control, the workflow owner sees an Available to any user label.

  • If the same participant control is used in multiple tasks, and it uses different task assignment options in those tasks, then the workflow owner will not see either the Assigned… or Available… label in the start dialog.
  • If the workflow owner is part of an assigned participant group but is restricted from receiving the task, the workflow owner will not receive the task.

Selecting Allow workflow initiator to select assign to all or make available allows the workflow initiator to decide how tasks are assigned to participant groups. This option is available only when a participant group is selected from the Assign Task To drop-down. This option is disabled for selection if Use role as participants is enabled on the participant group. If a different task in the same workflow is assigned to the same participant group with a task assignment of Assign to all users in participant group or Make available to all users in participant group, Vault will ignore the Allow workflow initiator to select assign to all or make available setting and assign the task based on the Admin’s selection.

Task Reminders

Task reminders allow you to configure notifications to send about open tasks. To set up task reminders:

  1. Choose a Notification Template for the reminder. Learn more about notification templates.
  2. Select up to five specific groups as Recipients (including the workflow owner and task owner). If no user has claimed an available task when it is time to send the reminder, all potential task owners receive the reminder.
  3. Choose the Send On date for the reminder. The date to send the reminder is a specified number of days from either the Task Due Date or Task Creation Date. For example, you can remind a user to complete a task one day before the task is due. Task Reminders use the Vault Time Zone.
  4. Optional: Click Add Task Reminder to add another reminder. You can add up to five reminders.
  5. Click Save.

Due Dates

Due dates for tasks can be based on:

  • Date controls on the workflow start step.
  • Date fields on the object; these can be offset by calculating the task due date. Vault will use the field value at the time it creates the task and will not update the due date if the field value changes. This option is not available for multi-record workflows.
  • Task Creation Date or Workflow Start Date; these can be offset by calculating the task due date.
  • Workflow Due Date; the date the entire workflow is due.
  • Formulas; use a formula expression to configure a due date.

Due dates are dates only and do not have time components. Task due status is based on the user’s time zone.

Calculated Task Due Dates

When selecting a workflow task due date, you can configure calculated task due dates. This allows Vault to automatically calculate task due dates without input from the workflow owner. To configure calculated task due dates:

  1. Select Workflow Start Date, Task Creation Date, Due Date (defined on start step), or a Date-type object field from the Due Date drop-down list. If you choose Workflow Start Date or Task Creation Date, the dates are based on the Vault time zone set by the Admin.
  2. Select either + or - as a date offset operator
  3. Select a day value up to 365 days.
  4. Optional: If your Due Date is controlled by a Date-type object field, select the Update active task due date when date field is updated checkbox to update this task’s due date whenever the controlling field is updated. If you select this option, Vault does not allow manual updates to the due date. For example, if your due date is controlled by the Release Date field, selecting this checkbox updates the due date for this task every time the Release Date field updates. When a task due date change occurs this way, Vault audits the change as System and updates the Last Modified field on the task.

Formula Task Due Dates

You can select Formula from the Due Date drop-down to base the due date on a formula expression. The Fields formula expression lists all fields associated with the object type, including related object fields, but is unavailable for multi-document workflows. Only expressions with a Date return type are valid. For more detailed instructions on writing the formula expression, see Creating Formulas in Vault.

Updating Sharing Settings

As part of a Task step, you can configure rules in the Update Sharing Settings section to add or remove the current owner from a role, upon specific events. To add or remove the current task owner from a role:

  1. From within the Task step, navigate to the Update Sharing Settings section.
  2. Click Add rule.
  3. In the Select Event drop-down, select if this rule should trigger upon task assignment, completion, cancelation, or reassignment from another user.
  4. In the Select Operator drop-down, select whether to Add or Remove the current task owner from a role when this event is trigered.
  5. In the Select Roles drop-down, select which roles you want to add to or remove from the current task owner.
  6. Optional: Click Add rule to define additional rules.

When using the Task Reassignment From event action, adding or removing actions affects the user who originally owned the task, not the new task owner.

How to Set Up Verdicts

Verdicts allow a task owner to indicate a recommendation or decision when completing a task. If you wish to make a workflow that branches based on the results of workflow tasks, you’ll need to set up verdicts that the Decision step will later use.

  1. Click Add Verdict to create each verdict.
  2. Enter a Verdict Label which users will see when selecting a verdict.
  3. Optional: Select Short-circuit tasks with the configured tags if you want the verdict to short circuit other workflow tasks.
  4. Optional: Click Add Comments and enter a label for the comment field. Select Required to indicate that the user cannot continue without adding a comment. This option inserts a text field (500 character limit) in the task completion dialog and allows the task owner to provide a comment.
  5. Optional: Select Add Capacities if users selecting this verdict need to provide a capacity. See details below.
  6. Optional: Select Add eSignature if users selecting this verdict need to electronically sign. See details below.
  7. Optional: Click Add Reasons. Enter a Reason Label. Select the Required checkbox to require users to select a reason when they select the specific verdict. Add Reason Values. The label appears on the picklist field and the values appear within the picklist.
  8. Optional: Click Add Field Prompts and an object field. This option inserts fields from the object record and allows the task owner to update field values when selecting the specific verdict. Select Required to indicate that the user cannot continue without filling in the field. Click Add Field if you need additional field prompts.
  9. When you’ve finished setting up all verdicts, click Save.

How to Set Up Capacities

Verdicts can include a Capacity field, which lets the user provide additional context for their task verdict.

  1. Select Add Capacity.
  2. Enter a Capacity Label for the capacity field.
  3. Optional: Select the Required checkbox to require users to select a capacity.

Add Capacity Values. When users complete a task, the capacity label appears with a drop-down that includes these values.

How to Set Up eSignatures

When you add an eSignature prompt to a workflow task or a verdict, users completing the task or selecting the verdict must provide an electronic signature by entering their login credentials. The Signature Type option allows Admins to use a lifecycle state entry action to preserve eSignatures of certain types and make other types obsolete when related object records move to a new state. To learn about eSignature management, see Managing Object eSignatures.

  1. Select Add eSignature.
  2. Optional: Select a Signature Type from the picklist.
  3. Enter Instructions for users.

About Asynchronous Task Completion

The Complete task asynchronously option allows users to complete individual tasks without affecting other workflow tasks or processes. If the workflow encounters an error, it will take the alternate workflow step that you select.

We recommend using this feature for tasks that your organization regularly assigns to over 100 users. Work with your Vault representative before enabling this option. This option is not available for multi-record workflows.

How to Define a Decision Step

A Decision workflow step lets a workflow diverge into separate paths based on verdicts from a previous Task step, field values on the object record, or variable values set by the workflow owner.

When defining rules for branching, start with the most restrictive rule. Vault evaluates the rules in the configured order. The first rule that evaluates to “true” is the path that the workflow takes.

To set up a decision step:

  1. Open the workflow from the Workflows page.
  2. Click into a Placeholder step. If the decision will be based on verdicts, this step must come after a workflow task that includes verdicts.
  3. Change the Type to Decision.
  4. Click Create Rule. You can create a maximum of 30 rules. Vault automatically includes an “Else” rule, which lets you define what happens if the object record doesn’t meet any of the rule criteria.
  5. For each rule, choose to base it on a Field, Task, or Variable. If the rule is field-based, select an object field, an operator, and a field value. If the rule is verdict-based, select a specific workflow task, an operator, and verdict labels. If the rule is variable-based, select a variable, an operator, and a variable value. After then, choose the next step for the workflow to go to if the object record matches the rule.
  6. Define the Else rule. Vault automatically includes this rule, which lets you specify what happens if the object record doesn’t meet any of the rule criteria.

How to Define a Join Step

The Join workflow step lets you merge two separate paths within a workflow. You’ll use this step in workflows that branch or contain parallel steps. For example, a Review & Approve workflow branches based on workflow task verdicts, so an object record moves into Approved state or back to Draft state. After the state change steps, you’d join the branches so that you can set up a single notification step informing the workflow owner that the process is complete.

To set up a join step:

  1. Open the workflow from the Workflows page.
  2. Click into a Placeholder step.
  3. Change the Type to Join.
  4. Click Save.
  5. If your workflow outline isn’t complete, edit the preceding steps to point to the join as their next step.

How to Define an Update Sharing Settings Step

The Update Sharing Settings step allows you to add or remove workflow participants to or from specific roles in Sharing Settings. For example, a workflow to approve an object record may require an additional review from a user that isn’t normally assigned to the Reviewer role. You can use this step to add the workflow participant to the Reviewer role for this particular instance. Once the participant completes her task, you can configure another step to remove her from the Reviewer role.

To set up an update sharing settings step:

  1. Open a workflow from the Workflows page.
  2. Create a Placeholder step.
  3. Change the Type to Update Sharing Settings
  4. Select the workflow participant(s) from the Workflow Participants picklist.
  5. In the Action field, use the radio buttons to Add or Remove participants.
  6. Select the applicable role(s) from the Roles picklist.
  7. Click Save.

You can also update sharing settings in a task step.

How to Define a Notification Step

Notification steps allow you to send email and in-Vault messages to workflow participants at various points during the workflow. For example, you could send a notification to workflow owners as the final step, so they know the workflow is complete. You could also send notifications to reviewers after a decision step, letting them know what the final decision was, based on their verdicts.

You don’t need to set up separate notification steps to alert task owners that they have a task. There’s a setting within the workflow task step to include a notification.

To set up a notification step:

  1. Open the workflow from the Workflows page.
  2. Click into a Placeholder step.
  3. Change the Type to Notification.
  4. Select a Message Template. You can set these up beforehand from Admin > Configuration > Object Messages.
  5. Select a Recipient. Your options include the Workflow Owner, any participant group you defined in the start step, or a role in the object record’s sharing settings.
  6. Optional: Select the Include verdicts and comments from previous tasks checkbox and select one or more previous tasks in the Select Tasks field.
  7. Click Save.

How to Define a System Action Step

While most system actions are specific to Clinical Operations or RIM application vaults, the Check Participant Access to Related Documents system action is available for all Vaults. See configuration details below.

Custom system actions may also be created using Vault Java SDK record actions. Once the code is uploaded to Vault, select it from the dropdown list. Learn more about Record Actions in the Developer Portal.

Configuring the Check Participant Access Step

Check Participant Access to Related Documents is a type of system action in object workflow within all application and platform Vaults. To configure it:

  1. Add a System Action step to the workflow. We recommend adding this step before any workflow tasks assigned to users who may lack necessary permissions on related documents.
  2. Select Check Participant Access to Related Documents in the System Action drop-down.
  3. Select the Participant Group for which Vault should check access to documents.
  4. Select the Application Role to Check Membership In. Vault will verify that all users in the selected participant group are members of at least one of these application roles for every related document. You can choose multiple application roles if needed.
  5. Select the Document Relationship to evaluate. You can select multiple relationships if needed.

Configuring the Participant Access Decision Step

You can select the Participant Access Check Results workflow variable in a decision step as a way to capture and track whether or not users have access to related documents. To configure this:

  1. Add a Decision step to the workflow. This step should immediately follow the Check Participant Access system action step.
  2. In the Rules section, select the Variable condition type in the first drop-down.
  3. Select the Participant Access Check Results variable in the second drop-down. This variable only supports Is blank and Is not blank operators.

If any user lacks access to one or more documents, Vault populates the workflow variable with the value is not blank. If the workflow variable is blank, all users have necessary access to all related documents. In some cases, is blank could also mean that the workflow configuration is incorrect.

Defining a Notification Template

You can use a Check Participant Access object notification template in your workflow to send notifications informing the workflow owner of which users lack access to which documents during a workflow. The token in this template references the Participant Access Check Results workflow variable.

Notifications include a list of users not assigned to the specified application roles, and the documents to which they lack access, including document number and version. The notification will indicate exact issues for up to thirty results. After that number, additional issues will be reported upon subsequent Participant Access Check workflow actions after the first thirty have been resolved. The notification does not specify the total number of issues encountered.

How to Define an End Workflow Step

By default, all new workflows include an End step, but you can create a new one if you accidentally delete the default step. The End step is a way for Vault to know that no further steps are coming and to close out an in-progress workflow.

Workflows can include multiple End steps if necessary. For example, if a workflow includes a Decision step, each decision can lead to a separate End step.

Start Next Workflow

Depending on your processes, it may be useful to allow a workflow participant to start another workflow for the same object record upon workflow completion. In the End step configuration, select Display start next workflow dialog when workflow ends to allow the user who completes the final task in the workflow to start another workflow immediately via the Start Next Workflow dialog. To see the dialog, the user must have Start permissions for workflows. This dialog is not available for multi-record workflows.

Variables

When configuring a workflow, you can include variables that you then use when evaluating decision steps in order to create branching workflows. The workflow owner sets values for these variables when starting the workflow. With workflow variables and decision steps, Vault can support small variations in a workflow process without needing to configure multiple workflows. For example, your organization may have a single review workflow, but include additional tasks in some situations.

How to Define Variables

To define a workflow variable:

  1. Navigate to the Workflow Details page and down to the Variables section.
  2. Click Add Variable and select a data type (Yes/No, Picklist, Text).
  3. Enter a Label for the variable. The workflow owner sees this when starting the workflow.
  4. For the picklist data type, enter picklist options.
  5. Click Save.

Example Usage

To define a workflow that asks the workflow owner whether secondary approval is required for the object record, and then branches to that step if so, you’d do the following:

  • Define the Secondary Approval variable for the workflow using the Yes/No data type.
  • Add a variable control to the Start step that references the Secondary Approval variable.
  • Create a Decision step in which rules send the workflow to the Approval 2 task step if Secondary Approval is set to Yes and skip that step if Secondary Approval is set to No.

Limits

  • Each workflow can include up to 25 variables.

Cancelation Actions

By default, when a user cancels a workflow, Vault deletes all outstanding tasks, notifies all participants, and reverts workflow content to the appropriate state. If you want to add additional cancelation behavior, configure actions in the Cancellation Actions section of the Workflow Details page:

  1. From the Cancellation Actions section of the Workflow Details page, click Edit.
  2. Click Create Rule.
  3. Optional: Select Perform with conditions to add conditions to the action.
  4. From the drop-down, select an action. The Send a notification action sends a notification using a message template. The Update Record field action updates a field according to a formula expression. The Remove eSignature from Record action removes all eSignatures applied to object records in the workflow. You may also see other actions listed here which were created by your organization with the Vault Java SDK to meet your specific business needs. Talk to your Vault Administrator to learn more about these actions.
  5. If you selected the Send a notification action, select a message configuration from the Message Template drop-down, and select the appropriate participants or roles from the Recipients drop-down.
  6. If you selected the Update Record field action, you can configure the update just as in an action step.
  7. Optional: Click Add Action to add additional cancelation behavior.
  8. Click Save.

How to Validate & Activate Workflows

When you’ve finished defining steps, you’ll need to make the workflow active.

  1. Click into the workflow from the Workflows page.
  2. Click Make configuration active.
  3. Vault validates the workflow and notifies you if it is not valid. If there are validation errors, fix your workflow and try again.

After activating the workflow, you’ll need to create a user action on specific lifecycle states to allow users to start the workflow. In the Start States field on the workflow details page, Vault displays all lifecycle states in which the current workflow can start.

How to Define Formula System Variables

You can use two formula system variables in areas of an active workflow that ask for a formula expression, such as task due dates, cancelation actions, and Action steps. @WorkflowOwner and @TaskOwner return data for the workflow owner and task assignee respectively, and allow you to calculate working days based on the user’s locale. These formula system variables provide access to user profile data, similar to the @User system variable. However, they are only valid in the context of active workflows.

For example, to define a task due date five (5) working days from today excluding the local holiday schedule of each task assignee:

  • Workday(Today(),5, 1, @TaskOwner.locale__sys

To define a workflow due date three (3) days from today excluding the holiday schedule of the workflow initiator:

  • Workday(Today(),3, 1, @WorkflowOwner.holiday_schedule__sys)

Object Record Sharing

If you have enabled Dynamic Access Control on an object, Vault does not check that the users assigned through a participant control have access to a specific object record. It is possible for a user to start a workflow with task assignments that the task owners cannot complete. When configuring workflows, keep this limitation in mind.

Workflow Versioning

If a workflow is active and there’s a user action making it available to users, editing the workflow doesn’t edit the “live” workflow. When you start editing, Vault automatically updates the workflow status to Editing. While the workflow is in this status, users can still start a workflow instance on an object record. That workflow instance uses the configuration as it was before the workflow entered Editing status. Once you’ve re-validated the workflow and changed its status to Active, the new configuration becomes the “live” version. However, workflow instances that started while you were editing the workflow will still use the previous version.

Sometimes, you may need to check whether a specific workflow instance used the previous workflow configuration or the new configuration. You can find this by checking the object’s workflow timeline view or active workflow home page for the workflow version and comparing it to the workflow version in the admin configuration page.