Sanity Validations

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 and configOffer documents have the correct price on the POS when we set a target price in Sanity.

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).

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.

Document Validation View

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).

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

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.

 

 

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.