Roles and permissions
The four roles in an organization, what each is for, and how API keys and connected apps stay within them.
Everyone who works in a Nuvelics organization has one role in it. A role is a named set of permissions, and a permission is the right to do one specific thing, such as approve a pitch or manage credentials. You assign a role when you invite someone, and an owner or admin can change it later.
The four roles
| Role | What it is for |
|---|---|
| Owner | Full control, including organization settings, billing, deleting the organization and deactivating members. |
| Admin | Manages people, API keys, credentials and integrations, but not billing or organization settings. |
| Member | Does the editorial work: creates and edits data sources, newsdesks, pitches and stories, and pushes stories and articles to connected systems. Sees other members. |
| Viewer | Read-only access. Cannot make changes. |
The roles mostly widen in the order viewer, member, admin, owner, with one exception: a viewer can read the organization's details, which a member cannot. These differences explain most of what you see on screen:
- Setup belongs to admins. Creating credentials, NRCS, MAM, CMS and social connections, output templates, brand kits and story checks, API keys and spending caps need an owner or admin. The editorial work of newsdesks, pitches and stories belongs to members.
- Deleting a data source is an admin's call. Members can create, edit and run data sources; only owners and admins can delete them.
- A viewer sees the work, not the money or the trail. A viewer can read the newsroom's pitches, stories and outputs, but not the activity log or the usage pages.
- Some things are owner-only. Editing organization settings, deleting the organization, deactivating members and billing.
What you see follows what you can do
The web app hides or disables what your role cannot do. A Push to NRCS button is missing for a viewer; a "No template yet" note tells an administrator to create one and tells a member to ask. The checks happen on the server as well, so a hidden button is never the only barrier. When you wonder why a control is absent, your role is the first thing to check. The permission matrix lists which role holds each permission, and each web page lists the permission it needs.
API keys and connected apps
Software acts for people, and is held to the same limits:
- Signed-in users are always checked against their current role. Change a member's role and it applies on the next request.
- API keys carry their own list of permissions, which can never be more than their creator held when the key was made.
- Connected apps and AI agents, such as an assistant that you authorize to use your account, get your current role's permissions limited to the scopes you approved. If you are demoted or removed, their access narrows on the very next request, with no need to revoke anything.
This is why the consent screen lists what an app asks for, in plain words such as Edit stories or Push stories to NRCS, before you choose Allow or Deny.
Where to go next
The full permission matrix, how members and invitations are managed, and how API keys and connected apps are set up are in Account.