Working with Salesforce Sites

If you have ever worked with Salesforce Sites, you know that the Site Guest User has limited access. This is a deliberate measure on Salesforce's part to prevent external users from being able to modify or delete data in your Salesforce instance. Moreover, to comply with Salesforce's security review process, we need to add an additional layer of security.

In the example below, we will update a customer record in NetSuite using the Global API. The process is basically the same, no matter what you want to do. You need to create a ReadOnly permission set for the objects you want to read from, plus sharing rules for the same objects.

Here is a very basic example of an invocable apex class calling our Global API. It will create the record in NetSuite first and immediately sync it back to Salesforce.

By default, the Site Guest User will not have access to Breadwinner's custom objects, so you must create a custom ReadOnly permission set. The 'Breadwinner Read Only' permission set cannot be assigned to the Site Guest User because it has the 'View All' object permission enabled, which is not allowed for the Site Guest User, so you must create your own.

Read access to the "NetSuite Object" and "Subsidiary" is required for all actions, and in this case, because we are updating the customer, we need to give read access to the NetSuite Company object, too.

Enable 'Read' at the Object Permissions level and check Read Access for all the fields at the Fields Permissions level for all objects that need access.



Assign that permission set to the Site Guest User.

We also need to create Sharing Rules for each object. More can be found here about sharing rules.

The image below is an example of sharing rules for the NetSuite Object

Update NetSuite records via Site Guest User:

The 'skipDML' option here is important if you are doing an update because the Site Guest User only has the ability to Read or Create, not update.