Every portal page has one of three access levels. The access level decides whether a visitor must sign in before Rhythm shows the page, separate from any security policies on that page.
Every page on your portal has one of three access levels. The level controls whether a visitor must sign in before Rhythm shows the page at all, even if the page also has security policies.
The Three Access Levels
| Access level | What a visitor needs |
|---|---|
| Public | Nothing; anyone can open the page without signing in |
| Requires Login w/o Rolodex Record | The visitor must be signed in, but does not need a linked contact record |
| Requires Login & Rolodex Record | The visitor must be signed in and linked to an active contact record |
| Requires Login w/o Rolodex Record | The visitor must be signed in; no linked contact record is required | | Requires Login & Rolodex Record | The visitor must be signed in and linked to an active contact record |
You set a page’s access level by editing the page in Portals & Microsites › Pages, choosing the level in its security settings, then saving and publishing. On the Manage Pages list, a red lock icon means the page is not public and requires sign-in. To change that, edit the page’s access level the same way.
A membership or organization directory has its own visibility setting, separate from the page that displays it. For an otherwise public directory page to open without a login prompt, the directory must be enabled and its own visibility must be public. Directories also have a separate comments setting. When comments are enabled on a public directory, anyone can read them, but visitors must sign in before submitting one.
A Public Page
Anyone can open a public page, whether they are signed in or not. If the page also has one or more security policies, those policies still apply. A visitor who is not signed in must sign in before Rhythm can check whether the policies allow access. See How Several Policies Combine on a Page or Menu Item for how that check works. This also applies to direct links sent outside the portal. For example, if you email attendees a direct event directory link and that directory requires registered contacts, visitors who are not signed in must sign in first.
Tip
Changing a page’s access level to Public does not always remove every restriction. Login or security fields from an earlier, more restrictive setup can keep being enforced even when they are no longer selected in the current setup. If a page you changed to Public still asks visitors to sign in, check the page for leftover login or security fields and remove them.
Making a page public controls the page itself, not every component on it. An online store page set to Public still needs its Online Store component configured with the correct store ID from Orders & Inventory before anonymous visitors can open the store. Without that ID, the store can return an error for visitors who are not signed in. Likewise, an event registration page needs its own access level to require login. If the Register for Event page is set to Public instead of requiring sign-in, its registration form can fail to load, and changing that page’s access level to require login resolves it. Set the same login requirement deliberately on an integrated event’s registration page. Making it private sends a visitor who is not signed in to sign in, instead of sending them to a registration form that cannot load for them. Watch for this in longer flows, too. If a visitor starts on a public microsite page, clicks a Register link, and is forced to sign in partway through, that detour can create loading or error behavior on the registration page that follows. Making the starting page require sign-in from the beginning avoids that detour.
Rhythm does not include anti-fraud controls, such as CAPTCHA or a configurable minimum amount, on public donation or payment pages by default. If your account has enabled CAPTCHA to help with this, treat it as a beta feature. It has not been officially released, some accounts have used it without issues, and unforeseen problems are still possible.
For a billing notice sent to someone who may not have portal access, link to the invoice payment page instead of the account make-payment page. The make-payment page requires a portal login, while the invoice payment page is meant for paying a specific outstanding invoice without signing in.
Public access inside the portal does not extend to pages served by an external website’s content management system. If a member-only page or link lives on your organization’s main website instead of inside the portal, your website platform must enforce member and non-member access separately. Rhythm page access levels only control pages inside the portal experience.
A Page That Only Needs Sign-In
A page set to "Requires Login w/o Rolodex Record" requires only that the visitor sign in. The visitor does not need a linked contact record. The Console does not let you attach security policies to this kind of page, so sign-in is usually the only restriction unless the page still has policies from an earlier access level.
A Page for Signed-In Members Only
A page set to "Requires Login & Rolodex Record" is the most restrictive option. The visitor must be signed in and linked to an active contact record.
Rhythm sends the visitor to a different place depending on what is missing. If the visitor has no linked contact, Rhythm sends them to complete the sign-up process. If the visitor’s linked contact is inactive, Rhythm refuses access and shows this message: "This account is inactive. Please contact the main office to have this account enabled."
This access level also checks email verification and profile completion. Those checks are covered in How Portal Admission Works.
Being signed in with a linked contact gets a visitor past the page itself, but protected content behind that page can still depend on the record they are linked to. For example, a page restricted only to signed-in visitors can still show or hide content such as a members-only journal based on whether the visitor’s own record has the qualifying membership. Being logged in is necessary, but it is not always enough by itself.
A newly approved applicant can usually sign in and use the portal generally as soon as their account exists, even before their membership status is Active. Pages and menu items restricted to active members stay unavailable until that status changes. A security policy on a parent menu item also applies to every page under it, so restricting one parent item restricts its whole branch.
An Unrecognized Access Level Is Treated as Members-Only
If a page ever has a stored access level other than the three listed above, Rhythm treats it like "Requires Login & Rolodex Record," the most restrictive option. This safety default keeps an unexpected value from making a page available more broadly than intended.
Changing Who Can See a Members-Only Page
You can loosen who sees a members-only page without changing its access level. If a page requires sign-in and a linked record, and it also has a security policy, removing the policy opens the page to any signed-in visitor with a linked record. For example, if the removed policy limited the page to your association’s active members, the page is no longer limited to that narrower group.
- Open the page in Portals & Microsites › Pages.
- Edit the page and remove the security policy that is narrowing access, such as an active-members policy.
- Save the page.
- Publish the page so the change takes effect for visitors.
Keep the two kinds of control separate. A page’s access level and policies decide whether the page is shown. They do not loosen permission checks inside the widgets on that page.
For example, a page in your account that lets members manage their organization’s people can be public, but that does not mean every visitor can add or remove someone. Rhythm checks that action separately, so the visitor must sign in before making that kind of change, even on a page that is otherwise open to everyone. See Manage Your Organization's People for what that looks like from a member’s side. The same separation applies to a certification program’s browse page. Making that page public does not necessarily make the certification data behind it available to anonymous visitors, because the underlying data source can enforce its own authorization separately from the page’s access level.
This also explains a common pattern to check when members report that they cannot reach something, such as event registration. A sign-in requirement on an earlier page in the path can block the visitor before they reach the registration itself. If a feature that used to be open to anyone suddenly asks members to sign in first, check the access level of the page that leads to it, not only the feature’s own settings. When you troubleshoot a registration, verification, or similar onboarding flow, review every page in that path for access rules that assume the visitor is already fully signed in and linked to a member record. A rule written for that case can block someone earlier in the flow who is not there yet.
A page’s access level and widget permissions only control whether a page or action is available, not what happens inside features such as chapter management. If you need to limit a chapter-management area to specific chapters instead of members generally, page-level access restrictions alone will not do that.
Tip
A lingering policy from an earlier setup can keep blocking a page even when the rest of its current security settings look correct. For example, a page that previously used "Requires Login & Rolodex Record" can still have an old Rolodex-specific policy attached. If a page unexpectedly denies access, check for a leftover policy like this before assuming the configuration is wrong somewhere else.
A contact who belongs to a parent organization can typically act on a child organization’s behalf only in specific functional areas, such as CRM, finance, and certifications. That access does not automatically cover every action available to the child organization itself, so submitting a membership application on the child’s behalf is not necessarily included. Similarly, a parent organization contact who can view and pay a descendant organization’s invoices does not automatically see that descendant’s broader financial history. Invoice payment and financial-history visibility are separate. The portal’s labels for managing child or descendant organizations, such as "manage child/descendant organizations" and "Allow for editing new child organizations in the portal," can also be easy to misread. The second one applies to the workflow for newly added child organizations, not ongoing profile or contact management for existing ones.
A contact with an organizational membership, but without the role that grants administrative capability, can typically still see information such as an organization’s auto-renewal status and banner. They cannot change it. Seeing a setting and being able to act on it are different permission checks.
Required fields on a portal contact form, such as requiring an email address, are configured on the individual field in the form setup, not in the page’s access level or security settings. If a required-field rule is not working as expected, look at the field setup instead of the page privacy settings. If you need different fields available to different kinds of users, such as showing a Contact Roles field only to portal administrators, build two versions of the form instead of relying on conditional visibility. Create one form with the field and one without it, and place each on its own page with the security policy for that audience. The same pattern works when different membership types need different profile fields. Duplicate the profile page, configure each copy with the fields and form that type needs, add each to the menu, and use security policies so each audience reaches only its own version.
Before you decide where to store files for members, decide who needs access. If only staff need the files, a Console-only location is enough. If members need to reach them too, plan for a portal page with the right access level. One pattern is to link from a members-only benefits page to a separate digital library page. The digital library page can hold the uploaded files and show them only to visitors who meet criteria you configure there, such as active membership, so you do not have to embed every file directly on the benefits page. You can publish a roster or membership directory the same way: as its own page, hidden behind sign-in, and narrowed to the audience you want with the access levels and policies described in this article.
If you want to hide your account’s membership application entry point from the portal instead of restricting who can see it, that option can also be configured. Check with Rhythm support for the steps if you need to turn it off entirely rather than restrict its audience.
A public page can be opened by anyone, signed in or not. This level does not control everything else placed on the page. If the page also has one or more security policies, those policies still apply, and a visitor who is not signed in must sign in before Rhythm can evaluate them. See How Several Policies Combine on a Page or Menu Item for how that check works.
A Page That Only Needs Sign-In
A page set to "Requires Login w/o Rolodex Record" asks only that the visitor be signed in. It does not require the visitor to have a linked contact record. The Console does not offer security policies for this kind of page, so sign-in by itself is the only restriction unless the page still has policies left over from an earlier access level.
A Page for Signed-In Members Only
A page set to "Requires Login & Rolodex Record" is the most restrictive of the three. The visitor must be signed in, linked to a contact record, and that record must be active. Rhythm sends the visitor down a different path depending on what is missing. Someone with no linked contact is sent to complete the sign-up process. Someone whose linked contact is inactive is refused access and sees this message: "This account is inactive. Please contact the main office to have this account enabled." This level also checks email verification and profile completion, which are covered in How Portal Admission Works.
An Unrecognized Access Level Is Treated as Members-Only
If a page’s stored access level is ever something other than the three above, Rhythm treats it the same as "Requires Login & Rolodex Record," the most restrictive option. This safety default keeps an unexpected value from showing a page more broadly than intended.
Changing Who Can See a Members-Only Page
You can loosen who sees a members-only page without changing its access level. If a page requires sign-in and a linked record, and it also has a security policy, removing that policy while leaving the access level in place opens the page to any signed-in visitor with a linked record. For example, if the removed policy limited the page to your association’s active members, the page is no longer limited to that narrower group.
Keep the two kinds of control straight. A page’s access level and policies decide whether the page itself is shown. They do not loosen any permission checks inside the widgets placed on that page. For example, a page in your account that lets members manage their organization’s people can be public without changing whether a visitor can add or remove someone. Rhythm checks that action separately, so the visitor still has to sign in before making that kind of change, even on a page that is otherwise open to everyone. See Manage Your Organization's People for what that looks like from a member’s side.
This also explains a pattern worth checking if members report that they cannot reach something, such as event registration. A sign-in requirement added to an earlier page in the path, such as the page hosting the registration link or widget, can block a visitor before they ever reach the registration itself. If a feature that used to be open to anyone suddenly asks members to sign in first, check the access level of the page that leads to it, not only the feature’s own settings.