Document workflows allow users to send one or more documents out for a wide variety of processes, such as review and approval, with up to 100 documents on a single workflow instance. Document workflows use object workflow functionality via the raw Envelope object. Within an individual workflow instance, there is one (1) Envelope object record and one or more related documents. End users do not directly interact with the Envelope object.

About Document Workflows

Within a document workflow, you can create tasks and actions that affect the “envelope contents.” Envelope contents are the documents associated with the workflow. You can configure document workflows to apply to documents in any document lifecycle or only a specific lifecycle.

About Envelope & Envelope Content Object Record Access

Access to Envelope and Envelope Content object records should be carefully controlled. Because the objects are raw 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 document is in an active workflow, clicking on the record link may take the user to the document workflow viewer, even if the user is not a participant of that specific workflow. A user’s ability to view the documents in the Envelope is still determined by the document’s sharing settings.

About Document Lifecycles

Document workflows have two options for interacting with document lifecycles:

  • A document workflow can apply to any lifecycle. This means that the workflow envelope can include documents from a single lifecycle, two different lifecycles, or from every lifecycle in your Vault. However, the options available for this type of workflow are constrained. For the workflow to be valid across lifecycles, it can only access configuration elements (document fields, etc.) that apply to all documents.
  • A document workflow can apply to a specific document lifecycle. This means that it’s only available to documents in that lifecycle. Because the workflow only works on documents in a single lifecycle, you can access any fields defined for document types associated with that lifecycle. The workflow can also use specific lifecycle states, rather than state types.

This table compares the document workflow options:

  Any Lifecycle Specific Lifecycle
Use workflow for single document No equivalent option Restricts the workflow to apply to a single document only and allows users to select document notification templates in step configuration
Prompt for Fields in Start step Can only access document fields defined at Base Document Can access document fields available to any document types that use the selected lifecycle
Prompt for Fields in Task step Can only access document fields defined at Base Document Can access document fields available to any document types that use the selected lifecycle
Automatically remove matching documents in Action step Allows conditions based on lifecycle state type Lifecycle state type is not allowed as a condition
Update document field in Action step Can only access document fields defined at Base Document Can access document fields available to any document types that use the selected lifecycle
Roles allowed to participate setting in Participants Control Uses application roles to map to document lifecycle roles Uses document lifecycle roles
Enable allowed group in this Dynamic Access Control Role in Participants Control No equivalent option Allows workflow owner to select users or groups from allowed group DAC roles in addition to other eligible users
Update Sharing Settings step Uses application roles to map to document lifecycle roles Uses document lifecycle roles
Do not prompt for verdict on documents in state type setting for verdict prompt in Task step Allows workflow skip verdict prompt based on State Type No equivalent option
Lifecycle condition type on Action step Allows Action to be conditional based on state type No equivalent option
Change state of documents action in Action step Uses state type to map to document lifecycle state Uses document lifecycle state
Lifecycle rule type in Decision step Includes Lifecycle > State Type condition No equivalent option
Read & Understood workflow class No equivalent option Allows the R&U Workflow Task step type and disallows some other step types
Start States display in workflow details page Start States are not displayed In the Start States field, Vault displays all lifecycle states in which the current workflow can start
Role not allowed to complete tasks Can select only application roles Can select roles configured on the document’s lifecycle

How to Create Document Workflows

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

Creating a New Document Workflow

