ReFresh applies a few guardrails so a role change cannot quietly break access, lock your organisation out, or let someone give themselves more power than they have. This article explains each one, the message you will see, and what to do. For the basics of creating and assigning roles, start with Managing custom roles and permissions.
You can only grant what you already hold
You cannot give a role, or build a role, that carries permissions you do not hold yourself. If you try, ReFresh refuses with a clear message such as "You cannot grant this permission set."
This applies everywhere a role is handed out:
assigning a role to a user (on the role's People tab),
setting the role on an invite,
choosing a single sign-on (SSO) connection's default role,
mapping an identity-provider group to a role, and
building a custom role (you cannot compose a role stronger than your own and then assign it).
Organization Admin holds the full set of assignable permissions, so an Organization Admin can assign any role. A narrower admin can only grant roles whose permissions are within their own. This is what stops someone quietly escalating themselves to full admin.
Provided roles cannot be edited
Roles marked Provided are maintained by ReFresh and are read-only. The role page shows "ReFresh provides this role. Create your own role to change what it can do." To change one, use Duplicate to Customise to make an editable custom copy, then edit the copy. See Managing custom roles and permissions.
When a role cannot be deleted
Deleting a role removes its permissions from everyone who holds it, and it cannot be undone. ReFresh blocks a delete (the Delete Role button is disabled, with the reason shown) in these cases:
The role is still in use: "This role is still in use by members, invites, or SSO mappings. Remove those first." Reassign or remove the holders, invites and SSO mappings, then delete.
The role is a default: "This role is a default for new members. Choose a different default role first." Pick a different organisation, group or SSO default, then delete.
It is the last role that can manage roles: "This is the only role that can manage roles. Deleting it would leave nobody able to edit roles for your organisation." Make sure at least one other role, held by someone, can manage roles first.
It has already been deleted: "This role has already been deleted." This is usually a stale tab, so refresh the page.
The "Delete" button is not available, nor is the "Save" button, on roles that you did not create.
Admin permissions do nothing without admin panel access
Allow admin panel access is a separate setting in the role editor, not a permission in the picker. If you grant a role admin permissions but leave this setting off, the holder stays in My ReFresh and cannot reach the screens those permissions unlock, so the role looks as though it does nothing. If a newly assigned role is not working, check this setting first. A portal-only role with the setting off is perfectly valid; see Managing custom roles and permissions.
"Own" versus "whole-organisation" permissions
Two permissions can look almost identical but differ in reach. A "View" or list permission often means "across your organisation, not just your own", which exposes everyone's records of that type, not only the holder's. The description under each permission tells you which it is. Read it before ticking, especially for people data, survey responses and incidents, and prefer the narrowest permission that does the job.
Some permissions cannot live in a custom role
A few permissions are reserved for the platform and cannot be granted through a custom role. If you duplicate a provided role that includes one, the save is refused with a message that names the permissions involved (for example, permissions that manage programmatic API access). Start from a role without those permissions, or remove them from your copy. This is most likely when duplicating the broad Admin or Organization Admin roles; the more focused provided roles duplicate cleanly.