Troubleshooting Guide

There are multiple possible reasons for a customer (or some customers) not receiving an invitation which can broadly be classified based on whether the invitation has failed within the Experience Management account or after it has been sent to the communication vendor.

Follow these steps to identify where the failure is occurring:

Step 1: Make a note of the customer’s information, in particular, the Customer ID. You can proceed if you have the token information as well.

Step 2: Use the Customer ID or Token ID in /api/DeliveryEventsBy/Target/{id}, where {id} is replaced by the token or customer id.

This API will give you information on whether the Customer’s invitation has been throttled within Experience Management due to the customer having unsubscribed previously or to avoid over-surveying in adherence to the fatigue rules set.

Further, the API response will indicate whether the Invitation has been sent to the communication vendor or whether it has failed within Experience Management.

If you see the message in the response body of the API that it has been pushed to the communication vendor, then please check with your SMS/email vendor on whether the message has been dropped our delayed at their end. Also, check the following:

Step 1: Check if the SMTP vendor/SMS vendor is processing all the requests sent from the Experience Management Invitation module.

Step 2: Check if the password has changed for the vendor.

Step 3: Check if the Experience Management IP range has been whitelisted with the vendor.

For failure within Experience Management, continue reading the topic “Invitations are not going out/Non-delivery of Invitations”.

Are you logging responses?

If yes, click this link to view the categories.

Not logging responses? Check your email (or the inbox of your Experience Management account’s admin) for the notification with the error description. This can be configured from your ACM application page for each dispatch.

As throttling is now present by default in the Invitations module for an existing token, it is unlikely for a customer to receive a duplicate invitation. A few exceptions to take note of:

Step 1: Check the UUID for the customer used for each received invitation. As throttling is managed on the UUID, if this identifier changes value, then the same email address or mobile number can receive multiple invitations.

Step 2: Check if the token has expired between the receipt of the first and the duplicate invitation. If the token has expired, when the customer makes an interaction, they will be eligible to receive an invitation.

Step 3: Use GET /api/DeliveryEventsBy/Target/{id} to verify if the contact is added in the Throttling database and throttling logic is working properly.

If these are verified but to do not account for the customer receiving the duplicate invitation, then please reach out to support@xm.webex.com

If your customers are unable to provide their responses to the surveys or they see the message “Oops, the survey URL has expired”, then the following steps need to be followed:

1. Navigate to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Delivery Policy.

   

   
   

2. Select the Delivery Policy by clicking on the name of the policy or by clicking on the edit button to the right of the policy name.

3. Scroll to section marked Messages & Schedules and note down the total duration of time between the first message and the final one.

   

   
   

4. Now head over to Token Template page by navigating to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Token Template and select the token being used for the survey in question.

   

   
   

5. Ensure the option from the dropdown for “Survey Link Expires in” for the token exceeds the total duration of time for your Delivery Policy.

   

   
   

   Note: : If you have business rules set up, be sure to add the non-operating hours to the total duration as well as allowing ample amount of time for your customer to respond on receipt of the survey.

First, we need to verify that the customer is unsubscribed with the following steps:

Step 1: Check if the email id/mobile number is present in the Unsubscribe database. If not present, then the customer email id/mobile has not been entered into the Unsubscribe database due to:

1. The customer not clicking on the unsubscribe link.

2. Error while connecting to the unsubscribe DB, when the customer clicked the link.

Step 2: Before the customer clicked the unsubscribed link, the survey invitation would have been sent.

If it is established that the customer is indeed unsubscribed, then please reach out to support@xm.webex.com to investigate this further.

Prefills are passed as API parameters to api/dispatchRequest. If the responses seem to have incorrect prefill data, validate the following:

Step 1: Check if prefill is being passed in the API payload.

Step 2: Check if the prefill is mapped to the correct variable and tag in your system.

Step 3: Check if the question IDs of the prefills are correctly selected from the question settings.

Step 4: Ensure the prefill question is active and not retired in the questionnaire.

The invitations module allows for message templates with dynamic fields which help to personalize the invitations you send to your customers. If you notice the dynamic fields have incorrect data, check the following:

Step 1: Check if the dynamic field in the message template is compatible with the questionnaire you are surveying for.

Step 2: Ensure to add a default value in case the information is not present for a particular customer.

Step 3: Make a note of the prefill question ID for which dynamic substitution is required.

Step 4: Verify the question ID is being passed in the API payload along with the correct variable value. Ensure the mapping of the tag to the variable is completed in your system.

The Invitations Module supports multiple languages which can be configured from the Message Template page. When the invitations are being sent to the users, the preferred language is determined by Token Template selected. The below steps will show you how to adjust your preferred language settings:

1. Navigate to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Message Template.

   
   

2. Select the Message Template associated with the survey by clicking on the name of the template or the edit button ( ) on the right side of template name.

3. Under the Content tab -> Content For, ensure you have added the HTML (plain text on rich) or SMS content for the intended language. Don’t forget to save your changes.

   

   
   

4. Now head over to Token Template page by navigating to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Token Template and select the token being used for the survey in question.

   

   
   

