To test the integration, we're going to escalate a case in Salesforce. In our scenario, we escalate high-priority cases that still have the status New after an hour. To notify the assigned case owner, we're going to change the STATUS of a case to Escalated:
In our Salesforce, we have one case that meets our criteria, but the trigger works with every case where the status is changed to Escalated. Click on the case number that we want to escalate to inform the case owner to take a closer look. The page shows the case details, which also includes the interaction feed and its related items, for example, case comments.
To change the status of a case, click on the pencil next to the status field to edit it. It will change the form from text to input fields. Select the Escalated status from the list:
After changing the status we can save the new value. Click Save on the bottom of the form to accept the change. This will instantly trigger our workflow rule, and when the message is successfully sent through Twilio, we will see a new case comment added to the related case items:
We see that the case comment is created, which means that the outbound message was sent to ICS and delivered to Twilio. Because we are using the test credentials, the SMS is not yet delivered to our mobile phone.
Let's investigate the instance in ICS itself. Log into ICS and navigate to the monitoring page. Click on Tracking in the left-hand menu to see all instances that have recently run. If you have a lot of instances, you can use the primary tracking field value to find the instance. Enter your case number in the search field to filter out the other messages, in our case, it's 00001026. You can also limit the timeframe by changing it to the last hour or day:
If we look at the details of the instance, we see that the notification was received and the successful callback was called:
Despite all the details about the instance given, we won't find the message payload that was sent to Twilio and back to Salesforce on this page. Remember that we enabled tracing when activating the integration. This stated that the message payloads were also going to be saved. The payloads are saved to the ICS diagnostic log files. To retrieve these log files, navigate to the Monitoring page and find the Download Logs link on the right side of the page. Click on the link and select the Download Diagnostic Logs option.
This will download a ZIP file with all the log files of our instance. Unzip the downloaded file and take a look in either ics_server1-diagnostic.log or ics_server2-diagnostic.log. It can be a long file, so scroll to the end to find our instance tracing details. In our case, we can see the payload of the request message from Salesforce, a compressed request to Twilio, the response from Twilio, and the request to Salesforce.
Here we can see the message we sent to the mobile phone as part of the response:
<accountResource.definitions.newSms_response> <to>+31645100000</to> <from>+15005550006</from> <body>Sent from your Twilio trial account - Case #: 00001026, Product: GC1040, Case Subject: Delivered product GC1040 is missing essential parts</body> </accountResource.definitions.newSms_response>
We also see the request message to Salesforce that ultimately creates the comment:
<nstrgmpr:create xmlns:ens="urn:sobject.enterprise.soap.sforce.com" xmlns:nstrgmpr="http://xmlns.oracle.com/cloud/adapter/salesforce/ReceiveEscalatedCases_CALLBACK_SUC"> <nstrgmpr:CaseComment> <ens:CommentBody>The Case owner is notified about the escalation.</ens:CommentBody> <ens:IsPublished>true</ens:IsPublished> <ens:ParentId>500580000023G7aAAE</ens:ParentId> </nstrgmpr:CaseComment> </nstrgmpr:create>
In this scenario, everything went as planned for us, but in the real world it is possible we will run into problems with one of the applications we are integrating. For example, the phone number given is not verified or the number we are sending from is not one that is capable of sending SMS messages.
To simulate this and test if the fault callback will create a new FeedItem, we are going to change the Twilio connection settings and change the configuration so it uses the live credentials.
Log into ICS and navigate to the Connections page of the Developer Portal. Search for the Twillio_Ch4 connection and click the name to open the configuration. Reconfigure the Security settings and change the AccountSID and AuthToken values to represent the LIVE credentials of your account. Test and Save the connection. Notice the warning popping up mentioning that it might affect our integration. Click Yes and Exit Connection.
Navigate to the integrations page and see if our integration is still active; it should be, but if it is inactive, re-activate the integration. Now that we have set up the connection in ICS with the new credentials, we can come back to Salesforce and escalate the case again.
We can change the case status to Working first and subsequently change it back to Escalated. Instead of a new case comment being created, a new feed item is created in our personal feed. We can access our feed by clicking the feed icon in the menu on the left. In our feed, we see that a new item has been created, letting us know that the given phone number is not capable of sending SMS messages. The reason is that we are still using the number we can only use with our test credentials:
Let's investigate the instance in ICS itself. In ICS, navigate to the Tracking page. Again, search for the case number, for example, 00001026, to find our instance and to filter out the other messages. This time, ICS also reports that the instance has failed with a business fault:
If we look at the details of the instance, we see that the notification was received, an error occurred when invoking Twilio, and that the fault callback was called:
To see the fault details, we download the
Diagnostic Logs
. Again, look in the ics_server*-diagnostic.log file. We see the same error as is shown in our Salesforce feed:
{"code": 21606, "message": "The From phone number +15005550006 is not a valid, SMS-capable inbound phone number or short code for your account.", "more_info": "https://www.twilio.com/docs/errors/21606", "status": 400}
Now that we know we are using the wrong phone number in combination with the live credentials, we need to change it. Navigate to the list of active integrations, and before we can edit the integration, we need to deactivate it. Deactivate the integration using the actions menu (the hamburger icon) and edit the request mapping. Change the target's from value in the request mapping to represent the phone number you assigned when setting up Twilio. Subsequently save and exit the mapper and integration.
Now that we are using a real phone number to send our messages from we can re-activate the integration. You can enable tracing again, but it is not necessary.
Retest the process of escalating a case in Salesforce and test whether you receive a SMS message on the phone number mapped to the target's To node:
If you want to experiment with this scenario, it is possible to create an enrichment service to call Salesforce to retrieve the phone number from the case owner instead of assigning a hardcoded phone number to send the message to, as we did. For example, we can use the ownerId to retrieve a People object.