Snapshot 64373
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Declarative Webhooks 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. 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, 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, the canvas app connects to the server and stores the following data: Salesforce Org Id Salesforce User Id 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 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 and statistics is: Date and time of 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 relay server, but the external system must be capable of login into Salesforce using Salesforce REST API. Edit the inbound call template page layout and remove the InboundTemplateCanvas VF page. 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 this URL: /services/apexrest/d_wh/InboundCall?templateId=… and provide the inbound call template id. HIPAA Compliance Declarative Webhooks is HIPAA compliant. In contrast to other middleware that may store and persist Protected Health Information (PHI) on external servers, Declarative Webhooks sets itself apart by prioritizing Salesforce-native functionality as much as possible. Our approach involves SSL-secured requests over HTTPS during inbound calls from external servers into Salesforce. These requests are transmitted to relay servers, which then facilitate the transfer of information to Salesforce. No data, including PHI, is actually persisted or stored on Omnitoria’s servers. The transient nature of the information, coupled with the inability to access it externally from Salesforce or the originating system, aligns Declarative Webhooks with the HIPAA Conduit Exception Rule. This rule is applicable to organizations that, although they might typically be considered business associates, are exempted due to their transient access to PHI. As conduits, these organizations, including Declarative Webhooks, only provide data transmission services. The storage of PHI by a conduit must be transient and not persistent, precisely mirroring the operational mechanism of Declarative Webhooks inbound relay servers. Declarative WebhooksOur PlansBook a DemoUser GuideInstallSecurityFullfillment PolicyTerms of Service Learning HubSaleforce IntegrationsArticlesUpdates & News AboutOur StoryMeet the TeamPartnersContact Omnitoria helps Salesforce customers, admins and developers build and scale faster. © Omnitoria, All Rights Reserved.