Best Practices and Considerations for Using the Guest Record Default Owner

General Best Practices and Considerations

• Any active user in an org (excepting guest users) can be assigned as the default owner of records created by guest users. However, only users with at least read access to the records can actually access them. Ensure that the user chosen as the default owner has at least read access on the records created by guest users.
• While the new default guest user field is helpful in assigning a record owner to records created by guest users, using the field as the sole way to assign users is not considered a best practice. Set up assignment rules, processes, or triggers to correctly assign records to different users or queues based on object or criteria.
• Make sure that you have more than one person being assigned as the owner of records created by guest users. One person owning all records created by guests leads to performance issues, and causes errors if the user is no longer active in the org.
• When possible, create and assign queues as owners of records created by guest users.
• Setting the default owner for records created by guests is an option in Experience Cloud sites.
• Check all out-of-the-box
• Reassign records in your org that are owned by the guest user site user. Use Data Loader to migrate existing records owned by guest users to a new designated user in the org.
• Avoid using Apex future methods to insert ContentVersion for guest users.

OwnerID vs. CreatedByID Fields

• Any existing conditions in rules and processes (such as assignment rules, processes, criteria-based sharing rules, flows, and list views) that are based on OwnerId equaling the guest user ID must be updated to CreatedByID. Remove any rules or processes that rely on the guest user ID as the owner.
• Review internal processes and ensure that employees and teams still have access to guest user records.

Apex Without Sharing

While using Apex without sharing is an option, use it rarely and with extreme caution.

• Any Apex code that creates and updates a record (in a single transaction) as a guest must run without sharing, also known as system mode. In such cases, when Apex code runs without sharing, the guest user should only update records they’ve just created, and no other record in Salesforce.
  

  Note See Create Custom Component for Guest User Flows for an example of a component code for flows that uses an Apex class without sharing.
• You may have a multi-step flow for guest users that creates a record and then updates the record. To allow the guest user to run the flow, save the flow with the System Context Without Sharing—Access All Data option.
• Custom implementations that create a record and view or update it later must use an encrypted key to identify and access the record (usually an encrypted record ID), Apex without sharing, and extra checks in the Apex class (for the subsequent VIEW or UPDATE process) to limit record exposure. Limit the scope of key encryption, and narrow down the records that can be updated to specific use cases. Always check to make sure that the record is created by the guest user.

Behavior Change After Record Creation

• If your implementation is using the out-of-the-box behavior for record creation, guest users who create a record see a toast message and are redirected to the page they were using before record creation. If you’d like to create a different experience for guest users, use flows in System Mode to redirect guest users to a different custom screen after they create a record.
• Your custom implementation may allow a guest user to create a record, after which the guest user automatically sees the record detail page of the just-created record. However, the guest user loses access to the just-created record, since the record owner is assigned to a different user in the org. In this case, consider changing your implementation so the guest user is taken to a different part of your site after creating a record.
• Guest users may have the option of associating a newly created record to a parent record via a lookup (for example, creating a contact and associating it to an account).If guest users create a new parent record via a lookup, they see an error in the org (because upon creation, the guest user loses access to the parent record). To avoid error messages, you can:
  • Ensure that your org has a parent record shared with guest users via a sharing rule, so the newly created record can be associated with it. The parent record should not contain any sensitive data; or
  • Remove the create object permission for guest users.