A console user is someone your organization allows into the Rhythm Console, such as a colleague, volunteer, or outside bookkeeper. Console users can work in Rhythm instead of only appearing in your records.
A console user is separate from a contact. Creating a console user does not create a member or add anyone to your CRM, and a contact record does not give someone Console access. You manage contacts and console users on separate screens. If someone already has a contact record and needs a Console login, create a separate console user with their name and email. Rhythm does not link those records automatically. There is also no self-service way in the Console to remove or move a sign-in that is already associated with a contact. If you need that changed, contact Rhythm Support.
Rhythm's support system, where you submit tickets to Rhythm, is also separate from the Console. Disabling or deleting someone's console user does not change their access to that support system, and the reverse is also true. If someone leaves your organization, address both accounts if they had both.
Identity and Access Are Two Different Things
Each console user has identity details and access settings. Their identity includes their name, email address, phone number, and whether they are disabled. Their access settings control what they can do through the security roles, policies, and individual permissions assigned to them.
This distinction matters when you review users. A console user can appear in your user list even when they have no access, either because they were disabled from the start or because no one assigned them a role. When you disable a user, you stop their access without deleting their identity, so you can restore them later without re-entering their details.
Rhythm does not give you or your staff direct access to the sign-in service behind the Console. For routine account tasks, such as resetting someone's password or sending a setup link, use the Console's security screens.
Who Can See Your Users
Every console user in your organization appears on the Manage Users screen, which you open from System & Security › Security › Users. Each row shows the person’s last name, first name, email address, and whether they are currently Active or Inactive. From this screen, you can create, edit, clone, or delete a user.
The list shows who exists and whether each person is active, but it does not show what each person can do. To review or change someone’s roles, policies, or individual permissions, open that user’s record and review the sections described below. The Security area also usually shows only the most recent sign-in details for a person, not a full history. If someone signs in from one location one day and another location later, you will generally see only the latest sign-in details.
If you need to identify who performed a specific action, such as a refund or a credit memo, and the visible history does not make that clear, look at the record's raw data for the internal user identifier attached to the transaction. Then match that identifier against your console users under System & Security › Security › Users.
Multi-Factor Authentication for Console Users
Console users can be required to complete a second step at sign-in in addition to their password. Any standard authenticator app works; Rhythm does not require a specific one. Rhythm Support coordinates turning this on for your organization, so it is not something you switch on yourself. Once it is turned on, it takes effect immediately for everyone it applies to.
Granular Security: What Every Organization Has, and What Some Don't
Every organization can create and manage console users. Named security roles, security policies, and individual permission statements are part of advanced granular security, which not every organization has. If your organization has granular security, the console user form includes a section where you can attach roles and policies and write individual statements. If your organization does not have granular security, that section is not shown. Creating a user still creates their identity, but you do not get a way to build fine-grained access beyond what your organization’s plan allows by default.
If you open the security roles or policies screens directly without this capability, Rhythm tells you the capability is not available. That is different from a permission message. Unavailable means nobody in your organization can use that capability without upgrading, while a permission message means you personally need a different role. For the mechanics of composing a role or policy once your organization has this capability, see Security Roles, Policies, and Permission Statements.
What Determines Access
When your organization has granular security, a console user’s access comes from several places:
- Any security roles attached to the person.
- Any security policies attached directly, separate from a role.
- Any individual permission statements written for that person alone, not shared with anyone else.
- Optional restrictions to specific accounts and specific applications, if your organization uses more than one account or wants to keep a person out of certain applications entirely.
Rhythm does not have one screen that summarizes a person’s final combined access after every role, policy, and statement is added together. To review someone’s access today, open their user record and follow each attached role and policy. Because a record edited long ago may have been edited by someone who had broader access then than they have now, treat an old change as evidence of what was possible at the time. It does not always prove what the person can do today, especially when the timing of a permission change is not clear.
A security role generally controls which actions a person can take, while a managed policy controls which applications or modules they can reach at all. Raising someone’s role does not help if the real issue is that they cannot reach the application, including Security & Settings. Administrators commonly work with a small set of built-in role levels: a Read-Only level for viewing only, Day-to-Day for standard record work, Power User for broader operational tasks, and Administrator, sometimes called Superuser, for full administrative and setup access, including billing and configuration that lower levels cannot touch. Some organization-level roles, such as a facilitator role for an organization's own administrative contact, are built to automatically carry every permission for that organization. Moving that person to a more limited role removes that broader authority along with it. These descriptions only go so far. They will not always tell you whether a specific role can perform one particular action, such as cloning an event. When the general description leaves you unsure, check the person's actual permission statements or test the action in question instead of guessing from the role's name.
Rhythm-managed policies are useful when one person needs different access in different applications. For example, you can give someone read-only access to CRM records while giving them full day-to-day access to Events, combined with access to every account and the ability to sign in to the Console at all. That gives you more control than relying only on a broad security role that treats every application the same way.
flowchart TD
U[Console user] --> R[Security roles]
U --> P[Policies attached directly]
U --> S[Individual statements]
R --> RP[Policies inside each role]
RP --> RS[Statements inside each policy]
P --> PS[Statements inside each policy]
Your own Console permissions must allow you to grant someone else account or application access. Not every console user who can sign in can also decide what other console users are allowed to reach.
Restricting a User to Specific Accounts or Applications
When granular security is available, you can limit a console user to specific accounts and specific applications instead of letting them reach everything your organization has. The list of accounts you can choose from appears only after you turn on the account restriction. If you leave it off, the person keeps access to every account you have.
If you restrict accounts, you also choose the person’s default account, which Rhythm opens when they sign in. The default account must be one of the accounts you allowed. Otherwise, Rhythm refuses to save and explains the conflict so you can fix it before anything is written. You can grant someone access to a sandbox without making the sandbox their default. Keeping your live account as the default, even for someone who also works in a sandbox, is the safer choice because it makes them less likely to mistake one for the other during routine work.
If you set up a new sandbox, you may need to update an existing console user's profile before they can reach it, even if they could already reach your other accounts. Make that change the same way you make any other account-access change: edit the person's record under System & Security › Security › Users.
Switching Between Accounts You Can Access
If your own console user can reach more than one account, you are not limited to the account that opened when you signed in. Use the account switcher in the top bar, choose the option for another account, and start typing that account's name to find and switch to it.
Cloning a Colleague's Access
You can clone an existing console user instead of building a new person’s access from scratch. Cloning copies the source person’s roles, policies, statements, and account or application restrictions into a new, unsaved user record. You then adjust the record and save it under the new person’s identity. Rhythm does not show a summary of what will be copied before you save, so review the source person’s roles and policies first if you are not sure they are appropriate for the new person.
Removing or Suspending Access
You can disable a console user without deleting their record. Disabling keeps the person’s history and settings while stopping their access, and you can re-enable them later. Deleting a user is separate and permanent. Rhythm confirms deletion with a warning that it cannot be undone, and deleting removes both the person’s identity and the access profile that held their roles and policies.