A security policy is a named rule that you create and attach to a page or menu item. It controls whether a visitor can see that page or menu item, and which message they see if they are refused. You can reuse the same policy on as many pages and menu items as you need.
What a Policy Is Made Of
Every policy has the same four parts, no matter which page or menu item it protects:
- Eligibility criteria describe who qualifies, such as active members of certain types, committee members, or people in certain countries.
- Restrict to console users only lets staff preview new content on the live portal without showing it to members. When this is turned on, only staff who are signed in to the portal can pass this part of the check; members and visitors are refused even when they meet the rest of the policy.
- Event permissions only apply on an event microsite. They can limit access to active registrants for that microsite’s event, registrants who are paid in full, registrants in certain categories, speakers, or people whose organization sponsors the event. Exhibitor access to areas such as the microsite's Exhibitors tab usually depends on both an organization-based rule and a contact-role rule; without both, an exhibit admin might not see the tab they need to assign contact roles and register staff.
- An Access Denied message is the sentence a refused visitor sees. If the policy does not have a message, Rhythm shows “Access Denied” instead.
One eligibility option, "For contacts, apply this rule to the organization to which the contact belongs," changes which record Rhythm checks against the rest of the criteria. When you turn it on, Rhythm checks the organization the contact belongs to instead of the contact’s own record. Because of that, the same logged-in contact can pass or fail the same policy depending on whether this option is on.
A policy controls whether a visitor can see the protected page or menu item at all. It does not show different content to different roles within one shared page. If one group should see renewal messaging and another should see new-member welcome messaging, use two policies and two pages. Showing different content by role inside a single shared page is not built in, and would require custom web design work or a product enhancement.
A policy with Restrict to console users only turned on can look like it works for members when it is really only working for you. If a staff member impersonates a member, the protected page or menu item appears because the staff member is signed in to the Console. The same policy still refuses that member when they sign in to the portal directly. Test this setting by signing in to the portal the way the member would, not only by impersonating them. This setting also controls menu visibility: a menu item that uses a console-users-only policy is hidden from every public visitor and every logged-in member who is not signed in to the Console, not only refused after they click through to its page.
You build and manage security policies in Portal Security Policies in Setup. This is a dedicated portal-specific area, separate from your account's broader Security and Settings area.
A policy also has an active or inactive status. That status is important because it does not stop the policy from working.
Turning a Policy Inactive Does Not Stop It
Marking a policy inactive does not stop it from restricting the pages and menu items it is attached to. Rhythm still checks visitors against the policy’s eligibility criteria and event permissions because the inactive flag is not part of that decision. The only visible change is in the policy list, where the status column changes. To stop a policy from restricting content, remove it from the pages and menu items that use it instead of marking it inactive.
How a Visitor's Eligibility Is Decided
When Rhythm checks whether a visitor meets a policy, it follows a fixed order, not the order shown on the policy form:
- Rhythm checks the eligibility criteria first. If the visitor does not meet them, Rhythm refuses the visitor immediately and does not check anything else.
- If the visitor meets the criteria, Rhythm checks event permissions only when the page is on a site that belongs to one event. Rhythm always checks the event tied to that site; a policy cannot name a different event. If the page’s site has no event, Rhythm skips event permissions and decides based on the criteria alone.
- Finally, if Restrict to console users only is turned on and the visitor is not signed-in staff, Rhythm refuses the visitor regardless of the first two checks.
Within event permissions, two options only work when a third option is also turned on. Restrict to specific registration categories and Restrict to paid registrations only are both ignored unless Restrict to active registrants is also turned on. If you turn on either option without requiring active registrants, Rhythm quietly ignores it, so the policy does not restrict by category or payment status. In this check, “paid” means the registration has no outstanding balance. A cancelled registration still counts as paid if nothing is owed on it, even when the same contact also has another active registration.
Tip
When several conditions fail at once, Rhythm reports only the first reason it finds, using the order above. If a contact fails the eligibility criteria, they never see whether they would also have failed an event permission. The Access Denied message reflects only the first problem.
A menu item restricted to active event registrants can seem to disappear only after sign-in. Rhythm cannot evaluate an event-permission rule for a signed-out visitor, so the item can show before sign-in. After a visitor who is not registered for the event signs in, Rhythm checks the policy and hides the item.
What a Refused Visitor Sees
A refused visitor sees the policy’s Access Denied message, or “Access Denied” if that field was left blank. Rhythm shows that message exactly as written to everyone the policy refuses, no matter which condition they failed. The specific reason is recorded separately and is available to staff and integrations that ask for it directly. See Check a Contact's Eligibility Through the Integration Interface for how to retrieve it.
To change that message for a flow controlled at the microsite level, edit it under that microsite's own Security Policies settings. You may need to switch into the microsite's own context first to reach the right policy.