Duncan_Stewart | 2017-01-12 17:02:08 UTC | #1
We're looking to expand our IVR functionality in PureCloud, and I have a couple of internal clients who would like to use an IVR to collect information from the caller and write it to Salesforce. The Salesforce data dip connector could be used to figure out who the caller is, but it appears that getting data retrieved in the IVR and writing it out to Salesforce would not be trivial.
I have the following questions, initially (my apologies in advance if the terminology is off; I'll get better, I promise!) :
- As part of an IVR, can a Call Bridge Action pass data out to an external REST service?
- I've seen reference elsewhere to storing information in an interaction note field, and then writing an integration to reach into PureCloud to retrieve that Note (or those notes). Would that be an option? I could imagine a process that would query those notes based on the last few hours' calls. (Then again, if part of the standard Salesforce integration is to capture the notes in a Salesforce activity, then I could just query those activities natively, once I/we figure out how to move the data from the IVR to the note.
- If 2) ^ is possible, is there any option for having a custom table associated to our license/organization/data where we could store call information, and then retrieve it?
Thanks!
Duncan
tim.smith | 2017-01-12 17:14:39 UTC | #2
Duncan_Stewart, post:1, topic:791
As part of an IVR, can a Call Bridge Action pass data out to an external REST service?
That would be possible using custom bridge server actions. You get to define the request and response schema, so you can pass data to the service and return a confirmation. That's the opposite direction of the intended use case, but it should work.
Duncan_Stewart, post:1, topic:791
I've seen reference elsewhere to storing information in an interaction note field, and then writing an integration to reach into PureCloud to retrieve that
Yes, you can use Architect's Set Participant Data action to set any variables you have in Architect to custom attributes on the participant (the caller). You can then retrieve that data at a later date via GET /api/v2/conversations/{conversationId}. The data will be found on the attributes property of the caller's participant.
I actually just wrote an example that will retrieve participant attributes for a list of conversations and then export the data. It's the CDR report in the Open Data Exporter open source project.
Duncan_Stewart, post:1, topic:791
If 2) ^ is possible, is there any option for having a custom table associated to our license/organization/data where we could store call information, and then retrieve it?
No, PureCloud does not maintain any custom databases for you to use. The only information available is that which is available through the API.
Duncan_Stewart | 2017-01-12 19:54:33 UTC | #3
Thanks Tim -- those answers & links are really helpful!
It looks like the custom bridge server actions are the way to go, though what I want to have happen is to be able to collect a number of attributes during the call, and then submit/POST them all together. Am I correct in thinking that I would define Architect variables, and then (at the appropriate time) create an action (and the corresponding webservice) that would use those variables as parameters?
In my head the flow would be ~ this (best case):
- Call comes in, we use standard bridge server action to get Salesforce Contact.Id
- Capture caller's input(s) in the IVR, storing the values in Architect-defined variables
- Call custom bridge server action method(s) using those variables as params, return result (yay/nay)
- Store vars, result in conversation for later review
Assuming that I get to the point of having such an action (3^) defined, is there a way from PureCloud to verify it before adding it to an IVR, or would we have to put it into a test IVR of some sort and validate it through actual calls?
tim.smith | 2017-01-13 15:29:19 UTC | #4
It looks like you have a good understanding of the process required.
Duncan_Stewart, post:3, topic:791
is there a way from PureCloud to verify it before adding it to an IVR, or would we have to put it into a test IVR of some sort and validate it through actual calls?
Unfortunately, there is no way to simulate an architect flow; you must place a call to the IVR and test it live.
Just as an FYI, there is work planned to significantly enhance the service integration capabilities of Architect. One of the prominent features is the ability to configure requests and then test them from the UI without having to place a call. There isn't an ETA at this time as this project is still in the early stages.
Duncan_Stewart | 2017-01-13 17:23:03 UTC | #5
February, then ..? :stuckouttongue:
At this point, we don't have a Bridge Server set up, so it's all rather moot.
anon5606108 | 2017-01-13 18:38:46 UTC | #6
Hi Duncan
While Tim is correct that you cannot test the IVR call flow in any way other than actually calling in, you can isolate and test the Bridge Action call using REST calls into the PureCloud Bridge API. This has been tested with PostMan, but they’re all just REST calls, so feel free to use whatever you want.
The short version, if you’re already familiar with how things work on our side: Make a REST call to the following endpoint: /bridge/api/v1/actionCall/YOURACTIONNAMEHERE. This will accept a json entity which adheres to the Request Schema you have defined in setting up your connector, and will return a flattened version of the data as defined in your Response Schema. This is how your Call Bridge Action Step works when executing Architect flows.
The long, detailed version: From here, I will assume the following:
Once you are at this point, you will need to do the following to test your actions through our Bridge API:
- The endpoint you will need to call is: https://apps.{{environment}}/bridge/api/v1/actionCall/YOURACTIONNAMEHERE, where YOURACTIONNAMEHERE corresponds to the name of your published Bridge action.
- The body of this request should be the same as the body for your Web Services server request. Be sure to set the content type to application/json in the headers.
- You should apply authorization in the same way as presented in the article above, with one caveat: once the bearer token is in the headers, you will need to ensure that the word "bearer" is all lowercase. Unfortunately, the Bridge API is case-sensitive about the word, and Postman, at least in my test environment, supplies a capital B.
- Assuming your data matches something that your Web Service will return, you should receive a flattened version of the return body. The flattening process moves everything from its nested objects to the top layer, with a '.' separating the layers. If your call does not return data, an error should be produced.
I have done my best to identify and supply further documentation where necessary. However, if you find any part of these instructions unclear, please do not hesitate to reply to this thread.
Duncan_Stewart | 2017-04-05 20:08:47 UTC | #7
I've looked through the Resource Center to find instructions for creating a Custom Action that leverages a web service, but I'm not having much luck. I can see the default actions (getContactByPhoneNumber, etc.) but I don't see any documentation for accessing an exposed web service method that I've created in Salesforce.
tim.smith | 2017-04-06 18:19:18 UTC | #8
Take a look at the user defined schemas: https://developer.mypurecloud.com/api/webservice-datadip/
Duncan_Stewart | 2017-04-06 18:44:52 UTC | #9
I was beginning to think that it was the webservice datadip connector that I needed, and not (just) the Salesforce data dip; as I'm only seeing the Salesforce one in our instance, I guess we also need the webservice connector.
I think, then, that we'll use the mostly-preconfigured Salesforce actions to get the Caller's Salesforce contact.Id, store that in a variable, and then use the webservice action(s) to retrieve the subsequent information that I need from Salesforce..? Plausible?
tim.smith | 2017-04-06 18:46:02 UTC | #10
Sure, you can use a combination of OOTB and custom connectors.
system | 2017-08-28 19:29:54 UTC | #12
This post was migrated from the old Developer Forum.
ref: 791