OKR roles and permissions
Last updated: September 4, 2026
Rhythms has three workspace roles: Rhythms Admin, Member and Guest. Two other labels you will see are not workspace roles: Team Owner is a flag on a team membership, and Delegate is a role on a single OKR. What Members and Team Owners are allowed to do with organization, team and individual OKRs is set by a Rhythms Admin at Settings › OKRs › Permissions, which has five rows for each level: Create, Manage, Edit, Approve (shown only when the approval workflow is on) and View.
Workspace roles
Every user in Rhythms has exactly one workspace role. The role is set on the Users page (Settings › Workspace › Users) in the Role column.
| Role | Who it is for | What it can do |
|---|---|---|
| Rhythms Admin | The people who run the workspace | Full access to every OKR regardless of the permission settings. Manages everything under Settings: users, teams, OKR permissions, security (SSO and directory sync), connectors and billing. Can log in as another user to troubleshoot. |
| Member | Everyone who owns, updates or works with OKRs | Creates individual OKRs. Creates team-level or organization-level OKRs when the Permissions page allows it. Edits and manages the OKRs they own or created, and any others the permission settings allow. Can be made a Team Owner or a Delegate. |
| Guest | Stakeholders who only need to look | Views the OKRs, documents and views that are visible to them and can ask the Rhythms agent questions. Cannot create, edit, check in, comment or own OKRs, and is never granted any of the permissions below. See Guest users: read-only access. |
Team Owner
A Team Owner is a member of a team whose membership is set to "Team Owner" on that team's Manage members page. Team Owners add and remove members of their team, create sub-teams under it, and, depending on the Permissions page, create, edit, manage and approve OKRs assigned to their team. Team Owner is not a workspace role: a Team Owner is still a Member (or a Rhythms Admin). See Create and manage teams.
Delegate
A Delegate is assigned on one OKR by its owner or by anyone who can manage that OKR. A Delegate can edit the OKR's content, update progress, check in, align it and change its visibility, but cannot delete it, transfer ownership or change who the delegates are. See Assign delegates.
The five OKR permissions
Each row on the Permissions page controls one kind of action on OKRs at that level. The descriptions below are the ones shown on the page.
- Create — who can create new OKRs at this level.
- Manage — who can delete, transfer ownership, and change delegate settings.
- Edit — who can modify content, update progress, and check in. Check-ins always follow the Edit permission; a Manage permission on its own does not let you check in.
- Approve — who can publish draft, pending-approval OKRs. This row appears only when the approval workflow is enabled for your workspace.
- View — who can view OKRs at this level. This sets the default visibility of new OKRs at the level and can be overridden per OKR through its visibility settings.
Change OKR permissions
- Open Settings from the left navigation, then OKRs › Permissions. Only Rhythms Admins can open Settings.
- Choose the level you want to change: the Organization, Team or Individual tab.
- Pick an option in the dropdown next to Create, Manage, Edit, Approve or View.
- The change saves immediately and Rhythms confirms with "Permissions updated". It applies workspace-wide to every OKR at that level the next time someone attempts the action.
If your workspace uses custom terminology, the page and its option labels use your word for OKR (for example "Goal owners and their managers").
Options and defaults by level
The same set of options appears across the levels. This is who each option grants the permission to:
- Admins only — Rhythms Admins.
- Team owners (organization-level Create only) — anyone who is a Team Owner of at least one active team.
- OKR owners and their managers — the OKR's owners and each owner's direct manager (the Manager on the user's profile). It does not extend further up the management chain.
- OKR team owners — people who are Team Owners of every team the OKR is assigned to. Not all Team Owners in the workspace.
- OKR team members — people who are direct members of every team the OKR is assigned to.
- Anyone in the organization — every Member and Rhythms Admin. Guests are always excluded.
The default for each row is in bold. The Permissions page always shows your workspace's current values.
| Level | Permission | Options |
|---|---|---|
| Organization | Create | Admins only · Team owners · Anyone in the organization |
| Organization | Manage, Edit, Approve | Admins only · OKR owners and their managers · Anyone in the organization |
| Organization | View | Anyone in the organization (the only option) |
| Team | Create | Admins only · OKR team owners · OKR team members · Anyone in the organization |
| Team | Manage, Edit, Approve | Admins only · OKR team owners · OKR owners and their managers · OKR team members · Anyone in the organization |
| Team | View | Anyone in the organization · OKR team members |
| Individual | Create | Anyone in the organization (the only option) |
| Individual | Manage, Edit, Approve | OKR owners and their managers · Anyone in the organization |
| Individual | View | Anyone in the organization (the only option) |
Who always has access, whatever the settings
- Rhythms Admins can view, edit, manage and approve every OKR in the workspace.
- Owners and creators can always edit and manage the OKRs they own or created. If you create an OKR and assign it to someone else, you keep full access alongside the new owner.
- Delegates can always edit (but not manage) the OKRs they are delegated on.
- Guests never gain any of these permissions, even when a row is set to "Anyone in the organization".
Permissions and visibility are different controls
OKR permissions decide what you can do with an OKR you can see. Visibility decides who can see the OKR at all. An OKR with limited visibility must be shared with you (directly or through your team) before any permission applies; owners, creators and delegates are always included, and Rhythms Admins always see everything. The View row on the Permissions page only sets the default visibility for new OKRs at that level. See OKR visibility.
Permission matrix by role
How the roles compare when the Permissions page is at its defaults. "Per setting" means the answer depends on the row for that level.
| Action | Rhythms Admin | Member | Team Owner | Guest |
|---|---|---|---|---|
| Create organization OKRs | Yes | Only if Create is "Anyone in the organization" | Only if Create is "Team owners" or "Anyone in the organization" | No |
| Create team OKRs | Yes | Only if Create is "OKR team members" (for their teams) or "Anyone in the organization" | Yes for their own teams (default "OKR team owners") | No |
| Create individual OKRs | Yes | Yes | Yes | No |
| Edit and check in | All OKRs | OKRs they own, created or are delegated on; others per setting | Same as Member; plus their teams' OKRs when Edit is "OKR team owners" | No |
| Manage (delete, transfer, delegates) | All OKRs | OKRs they own or created; others per setting | Same as Member; plus their teams' OKRs when Manage is "OKR team owners" | No |
| Approve pending OKRs | Yes | Per setting (default: OKRs they own or whose owner reports to them) | Per setting | No |
| View OKRs | All, including limited visibility | OKRs visible to them | OKRs visible to them | OKRs visible to them |
| Invite users to the workspace | Yes | Only if Invite Permissions (Settings › Workspace › General) is "All Members" | Same as Member | No |
| Add members to a team | Any team | No | Their teams | No |
| Create teams | Top-level teams and sub-teams | No | Sub-teams under their teams | No |
| Change roles, deactivate users, configure SSO, directory sync, connectors, billing | Yes | No | No | No |
Troubleshooting "permission denied"
When Rhythms refuses an action it tells you which setting is in the way. The messages map to the Permissions page like this:
- "Only Admins can edit this goal" (or manage, or approve) — the row for that level is set to Admins only.
- "Only the Owners and their managers can edit this goal" — the row is OKR owners and their managers and you are neither an owner nor an owner's direct manager.
- "Only the OKR's Team Owners can edit this goal" or "Only the OKR's Team Members can edit this goal" — the row is OKR team owners or OKR team members and you are not an owner or member of every team the OKR is assigned to.
- "Only Rhythms Admins can create organization-level OKRs", "Only Team Owners and Rhythms Admins can create organization-level OKRs", "You are not an owner of {team}. Only Team Owners can create OKRs for their teams." and "You are not a member of {team}. Only Team Members can create OKRs for their teams." — the Create row for that level.
- "Guest users are not allowed to perform this action" or "You do not have permission to create OKRs" — the user is a Guest. Change the role to Member on the Users page.
To get the action done, ask the OKR's owner or creator (they always have full access), ask a Rhythms Admin, or ask a Rhythms Admin to change the row for that level. If you cannot see the OKR at all, the issue is visibility, not permissions.
Frequently asked questions
What is the difference between editing and managing an OKR? Editing is day-to-day work: changing the title, description, dates or key results, updating progress and checking in. Managing controls the OKR's lifecycle and ownership: deleting it, transferring it to another owner and changing delegates. They are separate rows so a workspace can let many people update progress while restricting who can delete.
Why can I edit an OKR but not delete it? You have Edit but not Manage for that level. Ask the owner, creator or a Rhythms Admin to delete it, or ask a Rhythms Admin to widen the Manage row.
Can Team Owners always edit their team's OKRs? Not automatically. Team Owners always have access to the OKRs they own or created; for the rest of their team's OKRs it depends on the Team tab. With the default "OKR owners and their managers", being a Team Owner alone does not grant edit. Set Edit (and Manage) to "OKR team owners" if you want team leads to be able to update every OKR assigned to their team.
Does "OKR owners and their managers" include my manager's manager? No. Only the owner and the owner's direct manager qualify.
What happens if I restrict a permission after OKRs already exist? The new setting applies to every OKR at that level the next time someone attempts the action. Owners and creators keep full access to their own OKRs, so a restriction mainly affects people who were relying on a broad setting.
Why is there no Approve row on my Permissions page? The approval workflow is turned off for your workspace. The row appears as soon as it is enabled.
Can I grant a Guest one of these permissions? No. Guests are view-only regardless of the settings. Change the user's role to Member instead.
Which settings are right for us? Larger organizations usually keep organization-level Create at "Admins only" and Manage at "Admins only" or "OKR owners and their managers", set team-level Edit to "OKR team members" and Manage to "OKR team owners", and leave individual OKRs at the defaults. Smaller teams often set Edit to "Anyone in the organization" and keep Manage narrow to avoid accidental deletion.