To create a new document workflow:

  1. From Admin > Configuration > Workflows, click Create.
  2. From the drop-down list, select Document Workflow.
  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 a Document Lifecycle or select Any document lifecycle to create a workflow that applies to all lifecycles. Note that this selection is not editable after you save. See Document Lifecycles to understand how this selection affects other options.
  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: Select the Use workflow for single document checkbox to restrict the workflow to allow only a single document. This option displays only if you select a specific document lifecycle. With this option enabled, the workflow will not appear in bulk action menus such as Cart, Library, Favorites, or Recent Documents. Additionally, if you enable this option, you can select a Document Notification Template when you define a notification or notification step within a document workflow task, a task reminder, or a cancelation action.
  9. Optional: Select the Create Draft maintains current version checkbox to allow the Create Draft action to increment the document’s minor version while the active workflow remains on the previous major document version.
  10. Optional: Select the Workflow cancellation comment checkbox to require users who cancel the workflow to provide a comment.
  11. Optional: Select the Allow auto-start from entry action checkbox to automatically initiate this workflow when a document record enters a specific lifecycle state.
  12. Optional: Select Users in this workflow can only complete one task to prevent an individual participant from completing multiple tasks in the workflow.
  13. Optional: Select a role to exclude from tasks in the workflow from the Role not allowed to complete tasks drop-down. You can select any role configured on the document’s lifecycle or, if the document’s lifecycle is set to Any Lifecycle, only the application roles.
  14. Optional: Select an option from the Actions not allowed for the Workflow Owner picklist. You can select multiple workflow and task actions.
  15. Optional: Select an option from the Actions not allowed for all users except the Task Owner picklist. You can select multiple task actions.
  16. Select an option from the Actions not allowed for all users picklist. You can select multiple task actions.
  17. If you selected a specific document lifecycle, you can select a Class for the workflow. Either leave this field blank or select Read & Understood. See more details below.
  18. Click Save.

After you save the new workflow, you can configure it:

  1. In the Workflow Steps section, plan the workflow path using Placeholder steps.
  2. Optional: Create message templates for any notifications or task reminders that your workflow sends.
  3. For Any Lifecycle workflows: Define state types for each document lifecycle in your Vault.
  4. For Any Lifecycle workflows: Check that document lifecycle roles have been mapped to application roles.
  5. Return to the workflow and set up the workflow steps, beginning with the Start step. In the Start step, define user controls for any later tasks and notifications. The sections below describe how to configure document workflow steps.
  6. Optional: Add variables to the workflow from the Workflow Details page. Variables support decision steps and branching workflows.
  7. Optional: Add Cancellation Actions to the workflow from the Workflow Details page.
  8. When you finish configuring the workflow, activate it. See details about this step below.
  9. For Specific Lifecycle workflows: Add a Workflow user action to each document lifecycle state where you want the workflow to be available. When you define the user actions, you can also configure them to only be available when the document contains certain field values.

Copying an Existing Document Workflow

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

To copy an existing document 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 step changes to or copies of previous workflow versions. If a previous version has steps containing deleted items, such as deleted fields or lifecycle states, then the history shows those steps as errors.

Read & Understood Workflows

Read & Understood (R&U) workflows are a special class of workflow that allows users to assign one or more documents or binders to specific users for review. See details about configuring Read & Understood workflows.

Configuring Active Workflow Action Security

The document 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. You can revoke the ability for the workflow owner to cancel the active workflow or allow task owners to cancel their own tasks they are assigned, but restrict them from canceling anyone else’s task. For example, if your users accidentally cancel tasks not assigned to them, you can prevent this error by selecting Cancel Tasks under Actions not allowed for all users except the Task Owner.

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 and task 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 from all participants:

  • 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 Define the Start Step

The Start step controls the dialog that users see when starting the workflow. From here, you can enter workflow instructions, create user controls where workflow owners will select workflow participants, and set up date fields.

To define the start step:

  1. From Admin > Configuration > Workflows > [Workflow].
  2. Click into the Start step and click Edit.
  3. Click Add Control.
  4. Select a control type from the drop-down, and define type-specific. Details for each control type are below. You can add as many controls as needed using these steps.
  5. 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.
  6. 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.

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 Document Fields, Instructions 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 new 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’s standard expression grammar and return true/false. Vault applies the rule’s effect to controls in the workflow start dialog when the expression returns true. The rule expression must return true for every document in the workflow for the rule to take effect. 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. If the same control is affected by rules which both hide and require it, the required-type rule takes precedence.

Control Types

