Overview
Reduce issues due to availability, pricing, and order injection by running automated validations on Sanity menu-related documents.
This service currently runs the following validations:
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
,configOffer
, andoffer
documents have the correct price on the POS when we set a target price in Sanity.
Relevant KPIs:
Average Restaurant Sales (systemwide)
Average count of unavailable PLUs per restaurant
Average count of price mismatches per restaurant
Total number of price outliers systemwide (makes us vulnerable to lawsuits)
Regression → Impact of unavailable PLUs on restaurant sales
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.
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).
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.
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.
Additional technical context for CSM: /wiki/spaces/FEP/pages/3675193369