Invitations are not going out/Non-delivery of Invitations

The following five scenarios encapsulate probable reasons for the dispatchRequest API to fail. The failures will be associated with some 4XX error codes that would signify that the request has been rejected.

If you are unable to log the response of the API request or unsure as to the reason for failure, it is advisable to follow the remedial steps of all five scenarios as a checklist

Scenario 1

Error Description/Log Message:

Root Cause:

Account Configuration not set-up

Remedy:

Step 1: Log in to the Account Configuration Module (ACM)

Step 2: Select the Dispatch from the dropdown

Step 3: Configure vendor details, notification details and other requisite information for selected Dispatch

Step 4: Save the changes

Scenario 2

Error Description/Log Message:

Root Cause:

Authentication failed

Remedy:

Step 1: Check the credentials being used to authenticate the API request.

Step 2: Ensure the bearer token used is being regenerated every 12 hours to avoid token expiry.

Step 3: Please reach out to support@xm.webex.com for further assistance.

Scenario 3

Error Description/Log Message:

-or-

Root Cause:

Unknown Exception/Error while making API request to WXM

Remedy:

Step 1: For exception, please make a note of the exception and reach out to support@xm.webex.com for assistance.

Scenario 4

Error Description/Log Message:

Root Cause:

Max Record size Exceeded

Remedy:

Step 1: Check the properties for creating the Dispatch API request

Step 2: Ensure that no more than 18000 records are added in a single request

Scenario 5

Error Description/Log Message:

Root Cause:

Max dispatch supported exceeded

Remedy:

Step 1: Check the properties for creating the Dispatch API request

Step 2: Ensure that no more than 15 dispatches are added in a single request

Scenario 6

Error Description/Log Message:

Root Cause:

WXM API Failed for dispatch/questions/DP/Settings/Questionnaire

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a dispatch associated with an active questionnaire and delivery policy here.

A record accepted for processing, due to the following cases, they may be stopped from reaching the Dispatcher or the vendor responsible for end-delivery.

If you are logging the response of the dispatchRequest API, you can use the batchid received in the response to further check for the root cause in the EventLog API.

Scenario 1

Error Description/Log Message:

Root Cause:

Trigger has invalidated the invitation due to failure against Null-Checks

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a dispatch associated with an active questionnaire, delivery policy and token template here.

Step 2: If you have verified that your configurations are correct, please reach out to us at support@xm.webex.com

Scenario 2

Error Description/Log Message:

-or-

Root Cause:

Trigger has failed to identify invitation’s channel as both email Id and mobile number are attached with the invitation

-or-

Trigger has failed to identify invitation’s channel as both email Id and mobile number aren’t attached with the invitation

Remedy:

Step 1: Log in to your Experience Management account and navigate to CX Setup -> Invitations -> Delivery Policy

Step 2: Select the active Delivery Policy associate with the dispatch request

Step 3: Make a note of the line-up of emails and SMS under Messages & Schedules

Step 4: Ensure your prefill data is passing information relevant to the channels of the messages line-up.

Scenario 3

Error Description/Log Message:

-or-

-or-

Root Cause:

Trigger couldn’t find the vendor details within the AccountConfiguration collection

Remedy:

Step 1: Log in to Account Configuration Module (ACM)

Step 2: Select the Dispatch from the dropdown

Step 3: Configure vendor details, notification details and other requisite information for selected Dispatch

Step 4: Save the changes

Step 5: Adding/Editing a dispatch or adding/editing vendor details for a dispatch requires a restart of the dispatcher component in the Azure Functions or AWS Lambdas. Please see this link for more information on caching, here.

Scenario 4

Error Description/Log Message:

Root Cause:

Time-Trigger has failed to find the vendor implementation object in its runtime

Remedy:

Step 1: To integrate with a new Single-Send Vendor, an object of type ISingleDispatchVendor is required to be added to your Queue-Trigger Serverless Compute’s runtime.