5. Select the preferred language for the token, making sure it’s the same as the message content and save it.

   

   
   

6. From the Dispatch Settings (CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Dispatch Settings) select the dispatch.

   

   
   

7. Tie up the Token to this dispatch (ensure your delivery policy allows for the selected message template).

   

   
   

During the creation of message templates, it is possible to preview changes on the go without having to make a dispatch live. See the below steps, if you are unable to preview and test your messages:

1. Navigate to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Message Template.

   

   
   

2. Select the Message Template associated with the survey by clicking on the name of the template or the edit button ( ) on the right side of template name.

   Note: The Preview & Send feature is only available for email type message templates.

3. Click on the tab marked Preview & Send and select the questionnaire for which the preview is required.

   

   Note: If the selected questionnaire is not compatible (the template uses prefills which are not present in the selected questionnaire), the send function won’t work.

4. To send the test email, select the users from the drop down on the right-hand side.

   Note: You can only select recipients that are users of your Webex Experience Management account. The limit of users you can select is five.

To set up a dispatch, a questionnaire, a token and a policy for delivery must be associated. If you notice that while setting up your dispatch, a particular Delivery Policy is not present, follow the below steps:

1. From the Dispatch Settings (CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Dispatch Settings) select the dispatch (select Create New if you do not want to edit an existing dispatch).

   

   
   

2. Make a note of the Questionnaire Name if you are editing an existing dispatch. For a new dispatch, note the Questionnaire that you wish to use).

3. Navigate to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Delivery Policy.

   

   
   

4. Select the Delivery Policy which is not showing up during the setup of the dispatch and scroll down to the section marked Fatigue Rules.

   

   
   

5. Make a note of the unique identifier. Now navigate to the Questionnaire Builder (CX Setup -> Questionnaire Builder) and select the earlier noted questionnaire from step 2.

6. If the UUID is not present in the questionnaire, you should add it as a prefill. Alternatively, you can note any other prefill from that questionnaire and edit the fatigue rules to use that prefill as the UUID (be sure to enable the option “Show all questionnaire prefills for UUID”).

7. Return to the Dispatch Settings page and update the dispatch or create a new dispatch with the modified delivery policy.

Delivery Policy can be used not only to define the order and type of messages that need to be delivered but also the time between consecutive messages. If you are having trouble setting the time between consecutive messages, refer to the below steps:

1. Navigate to CX Setup -> Invitations & Tokens from the left pane -> Invitations -> Delivery Policy.

   

   
   

2. Select the Delivery Policy by clicking on the name of the policy or by clicking on the edit button to the right of the policy name.

3. Scroll to section marked Messages & Schedules and for the first message, set the “Delay Delivery By” from the options in the drop down. Repeat this for every consecutive message within that delivery policy.

   

4. Scroll further down to the section titled “Business Rules” and choose the days of the week during which you want the surveys to reach your customers.

   

   
   

5. You can also set the operating hours during which the messages will be sent for the selected days.

   Note In the example in point no. 3 and 4, the delay between the messages is considered during non-operating hours as well. However, if the delay elapses during the non-operating, the message is not sent until the start of the next window of operating hours as defined.

The Delivery Policy requires an Amazon or Azure queue to be configured in Experience Management. This configuration is saved along with each Delivery Policy.

If you are having trouble creating a new Delivery Policy in your Experience Management with the following message: “INVITATION QUEUE DETAILS MISSING”, then follow the below steps:

Step 1: You can start by navigating to CX Setup -> Account Settings -> Integrations.

Step 2: Use the scroll bar on the top of the integrations page to navigate to the header titled “Invitations Queue”.

Step 3: Select a queue type from the dropdown (Microsoft Azure Queue or Amazon SQS Queue and enter the requisite information. For Microsoft Azure Queue, you need to provide the Queue name and the Connection String. For Amazon SQS Queue, you need to provide the Access ID, the Secret Access Key, Region and the Queue URL.

Step 4: Click on update and begin creating the Delivery Policy.

If you are facing API failures and notice errors that indicate your invitations are not being pushed to Experience Management, then this might indicate that the API endpoint for your hosted infrastructure is not updated in your account. A typical error associated with this issue is: “invitationsExternalHostURL for dispatchRequest is not set”

To remedy this, follow the below steps:

Step 1: Note down your API Endpoint where your dispatcher is hosted

Step 2: Navigate to the Edit Profile section of your account

Step 3: Scroll down till you reach a boxed section titled “API ENDPOINT FOR SENDING INVITES”

Step 4: Enter the API Endpoint URL and click on update

If you are trying to log in to your ACM application’s frontend but even after entering the correct credentials you are getting an error as below:

Follow the below steps to fix this error (provided the issue is not with the correctness of the credentials):

Step 1: Note down your API Endpoint where your dispatcher is hosted

Step 2: Navigate to the Edit Profile section of your account

Step 3: Scroll down till you reach a boxed section titled “API KEY”

Step 4: Click on create, to generate a new API key.

Step 5: Using the account credentials (not the generated API key), re-attempt login to the ACM application.