How to Dynamically Call a Web Service using Process Builder in Salesforce?

 

OR How to Use Process Builder instead of Trigger?

Written by: Martin Bystriansky, CRM developer

What is our goal?

 

We want to develop a universal application and give an administrator the ability to call a web service dynamically, i.e. with different inputs at different times from anywhere in the system.

We will present the case on the example of integration into the Staffino service, which is possible thanks to our developed app STAFFINO INTEGRATION APP. Staffino is a software solution for, among other things, the collection of clear information within CX/EX (Customer/Employee Experience). Staffino sends questionnaires to customers, evaluates and processes them, and provides CX/EX information.

 

What problem are we solving?

• We need to call the web service and authenticate it with a token.
• We want to create a simple architecture that is easy to use.
• We need to retrieve data from a web service that is not available immediately upon our first inquiry.
• We want to allow the user – administrator to perform the action, after receiving data from WS.
• but We can’t use the trigger because we don’t know when to call WS. Only the user of the application, the administrator, who knows his system, has this information.

 

 

We describe Architecture in these parts:

• entering and storing a token
• calling a web service from the Process Builder environment,
• creation of Custom objects for data storage,
• JOB settings for retransmission of unsuccessfully processed calls (in case of service unavailability).

 

 

Entering and storing a token

We will use custom metadata to store the authorization token. We will create a custom lightning web component to make it easier for the user to enter.

Minimal settings to maximize user comfort 

 

Calling a web service from the Process Builder environment

We wrap the web service call in a method. In order for this method to be available from Process Builder, it must contain the notation @invocable method.

Warning! Each class can contain exactly one invocable method. It is best to use the List of Object lists to enter this method. We declare the type of this object in our class as a nested class. All the parameters we want to be able to be executed from Process Builder must contain the notation @invocable variable.

 

 

 

 

Creation of Custom objects for data storage,

We will create objects that will be an image of the objects processed within the web service, which will allow us to minimize the need to convert the acquired data for storage in the Salesforce database while gaining the ability to report and monitor for users.

The Feedback object represents the customer’s response and has a link to the interaction – requesting an opinion

 

JOB settings for retransmission of unsuccessfully processed calls (in case of service unavailability).

Just as we made a simple setup to get feedback, we will create an invocable method to handle calls to our WS that have failed to become unavailable. It is up to you whether you leave this method available to the user for JOB setup, or you will create a simpler interface for the user the way we did it in the basic setup.

We have indicated the possibilities of solving a software request via Process Builder for cases where it is not possible to use a trigger. In this application, we can use the dynamic service for the creation of a universal connector for a web service, the call of which the customer can set up himself to suit his specific needs. This will allow us to create a generic application that provides a basic tunnel with all its capabilities and on the other hand, will allow the customer to take full advantage of the basic functionality of Salesforce – Process Builder and at the same time does not have to adapt operation to the system but adapt the system itself without further development.