Step 2: Follow further instructions under “3. Vendor Extensibility” of the Scalability and Extensibility topic.

Scenario 5

Error Description/Log Message:

Root Cause:

Trigger/Time-Trigger has run into an Internal-Exception

Remedy:

Step 1: Please reach out to support@xm.webex.com with the exception details

Due to missing information in the Experience Management account or memory cache issues a complete batch of requests can fail, below are the cases due to which this can happen.

If you are logging the response of the dispatchRequest API, you can use the batchid received in the response to further check for the root cause in the EventLog API.

Scenario 1

Error Description/Log Message:

-or-

-or-

-or-

-or-

Root Cause:

Failed to get details from memory cache or WXM platform

Remedy:

Step 1: Restart the serverless compute or wait for one hour for the cache to refresh.

Step 2: If you have established that it is not a cache issue, then please follow the steps in the following guides to ensure you have created a dispatch associated with an active questionnaire, delivery policy and token template here.

Scenario 2

Error Description/Log Message:

-or-

-or-

-or-

-or-

-or-

Root Cause:

(Respectively to the Error Descriptions above)

Exception getting Dispatch/deliverPlan/Question from cache and If not found from WXM

-or-

Unknown exception within a Batch Request in controller

-or-

Unknown exception while validating the Batch Request

-or-

Exception while validating every dispatch

-or-

Exception validating DP and getting valid channels

-or-

Unknown Exception in overall Dispatch while validation

Remedy:

Step 1: Please reach out to support@xm.webex.com with the exception details for help to address the issue.

Scenario 3

Error Description/Log Message:

Root Cause:

Internal Queue for batching is missing

Remedy:

Step 1: Dispatch Request makes use of an in-memory queue to batch the bulk API payloads. However, it can be extended to use persistent queues like Azure storage queue or AWS SQS queue, etc. Instructions for Extensibility options for In-memory queue, here.

Step 2: Ensure you are passing “wxm” in the “extendedProperties” API.

Please reach out to support@xm.webex.com for further assistance on extensibility.

In a batch of records, if you notice that records of a certain dispatch or multiple dispatches are being skipped while processing, you can address the issue by reviewing the following occurrences. All the occurrences can be traced back to configuration issues on your Experience Management account.

If you are logging the response of the dispatchRequest API, you can use the batchid received in the response to further check for the root cause in the EventLog API.

Scenario 1

Error Description/Log Message:

Root Cause:

Dispatch id passed is not a valid one created in WXM

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a live Dispatch, here.

Step 2: Update the dispatch details in the ACM. Adding/Editing a dispatch or adding/editing vendor details for a dispatch requires a restart of the dispatcher component in the Azure Functions or AWS Lambdas. Please see this link for more information on caching, here.

Step 3: Ensure that the dispatchRequest API payload is using the correct Dispatch ID.

Scenario 2

Error Description/Log Message:

Root Cause:

Delivery policy is paused

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a Delivery Policy and it currently is live, here.

Step 2: Ensure that any Dispatch using the Delivery policy is also made active.

There is a possibility where a delivery policy can become inactive on a 20% error rate or 25% exception rate from the day its created. Where errors are occurring, make sure to reach out to support@xm.webex.com if you are unable to resolve them.

Scenario 3

Error Description/Log Message:

Root Cause:

UniqueId question missing in Delivery Policy

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a Delivery Policy with UUID set as an active question from an existing questionnaire, here.

Step 2: If you have created a new question as the UUID, make sure the cache for your systems is refreshed to pull the latest version of the questionnaire.

Step 3: Check the payload of the dispatchRequest API to verify that the question id of the UUID prefill matches the one in the questionnaire.

Scenario 4

Error Description/Log Message:

Root Cause:

Invalid or unsupported channels configured in dispatch

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a Delivery Policy that supports the channels for the dispatch, here.

Step 2: Ensure that the dispatchRequest API is sending the email and mobile number in the correct formats

