One way to enforce business rules, prevent user errors, and automate your Vault processes is to use object lifecycle state entry criteria, entry actions, and user actions.
- Entry Criteria ensure that a record meets conditions before entering a lifecycle state.
- Entry Actions are automatic actions that Vault performs on a record when it enters a lifecycle state.
- User Actions are actions available for users to execute on records. Like entry criteria and entry actions, user actions are defined within a specific object lifecycle state.
Note: Lookup fields update asynchronously. For this reason, we do not recommend using them in time-based processes such as lifecycle entry actions or entry criteria.
To configure any of these options, you must first set up an object lifecycle and lifecycle states. Then, click into a specific lifecycle state.
Entry Criteria
You may need to ensure that an object record meets conditions (fields are populated or have certain values) before entering a specific lifecycle state. For example, users may not know the start date when first creating a Marketing Campaign record, but they will need to fill in the Start Date field before the campaign can enter In Review state.
When users move an object record from one state to another, Vault confirms that the record meets the entry criteria for the new state. Vault blocks the move until the criteria are fulfilled. Users see a message with details on the unmet entry criteria. When this happens as part of a workflow, the workflow fails to complete and you will see an error message. Before restarting the workflow, ensure that all entry criteria are met.
Note: Vault does not check entry criteria on the initial lifecycle state for a new record. However, if the record moves to another state and then back to the initial state, it must meet the initial state’s criteria to move back.
Restrictions & Limitations
To define an entry criteria for a related object:
- The related object must use an object lifecycle.
- The related object cannot have the User Role Setup object class.
Entry Criteria Types
- Field: Requires that a specific object field is populated.
- State of Related Record: For outbound relationships, Requires that any or none of the related object records are in a specific lifecycle state. For inbound relationships, requires that a single related object record is in a specific lifecycle state or that any, all, or none of the related object records are in a specific lifecycle state.
- State Type of Related Record: Requires that any, all, or none of the records of a specific relationship are in a specific state type. Admins can also configure this action to validate that at least one record (regardless of state type) is associated via the selected relationship.
- State Type of Related Document: Requires that any, all, or none of the documents of a specific relationship are in a specific state type. Admins can also configure this action to validate that at least one document (regardless of state type) is associated via the selected relationship.
How to Define Entry Criteria
To set up entry criteria for an object lifecycle state:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then click into an individual state.
- Click Edit in the Entry Criteria section.
- Click Create Rule.
- Optional: Select Perform with conditions if the criteria should only apply for object records that meet certain conditions.
- Under Validate that, specify the entry criteria. See details below for state type of related documents.
- Optional for State of Related Record or State Type of Related Record: Select Conditions on related records to execute the validation rule only on related records that meet your specified condition.
- Optional: Add additional criteria by clicking Add action. If the rule is conditional, these criteria will share the same conditions.
- Click Save.
- Vault immediately starts to enforce the entry criteria rule for records moving into the lifecycle state, but the new entry criteria do not affect records that are already in the state.
Rich Text Field Criteria
Field criteria or Perform with conditions criteria applied against Rich Text fields can only use the is blank or is not blank conditions.
State Entry Criteria on Related Objects
In addition to defining entry criteria on an object, you can also define entry criteria on that object’s related objects. For example, you may not want a Marketing Campaign record to enter Approved state unless its parent Product record is in Approved state. If your entry criteria validates conditions on related object records, the number of related records cannot exceed 1,000 records.
State Type of Related Documents
This criteria type allows Admins to configure Vault to require that documents related to the record are in a certain state type before the record’s state can change. This helps to prevent records from being routed through their lifecycles before related documents are in appropriate states.
For example, this criteria could ensure that all Documents to be Released in a Multi Document Change Control record are in the Ready for DCC Approval state of their respective lifecycles before the record itself is sent to approvers.
To define this type of entry criteria:
- Create a new rule under Entry Criteria on an object lifecycle state.
- From the drop-down menu, select State Type of Related Documents.
- Select a Document Relationship from the drop-down menu that appears. This rule will only apply to documents linked to the record through this relationship.
- From the Operator drop-down, select All document state types equal, At least one document state type equals, No document states equal, or At least one document exists.
- Select the required Document State Type related documents must be in.
- Click Save.
Entry Actions
Entry actions are automatic actions that occur when an object record moves into a specific lifecycle state. These can include simple notifications to let users know that an action has occurred or more complex actions like cascading lifecycle state changes for related records.
Note: Vault does not perform entry actions on the initial lifecycle state when users create a new record. However, if the record moves to another state, Vault will perform the entry actions when the record moves back to the initial state. To define an action that occurs on record creation, see Event Actions.
Entry Action Types
- Change related object lifecycle state: Moves all related object records to the state in their lifecycle that corresponds to the selected state. This action executes synchronously and updates up to 1,000 related records.
- Change related object lifecycle state asynchronously (no limit): Moves all related object records to the state in their lifecycle that correspond to the selected state. This action starts a job whose creation and id is included in the object record’s audit trail. Admins can view the job in Admin > Operations > Job Status. This job executes asynchronously and updates an unlimited number of related records. If an error occurs while updating one or more records, Vault skips those records and includes the error in the job log.
- Send a Notification: Sends an email and in-app notification to the selected users using the selected message.
- Update Record Field: Sets the value of a selected object record Text, Long Text, Rich Text, Number, or Date field during a state change using an Excel™-like formula language. You can also set the values for Yes/No, Picklist, and Object fields.
- Update Related Record Field: Sets the selected field on a related object record. You can set values for Yes/No, Picklist, Number, Date, Text, Long Text, and Rich Text fields. This is available for records related through Parent, Child, Reference, and join relationships. Note that you cannot update more than 1,000 related records.
- Change state of related documents: Moves all related documents to the state in their lifecycle that corresponds to the selected state type. This is only available with the Batch Approval lifecycle.
- Change related document lifecycle state: Moves the selected related document to the states in its lifecycle that correspond to the selected state type. This is available for documents related to the object record by a document reference field. Select Skip change state if document version is not found to prevent the action from running when the related documents are already in a steady state.
- Start Workflow: Begins a workflow on the object record. See Configuring Auto-Start Object Workflows for details.
- Copy Field to Related Object: Copies the value of a field to an equivalent field on a specified, related object.
- Check sibling records before updating related record: Checks the lifecycle state of “sibling” records and moves the related record into a new lifecycle state if all sibling records are in the appropriate state. See Configuring the Check Sibling Records Entry Action for details.
- Make previous checklist design version superseded: Moves the previous Approved checklist design version to Superseded when the current checklist design version moves to Approved.
- Make signature records obsolete: Sets all eSignature records not included as a preserved signature type to obsolete. When defining this action, select signature types from the Preserve these signature types drop-down list to prevent specified signature types from being set to obsolete. This is only available for objects with the eSignature option enabled. See Managing Object eSignatures for details.
- Start checklist: Initiates a checklist and sends to the selected set of respondents. See Configuring Checklists.
- Complete checklist: Clears disabled responses, and calculates the score for the checklist. See Configuring Checklists.
- Cancel workflow: Cancels an active workflow on an object record.
How to Define an Entry Action
To define an entry action for an object lifecycle state:
- Within the Entry Actions section, click Edit.
- Click Create Entry Action.
- Choose whether the entry action rule will Always apply or should only Perform with conditions. See details for defining conditions.
- Select an action type and additional details. These details will vary by action type.
- Optional: Add additional actions by clicking Add Action and repeating the steps above. If the rule is conditional, these actions will share the same conditions.
- Click Save.
Rich Text Entry Action Conditions
Entry actions with Perform with conditions criteria applied against Rich Text fields can only use the is blank or is not blank conditions.
Defining Entry Actions on Related Object Records
The primary object is the object for which you are modifying the lifecycle configuration. Most entry actions affect the primary object’s records. However, some entry actions can update related object records.
For example, if a user changes the state of a Product record to Approved, you can define an entry action to change the state of related Marketing Campaign records to Ready for Approval.
Setting Conditions for Related Object Records
Sometimes, you need an entry action to only change certain related records, not all related records. For example, when moving a Quality Event record to In Execution, its related Change Action records also need to move forward in their lifecycle. However, some Change Actions are in Canceled state, rather than Accepted. Those records should stay in Canceled state, but should also maintain their relationship to the Quality Event record.
Note: This option is only available for the Change related object lifecycle state, Change related object lifecycle state asynchronously (no limit), and QMS Change Related Object Lifecycle State Job entry actions.
To configure this, you must apply conditions to limit the related object records affected by the entry action:
- After defining the entry action details, select the Conditions on Related Records checkbox.
- Choose a Condition: Either exclude records in specified lifecycle states or only include records in specified lifecycle states.
- Choose the Related Record’s State to exclude or include.
Restrictions & Limitations
To define an entry criteria for a related object:
- The related object must use an object lifecycle.
- The related object cannot have the User Role Setup object class.
User Actions
User actions are actions available to users on an object record in a specific lifecycle state. User actions can begin a workflow, move the record into a new lifecycle state, etc. Without user actions, there is no way for a record to move forward in its lifecycle.
User Action Types
You may have additional application-specific user actions available in your Vault in addition to the standard Vault platform user actions below:
- Change State to: Allows the user to manually move a document into a different lifecycle state. Vault executes entry actions for the state change.
- Web Action: Allows the user to execute a web action. Note that these appear in the Vault’s base language within the user action setup, even if you are using a different language.
- Workflow: Allows the user to start a workflow.
- Start checklist: Initiates a checklist and sends to the selected set of respondents. See Configuring Checklists.
- Export Checklist Design: This action exports a checklist design and all related records in CSV format. See Using the Checklist Design Loader.
- Deep Copy Checklist Design: This action copies a checklist design and all related records to a new Checklist Design record. See Copying a Checklist Design.
- Sync Checklist Design Lifecycle States: This action changes the lifecycle state of the Checklist Design record and all of its related sections, questions, answers, and dependencies. See Configuring Checklists.
- Create New Version: This action is available only for Checklist Types with version control enabled. This action creates a new version, in the Draft state, of an existing Checklist Design. See Designing Checklists.
How to Define a User Action
- Within the User Actions section, click Edit.
- Click Create User Action.
- Choose whether the user action rule will Always apply or should only Perform with conditions. See details for defining conditions.
- Select an action type and additional details. These details will vary by action type.
- Optional: Add additional actions by clicking Add Action and repeating the steps above. If the rule is conditional, these actions will share the same conditions.
- Click Save.
Rich Text User Action Conditions
User actions with Perform with conditions criteria applied against Rich Text fields can only use the is blank or is not blank conditions.
About Conditional Entry Criteria & Actions
Any entry criteria, entry action, or user action that you define for a lifecycle state can be conditional based on the object or a related object record’s field values. For example, you could have several conditional entry actions configured to send notifications when a product record enters Retired state. One condition specifies that the Therapeutic Area must be Cardiology. The related entry action sends a notification to the group Cardiology Team. Another rule could send a notification to the group Veterinary Team if the product record’s Therapeutic Area field is set to Veterinary.
To define conditions, select an object or related object field, operator, and value. If needed, you can define multiple conditions by clicking Add condition.
An object record must meet all of the conditions defined within a rule. For example, if a record meets one of two conditions for the entry criteria, Vault will not apply the entry criteria.
About Referencing Missing Records in Criteria & Actions
When you clone a lifecycle configuration during Vault provisioning, references to specific object records in entry criteria or conditions may become invalid if those records do not exist in the new environment. If this occurs, references to missing object records are shown as empty in lifecycle configuration fields.
While Vault allows you to save configurations even with these missing records, we recommend resolving these missing references by recreating the records with the same ID values using Vault Loader or via the API if you want to use these conditions in the new environment. If you only want to update another configuration and take it back to the source environment, you can leave the missing references as is.