Salesforce limits
S4S Cloud 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 S4S Cloud data is correctly sent to Salesforce. If usage is particularly heavy you may consider purchasing more page views from Salesforce.
Monitor your Site usage within Salesforce. Consider the points below if you find that your website is approaching or exceeding the limits.
Page requests
S4S Cloud sends a request for each form submission, and each visitor update.
The frequency of visitor updates can be adjusted in the client settings. The S4S Cloud 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.
S4S Cloud 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.
S4S Cloud also includes client settings to limit form submissions. Adjust the time and submission limits as required to limit unwanted bulk submissions.
Bandwidth
S4S Cloud 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.
If not uploading files bandwidth probably isn’t going to be an issue. The 40GB monthly allowance for production orgs would cover tens of millions of typical S4S Cloud requests.
Request time
Salesforce also limits request time. In general S4S Cloud 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 S4S Cloud automations are processed on all form submissions and visitor updates. Disable any that are unnecessary or not in use.
When configuring S4S Cloud automations, prefer additional conditions over checks in custom Flows and triggers. S4S Cloud queries the visitor and related object(s) 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.
During S4S Cloud stress testing, we found that client requests with randomly generated data using typical form mappings and automations complete in less than 1 second each. Page view limits are much more likely to be an issue over request time.
Identified visitors
All S4S Cloud 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.
S4S Cloud 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, Facets and general data still allow Personalization to occur on the client side for anonymous visitors.
Rogue requests
S4S Cloud implements mechanisms 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.