# 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 {#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.
### Entry Criteria 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. If an inbound relationship uses the _All records equal_ condition and no records exist, the condition is still met. You may use the _At least one records exists_ condition in conjunction with _All records equal_ to ensure that when the lifecycle state check is performed, Vault validates the condition only if records actually exist. The related object must use an object lifecycle. * **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. The related object must use an object lifecycle. * **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][1]. 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][2]. 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. 6. Optional: Add additional criteria by clicking **Add action**. If the rule is conditional, these criteria will share the same conditions. 7. Click **Save**. 8. 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 {#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 {#state-type} This criteria type allows Admins to configure Vault to require that documents related to the record are in a certain [state type][2] 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} 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][3] 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] [3] 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 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 entry action 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 this entry action from running when the related documents are already in a steady state. This setting is useful when multiple object records reference the same document within the entry action and attempt to change its lifecycle. For example, if two child records reference the same document within this entry action, the first action will execute and update the document's major version. The second action will fail and cause the entire state change to error as the version is already updated. The _Skip change state if document version is not found_ setting prevents this error from occurring by skipping the entry action altogether and continuing with the state change. * **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 it 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 {#define-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][1]. 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 {#entry-actions-on-related-objects} 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.
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. ## User Actions {#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 Veeva 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 {#define-actions} 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][1]. 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 {#conditions} 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 {#referencing-missing-records} 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 Vault 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. [1]: #conditions [2]: #state_type [3]: #entry-actions-on-related-objects