Sharing Active Pages and Classes

Sharing controls who can see and run an Active Page or execute the public actions of an Active Class. The sharing dialog supports Roles, User Groups, the Guest Role, and specific people. Group-based sharing was added so administrators can grant access by user segment without assigning new Roles.

Where Sharing Is Configured

Sharing is configured per record:

• Active Page: open the page from Setup > Develop > Pages, click the kebab menu (three dots), and select Share.
• Active Class: open the class from Setup > Develop > Classes & Triggers, click the kebab menu, and select Share.

The dialog opens with the record's current shares listed. Use the search box to find Roles, User Groups, or specific users to add.

Member Types You Can Share With

A user has access if any one of their Roles, any User Group they belong to, or their direct user share gives access. Access is additive across these sources.

Guest Role — Special Behavior

Sharing an Active Page or Class with the Guest Role changes the access semantics in two ways:

1. Anonymous (unauthenticated) visitors can access the page or call the class's actions. This is how public-facing landing pages and self-registration flows work.
2. All authenticated users get access regardless of their other Roles or User Groups. If a page is shared with Guest Role, every logged-in user can view it as well.

Use the Guest Role only when both behaviors are intended. For pages that should be visible to all logged-in users but NOT to anonymous visitors, share with each Role explicitly or with a User Group that covers them, and do not include Guest.

Roles vs. User Groups: When to Use Which

• Use Roles when the audience is defined by job function or user license type that already maps to existing Roles.
• Use User Groups when the audience is a cross-Role segment defined by attributes (region, partner tier, account type), or by hand-curated membership. Group sharing avoids the need to create a new Role just to gate access.
• Combine them: share with a Role for the broad audience and add a User Group for an extra cross-cutting segment.
• Use Specific People for one-off access that doesn't justify a Role or Group, such as a beta tester or a temporary auditor.

How Visibility Is Resolved at Runtime

When a portal user requests an Active Page (directly or through a navigation menu), the platform checks each access source in turn:

• Is the user's Role in the page's shared Role list?
• Is the user a member of any User Group in the page's shared Group list?
• Is the user listed individually under specific people?
• Is the page shared with the Guest Role (which grants access to all authenticated users and anonymous visitors)?

If any check passes, the page renders. If none pass, the user receives a not-found or unauthorized response, and any Menu Item linking to the page is hidden from their navigation. Navigation menu visibility logic respects both Role-based and User-Group-based sharing.

Sharing for Embedded Active Pages

Active Pages can be embedded inside an Engagement Page via the Active Pages widget. For an embedded Active Page to render to a non-administrator:

• The Engagement Page must be shared with the user (Role, User Group, or specific person).
• The embedded Active Page must also be shared with the user (or with the Guest Role).

If only the Engagement Page is shared but the Active Page is not, the widget will not render its content for non-admin users.

Active Class Sharing — What It Controls

Sharing on an Active Class controls who can execute the class's public action methods (Controller actions, public methods callable from JavaScript via the AJAX API). It does NOT control who can read the source code; source access is administrator-only.

Internal references — one Active Class calling another, a Trigger using a utility class — run with the platform's normal security context and do not require explicit sharing on the called class.

Add a Share

1. Open the Share dialog from the record's detail view.
2. In the search box, type a Role name, a User Group name, or a User name.
3. Select the result from the dropdown.
4. Repeat to add more entries.
5. The dialog auto-saves each entry. Close the dialog when finished.

Remove a Share

1. Open the Share dialog from the record's detail view.
2. Locate the entry to remove.
3. Click the remove icon next to the entry. Confirm if prompted.

Removing a share takes effect immediately. Users who lose access lose it on their next request to the page or action.

Troubleshooting Tips

• If a user can't see a page they should, confirm at least one of their Roles or User Groups is in the page's share list.
• If logged-in users unexpectedly see an internal page, check whether the Guest Role is on the share list — that grants access to all authenticated users in addition to anonymous visitors.
• For embedded-widget visibility issues, confirm both the Engagement Page and the Active Page are shared with the user.
• For full symptom-by-symptom resolutions, see Active Pages Troubleshooting.

<< Managing Active Classes | Active Pages Troubleshooting >>