With document workflows, you can configure Instructions, Participants, Date, and Prompt for Document Fields controls. When workflow owners start workflows, they see instructions and options based on the controls you created. If the owner needs to select users to review documents, you should create a Participants control. If the owner needs to choose a workflow due date, you should create a Date control.

Instructions Control

The Instructions control type lets you enter an explanation or instructions for the workflow owner. For example, instruct owners to add approvers in an approval workflow.

You can include tokens for document name ${docName} and document number ${docNumber} in your instructions. The tokens will only resolve if the workflow has a single document.

Date Control

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

You can also set a workflow due date for the entire workflow by enabling the Set Workflow Due Date checkbox. 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 upcoming or overdue 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.

Participants Control

The Participants control allows you to create participant groups to assign users to tasks. For example, create an Approver participant control. Later, you can assign a task to that participant group.

To define a participant control:

  1. Select a Participant Label. This label will appear to the owner when starting the workflow, to users viewing workflow progress, and to users reviewing the workflow after completion. Use a label that aligns with your organization’s terminology.
  2. Select Allow workflow initiator to select participants to display the participant control in the workflow start dialog or Use role as participants to auto-assign participants based on roles on the document.
  3. Optional: If you selected Allow workflow initiator to select participants, select specific roles to define the list of valid users in Roles allowed to participate. On the start dialog, the owner can only select a user if that user is allowed in one of the defined active roles on each document in the envelope.
  4. Optional: If you selected Allow workflow initiator to select participants, select the Allow task instructions for these participants checkbox to allow 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.
  5. Optional: If you selected Allow workflow initiator to select participants, select the Default users from sharing settings checkbox to auto-populate role assignments in the start dialog with users and groups currently in those roles in the document sharing settings. Users and groups must be in those roles in each document of the workflow.
  6. Optional: If you selected Allow workflow initiator to select participants, select the Display users and groups allowed in role checkbox to display allowed groups in the participant selection in addition to other eligible users.
  7. If you selected the Use role as participants checkbox to populate participants based on document role, you must select a role under Roles allowed to participate. Vault auto-assigns any users already in these roles on the document when the workflow starts. With this setting, Vault does not display the participant control in the workflow start dialog or when users add participants to active workflows.
  8. If you selected Use custom action to define participants, select a custom action from the picklist. 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 in the Developer Portal.

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.

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 every document 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 assigned, a new user or group is added to the role on every document included in the workflow, these new users or groups do not automatically receive the task. 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.

Prompt for Document Fields Control

The Prompt for Document Fields control allows you to prompt the workflow owner to fill out document fields. Vault will populate the field values across all documents in the workflow envelope.

How to Add Document Field Prompts

To add a document field prompt:

  1. Select a Field. Only fields from valid document types are available.
  2. Select the Required checkbox if the workflow owner cannot proceed without setting a value for the field. If the field already has a value, the owner does not have to modify the value.
  3. Optional: Click Add field to select an additional field.
  4. Optional: Click the - (minus) icon to remove the field.

Valid Fields

The following field types are valid:

  • Text
  • Number
  • Picklist
  • Date
  • DateTime
  • Yes/No
  • URL
  • Object

Object reference fields used in field prompts respect reference constraints.

We recommend not including certain fields (or not setting them as required) because this can result in workflows that task owners cannot complete:

  • Fields that Vault requires to be unique.
  • Fields with configured field-level security, which may prevent task owners from editing the field.

Document workflows do not support document field dependencies.

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 drop-down 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 Document Fields, Instructions 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 new 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’s standard expression grammar and return true/false. Vault applies the rule’s effect to controls in the workflow start dialog when the expression returns true. The rule expression must return true for every document in the workflow for the rule to take effect. 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. If the same control is affected by rules which both hide and require it, the required-type rule takes precedence.

How to Define a Task Step

Task steps assign a task to users in a specific participant group. Tasks can include instructions, verdict prompts, and eSignatures.

