You or a colleague tried to sign in to the Console, open Security settings, or use a security feature, but Rhythm denied access, showed a blank result, or did not show the option. This page covers Security & Settings causes, such as a console user missing a default account or role, a recent change to a security policy or role, or your organization not having this level of security turned on. For a general explanation of Access Denied messages and greyed-out buttons anywhere in the Console, see I Get "Access Denied" or a Button Is Greyed Out.
1. Their Console User Record Is Missing a Default Account or a Role
Check. Open the person’s console user record from System & Security › Security › Users, then select their name. In their account settings, confirm that they have a default account to open. If their access is limited to certain accounts, make sure the default account is one they are allowed to use. Then check whether they have a security role, an attached policy, or their own permission statements. When a console user has none of those, they can sign in but have nothing granting access beyond that. A newly created console user starts with no default account and no role, so check both for every new person, not only when something changes.
Why this happens. The default account field is not required, so the record still saves when it is blank. Rhythm also does not automatically give a newly created console user a role or policy. Someone can be created and saved successfully, but still be unable to do anything useful in the Console until you set both. A blank default account can look like the Console is stuck because the person signs in, but the screen cannot move past loading or verification when there is no account to open.
A related setting can look the same but needs a different fix. If the person's default account points to an account they are not meant to use day to day, such as a sandbox or test account, the Console can load indefinitely or refuse access until you change the default account to the correct one. Check what the default account is actually set to, not only whether one is set.
For staff who sign in with a Rhythm-managed login rather than a personal one, the same two settings matter, but reports on exactly what is required have varied. Some describe needing only a default account and any applicable role, while others describe needing an administrator or superuser-level role before the person could sign in at all. Until your administrator confirms which applies to your organization, set both a default account and a role that matches the person's job. If you need to rule out a role shortage quickly, use a higher-privileged role temporarily.
A valid sign-in does not always mean useful access. A person can be created correctly, appear in the list as active, and still see no accounts or data if their access level for a particular account or team is set to None instead of an actual role. Check the access level for the account in question, not just whether a role exists somewhere on the record.
If the permission checkboxes on a user's record keep loading and never populate, the cause is usually not the user's own record. This can mean your Rhythm account does not yet have the applications those permissions cover turned on. Contact Rhythm Support to confirm which applications are enabled for your account if this happens.
Fix. Set a default account the person is allowed to use, then attach a role, a policy, or both. If you need to restore access quickly while you work out the right long-term role, making the person a full administrator temporarily is the fastest way to rule out a permissions problem. If several people in your organization are denied access at once, the Console is not necessarily down. Several people's access configuration or sign-in credentials may need attention, so check each affected person instead of assuming one outage. If the person's account and role both look correct and sign-in still fails, their credentials may need to be refreshed; ask Rhythm Support about this after you have ruled out everything else.
Warning
Giving someone a higher-privileged role does not guarantee the problem is fixed. If the same Access Denied message appears after you give them more access, check for a separate policy or restriction that still blocks that specific action. The issue could also be with the record they are working on, rather than a simple role shortage. Confirm that the person is genuinely an administrator or superuser before you dig further. Once that is confirmed, ask whether the error happens only for one particular query, page, or action, since that points to a narrower restriction instead of a missing role.
Resaving someone's allowed applications is a useful way to confirm their access is set correctly, but it is a diagnostic step, not a guaranteed fix. If the same person can already use the page or feature from a different computer or browser, an unchanged access setting does not rule out the problem. It points toward something local to that browser instead.
2. A Permission, Role, or Account Boundary Is Blocking One Specific Action
Sometimes a person can sign in, has a sensible role, and can use most of the Console, but one specific action still fails, does nothing, or is refused. This is different from the missing default account or role issue in section 1, so it needs a different check.
Check. If a clickable option does nothing for one person but works when a colleague tries the same thing on the same record, compare their roles and policies first. Some actions require more than the general role the person holds. For example, the duplicate-contact review action on a contact record can be visible but not work for someone with a Day-to-Day role, because it requires a higher level of access than that role provides.
Account boundaries can create the same kind of narrow refusal. A person who is a full administrator for more than one account can still be denied when opening Policies or Roles after switching to another account, even though the same access works on the first account. When an administrator's own sign-in email uses a different domain than the account they are trying to administer, changes to that account's Security Policies or Roles can be refused, even though the same administrator can change other settings normally.
If you administer single sign-on for your own website or application, that configuration lives in the same area as your other security policies. It depends on the same role and policy access as everything else here. Being able to view that area does not mean every change you try to save will succeed, because a save can still fail for a separate reason after the section is visible. Setting up the connection to an outside identity provider is often a two-sided task. Some configuration happens in Rhythm, and some happens with the identity provider itself, so full access inside Rhythm does not always mean you can finish the setup without help from whoever manages that outside system.
Fix. Compare the affected person's role, policy, and any individual permission statements with a colleague who can perform the action successfully. Add whatever the working colleague has that the affected person lacks. If the barrier is an account boundary rather than a role, check which account you are working in and confirm that the administrator's own account access and sign-in details match what that account expects.
3. A Security Policy or Role Someone Depended on Was Recently Changed
Check. Ask what recently changed in your organization’s security roles or policies, and who was affected. Rhythm does not warn you before you delete a security policy or role that is still attached to someone, and it does not check first whether anyone is using it. If a policy or role was deleted, renamed, or had its statements changed, everyone who had it loses whatever it granted, without notice to them or to you. Missing sections on a person's screens can disappear for the same reason. For example, if sections that used to appear on a contact's record no longer appear, a role or group change may have removed the permission that showed them.
Before you assume access was removed outright, check when the person's role, policy, or permission assignment changed, then compare that with when they first noticed the problem. The same role or policy can still be attached but have edited statements, which produces the same symptom as losing the role entirely.
If your organization recently turned on basic security policies for the first time, every console user needs a role before they can sign in at all under that change. They need the role before they can sign in, not only before they can do anything useful. If people who could sign in before suddenly cannot, assign a high-level administrative role first, then adjust roles afterward. That is the fastest way to restore access while you sort out who should have what.
Fix. Open Security Roles and Security Policies and look for the policy or role in question. If it is gone, recreate it or create a replacement, then attach it to everyone who needs it. If it still exists, review its permission statements and any policies attached to it to see what changed. After a broader security-policy release, some console users may need their role reviewed and re-set to a more elevated one to match the new policy. Rhythm Support cannot make that role change inside your organization on your behalf.
4. Your Organization Hasn't Turned On This Level of Security
Check. Open System & Security › Security › Policies or › Roles from the left-hand menu instead of using a saved link. If your organization does not have this capability, you will see a message that custom security roles and policies are not available under your license. The message also names your Customer Success Manager as the person to contact about upgrading.
This is different from being denied because you lack a permission. Every administrator in an organization without this capability sees the same message, no matter what else they are allowed to do. It only affects the Policies and Roles screens. You can still create and manage individual console users, and attach any roles or policies that already exist, without this capability turned on.
Fix. If your organization should have this capability, contact your Customer Success Manager. If you reached the Policies or Roles page from a bookmark or browser history and nothing happened, that fits the same cause. Try the left-hand menu instead, because that is the only path that shows the explanation.
5. Multi-Factor Authentication Prompts or Blocks Sign-In
Check. If you completed a CAPTCHA challenge recently and are asked to complete another one soon after, that is not expected. A successful challenge should be reused for about five hours before you are asked again, so repeated prompts within that window mean the earlier CAPTCHA was not recognized.
If you are enrolling in multi-factor authentication and the text-message option shows an error about exceeding the maximum number of messages per hour, even on your first attempt, try an authenticator app instead, such as Microsoft or Google Authenticator. Authenticator-app enrollment has worked in cases where the text-message option did not.
If you turned on multi-factor authentication for a console user but they are never prompted to enroll, or enrollment seems stuck, try signing in again from an incognito or private browser window. You can also clear the browser's cache and cookies first. This resolves many cases, but not always. If enrollment still does not proceed afterward, the person's multi-factor setup may need to be reset before a fresh enrollment prompt appears, so contact Support if clearing the browser does not help.
Fix. For a stuck CAPTCHA, sign out completely and sign back in to get a fresh challenge. For multi-factor enrollment problems, use an authenticator app instead of text messages, and retry from a private browser window before escalating.
When to Contact Support
Contact your own administrator first for anything involving a specific person’s role, policy, or default account. Rhythm Support cannot grant or change access inside your organization, and cannot create a console user login for you. An administrator in your organization creates new console users from System & Security › Security › Users. Contact Rhythm Support when:
- your organization should have advanced security, meaning custom roles and policies, but the upgrade message still appears after your Customer Success Manager has confirmed the upgrade;
- an Access Denied message names a permission your administrator has already confirmed is correctly granted, and the problem continues after you allow a few minutes for the change to take effect;
- sign-in fails repeatedly for one person even after you have confirmed their default account, role, and access level are correct. Support can sometimes refresh that person's access as a remediation step and ask them to try again.
Include the affected person’s name, the exact message shown, any permission name included in the message, the account they were working in, and what they were trying to do.