Scenario 5

Error Description/Log Message:

Root Cause:

All records are rejected due to invalid channel or data

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a Delivery Policy with UUID set as an active question from an existing questionnaire, the Delivery Policy supports the channels for the dispatch, here.

Step 2: Ensure that the dispatchRequest API is sending the email and mobile number in the correct formats

Scenario 6

Error Description/Log Message:

Root Cause:

Dispatch is paused

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a live dispatch whose details are updated in the ACM application page as well as passed in the API request, here.

Step 2: Adding/Editing a dispatch or adding/editing vendor details for a dispatch requires a restart of the dispatcher component in the Azure Functions or AWS Lambdas. Please see this link for more information on caching, here.

There is a possibility where a delivery policy can become inactive on a 20% error rate or 25% exception rate from the day its created. Where errors are occurring, make sure to reach out to support@xm.webex.com if you are unable to resolve them.

Invitation requests once accepted are queued for Token creation. For a record, if a token is not created, it will not progress for delivery. The reasons for Token not being generated are below.

If you are logging the response of the dispatchRequest API, you can use the batchid received in the response to further check for the root cause in the EventLog API.

Scenario 1

Error Description/Log Message:

Root Cause:

Record rejected due to Common Identifier missing

Remedy:

Step 1: Navigate to CX Setup -> Invitations -> Delivery Policy.

Step 2: Make a note of the Common Identifier (UUID) for the selected Delivery Policy.

Step 3: Navigate to CX Setup -> Questionnaire Builder.

Step 4: Select the Questionnaire associated with the Delivery Policy.

Step 5: Ensure the UUID belongs to the questionnaire as an active question and make a note of the Question ID from the Question Settings tab on the right-hand side.

Step 6: Check the request body of the dispatchRequest API to validate the UUID prefill is being passed with the correct Question ID.

Scenario 2

Error Description/Log Message:

Root Cause:

Record Rejected due to Invalid or missing Email or Mobile number

Remedy:

Step 1: Navigate to CX Setup -> Invitations -> Delivery Policy.

Step 2: Make a note of the channels for the selected Delivery Policy.

Step 3: Navigate to CX Setup -> Questionnaire Builder.

Step 4: Select the Questionnaire associated with the Delivery Policy.

Step 5: Ensure the Email and Mobile prefill question is present in the questionnaire as an active question and make a note of the Question ID from the Question Settings tab on the right-hand side.

Step 6: Check the request body of the dispatchRequest API to validate the email and mobile prefill is being passed with the correct Question ID.

Step 7: Also validate that prefill data for mobile number and/or email id is being captured and sent in the correct and accepted format.

Scenario 3

Error Description/Log Message:

-or-

-or-

-or-

-or-

Root Cause:

Bulk request failed due to Inactive or Invalid Dispatch

-or-

Bulk request failed due to Inactive or Invalid Delivery Policy

-or-

Bulk request failed due to Invalid token Template

-or-

Bulk request failed due to Invalid content template

Remedy:

Step 1: Please follow the steps in the following guides to ensure you have created a Delivery Policy with UUID set as an active question from an existing questionnaire, the Delivery Policy is live, the Message and Token templates are valid for the dispatch and the correct live dispatch details are updated in the ACM application page as well as passed in the API request, here.

A dispatch or delivery policy can be paused manually by the administrator of the Experience Management account. A delivery policy could get paused because of any error that occurred and hence causes the Dispatch to get paused as well. The delivery policy will auto-resume after 4 hours.

There is a possibility where a delivery policy can become inactive on a 20% error rate or 25% exception rate from the day its created. Where errors are occurring, make sure to reach out to support@xm.webex.com if you are unable to resolve them.

Scenario 4

Error Description/Log Message:

Root Cause:

Exception while generating bulk token creation

Remedy:

Step 1: Please reach out to support@xm.webex.com with the exception details to address the issue.