Table of Contents | ||||
---|---|---|---|---|
|
Overview
Maintaining correct PLU configurations between Sanity and your POS is essential for successful order injection, and can be challenging. For that reason, we’ve introduced the Sanity Validation feature which aims to reduce issues due to availability, pricing, and order injection by running automated validations on Sanity menu documents and generating reports.
Two types of validations are run to generate the respective reports:
Restaurant Availability: checks that documents are available at > X% of restaurants for each POS vendor. Thresholds are set in Sanity by each brand. All POS vendor thresholds must be met or exceeded in order for the validation to be considered successful.
Pricing Distribution: checks that
systemwideOffer
andconfigOffer
documents have the correct price on the POS when we set a target price in Sanity.
Info |
---|
The pricing distribution validation is only available for offers because it utilizes the target offerPrice field in Sanity to validate the Sanity pricing against the Menu Service pricing (which is derived either from the POS or the Digital Operations Portal depending on the integration in a given market). |
Info |
---|
Validations are only available in the staging environment, which is the environment where operators edit and test their menus. This way we ensure that only working items are moved to production. Note that validations are executed against the PROD environment, meaning that they check pricing and availability against the POSs in production. |
Running Validations
Running Manual Validations
Automatic Validations By Editing the Document
There are certain edits within the Sanity UI that will automatically trigger a validation. While the fields vary by document, editing any of the below fields will trigger an automatic validation:
vendorConfigs (these are what you might know as PLU)
ruleSets (offer rules, such as offer only valid on Wednesdays, or every day until 7PM)
offerPrice (price of an order)
Retrying Validations by Clicking the Retry Button
You can manually trigger a validation run for a document by clicking the Retry Validation button.
Note |
---|
Please note that the SUCCESS status for validation only means that the item/offer met the set thresholds - not that a product is available and/or configured with correct pricing in all restaurants. |
Reviewing Validations
View Statuses of Validations
Navigate to the validations overview tool in the sanity UI to see all documents and their corresponding validations' statuses. All validations are executed against the PROD environment. Each document is a clickable link that will take you to the document.
The list above can also be empty, meaning all validations were successful.
Validation Types
Each validation type on the Sanity document will have the following fields:
Validation Status - validation status of the most recent validation run (statuses are outlined below).
Last Validation - last validation timestamped by the user’s time.
Download Validation Report (button) - view the validation report upon completion.
Retry Validation (button) - Manually triggers a validation run for the validation type.
To validate whether all validations went through, visit any item (that is in the feature menu), combo (that is in the feature menu), offer (systemwide, config), or reward, and check the Document Validations section (item view).
Download the validation report specifying which stores and POSs have failed. You should also be able to retry the validation. There should be a visible date of the last validation, and it should be up to date (either today or the day before, depending on the timezone).
Info |
---|
Different types of items can have different types of validations. For example, items, combos, and rewards should only have restaurant availability validation, but offers also include price distribution validation. |
Note: Some validations fail without generating a report. This occurs, for example, when an item has no PLU assigned (either PLU Type = IGNORE or it’s empty).
Example config offer:
Example item:
Status | Meaning |
---|---|
RE_REQUESTED | Validation was manually requested via the retry button. |
NEEDED | Validation was triggered by a change in the document state that was published. |
ENQUEUED | Validation has been created on the backend service, but jobs have not started processing yet. |
IN_PROGRESS | Validation jobs are processing. |
ERROR | There was some error on the backend that caused validation to crash. |
FAILED | The validation successfully completed but thresholds were not met. |
SUCCCESS | The validation successfully completed and thresholds were met. |
Reading the Validation Report
Each validation type generates a validation report on completion. The layout of each report will be different depending on the validation type. Each report is sorted with failures at the top of the document, each row is an actionable data point.
Configure Sanity Threshold Configurations
Navigate to the CTG Configs → Sanity Configs document inside the Sanity Desk tool. You will see the different validation types that are available:
The values that you set for a given validation type are the minimum threshold percentage values. For example, if restaurant availability → Sicom is set to a value of 10
, the Sicom PLU in the offer being validated will need to be available in at least 10% of restaurants for the offer to pass validation. Note, if any of the posVendors from vendorConfigs do not meet the thresholds, the entire document will not pass validation.
Info |
---|
You will need to set values for at least one of the validation types in order for the service to run validations. If you do not, the service will throw an error. Temporary values have been put in place as placeholders. |
Document Migration
Additional notification is available document migration to notify users about possible misconfiguration of the document (or documents) that are about to be migrated.
Migrating One Document
When migrating single document (accessible from an Item view), notification can be seen about failing validations:
This generic information specify that one of the validations (pricing distribution or restaurant availability) is failing. To find details of the validation outcome, please refer to reviewing validations section. In case of single document migration, the validation warning is related to that particular document, the only thing to verify is which particular validation is failing.
Migrating Multiple Documents
You may encounter similar information when migrating multiple documents:
In this case, there is an uncertainty about which particular document is causing this warning since this migration can be performed to hundreds of documents, therefore it won’t be possible to display details about all of the items not passing validations.
Callouts and Edge Cases
Pricing Distribution Validations
Offers that have a referenced incentive that is of _type “offerDiscount“ automatically pass validation as the PLU price from the restaurant’s POS may not match the offerPrice on the document.
Carrols (pickup and delivery) POS prices are ignored when there is an offerPrice on the offer - the validation service will not evaluate them in this scenario.
Restaurant Availability Validations
Note on availability - there are several steps to make an offer available/visible in our application. Our script strictly looks at the POS availability from the menu service response (this endpoint is cached for ~60 seconds). In order for something to be available, POS vendors must add the PLU systemwide, but individual restaurants must refresh their POS/mark the PLU as available in order for the menu service response to come back as available for that restaurant.
Info |
---|
The price available in the restaurant availability validation file is the price in the menu service, for example, in case of NCR integration that is the price sent via the POS to the Menu Service. In case where the DOP is the source of truth for P&A, it is the price set in the DOP. |
Info |
---|
Additional technical context for CSM: /wiki/spaces/FEP/pages/3675193369 |