To define a document task step:

  1. From the detail page for the workflow, click into a placeholder step.
  2. Set the Type to Task.
  3. Enter a Task Label to identify the task.
  4. Add Tags if necessary.
  5. In Assign Task To, select Workflow Owner or a participant group. Each participant group is defined in the Start step as a Participants Control.
  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 in the Show more portion of the workflow heading within the document viewer. You can include tokens for document name ${docName} and document number ${docNumber} in your instructions if the workflow contains only a single document.
  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. Note that 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.
  13. Optional: Under Update Sharing Settings, create rules to update roles under certain conditions.
  14. Optional: Select Prompt for Fields. With this setting, the task owner can fill in document field values. See details for document field prompts.
  15. Optional: Select Prompt for Verdicts. See Configuring Verdicts below for more information.
  16. Optional: Under Notification, select a Notification Template to use when sending an automatic notification to the task owner. Only object message notification templates are available for selection on multi-document workflows. You can select Include verdicts from previous tasks and select one or more previous tasks in the Select Tasks field.
  17. Optional: Add Task Reminders. Task reminders allow you to configure notifications to send about open tasks.
  18. 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.

Updating Sharing Settings in Task Steps

You can configure rules in the Update Sharing Settings section of the task step to automatically manage Sharing Settings during a task step. Vault applies the sharing setting changes to the documents included in the workflow. To define sharing settings update rules:

  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 the triggering event of the task step. You can choose to trigger the sharing settings change at task assignment, completion, cancelation, or reassignment from another user.
  4. In the Select Operator drop-down, select whether to Add or Remove the role assignment upon the triggering event.
  5. In the Select Roles drop-down, select one or more roles affected by the rule. Note that each triggering event can only affect a role once, preventing conflicting rule definitions. You can only select active roles.
  6. Optional: Click Add rule to define additional rules.

Note that the Task Reassignment From event option updates the sharing settings of the user from which the task was reassigned, rather than the current task owner.

Configuring Verdicts

When configuring a document workflow, you have the option to prompt users to select either a single verdict or multiple verdicts. Select Single Verdict to require a single verdict that applies to all documents in the workflow. The selected verdict and any associated signatures will cascade to the content documents.

Select Multiple Verdicts to require a separate verdict for each document in the workflow. For document workflows configured for any lifecycle, you can choose to require verdicts on all documents in the workflow, for a specific document type, or for all documents that do not have a specific document type.

Due Dates

You can base task due dates on the following:

  • Date Controls on the workflow Start step
  • Task Creation Date
  • Workflow Start Date
  • Workflow Due Date
  • Document Date Field
  • Formulas

If you select one of these, excluding Formulas, you can configure an offset, for example, four (4) days after the workflow Start Date. Due dates are dates only and do not have time components. Users see the task status, such as overdue or due soon, based on the date in their own time zone.

Document date fields are available for selection only on single-document workflows associated with a lifecycle. 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.

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 document field from the Due Date drop-down list.
  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 document date 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.

If the task due date is calculated from the Workflow Start Date or Task Creation Date, the times are based on the Vault time zone set by the Admin.

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 document 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.

Document Fields

The Prompt for Document Fields setting allows the workflow to display editable document fields and prompt the task owner to fill those fields when completing the task. Vault will populate the field value across all documents in the workflow envelope. This option does not allow task owners to select different values for different documents: the same value will populate for all documents.

Valid Fields

The following field types are valid:

  • Text
  • Number
  • Picklist
  • Date
  • DateTime
  • Yes/No
  • URL
  • Object

Object reference fields used in field prompts respect reference constraints.

We recommend not including certain fields (or not setting them as required) because this can result in workflows that task owners cannot complete:

  • Fields that Vault requires to be unique
  • Fields with configured field-level security, which may prevent task owners from editing the field

Note that document workflows don’t support document field dependencies.

Verdicts

Verdicts allow a task owner to indicate a result when completing a workflow task. Within a document workflow, task owners assign verdicts individually for each document.

How to Set Up Verdicts

To add verdicts to a workflow task:

  1. Click Add Verdict to create each verdict.
  2. Enter a Verdict Label, which the task owner will see when selecting a verdict. This label also appears within workflow details.
  3. Optional: Select Short-circuit tasks with the configured tags if you want the verdict to short-circuit other workflow tasks.

