​

The Validation Framework offers a structured mechanism to detect and flag potential issues within a changeset prior to deployment. It categorizes issues into two types:

• Warnings – Informational messages indicating potential concerns that do not block deployment.

• Errors – Critical issues that must be resolved before the changeset can be deployed.

On the Review Issues page of the Inbound ChangeSet page, you can validate the issues and warnings and take appropriate actions.

Working Mechanism of the Validation Framework

Before a changeset is deployed, the Sandbox performs the following steps:

1. Analyzes the contents of the changeset.

2. Validates the changeset using the Validation Framework.

Based on predefined validation rules, each entity in the changeset is tagged Warning or Error.

A validation summary is presented to the user, who must acknowledge or skip each warning and error before continuing.

Example Scenario

Consider a changeset that includes the following:

• A Chatbot Configuration with a language update not available in the destination environment.

• A Custom Field with updated values.

Validation Results

The deployment will be blocked until all errors are resolved and all warnings are acknowledged or skipped by the user.

Deployment process for Inbound ChangeSet

1. Click the New Tab icon. Under the Platform Modules, click All Settings within Settings.

2. On the Platform Settings window, click Sandbox Manager from the left pane and select Inbound ChangeSets in the right pane. The list of Inbound ChangeSets are displayed.

3. From the three-dot menu, select Review Issues.

   ​

   ​

4. Address and close all open validation items.

   • The Review Issues page displays the Object Name, Entity, Error/Warning of the corresponding object and entity, and Last Modified By fields.

   • You can either Acknowledge or Skip the error or warning for each of the objects that is getting updated.

   • You will also be able to view the list of Pending issues, Acknowledged issues, and Skipped issues.

   ​

   ​

   ​

5. Using the Collaborate tab, the user will be able to view the person who added or modified the object or entity against which the error/warning is appearing. This helps in collaborating with the person who has added or modified the entity and resolve the error/warning amicably. Search for the person from the Search bar using @ as prefix.

   ​

   ​

   ​

6. Depending on whether or not Tiered Approval is creating for the changeset, perform the following steps:

   ​

   When Tiered Approval is not created for the changeset,

   • Click on Validate and Deploy to trigger the second round of validation before deployment.

   • After resolving any validation issues, proceed to deploy the changeset.

   • If the changeset is rejected:

     • The approver can add rejection comments explaining the reason.

     • The user can make the necessary changes and send it again for approval. .

   ​

   When Tiered Approval is created for the changeset,

   • Click on Submit for Approval.

   • From the Select Approval Path window, choose the appropriate Approval Path for the changeset. The Tiered Approval flow that are created in the Tiered Approval will be listed in the Approval Path drop-down.

     

     ​

   • Approvers review and either approve or reject the changeset based on the configured Tiered Approval flow.

     ​

     

   • When the final approver reviews the changeset, they will click Validate and Deploy to initiate the second validation before deployment.

   • After resolving any validation issues, proceed to deploy the changeset.

   • If the changeset is rejected:

     • The approver can add rejection comments.

     • The user can make the necessary changes and send it again for approval.

​