Performance considerations

Salesforce limits

The Send2CRM service uses a Salesforce public Site to provide REST endpoints for the JavaScript client. Much like standard API calls, these have daily and monthly limits imposed:

Salesforce Sites Usage and Billing

For websites with heavy traffic and a large number of identified visitors, additional steps may be required to ensure Send2CRM data is correctly sent to Salesforce. If usage is particularly heavy you may consider purchasing more page views from Salesforce.

Page requests

The Send2CRM client sends a request for each form submission, and each visitor update.

• The frequency of visitor updates can be adjusted in the client settings. The client has been designed to avoid unnecessary requests, for example visitor updates will not be sent if no action has occurred since the last. However you can also reduce the update frequency to mitigate too many page requests if required.

• It is possible to trigger visitor updates directly. Avoid placing obvious controls that allow visitors to trigger updates more frequently than the automated process.

• The Send2CRM service can process a single form submission against multiple mappings in a single request. Consider options to send data for multi-step forms all at once.

• There are also client settings available to limit form submissions. Adjust the time and submission limits as required to limit unwanted bulk submissions.

Bandwidth

All Send2CRM requests send and receive JSON data via a REST service, and are designed to be lightweight. For the most part requests and responses are measured in mere bytes and bandwidth is not a concern for production orgs.

• Although file attachments are supported, these use many times the bandwidth of normal requests. Avoid uploading large files via standard form submissions, configure the maximum file size to restrict (set to 0 to disable all file uploads). Websites with heavy traffic will likely want to use an alternate service for file handling, perhaps with its own Salesforce integration. See file uploads for more information.

• Avoid using personalization with very large Salesforce fields as these are sent back to the client on each visitor update.

Request time

Salesforce also limits request time. In general Send2CRM requests should take minimal time to process, however this may vary depending on configuration and what other automation is set up in your Salesforce org.

• Relevant automations are processed on all form submissions and visitor updates. Disable any that are unnecessary or not in use.

• When configuring automations, prefer additional conditions over checks in custom Flows and triggers. The visitor and related object(s) are queried only once, with the required fields included. Eliminating unnecessary actions at the condition level may avoid additional queries for related data in a Flow or trigger.

• Consider where existing Flows and triggers are unnecessarily inefficient. For example where a website form mapped to create/update a Lead includes a trigger that triples the save time, this may be added to the request time.

• If intensive operations via Flows or triggers cannot be avoided, consider using a staging object. The staging object can be updated quickly resulting in a shorter request time, then be processed into the required objects within Salesforce by another process. This also allows isolating errors from complex validation; website visitors are not exposed to them and the final processing can be repeated from the staged record at a later date without loss of information.

• Slower request times generally go un-noticed on the website for visitor updates as these are processed asynchronously. However form submissions must wait for the result so any improvements in this area will also improve form response time.

Identified visitors

All Send2CRM form submissions are sent to Salesforce. However visitor updates are only sent for identified visitors, those who have corresponding records such as Leads in Salesforce.

• Identify visitors who have sales potential, but avoid aggressively identifying those who do not. Visitors without potential pollute Salesforce records and generate unnecessary requests.

• The Send2CRM client offers various ways to record and calculate visitor intent purely on the client side which can help funnel only the useful leads into Salesforce.

• Goals, Segments and general data still allow Personalization to occur on the client side for anonymous visitors.

Rogue requests

Mechanisms are implemented to avoid processing requests from other clients, but the nature of allowing anonymous visitors to submit forms means that we can’t always stop determined operators. The mapping configuration means they can’t do any worse than a normal form submission, but high volume may introduce issues with Salesforce limits.

The shared key system rejects requests with HTTP error codes and a bare minimum of processing time when the key doesn’t match. This can be changed as often as you like.

Data storage

Salesforce also places limits on data storage, a total of 10GB for most production orgs. For very high traffic websites with a large number of visitor conversions additional data maintenance may be necessary.

• Check the current Salesforce usage by searching for ‘Storage Usage’ in Setup.

• Avoid identifying un-interesting website visitors. See Identified visitors section above.

• Configure the Maximum Sessions and Store Event Data custom settings to avoid keeping un-wanted data.

• Consider a scheduled job to delete visitor (send2crm__s2cVisitor__c) records that have not been modified for some time. The master-detail relationships will cause most related records to be deleted also, however this does not apply to lookup-related objects such as Leads and Contacts.