Short-Circuiting Workflow Tasks

You can short-circuit workflow tasks to reduce unnecessary task completion. When a user selects a verdict you have configured to short-circuit, Vault cancels all other workflow tasks with the indicated tags. For example, if only one user in a group of approvers needs to approve a document, Vault cancels 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. If the task has multiple verdicts, select Every Document has this verdict if you want to trigger the short-circuit when every document in the workflow has the verdict, or select At least one document has this verdict if you want to trigger the short-circuit when any document in the workflow has the verdict.
  4. Select or create the tags associated with the tasks you want to short-circuit.
  5. Click Save.

You can add short-circuiting task options to multi-document workflows that are available to either any lifecycle or to specific lifecycles.

Optional Verdict Settings

  • For each verdict, click Add Comments to prompt the task owner to enter comments. Enter a label for the prompt, for example, “Explanation for verdict.” Select the Required checkbox to require the task owner to enter comments before they can complete the task.
  • For each verdict, click Add Capacities if task owners selecting this verdict need to provide a capacity.
  • For each verdict, click Add eSignature if task owners selecting this verdict need to provide an eSignature. The Manifest eSig on Documents option captures signatures from every user completing the task on a signature page attached to downloaded documents. Deselect the Manifest eSig on Documents checkbox if you do not want the signature page to be attached to downloaded documents. This option can differ between multiple verdicts so that only the signatures for verdicts with Manifest eSig on Documents enabled are manifested on the downloaded document.
  • For each verdict, click Add Reasons to prompt the task owner to select a reason for their verdict. Select the Required checkbox to require the task owner to select a reason before they can complete the task. Enter a label for the prompt, for example, “Reason for verdict.” Enter each Reason Value, which the task owner will see when selecting a reason.
  • For each verdict, click Add Field Prompts and select one or more document fields. This option adds object record fields to the verdict dialog and allows the task owner to update field values when selecting this specific verdict. Select Required to indicate that the user cannot continue without filling in the field. Click Add Field to add additional field prompts.
  • Select Prompt for Verdict only on documents in document type and select one or more document types, subtypes, or classifications. With this setting, the workflow will only prompt task owners for a verdict on documents of a specific document type. This option is only available for document workflows configured for any lifecycle.

Capacities

When you configure a verdict to require a capacity, task owners must provide a capacity to provide additional context for their task verdict.

How to Add a Capacity

To add a capacity to a verdict:

  1. Click Add Capacity.
  2. Enter a Capacity Label for the capacity field.
  3. Optional: Select the Required checkbox to make the capacity selection required.
  4. Add Capacity Values. When users complete a task, the capacity label appears with a drop-down that includes these values. For multi-verdict configurations, the capacity values in each verdict must be the same.

eSignatures

When you configure a verdict to require an eSignature, task owners must provide an electronic signature by entering their login credentials.

How to Add an eSignature

To add an eSignature to a verdict:

  1. Click Add eSignature.
  2. Enter Instructions for users.

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 Vault to automatically send notifications to task owners with open tasks. Task reminders run daily based on the Task Reminder Notification job. By default, the job owner is System, meaning that no user will receive an email if the job fails. If you would like a user to receive an email if the job fails, update the Job Owner in Admin > Operations > Job Definitions. Task Reminders use the Vault Time Zone.

How to Set Up Task Reminders

To set up task reminders:

  1. Choose a Message Template for the reminder. Only object message templates are available for selection on multi-document workflows. Learn more about message templates.
  2. Select up to five Recipients. These can be Task Owner, Workflow Owner, or any of the configured participant groups. For the Task Owner recipient on an available task that no user has yet accepted, Vault will notify all available task owners.
  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 users to complete a task one day before the task is due.
  4. Optional: Click Add Task Reminder to add another reminder. You can add up to five reminders.
  5. Click Save.

Recipients

