The Rule That Reaches the Public

Module 3 of 6 in the chapter Public Groups and Criteria-Based Sharing Rules, chapter 7 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When anonymous visitors use your site, how do they see any records at all, and how do you make sure they see only what you mean?

Here’s a question I ask in class. You have a public site, a page anyone on the internet can open without logging in. How do I restrict what the public users can see or not see?

Somebody always remembers: the guest user profile. Every site and every Experience Cloud site has a guest user, one user that stands for every anonymous visitor, with a profile of its own. That’s an important concept to get. Whatever that one user can see, anyone can see.

Chapter 14 sets up sites and their guest users. This module is about the one rule that opens records to them.

The only way in

“A guest user sharing rule is a special type of criteria-based sharing rule and the only way to grant record access to unauthenticated guest users. Guest user sharing rules can only grant Read Only access” (Create Guest User Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-07).

It’s the exact same thing as a criteria-based rule (module 2), with one difference: the target. Instead of a group or a role, you pick the guest user of one site.

It wasn’t always the only way. A student in my class had a project where guests uploaded files, and in the middle of the project Salesforce put limitations on the guest profiles. They were locking it down. Today that lockdown is a setting called Secure guest user record access, and “This setting is enabled by default and can’t be disabled.” With it, guest users (Best Practices and Considerations When Working with the Site Guest User Record (opens in a new tab), Salesforce Help, checked 2026-11-07):

“Use private org-wide defaults for all objects. This access level can’t be changed.”
“Can’t be added to queues or public groups.”
“Can’t be given access to records through manual sharing or Apex managed sharing.”
“Can be granted Read Only access to records only through guest user sharing rules.”

So for the anonymous public, the 25 ways shrink to one.

Read the warning before you save

Salesforce puts a warning on the page, and I want you to read it slowly: “By creating a guest user sharing rule, you’re allowing immediate and unlimited access to all records matching the sharing rule’s criteria to anyone” (Create Guest User Sharing Rules).

Immediate. Unlimited. Anyone. This sharing rule grants access without login credentials, so you need to be careful using this one. Salesforce adds: “Salesforce is not responsible for any exposure of your data to unauthenticated users based on this change from default settings” (same page).

Danger: this rule makes records visible to an unlimited number of people. Every other rule in this chapter shares with people you can name: a group, a role, a team. This one shares with anyone on the internet, and you’ll never know who they were. One wrong value in the criteria, and records you meant to keep inside are public. Be very, very careful.

Keep guest rules off your core business records

Think about what lives on accounts and contacts. Your customers, their people, their phone numbers and email addresses, side by side with every other customer’s. A guest rule on an object like that is one criteria mistake away from showing one customer’s records to another customer, or to anyone at all. Don’t put guest user sharing rules on accounts, contacts, or any object that holds customer or personal data.

My recommendation: create a special custom object that is designed just for public access. Give it only the fields the public is meant to read, and fill it from your internal records with an automation. Then the guest rule shares that object and nothing else.

Here’s why I like it. Everyone who opens that object in Setup knows it’s public: the name says so, and every field on it was put there to be read by anyone. When someone adds a field to the account next year, it doesn’t go public by accident, because the account was never shared. You can be really aware of what you’re sharing.

Two locks: the profile and the rule

A guest sees a record only when two locks are open, the same two as for everyone (chapter 1): the office and the file cabinet.

The guest user’s profile decides which objects and which fields. You grant the profile access to the object using object-level security, and field-level security decides the fields. Chapter 14 covers the guest profile.
The guest user sharing rule decides which records, and only Read Only.

So design both. A rule that matches the right records still shows every field the guest profile can read. And a guest profile with access to an object still shows nothing until a rule matches records.

Click to enlarge

Design the criteria for the public

Everything module 2 said about the field you share on applies, more so. For a guest rule, that field decides what the internet can read.

Share on an explicit field. A checkbox such as “Published to the site,” set on purpose, is safer than a rule on a status or a type that changes for other reasons. When someone changes a status for their own work, they shouldn’t be publishing a record by accident.
Decide who can set it. Field-level security and the automation that fills it are now your publishing process.
Count it. Guest user sharing rules “count towards the limit of 50 criteria-based sharing rules per object” (Best Practices and Considerations When Working with the Site Guest User Record). In class I said “part of your 50, I think.” It is: you don’t get 50 and 50.
Records owned by site users. A guest rule can include records owned by high-volume site users, “If available in your org.” By default, “sharing rules include only records owned by authenticated users, guest users, and queues” (Create Guest User Sharing Rules).

One more object that matters for public sites: “For Product2, you can create only guest user sharing rules. Criteria-based and owner-based sharing rules aren’t available” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). Chapter 6, module 3 explained why: products have no owner.

Records guests create

When you set up a site, you designate the default record owners. Here’s why. “The site guest user must never own records.” A case from web-to-case, or a record created by a flow, is owned by the guest user unless you change it, and “If the record owner isn’t changed, anyone who has guest access to your Experience Cloud site can see the record.” Turn on Reassign new records created by guest users to the default owner (Best Practices and Considerations When Working with the Site Guest User Record).

Then choose that owner with care (Best Practices and Considerations for Using the Guest Record Default Owner (opens in a new tab), Salesforce Help, checked 2026-11-07):

“Make sure that you have more than one person being assigned as the owner.” One owner of every guest record will cause ownership skew (chapter 6, module 3), and it breaks when that user leaves.
“When possible, create and assign queues as owners of records created by guest users.”
Rules and automation that look for the guest as the owner must change: conditions “based on OwnerId equaling the guest user ID must be updated to CreatedByID.”

And know what the visitor experiences: after a guest creates a record, they lose access to it, “since the record owner is assigned to a different user in the org” (same page). That’s the design working. Build the site’s next page with that in mind.

Click to enlarge

What an architect decides here

Which objects guest rules may touch. My recommendation: a custom object built only for public access, never accounts, contacts or other customer data.
Which sites have guest access at all. Salesforce’s first best practice: “Enforce authentication where possible, and lock down access to the site guest user.”
For each guest rule, which records anyone may read, and the explicit field that marks them, with who can set it.
The guest profile’s objects and fields, designed with the rule (chapter 14).
How many of the 50 rules per object guest rules will use.
Who owns records guests create: a default owner or a queue, never the guest, with rules on CreatedById.
What the visitor sees after they create a record.

Beyond the exam: what AI changes. Public sites are where companies put agents in front of strangers. Before one goes live, answer one question: which user does it run as, and what can that user read? Anything a guest rule matches is readable by anyone already. An agent makes it easier to find: it searches, summarizes and answers, for anyone who asks. So review your guest rules as if someone will ask the agent for every record they match. Chapter 20 covers agents.

Explore

Create Guest User Sharing Rules (opens in a new tab), Salesforce Help (checked 2026-11-07)
Best Practices and Considerations When Working with the Site Guest User Record (opens in a new tab), Salesforce Help (checked 2026-11-07)
Best Practices and Considerations for Using the Guest Record Default Owner (opens in a new tab), Salesforce Help (checked 2026-11-07)
Sharing Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)