Documentation
Authenticated and Guest User Access Report and Monitoring gives you a visual overview of all objects, records, and permissions that the running user has access to.
Authenticated and Guest User Access Report and Monitoring
As of: Summer '23
Authored By: George Abboud
First Published: 01/17/2020 Last Updated: 06/8/2023
Reviews and Contributions:
Manish Aggarwal
Table of Content
Description
Authenticated and Guest User Access Report and Monitoring gives you a visual overview of all objects, records, and permissions that the running user has access to. Additionally, it outlines which public groups, permissions sets, if any, the user is a part of - which might impact sharing and record visibility.
After you install the managed package, you can quickly check your org's data security when it comes to specific users.
Note: This report should be run in the context of a specific user to return information relevant to that user.
AppExchange Listing URL
https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FYkDDUA1
Instructions for Use:
Real-time Runs
Install managed package into an org. Select 'Install for Admins Only' during installation.
If you run into an installation error stating that it could not install due to a scheduled job for the apex class, you have two options to resolve:
Delete the scheduled job, install, and then reschedule
Go to Deployment Settings from Setup in your org, and check the option: Allow deployments of components when corresponding Apex jobs are pending or in progress.
Grant a user (by profile or permission set) access to the Visualforce page called “UserAccessReport” that is part of the installed package.
Login as a specific user that you want to run the report for, and navigate to
Community (or Guest) User: https://[communityDomain]/[communityPrefix]/apex/uar__useraccessreport
For Guest users, to avoid any existing sessions, run the report from an incognito / private browsing session.
Internal User: https://[salesforceDomain]/apex/uar__useraccessreport
IMPORTANT: Once you are finished running the report, revert the configuration that was given to the user and revoke access to the “UserAccessReport” visualforce page.
Optional: Include specific objects regardless of access
Use the includeObjects URL parameter with a comma-separated list of object api names to include
Optional: Exclude specific objects regardless if access
Use the excludeObjects URL parameter with a comma-separated list of object api names to include
Optional: Skip certain sections from the report calculations (if you run into any performance issues or timeouts)
Use the skipSections URL parameter with a comma-separated list of section names as noted below:
Permission Set / Permission Set Group Information: Not Skippable
Queue / Public Group Membership Information: publicGroupInformation
Object and Record Access Information: objectAccessInformation
User Permission Information: userPermissionInformation
AuraEnabled Apex Profile Permission Information: apexInformation
Non-AuraEnabled Apex Profile Permission Information: apexInformation
Visualforce Page Permission Information: apexPageInformation
External Data Source Permission Information: externaldatasourceinformation
Named Credential Permission Information: namedcredentialinformation
Custom Settings / Metadata Type Permission Information: customEntityDefinitionInformation
Custom Permission Information: customPermissionInformation
Account Team Member Access Information: accountTeamMemberInformation
Case Team Member Access Information: caseTeamMemberInformation
Opportunity Team Member Access Information: opportunityTeamMemberInformation
Community Member Access Information: networkmemberinformation
Chatter Group Member Access Information: collaborationgroupmemberinformation
Limits
The following numbers represent maximum counts of entities that a user has access to, which the report will process:
SetupEntityAccess: 7000 each (Apex Classes, Apex Pages, etc.)
SetupEntities: 999 each (Custom Settings, Custom Metadata Types, etc.)
Objects: 999 each (Standard, Custom, Namespaced, External, etc.)
If the running user has access to more than the maximum numbers above on each of those entities, the report will include the first X number and ignore the rest - so the report will not be a complete representation of the user’s access.
Furthermore, the above numbers are not the only factor when it comes to limits. The app is subject to the same governor limits as any code that runs on the Salesforce platform. There are several factors that may contribute to the various limits on the platform, which makes it difficult to define specific limits. The report may error or halt processing prior to hitting a governor limit, which may also lead to an incomplete representation of the user’s access.
As general guidance, the less a user has access to the higher the chance the report will run successfully and not hit limits. On the other hand, in a scenario where there is an org with a lot of metadata and enough entity access counts are on the higher end of the spectrum (such as running the report for an admin user with a lot of access), the run will likely result in errors and failures due to governor limits.
The largest org the app has been tested with included the following criteria:
Admin user runs (most access to metadata)
~30 permission sets
~650 objects
~5000 Apex Classes
~ 1100 Visualforce pages
Automated / Scheduled Runs (Beta)
You can schedule a monitoring job to run the User Access Report on an interval and notify you of any changes or open access.
The job will query any UAR Result records that are set to "Active", and process those records per the specific record configuration.
Note: Automated runs cannot calculate the number of records a user has access to for objects, since they do NOT run as that user. The only way to get the actual number of records a user has access to is by running the report in real-time , logged-in as that user.
Limits
The following numbers represent maximum counts of entities that a user has access to, which the report will process:
SetupEntityAccess: 7000 each (Apex Classes, Apex Pages, etc.)
SetupEntities: 999 each (Custom Settings, Custom Metadata Types, etc.)
Objects: 999 each (Standard, Custom, Namespaced, External, etc.)
If the running user has access to more than the maximum numbers above on each of those entities, the report will include the first X number and ignore the rest - so the report will not be a complete representation of the user’s access.
Furthermore, the above numbers are not the only factor when it comes to limits. The app is subject to the same governor limits as any code that runs on the Salesforce platform. There are several factors that may contribute to the various limits on the platform, which makes it difficult to define specific limits. The report may error or halt processing prior to hitting a governor limit, which may also lead to an incomplete representation of the user’s access.
As general guidance, the less a user has access to the higher the chance the report will run successfully and not hit limits. On the other hand, in a scenario where there is an org with a lot of metadata and enough entity access counts are on the higher end of the spectrum (such as running the report for an admin user with a lot of access), the run will likely result in errors and failures due to governor limits.
The largest org the app has been tested with included the following criteria:
Admin user runs (most access to metadata)
~30 permission sets
~500 objects
~5000 Apex Classes
~ 1100 Visualforce pages
How to Setup Automatic Monitoring for User Access
Follow these steps to setup Automatic Monitoring for User Access. You will need to create both a Scheduled Job on which to run the process, and UAR Result records for the Scheduled Job to process.
1) Steps to Create New Job
This schedule will pick up any UAR Result records that are active and process each per its configuration.
Go to the Schedule Apex Page, fill out the form and choose the schedule and the frequency to run the job on.
For the "Apex Class" select "UARSchedulable"
Save the job
2) Create UAR Result Records
These will be the UAR Result records that the scheduled job will query and process per the options you configure for each.
Provide a text User Id, which will auto-populate the User Lookup field. (The lookup UI does not allow for selecting External or Guest Users, hence this work-around)
Provide the number of days to keep files for. If you input 0, no files will be deleted. If you input a number greater than 0, files will be kept for that many days (given that the record is being processed).
Choose which Access Sections you want to be notified about. This only controls notification, but access is always calculated for all sections.
Choose when you want to be notified, when open access is detected, when a change in access is detected, or both.
Provide Comma-separated email addresses to send email notifications to.
Section Explanations / Recommendations
Permission Set / Permission Set Group Information
This section of the report shows what Permission Sets and Permission Set Groups are assigned to the user, as these permission sets and groups open up additional access for the user on top of what their profile grants them. You will see the access resulting from these permission sets and groups throughout the various sections of the report.
Action:
Review the assignments and ensure any effects are intended to serve business requirements, and not an oversight.
Queue / Public Group Membership Information
This section of the report shows what Public Groups and Queues the user is a member of. Queues and Public Groups drive sharing to various elements, such as records, list views, etc.
Action:
For Internal and External users, review the memberships and ensure any effects are intended to serve business requirements, and not an oversight. For Guest users, it is a Salesforce best practice to not have guest users in public groups.
Object and Record Access Information
This section of the report shows information about object access for that user, including organization-wide defaults for sharing, View All and Modify All permissions, as well as record access due to various reasons for that user. The report displays the information in two groups: Record Access, and Object Permissions (CRUD).
Record Access includes columns:
Organization Wide Default Sharing
Total Number of Records With Access To (which only gets calculated for real-time report runs, not for automated / scheduled runs)
Total Number of Records Owned
Total Number of Records due to Owner Sharing
Total Number of Records due to Manual and/or Apex Sharing
Total Number of Records due to Sharing Rules
This information should generally give you a good idea where object access is resulting from for records accessible by the user.
Object Permissions include Create, Read, Edit, Delete, View All, and Modify All permissions coming from the user’s Profile and/or assigned Permission Sets / Permission Set Groups, if applicable. There is also an Overall row that is calculated based on the sum of access granted by the Profile and Permission Sets / Permission Set Groups (i.e. if access is granted by any, then the user has the access).
Action:
As a best practice, Organization-wide defaults should be set to private for objects, and record sharing opened up as needed by the various platform mechanisms. For Guest users, organization-wide Defaults is always private. While access to records for Guest users can be opened in other ways, admins should exercise caution in opening up record access for Guest users via the various platform mechanisms. Do NOT create Guest User Sharing Rules or open up record sharing to the Guest user for any records containing sensitive information, confidential information, or Personally Identifiable Information (PII).
Sometimes, users may own records they shouldn't. In such cases, the record sharing mechanism alerted in the report is Owner Sharing. If a user owns records they should not own, an admin needs to change record ownership to another user, and implement automation to prevent future occurrences.
If a user is gaining access to records due to Manual and/or Apex Sharing when they shouldn’t, an admin will need to delete existing Manual and/or Apex Sharing records in the object’s share table, and disable any code or automation that is creating these share records. Manual sharing may also be a result of users manually sharing records via the UI, so you will need to update page layouts to remove access to manual sharing capabilities for users.
If a user is gaining access to records due to Sharing Rules when they shouldn’t, an admin will need to find and delete or update the sharing rules to exclude the user.
If a user has object (Create, Read, Edit, Delete, View All, Modify) access when they shouldn’t, an admin should review all sources (profiles, permission sets, permission set groups) granting that access, and remove access.
Note: Anything flagged as Is Exposing Data and/or showing a number greater than zero for any of the totals means that the user has access to that data. In case of Internal users, that usually means authenticated employees. In case of External users, that usually means authenticated customers and/or partners. In case of unauthenticated Guest users, that means everyone on the web who can publicly access the site. So unless access is intended and does NOT include sensitive information, confidential information, or Personally Identifiable Information (PII), an admin needs to lockdown access immediately.
User Permission Information
This section of the report shows information about User Permissions, which are usually checkboxes in Profiles and/or Permission sets under General User Permissions or System Permissions sections. These permissions include granting access to data, as well as other functionality on the platform.
For example, the Access Activities (permissionsactivitiesaccess) permission grants access to Activity (Task/Event) objects. That, combined with record access, will allow a user to see Task and Event records.
Another example would be the Run Flows (permissionsrunflow), which grants a user access to run any flow in the org.
Action:
As a general best practice, ensure that users are granted only the permissions they require to be able to execute their business processes.
User permissions may be granting access to more than just the intended functionality, like the Run Flows permission. If your user needs access to run one flow, grant them access to run that single flow, instead of the Run Flows permission which allows them to run any flow in the org.
For Guest / Unauthenticated users, user permissions should be locked down completely as a default, and if there is functionality that requires a user permission to function for a guest user, those should be carefully evaluated and granted on an exception basis. For example, you might need to grant the Access Activities permission to display activities related to a custom object, but granting that permission will expose any and all activities related to anything that the Guest / Unauthenticated user has access to. So before granting this permission, the rest of the access should be evaluated and locked down.
AuraEnabled Apex Class Permission Information
This section of the report includes information about Apex Classes that the user has access to, which also contain methods that are decorated with @AuraEnabled. These methods are usually used with Lightning components (both Aura components and LWCs).
The report will display the API name and Id of the Apex Class, as well as the namespace prefix (if it’s part of a managed package or namespaced org).
Note: This section also includes classes in managed packages where code is hidden and this report cannot check for @AuraEnabled method decorations.
The reason @AuraEnabled methods are significant is because, as stated in the Component Security section in the Lightning Aura Components Developer Guide:
In Apex, every method that is annotated @AuraEnabled should be treated as a web service interface. That is, the developer should assume that an attacker can call this method with any parameter, even if the developer's client-side code does not invoke the method or invokes it using only sanitized parameters. For more information, see the Secure Coding Guide.
In other words, an attacker can access your data without using a user interface by using the Session Id that belongs to a user with access to an apex class that contains @AuraEnabled methods, and invoking calls to those methods.
Action:
Ensure that @AuraEnabled methods are coded securely, and don’t rely on an assumption that they will only be invoked from a UI client.
Ensure that responses from @AuraEnabled methods do not contain plain text information that you may not want an attacker to see.
Ensure that Users who do not need access to an @AuraEnabled method, do not have access to the Apex Class.
Remove access to an Apex Class with @AuraEnabled methods, for Guest / Unauthenticated users unless you intend to allow anyone on the web who can publicly access the site to invoke these methods bypassing any UI constraints.
In case of managed packages where the code is hidden, check with the publisher of the app to determine whether there are or aren’t any @AuraEnabled methods in Apex Classes that are part of their managed package.
Non-AuraEnabled Apex Class Permission Information
This section of the report includes information about Apex Classes that the user has access to, and also do not contain any @AuraEnabled methods.
The report will display the API name and Id of the Apex Class, as well as the namespace prefix (if it’s part of a managed package or namespaced org).
Action:
As a general best practice, remove access to Apex Classes from Users who do not need that access.
Lightning Out Visualforce Page Permission Information
This section of the report includes information about Visualforce Pages (ApexPages) that the user has access to, which also contain the Lightning Out tag (<apex:includeLightning />). Both Lightning site pages and Visualforce pages that implement Lightning Out include the Aura standard controllers, which is the framework that operates the lightning components in the Aura runtime. And similar to @AuraEnabled methods in Apex (outlined in the Auraenabled Apex Class Permission Information section above), methods in the standard controllers can be invoked without UI constraints.
So it is important to understand which pages in your org may be utilizing these standard controllers, and remove access to those pages where it is not needed.
The report will display the API name and Id of the Visualforce Page, as well as the namespace prefix (if it’s part of a managed package or namespaced org).
Action:
As a general best practice, remove access to Lightning Out Visualforce pages from users who do not need the access.
Remove access to an Visualforce Pages with Lightning Out, for Guest / Unauthenticated users unless you intend to allow anyone on the web who can publicly access the site and Visualforce pages to be able to invoke standard controller methods bypassing any UI constraints.
Non-Lightning Out Visualforce Page Permission Information
This section of the report includes information about Visualforce Pages(ApexPages) that the user has access to, and also do not contain any Lightning Out tags (<apex:includeLightning />).
The report will display the API name and Id of the Visualforce Page, as well as the namespace prefix (if it’s part of a managed package or namespaced org).
Action:
As a general best practice, remove access to Visualforce Pages from Users who do not need that access.
Flow Permission Information
This section of the report includes information about Flows that the user has access to. The report will display the flow Id and name, as well as the namespace prefix (if it’s part of a managed package or namespaced org) and whether the flow is active or inactive.
Granular flow permissions (at the profile and/or permission set level) were more recently introduced to the platform, where an admin can configure a flow to be allowed to run only by users who have access to that specific flow via their Profile or a Permission Set assigned to them. Before this was introduced, there was a more open permission called Run Flows (permissionsrunflow), which an admin can grant also at a Profile or Permission Set level, that allowed a user to run any flow. The latter may be remnant in older orgs that were configured this way, but it is a recommended best practice to follow the more granular approach and only grant access for users to flows that they need to be able to run.
Action:
As a general best practice, remove access to Flows from Users who do not need to be able to run these flows.
If a user has the Run Flows permission assigned to them via a Profile or Permission Set, consider removing that permission and granting more granular access only to flows that the user requires.
Guest users should not have the Run Flows permission, and should only be configured to be able to run specific flows that they require. Reminder that granting access to a guest user to run a flow is allowing anyone on the web to be able to do so.
External Data Source Permission Information
This section of the report shows information about External Data Sources that the user has access to, including Name and Id, and Namespace Prefix (blank if it’s not part of a managed package). External Data Sources are a way to configure a data source that is external to the Salesforce org, and allow access to data stored outside the Salesforce org in the form of External Objects.
Platform sharing capabilities are not available for External Objects, since the data does not reside within the org, but instead is coming from an External Data Source. All that a user requires to access the data from an External Object, is Read access to the External Object and access to the External Data Source connection.
External Data Sources could be authenticating to an external endpoint via a single “Integration User”, in which case any user with access to use the External Data Source and Read access to an External Object, essentially has access to query the External Object’s data from the external source while authenticated as the integration user. Guest users having access to an External Data Source and Read access to its External Objects, means that anyone on the web can query data from that External Data Source’s External Objects.
Action:
Review and confirm that the user requires access to the External Data Source, or remove access to the External Data Source.
Review the External Object Permissions as well to ensure that the user has access only to the objects needed.
Named Credential Permission Information
This section of the report shows information about Named Credentials that the user has access to, including the Name and Id, and Namespace Prefix (blank if it’s not part of a managed package). Named Credentials are used to define endpoint URLs for API callouts to retrieve data from sources external to the platform. Named Credentials can be used in conjunction with External Data Sources or via other mechanisms (like Apex callouts, External data sources, External Services) to make callouts to external platforms.
Named Credentials could be authenticating to an external platform via a single “Integration User”, in which case any user with access to use the Named Credential, essentially has access to make a callout to the external endpoint, authenticated as the integration user. Guest users having access to a Named Credential means that anyone on the web can potentially execute code that utilizes the Named Credential and, in turn, successfully execute a callout to an external system.
Action:
Review and confirm that the user requires access to the Named Credential to perform some functionality, or remove access to the Named Credential.
Conduct a security review of the functionality that is utilizing the Named Credential to ensure best practices are implemented.
Custom Settings / Metadata Type Permission Information
This section of the report shows information about Custom Settings and Custom Metadata Types that the user has access to, including the Name and Id of the Custom Setting or Metadata Type, Namespace Prefix (or blank if it’s not part of a managed package), and Type (Custom Setting or Metadata Type).
Custom Settings and Custom Metadata Types are generally used in custom-developed apps, components, automations, and other functionality built on the Salesforce platform. It can also be introduced into an org as part of a managed package.
Action:
Review and confirm that the user requires access to the Custom Settings and Custom Metadata Types, or remove access.
Custom Permission Information
This section of the report shows information about Custom Permissions that are assigned to the user. These are usually permissions that are defined for use with a custom-developed App or component, which may be part of a managed package namespace or just developed / deployed directly in the org. The report will show the Custom Permission Name and Id, and Namespace Prefix (or blank if the Custom Permission is not a part of a managed package).
Action:
Review and confirm that the user requires access to the Custom Permissions assigned to them, or remove access to the custom permissions.
Account Team Member Access Information
This section of the report shows information about what Accounts the user is a team member of, including the AccountName and Record Id, the Team Member Role, and the Account, Contact, Case, and Opportunity Access Levels. Adding a user to an Account Team grants them access to that Account and potentially its related Case, Contact, and Opportunity records. Refer to the Account Team documentation on what access is granted when using Account Teams.
For Guest users, this should be a non-issue (blank section) since Guest users cannot be added as Account Team Members.
Action:
Review and confirm user’s Account Team Member and any implicit access granted due to that (if applicable), or remove user from Account Team Membership.
Case Team Member Access Information
This section of the report shows information about what Cases the user is a team member of, including the Case Number and Record Id, and the Team Member Role. Adding a user to a Case Team grants them access to that Case based on the pre-defined Role configuration. Refer to the Case Team documentation for more on using Case Teams.
For Guest users, this should be a non-issue (blank section) since Guest users cannot be added as Case Team Members.
Action:
Review and confirm user’s Case Team Member and any implicit access granted due to that (if applicable), or remove user from Case Team Membership.
Opportunity Team Member Access Information
This section of the report shows information about what Opportunities the user is a team member of, including the Opportunity Name and Record Id, the Team Member Role, and the Access Level. Adding a user to an Opportunity Team grants them access to that Opportunity and its related Account records. Refer to the Opportunity Team documentation on what access is granted when using Opportunity Teams.
For Guest users, this should be a non-issue (blank section) since Guest users cannot be added as Opportunity Team Members.
Action:
Review and confirm user’s Opportunity Team Member and any implicit access granted due to that (if applicable), or remove user from Opportunity Team Membership.
Site Member Access Information
This section of the report shows information about the user’s membership to a site, including the site Id and Name. Guest users will not show up as members of a site, since they are already tied to the site and only exist to run the unauthenticated experience of a site. Site Membership will only reflect authenticated users that are members of a site.
When a user is a member of a site, they could potentially gain access to many things depending on various settings in the org and the site itself. Some examples are: Topics, Chatter feed / groups, files, users (other members of the site), etc.
Action:
Review and validate whether users should be a member of a site and that access granted by site membership to various assets is intended, or remove membership if not needed.
Chatter Group Member Access Information
This section of the report shows information about what Chatter Groups the user is a part of. It also indicates what role the user has in a chatter group, and whether that group is within a site or the internal org (blank value). For the Guest user, this should always be a non-issue, as the Guest user cannot be a member of a chatter group. For Internal and External authenticated users, access to a chatter groups grants access to the group’s chatter feed and files posted to the group or the feed.
Action:
If the user should not have access to a group’s feed and/or files posted to the group, remove the user from the group’s membership
Screenshots & Videos
Release Logs
Click here to view all release logs.