You can choose a few options when selecting recipients for workflow task reminders:

  • Task Owner: Sends a notification to users that currently have an assigned task.
  • Workflow Owner: Sends a notification to workflow owners, even if they don’t have an assigned task.
  • Specific Role: Sends to all users in the specified role (such as Trainee, Editor, Viewer) even if they do not have an assigned task.

Task reminders run daily based on the Task Reminder Notification job. By default, the job owner is System, meaning that no user will receive an email if the job fails. If you would like a user to receive an email if the job fails, update the Job Owner in Admin > Operations > Job Definitions.

Action Step

Action steps define actions that Vault will automatically complete on documents within the workflow envelope. For example, an action could move all documents into a new lifecycle state.

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, Automatically remove matching items, 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

The Change state action moves documents into a new lifecycle state. To define this action, choose a new lifecycle state or lifecycle state type. 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

The Update document field action allows the workflow to automatically update fields using a formula. Vault will populate the field value (static or calculated) across all documents in the workflow envelope. For example, an approval workflow could include a step to set an expiration date for the content by adding 180 days to the Approval Date.

Valid Fields

The following field types are valid:

  • Text
  • Long Text
  • Rich Text
  • Number
  • Date
  • Picklist
  • Yes/No
  • URL

Automatically Remove Matching Items Action

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

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

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

Remove eSignature from Items Action

The Remove eSignature from items action allows the workflow to remove eSignatures from documents for specific tasks and verdicts. For example, an approval workflow could include a step to remove an eSignature in the event that an incorrect user approved the document.

To define this action, select Always or Perform with Conditions and specify one or more conditions, then specify the Task and Verdicts. The action removes signatures from documents in the workflow that match the specified conditions, task, and verdicts.

If a document is up-versioned during the workflow, the action only removes the signatures on the latest version.

Conditional Actions

Action step effects can also be conditional. Using conditional actions, you can configure a workflow that will allow different outcomes on individual documents. Note that decision steps allow you to branch a workflow, but decision steps look at the complete set of documents, not individual documents. Only action steps can act on individual documents within the workflow envelope.

For example, an approval workflow includes a task that prompts for verdicts: Approved without edits or Requires changes. The Admin creates an action step with conditional rules. When Vault applies rules, it does so for each document in the envelope individually.

  • For each document, if all verdicts from the Review task have the verdict Approved without edits, move the document into Approved state. This rule could also set the Approval Date field to the current date.
  • For each document, if any verdicts from the Review task have the verdict Requires changes, move the document back into Draft state.

Vault puts each document through the full set of rules before moving on to the next document in the workflow envelope. In this way, individual documents can have different outcomes, for example, with one moving into Approved state and another into Draft state. However, the action does not branch the workflow. There is no way to branch the workflow itself that allows some documents to follow one path while other documents follow a different path. See Decision Step for more information.

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 document must meet all of the conditions for a rule in order for Vault to perform the action.

Condition Types

  • Task references verdicts from a preceding Document 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.
  • Lifecycle references the document’s lifecycle state. For this condition, you select State Type, operator, and state type value. This option is not available for specific-lifecycle 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.

Decision Step

Decision steps let a workflow diverge onto separate paths based on conditions. When evaluating document conditions for a decision step, Vault looks at the envelope documents as a whole, not at individual documents. Decision step conditions can also use a workflow variable. When branching a workflow, all documents in the workflow envelope follow a single branch. Individual documents cannot follow the branches separately.

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 the workflow takes.

To set up a decision step:

  1. From the detail page for the workflow, click into a placeholder step. If the decision will reference verdicts, this step must come after the task step where the workflow gathers verdicts.
  2. Set the Type to Decision.
  3. Click Create Rule to set up a new rule.
  4. Select a Rule Type.
  5. Define the Else rule. Vault automatically includes this rule, which lets you specify what happens if the workflow envelope documents do not meet any of the rule criteria.

