Portal Health Check
A Portal Health Check is a Setup tool in Salesforce that reports on the security-related settings of portal and Experience Cloud site users.
Definition
A Portal Health Check is a Setup tool in Salesforce that reports on the security-related settings of portal and Experience Cloud site users. It surfaces the permissions, object and field access, and sharing configuration that decide what an external user can see, so an administrator can review exposure in one place instead of clicking through dozens of screens.
The tool produces four read-only reports built from your portal profiles, organization-wide defaults, and sharing rules. It does not change anything on its own. You read each report, decide whether the access shown is intended, and then go fix anything that looks too broad in the normal Setup areas.
How Portal Health Check audits external access
How the four Portal Health Check reports fit together
Portal Health Check is organized as four separate reports, and each answers a different access question. Administrative and User Permissions lists the system and user permissions granted to your portal profiles, so you can spot dangerous flags like Modify All Data sitting on an external profile. Object Access and Field-Level Security shows which objects and fields portal users can read, create, edit, or delete. Sharing Organization-Wide Defaults lists the default internal and external access for every standard and custom object, which is the baseline the rest of your sharing model builds on. Sharing Rules details each rule that grants record access to portal users and how many users it affects. Read together, the four reports trace the full path from a profile permission down to an individual record. A field can only leak if the profile has object access, the field-level security exposes it, and the org-wide default or a sharing rule grants the row. Checking all four is how you confirm that no single misconfiguration opens a door you did not intend.
What the reports deliberately leave out
The reports are useful, but they are not a complete picture, and treating them as one is a common mistake. Portal Health Check does not include criteria-based sharing, high-volume portal users, or Self-Service portal users. It also ignores access granted through permission sets, manual sharing, Apex-managed sharing, territories, list views, groups, queues, teams, content libraries, and folders. That is a long list of blind spots. A guest or portal user could still reach data through any of those paths without a single flag appearing in the report. The practical takeaway is to treat Portal Health Check as one layer, not the whole audit. Pair it with a direct review of permission sets assigned to external users and, for Experience Cloud guest access, the Guest User Sharing Rule Access Report. The Object Access and Field-Level Security report is also worth cross-checking, because the Sharing Rules report grants rows but does not verify that the profile actually has the object permission to open them. Knowing the gaps keeps you from a false sense of safety.
Reading the Sharing Rules report and the Number of Portal Users Affected
The Sharing Rules report is the one most admins spend the most time in, because sharing rules are where over-broad external access usually hides. Each row shows a rule that grants portal users access to records, who owns those records, who they are shared with, and a Number of Portal Users Affected column. That count includes the users named in the rule plus, when Grant Access Using Hierarchies is enabled for the object, any portal users above them in the role or territory hierarchy. A surprisingly large number in that column is your signal to look closer. Suppose you find a sharing rule that shares all Cases owned by a support queue with a public group, and the affected count reads in the thousands. That tells you the rule is wider than its name suggests, probably because hierarchy access is pulling in users you never meant to include. From the report you can click Edit to change the access level, or drill into the Owned By and Shared With links to see exactly which user set is involved. Remember the report skips criteria-based rules entirely, so review those separately.
Where Portal Health Check fits among Salesforce security tools
It helps to know how Portal Health Check relates to the other audit tools, because the names are similar and easy to confuse. Security Health Check, reached from Setup under Health Check, scores your whole org against a security baseline like the Salesforce Baseline Standard and can fix settings to match it. That tool is about org-wide settings such as password policies and session timeouts. Portal Health Check is narrower and external-facing. It is specifically about what portal and Experience Cloud users can access through their profiles and your sharing model. For modern Experience Cloud sites with unauthenticated visitors, the Guest User Sharing Rule Access Report is the closer companion, since it shows exactly which objects, records, and fields a guest user can reach. A sensible routine uses all three. Run Security Health Check for org settings, Portal Health Check for portal profile and sharing exposure, and the Guest User report for guest access on each site. Each covers a slice the others miss, and external data exposure is the kind of mistake that turns into a public incident.
Guest users and the least-privilege rule
The reason all of this matters is the guest user, the unauthenticated profile behind every public Experience Cloud page. Salesforce is direct about the standard here. Review every default object permission on the guest user profile and apply the most restrictive setting, and for almost all objects the guest user should have no access at all. Never grant View All Records or Modify All Records to a guest user, and avoid update or delete permissions entirely. The danger with guest user sharing rules is that they hand access to people with no login. Creating one grants immediate access to every record matching the rule criteria to anyone who reaches the site. Portal Health Check helps you catch profile permissions that drifted past least privilege, but the guest user case is sharp enough that you should also verify it directly. New objects ship with default sharing, new fields arrive with field-level security set, and new sharing rules get added without anyone tracing the guest implication. Run the check after any change to a site, after a release that touches sharing, and on a quarterly cadence regardless. It is free and fast.
Run Portal Health Check and read its four reports
Portal Health Check lives in Setup and runs on demand. You open it, pick a report, review the access it shows, and remediate anything that is broader than you intended. The steps below walk through a single pass.
- Open Portal Health Check
From Setup, in the Quick Find box, enter Portal Health Check, then select Portal Health Check. You need Customize Application, Manage Users, and Modify All Data to view the reports.
- Review permissions and field access
Open Administrative and User Permissions and look for risky flags on external profiles. Then open Object Access and Field-Level Security to confirm portal users only see the objects and fields they need.
- Check defaults and sharing rules
Open Sharing Organization-Wide Defaults to confirm external access is locked down at the baseline. Then open Sharing Rules and scan the Number of Portal Users Affected column for any rule wider than expected.
- Remediate outside the report
The reports are read-only, so fix issues in the normal Setup areas. Tighten profiles, adjust field-level security, raise org-wide defaults, or edit the offending sharing rule, then rerun the report to confirm.
Lists the system and user permissions granted to portal profiles so you can catch over-broad flags.
Shows which objects and fields portal users can read, create, edit, or delete.
Lists the default internal and external access for every standard and custom object.
Details each rule granting record access to portal users and the Number of Portal Users Affected.
- The reports are read-only. Portal Health Check never changes settings, so remediation always happens in the underlying Setup areas.
- Coverage has real gaps. Permission sets, criteria-based sharing, manual sharing, Apex sharing, and high-volume portal users do not appear in any report.
- The Sharing Rules report grants rows but does not check object permissions, so cross-reference the Object Access and Field-Level Security report.
- For unauthenticated Experience Cloud visitors, also run the Guest User Sharing Rule Access Report, which Portal Health Check does not replace.
Prefer this walkthrough as its own page? How to Portal Health Check in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Portal Health CheckSalesforce
- View the Sharing Rules Report for Portal UsersSalesforce
Straight from the source - Salesforce's reference material on Portal Health Check.
Hands-on resources to go deeper on Portal Health Check.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Portal Health Check primarily evaluate in an Experience Cloud site?
Q2. Which finding is Portal Health Check designed to flag as a risk?
Q3. When is running Portal Health Check most warranted?
Discussion
Loading discussion…