Following Winter 20' release, it looks like Site Guest user will have restricted access to objects. We heavily use unathenticated webhooks to notify of external systems changes to Salesforce. Can this still be done? If yes, what considerations do we need to make?
asked Jan 30, 2020 at 15:41
-
The Community Team also have this site which is helpful in explaining some of the changes: learncommunitycloud.com/s/news/…– BritishBoyinDCCommented Jan 31, 2020 at 14:08
Add a comment
|
1 Answer
You can, but you have to be incredibly careful. I've been going through the process of testing and modifying such implementations for our customers.
Approach 1
Write your REST class as without sharing, and make sure any triggers/flows which follow from the DML of your REST class are OK.
This has the advantage of being simple, but is somewhat brittle. If someone later introduces something like a Flow which gets invoked as a result of your REST service, then this can cause a fault which would have been hard to anticipate. We even found this a problem when the customer installed Financial Services Cloud on top of what we'd already done, and that introduced a load of profile-restricted stuff.
Approach 2
Just fire a Platform Event from the REST class, and do the DML in a trigger on the PE. This works by switching to the Automated Process User, who should have the required permissions.
This is robust to changes like the ones above, but makes it harder for you to give a synchronous response to the REST call. For example, if you were previously doing DML in your REST class, and returning validation errors back to the caller, you won't be able to do that anymore as you won't get a synchronous result. You would have to check the validity of the REST call manually in your rest class, and trust that if it passes the check, then the DML will succeed later. Arguably, this is a better way to separate concerns anyway, but it adds complexity.
