Guest User Access Comes to BrightSIGN
Guest Users in Salesforce typically can't edit records or save files due to security restrictions since Spring '21, preventing unauthenticated users from signing records. BrightSIGN version 4.1 introduces a workaround where Guest Users can capture signatures as files, though these files are initially orphaned since they can't be linked directly to records. Admins can then implement Apex triggers or additional components to associate these files to relevant records securely post-installation. This approach respects security review requirements while empowering organizations to support guest signature capture.
- Guest Users cannot have Edit access to records since Spring '21 release.
- BrightSIGN v4.1 allows Guest Users to capture signatures as files with limitations.
- Orphaned files need Apex triggers or components to link them to records.
- Modifying package to run in system context without sharing fails security review.
- Admins can extend package after install to handle guest file associations securely.
Over the last couple of years I've received a number of requests to allow Unauthenticated/Guest Users to be able to sign records like internal users. Unfortunately this isn't something that isn't possible for a security reviewed package. In order to be able to save a File/Attachment against a record, the user must have Edit access to the record, and since the Spring '21 release of Salesforce Guest Users can't have Edit access. The Experience Cloud Developer Guide has a handy workaround of executing in system context and without sharing . but if I change the BrightSIGN code to work this way it will fail the security review, and rightly so - I'd be ignoring the security settings of the org and allowing an unauthenticated user to carry out actions that should be blocked. While I can't publish a package that allows a Guest User to execute code in system context without sharing, there's nothing to stop the owner of the org adding this capability after installing the package.