Sandbox Validation Framework
Updated
Note: This feature is a Limited Availability feature and DP controlled. To enable this feature in your environment, contact your Success Manager. Alternatively, you can submit a request at tickets@sprinklr.com.
The Validation Framework in Sandbox Changeset Management process is used while moving changesets from one environment to another.
Note: Currently, Sprinklr only supports Versioning Mechanism in Validation Framework.
The Versioning mechanism in the Sandbox Changeset Management process is introduced to enhance environment traceability and control. This feature will enable users to:
Track and manage multiple states of sandbox environments.
View detailed histories of changes and previous versions.
Compare different sandbox versions to identify changes.
Supported Entities for Versioning:
Custom Fields
Rules
Users
These entities, when modified in the sandbox, are version-controlled. This allows Sprinklr to detect when a change is outdated or has been superseded by updates in the production environment.
Integration with Validation Framework
The Review Issues page in the Inbound ChangeSet page has been enhanced to include versioning validations alongside the standard warning and error checks.
How Versioning Works
1. When a changeset is created and an entity (e.g., a Rule) is included:
Its current version from production is stored.
2. If the same entity is later updated in production before deployment:
A version conflict is detected during validation.
3. This conflict will be flagged in the Review Issues page.
Note: While Sprinklr flags version mismatches, the user has the discretion to proceed, override, or exclude the change.
Example: Understanding a Version Conflict
Suppose there is a Rule A:
1. You export Rule A from Production to Sandbox for testing and updates.
2. You make changes to Rule A in Sandbox.
3. Before deploying the updated Rule A back to Production, someone updates Rule A directly in Production (example, adds a new condition).
4. When you attempt to push the Sandbox version back to Production, Sprinklr will detect a version mismatch.
In the Review Issues page, you will see a version-related warning:
The version of Rule A in Production has changed since it was last exported to Sandbox.
At this point, you can:
Acknowledge the warning and continue with deployment, accepting the risk of overwriting changes in Production.
Skip deploying this particular entity and investigate the change in Production before proceeding.
Validation Outcomes:
Version Mismatch Warning: Indicates that the entity in the sandbox has a different version than what's currently in production.
Acknowledge or Skip: For each entity, users can choose to acknowledge the version mismatch (proceed with caution) or skip the update (do not deploy this entity).
Validation Framework in Sandbox
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 with higher severity.
On the Review Issues window of the Inbound ChangeSet page, you can validate the issues and warnings and take appropriate actions.
Working Mechanism
Before a changeset is deployed, the system:
Analyzes the contents of the changeset.
Validates the changeset.
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
Entity | Object Name | Validation Type |
Chatbot | Chatbot Language | Warning – Language is being updated. |
Custom Field | Field Values/Type | Warning – Custom field value updated. |
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
Click the New Tab icon. Under the Platform Modules, click All Settings within Settings.
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.
From the three-dot menu, select Review Issues.
Address and close all open validation items.
The Review Issues window 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.
The Collaborate tab helps in collaborating with the person who has added or modified the entity and resolve the error/warning amicably. Multiple users can collaborate and work on resolving the error.
Depending on whether or not Tiered Approval is created 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.
Note: 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.