Introduction
The following article has been created to detail how to set up standardised order errors enabling a clearer & more concise way to report back error patterns from the fulfiller by grouping these by error type in the Kornit X Platform & providing a more coherent message back for these errors to the end user (client, brand, demand generator etc). Examples of this could be incorrect SKUs, order duplicates and expired print files.
Please note that this is only set to work with the Canva PSP 'Sales Channel' notification integration, however we do anticipate more to be added in time.
This feature is only accessible within dropship companies only.
How To Set Standardised Errors Against Dropship Companies
In order to set up standardised error groups, navigate to your dropship company, edit and go to the "Advanced" menu and select the "Standardised Order Errors" option as shown below.
To create a standardised Error you can click the blue "+ Standardised Error" button.
Once clicked the following menu will appear allowing you to set your error messages into standard groups.
Adding a 'Standard Group' & 'Standard Message' BUT leaving the 'Original Message Pattern' blank will cause the original error to feed back on the incorrect group, leaving this field blank will act as an 'anything' trigger. Because of this, it is advised that you do not add a standard group or standard message if there is no original message pattern present from the fulfiller.
Some examples have been added below such as if user zip codes or delivery names are invalid or missing, this feature will group these original message patterns as per the standard group allocated.
An example of how these errors are sent back from the fulfiller is shown below.
What Each Standardised Order Error Option Means?
There are multiple options that can be set within each Standardised Error and these options have been explained below.
- Original Message Pattern - this will be the error message taken directly from the fulfiller, for example they may use the pattern "file URL is invalid or unsupported image format" when files downloaded have expired.
- Standard Group - This is the error group that the client/brand/demand generator etc sets that the standard message errors will be grouped under. E.g. if we are using the invalid URL example this could be "ORDER_URL_EXPIRED".
- Standard Message - This is the client/brand/demand generator etc error message and the meaning behind the set pattern, which will be associated to a standard group. With the invalid URL example this could be "Order files may have expired".
- Transient - The transient on/off toggle is for the reattempting/resubmitting of an order after error. An error can either be retriable or not retriable (i.e. transient), so essentially, if "Is Transient" is toggled on then it effectively means the error will be ignored and the order will be retried, Currently the order will be retried an hour after an error, ad infinitum.
- Note: No expectation that transient errors are to be grouped or have a standardized message
We have created an example standard message based on the missing URL option and detailed this below.
There is also an option to delete the standardised error options and that can be done one by one using the trash can icon.
Example Standard Order Error Groups
There are multiple different examples of the types of standard order error groups you may want to set, we have detailed some examples, but not limited to those shown below.
- SKU_ISSUE - SKU may be invalid or missing
- ORDER_URL_EXPIRED - Order print files may have expired
- USER_DETAILS_ISSUE - User details may be invalid or missing
- USER_ADDRESS_ISSUE - User address may be invalid or missing
- DUPLICATE_ORDER - Duplicate order may have been created by partner
- ALREADY_FINALIZED - Order may be in an unmodifiable or completed state
- DELIVERY_ISSUE - Carrier or collection store may be unavailable
- UNKNOWN - Ungrouped Error
When adding against the dropship, If there are multiple "Original Message Pattern" error messages for a single group provided, you can either list them separately, OR, You can use * in the 'Original Message Pattern' to match anything. There is an implicit * (wildcard) at the start and end of the string.
For example: 'Invalid user details' matches both 'Invalid user details: Missing first name' and 'Invalid user details: Missing surname'. For errors like The 'specified postcode is invalid' and the 'specified country code is invalid', you can't really use the 'specified' because it's too broad. So, the 'specified * is invalid' would be better.
Essentially, to save time by creating multiple rows & if you don't want to map them twice, you can just use the * as a wildcard for the 'Original Message Pattern' received from the Fulfiller.
Please note that within Order Manager we will show the original error message and not the standardised one set. The standardised error message will get sent to the client/brand/demand generator etc via their notification API.
Configuration and Admin
Fulfiller -> KX Platform
The fulfiller will send errors on the designated supplier integration the same way as they do today, there will be no change on this aspect of the flow, Kornit X will group these once they enter the Kornit X Platform, as per the error groups as specified in this knowledgebase article.
KX Platform -> Client/Brand/Demand Generator etc
Once grouped, for error groups to pass back to client/brand/demand generator etc they need to update their Event Handle webhook on their side to accept new fields in the Item Event Update (error group & message). The client/brand/demand generator etc need to add support for the fields on their side as per the Notification integration configured on the sales channel.
As part of new and existing customers being onboarded, if they wish to use standardised errors they will be asked to supply these errors on a spreadsheet which will be used to configure.
As per the specifications, currently standardised error messages are only applied for supplier integrations which will in turn feedback to the client/brand/demand generator etc via the notification integration on the sales channel.
FAQs
Below are some questions with answers that we wanted to highlight.
Any errors that aren't caught by the standard rules are forwarded to the client/brand/demand generator etc as they currently do today, correct?
This is correct.
Does the client/brand/demand generator etc need to setup any existing error messages?
Yes, based on the proposed error groups. We would recommend gradually rolling these out to check and test all is working before assigning.
Are all error messages regex or is it just the wildcard * that is included as a regex?
They are not regex, we decided against using this as user supplier regex patterns can be a security risk and we wanted to keep this simple. The "*" represents any character repeated any number of times.
Will the client/Brand/Demand Generator etc send errors on the designated supplier integration the same as they have done before this was implemented?
There will be no change from the client/Brand/Demand Generator etc point of view.