Rule Types

  • Variable references the variable value set by a workflow owner in the workflow start step. For this condition type, you select the variable label and the variable value.
  • Task references verdicts from a preceding task step. For this condition type, you select the workflow step, operator, and verdict label. Remember that decision steps look at all documents in the workflow envelope as a whole, not at individual documents.
  • Lifecycle references the documents’ lifecycle states. For this condition, you select State Type, operator, and state type value. This option is not available for specific-lifecycle workflows.

How to Define a Join Step

The Join workflow step lets you merge two separate paths within a workflow. Use this step in workflows that branch or contain parallel steps.

  1. From the detail page for the workflow, click into a placeholder step.
  2. Change the Type to Join.
  3. Click Save.
  4. 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 edits the Sharing Settings for envelope documents by adding workflow participants to a specific role or removing participants from a role. For example, a workflow to approve documents may require an additional review from a user that isn’t normally assigned to the Reviewer role. This step adds the workflow participant to the Reviewer role before assigning the task. Once the task is complete, another step removes the user from the Reviewer role.

To set up an update sharing settings step:

  1. From the detail page for the workflow, click into a placeholder step.
  2. Change the Type to Update Sharing Settings.
  3. Select the workflow participant group from the Workflow Participants picklist.
  4. In the Action field, use the radio buttons to Add or Remove participants.
  5. Select from the Roles picklist. Note that you can only select active roles.
  6. Click Save.

Note that you can also update sharing settings based on task events in a task step.

How to Define a Notification Step

Notification steps allow you to send emails and Vault notifications to workflow participants at various points during the workflow. For example, the workflow could notify the workflow owner as its final step, closing the loop with the user who started the workflow.

To set up a notification step:

  1. From the detail page for the workflow, click into a placeholder step.
  2. Change the Type to Notification.
  3. Select a Message Template. See below for details.
  4. Select a Recipient. Your options include the workflow owner, any participant groups you defined in the start step, or an active document role. If you select a document role, note that the user will receive the notification only if they are in the role on every document included in the workflow.
  5. Optional: Select the Include verdicts from previous tasks checkbox and select one or more previous tasks in the Select Tasks field.
  6. Click Save.

Notification Message Templates

Multi-document workflows use object messages (related to the Envelope object) while single document workflows use document messages. This behavior applies to the notification step as well as task actions, such as task assignment, reassignment, and reminders. You can set up notification message templates in Admin > Configuration > Notification Templates and create an object or document message. To include the name of the target workflow or the workflow contents in the subject of the notification, use the non-linking version of those tokens, ${workflowTargetNoLink} and ${workflowContentsNoLink} respectively.

To send document messages within workflows, we recommend using entry actions on document lifecycle states.

How to Define an End Workflow Step

By default, all 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 documents 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.

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 click Edit.
  2. Scroll down to the Variables section.
  3. Click Add Variable and select a data type (Text, Yes/No, Picklist).
  4. Enter a Label for the variable. The workflow owner sees this when starting the workflow.
  5. For the picklist data type, enter picklist options.
  6. Click Save.

Example Usage

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

  • Define the Requires Training variable for the workflow using the Yes/No data type.
  • Add a variable control to the Start step that references the Requires Training variable.
  • Create a Decision step in which rules send the workflow to the Training task step if Requires Training is set to Yes and skip that step if Required Training 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 with outstanding tasks and the Workflow: Participate permission, notifies the workflow owner, and reverts workflow content to the appropriate state. If you want 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 document field action updates a field according to a formula expression. The Remove eSignature from Document action removes all eSignatures applied to documents 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 document 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. If there are no validation errors, Vault sets the workflow to Active.

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)

Auto-Naming Envelope Workflows

By default, Vault allows the workflow owner to set a Name value for each Envelope record. Some organizations will want Vault to automatically assign Name values. To do this, navigate to Admin > Settings > General Settings and click Edit. Under Workflow, select the Automatically name envelope records checkbox.

Once this setting is enabled, the details page for each document workflow configuration shows Envelope Details. From here, configure auto-naming by selecting the System generates envelope name setting and providing a Value Format for naming. In the current release, this functionality only supports text strings and the Autonumber token.