Configuring Entry Criteria, Entry Actions & User Actions for Object Lifecycle States

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.

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.

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:

  1. Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then click into an individual state.
  2. Click Edit in the Entry Criteria section.
  3. Click Create Rule.
  4. Optional: Select All conditions are met or Formula evaluates to True if the criteria should only apply for object records that meet certain conditions. If you select Formula evaluates to True, use a formula that returns a boolean (true/false) expression to define the condition.
  5. Under Validate that, specify the entry criteria. See details below for state type of related documents.
  6. 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.
  7. Optional: Add additional criteria by clicking Add action. If the rule is conditional, these criteria will share the same conditions.
  8. Click Save.
  9. 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.

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:

  1. Create a new rule under Entry Criteria on an object lifecycle state.
  2. From the drop-down menu, select State Type of Related Documents.
  3. 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.
  4. 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.
  5. Select the required Document State Type related documents must be in.
  6. 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.

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.

The following entry actions are only available in Quality Vaults:

  • CC: Update Change Controlled Documents: Allows the Document Change Control record to perform state changes and field updates to documents related to document change controls and requests upon approval. See Configuring Multi-Document Change Control for details. This action is only available in the QualityDocs application.
  • CC: Update Related Change Request: Allows the Document Change Control record to trigger state changes to the related requests upon approval. See Configuring Multi-Document Change Control for details. This action is only available in the QualityDocs application.
  • Create Audit Record: Create an Audit record from Proposed Audits. This action is only available in QMS Vaults. See Configuring Audit Program Planning (QMS) for details.
  • Create Effectiveness Check Record: Creates an Effectiveness Check object record. This is only available with the QMS application on Quality Event and CAPA Action Item lifecycles. See Configuring the Create Effectiveness Check Entry Action for details.
  • Create Related Record: Creates records based on Related Record Configurations. See Related Record Configurations for details.
  • QMS: Activate Ext. Collaborator: Creates and activates temporary User accounts from Person records to allow external collaborators access during External Finding processes. This entry action is only available with the QMS application. See Configuring Audit Finding External Response Collaboration (QMS) for details.
  • QMS: Inactivate Ext. Collaborator: Inactivates temporary User accounts created via the QMS: Activate Ext. Collaborator entry action. This entry action is only available with the QMS application. See Configuring Audit Finding External Response Collaboration (QMS) for details.
  • QMS Change Related Object Lifecycle State Job: Executes a no-limit asynchronous job to move child records forward when the parent Audit Program or Assessment record transitions to a specific state. See Configuring the QMS Change Related Object Lifecycle State Job Entry Action (QMS) for details.
  • Send Issue Escalation Notification: Sends a notification to specified roles associated with an Issue Escalation record, and creates an Issue Escalation Notification record for traceability. This entry action is only available with the QMS application. See Configuring Issue Escalation (QMS) for details.
  • Sibling Check Related Record State Change: 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 and field conditions are met. This entry action is only available with the QMS application. See Configuring the Sibling Check Related Record State Change Entry Action (QMS) for details.
  • Generate Document From Formatted Output: Creates a document based on a Quality object record. These documents are created from Formatted Output templates. This entry action is only available with the QMS application. See Quality Document Generation (QMS) for details.
  • Generate Document From Document Template: Creates a document based on a Quality object record. These documents are created from Document Templates. This entry action is only available with the QMS application. See Quality Document Generation (QMS) for details.
  • Start Periodic Review Workflow: Starts a specified periodic review workflow. This action is only available in QualityDocs Vaults, in the Periodic Review object lifecycle Initiated state. See Configuring Periodic Review (QualityDocs) for details.
  • Create Evaluation Checklist: Creates a checklist for use as an evaluation form for Evaluation Training Assignments. See Configuring On-the-Job Training for details.
  • Link Available Document Change Requests: adds any Document Change Request records which target the document or documents to be made effective to the Document Change Control as related records. See Configuring Multi-Document Change Control for details.
  • Link Available Periodic Reviews: Adds any Periodic Review records which target the document or documents to be made effective to the Document Change Control as related records. See Configuring Periodic Review for details.
  • Run Quality Record Check: Starts a record check for users to review duplicates or recurrences of events and stores the results in a Record Check Result. This action is only available in QMS Vaults. See Configuring Recurrence Check for details.

How to Define an Entry Action

To define an entry action for an object lifecycle state:

  1. Within the Entry Actions section, click Edit.
  2. Click Create Entry Action.
  3. Choose whether the entry action rule will Always apply or should only apply when All conditions are met. You can also select Formula evaluates to True to use a formula that returns a boolean (true/false) expression to define conditions. See details for defining conditions.
  4. Select an action type and additional details. These details will vary by action type.
  5. 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.
  6. 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.

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.

To configure this, you must apply conditions to limit the related object records affected by the entry action:

  1. After defining the entry action details, select the Conditions on Related Records checkbox.
  2. Choose a Condition: Either exclude records in specified lifecycle states or only include records in specified lifecycle states.
  3. 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

  1. Within the User Actions section, click Edit.
  2. Click Create User Action.
  3. Choose whether the user action rule will Always apply or should only apply when All conditions are met. You can also select Formula evaluates to True to use a formula that returns a boolean (true/false) expression to define conditions See details for defining conditions.
  4. Select an action type and additional details. These details will vary by action type.
  5. 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.
  6. Click Save.

Rich Text User Action Conditions

User actions with All conditions are met 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 All Conditions are met, and then select an object or related object field, operator, and value. You can also select Formula evaluates to True to use a formula expression that returns a boolean (true/false) expression to define the condition. The criteria and actions execute only if the formula returns a true expression. 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.