If your organization has advanced (granular) security, three layers work together to determine what a console user can do: a permission statement, a security policy, and a security role. Each layer builds on the previous one, so you can define access once and reuse it wherever it applies.
The Three Layers
A permission statement is the smallest unit of access. It allows or denies a set of actions in one application area, at a specific scope. A statement does not affect anyone until you place it in a policy, place it in a role, or attach it directly to a console user.
A security policy is a named, reusable group of statements. Use a policy when the same rules should apply to several roles or several people, so you do not have to recreate the same statements.
A security role is a named group you attach to a console user. A role can include Rhythm-managed policies, your organization’s own policies, and statements written directly on the role.
flowchart LR
S[Permission statement] --> P[Security policy]
P --> R[Security role]
R --> U[Console user]
P -.also attaches directly.-> U
S -.or directly.-> U
You can also attach a statement, policy, or role directly to one console user instead of sharing it. A statement attached to one person is the least reusable option because it is not named anywhere else in your organization. When you review or audit one person’s access, check anything attached directly to that person, along with their roles and policies.
Security policies are also useful outside the Console. They can provide a flexible way to decide whether someone qualifies for something, such as an integration-specific benefit. Membership active status alone is not always precise enough for that kind of business rule, and a policy lets you change the qualifying logic later without reworking the integration that depends on it.
Rhythm publishes a reference that lists the roles and permissions available across applications, along with how to set them up, so you do not have to piece that information together from each application’s settings.
Composing a Statement
Every statement answers the same questions:
- Which application and area of it the statement concerns.
- Which actions it covers, whether you choose specific actions or every action in that area.
- Whether the effect is to allow or to deny those actions.
- At what scope the statement applies and, when that scope supports it, whether it applies to specific records or every record of that kind.
- Optional restrictions such as a date range, specific hours of the day, and specific network (IP) addresses the request must come from.
Rhythm gives you two ways to compose a statement: a guided form and a structured (text) view of the same statement. The guided form walks you through each question after you answer the one before it.
Some statements cannot be shown in the guided form. For example, a statement that spans more than one application, or names resources the form cannot represent, opens in the structured view instead. This is an intentional limit on what the guided form can safely show, not an error. Use the structured view for anything the form cannot display.
Where You Compose Each Layer
- Security policies are listed and edited from Security › Policies.
- Security roles are listed and edited from Security › Roles.
- The statements inside a policy or a role use the same statement editor, which opens from an Add Permission action inside the policy or role you are editing.
- You attach roles, Rhythm-managed policies, your own policies, and individual statements to one console user from that person’s record. See Console Users and Their Access.
When Your Organization Does Not Have This Capability
Advanced (granular) security includes named roles and policies, plus the ability to write individual statements. Some organizations have this capability and others do not. If you try to open the security policies or roles screens and your organization does not have this capability, Rhythm tells you the capability is not available. It does not say that you personally lack permission.
Those two messages mean different things. If the capability is not available, talk with your Customer Success Manager about upgrading. If you personally do not have permission, an administrator in your organization can grant access by attaching a role or policy.
When your organization does not have this capability, you can still create a console user. The sections for attaching roles, policies, and statements are simply absent from that person’s record, so there is nothing to compose beyond whatever your plan grants by default.
Hiding Content Based on Eligibility
Rhythm does not offer a page-level visibility setting based on whether someone has an active application or a similar status in progress. If you want to hide a portal page from people in that situation, evaluating security-policy eligibility criteria may be a workable alternative to check, though this has not been confirmed as a supported way to achieve it.
Nothing Shows You the Combined Result
Rhythm does not provide one view that shows what a role permits after all attached policies and statements are combined. Rhythm also does not show which console users currently have a role or policy before you delete it. If you plan to delete a role or policy that people may still use, review access by opening each console user, because deleting it changes what those people can do without naming them first.