Security
Like other software on the AppExchange, we had to pass a rigorous security review process administered by Salesforce as a precondition of being listed on the AppExchange.
Installing the application and giving access to your users
When you install the application, the recommended option to choose is “Install for Admin Only”. That way, only the system administrators will have access to edit templates, view stored credentials and administer the app.
The application also comes with 3 permission sets that you can assign to users that are not System Administrators:
- Declarative Webhooks Admin: Assign this permission set to users who needs to be able to manage the application, create templates, sequences,, view/edit credentials, check for logs, etc
- Declarative Webhooks User: Assign this permission set to users who needs to use integrations defined by the admins, like visual flows that use the Callout or Sequence screen, or custom buttons on page layouts
- Declarative Webhooks Experience Cloud User: Similar to the Declarative Webhooks User, but without the “View All” permission, which allows you to assign this permission set to an Experience Cloud User
Security for outbound calls
When you define an Callout Template, you have the option to provide credentials that will be sent in an outbound call. These credentials are stored in protected custom settings and you only have access to them in the Callout Template edit page. Make sure only the admin users have access to that edit page.
Security for Inbound calls
Declarative Webhooks is almost entirely native to Salesforce. For all components that are fully native, we inherit the Salesforce security you know and trust. Outbound callouts are fully native to the Salesforce platform. Inbound calls that are set to use the “Authenticated with REST API” Access Type are also fully native to Salesforce.
However, Inbound calls that are NOT set to use the “Authenticated with REST API” Access Type, while mostly native to Salesforce, use the Declarative Webhook Relay Server to handle the connections between the external system and Salesforce. There are some additional considerations here when it comes to security.
How Inbound Calls Work and What Data We Store
Whenever a user self-authorizes in the Inbound Call Template page, for and Inbound Call Template that is NOT set to use the “Authenticated with REST API” Access Type, the canvas app connects to the Declarative Webhook Relay Server and stores the following data:
- Salesforce Org Id
- Salesforce User Id
- Salesforce Username
- Client Id
- Client Token
We store this information in order to provide a connection to the org for incoming calls.
After the self-authorization, the server stores the Declarative Webhooks template id, creates a unique URL linked to that template, and displays it in the Inbound Call Template page.
When a call is made to the URL, the server will authenticate into Salesforce and relay the call data to the template. The call details are passed through. No call data is stored on the Relay Server. The only data that is stored for metrics, statistics and error handling is:
- Date and time of the inbound call
- Org Id & Template Id
- Response code: 200, 400, 500, etc.
Where is the Declarative Webhooks Relay Server hosted?
Declarative Webhooks Relay Server runs on Heroku. Heroku is a Salesforce product used for application hosting. For more information on Heroku security please see the following: https://www.heroku.com/policy/security
Can Declarative Webhooks be used without the Relay Server?
Yes, there is a way to use DW inbound calls without having a public URL or passing data through the Declarative Webhook Relay Server, but the external system that is making the call must be capable of login into Salesforce using Salesforce REST API.
- Edit the Inbound Call Template you wish to make private and set the Access Type field to “Authenticated with REST API”. That will ensure the inbound call is not connected with the Relay Server.
- To make a call that uses an inbound call template, after the REST authentication, use the URL displayed on the inbound call template page, similar to the one in the image below.
