Product · Roles & permissions
The right people, the right access.
Four built-in roles ship on every tier. Define your own custom roles on Business. Scope permissions to a workspace, an ontology, or a single scheme. Map your IdP groups straight to Semlify roles via SAML. Decide who can read, edit, tag, invite — and audit all of it from one screen.
Why it matters
A taxonomy is a shared artefact. Access shouldn't be a free-for-all.
The same workspace hosts the AI engineer who indexes against the graph, the taxonomist who curates it, the governance lead who approves changes, and the auditor who reads but never edits. Without roles, every action is a free-for-all — and every "who changed this?" question becomes an investigation.
Roles aren't the audit log; the audit log says what happened. Roles say what's allowed to happen. Together they're the smallest possible governance posture that survives a procurement review.
Level 1 · Every tier
Four built-in roles cover most teams.
Owner, Admin, Editor, Viewer. The four roles each correspond to a real lifecycle position — founder, trusted maintainer, day-to-day curator, read-only consumer. They ship on every tier from Free upward, with no setup. Most workspaces never need anything else.
- Owner — full control, including billing and member removal
- Admin — everything except billing; can invite and tag releases
- Editor — read and write concepts, schemes, relations; cannot tag or invite
- Viewer — read-only access for auditors and downstream consumers
Level 2 · Business tier
Custom roles for the 5% who need them.
When the four built-ins don't fit, design your own. A role is a name plus a set of granted permissions across the seven action categories: read, write, tag, deprecate, export, invite, billing. Build a 'Tagger' role that can read and tag but not edit. Build a 'Junior curator' that can write to drafts but not publish. Roles live at the workspace level and apply to every member granted them.
- Granular permissions across seven action categories
- Compose roles from primitives — no hidden inheritance gotchas
- Built-in roles remain available alongside custom ones
- Edit a role and every member with it inherits the change instantly
{
"id": "role_junior_curator",
"name": "Junior Curator",
"tier": "custom",
"permissions": {
"concept.read": true,
"concept.write": true,
"concept.deprecate": false,
"scheme.read": true,
"scheme.write": false,
"tag.create": false,
"export.run": true,
"member.invite": false,
"billing.view": false
},
"createdBy": "valentin@example.com",
"createdAt": "2026-04-12T11:08:33Z"
}Level 3 · Business tier
Permissions scope to the resource.
A role isn't always 'everywhere in the workspace.' Mixed-sensitivity workspaces — say, a public Cars ontology alongside a regulated Compliance ontology — need finer scoping. Grant a user Editor on `ont_cars` and Viewer on `ont_compliance`. The same person, the same workspace, two different postures, automatically enforced.
- Scope each role grant to: workspace · ontology · scheme
- A user can hold different roles in different ontologies of the same workspace
- Per-scheme grants for shared ontologies with mixed sensitivity
- Validation panel and exports respect the active grant — no leakage
[
{
"userEmail": "claire@example.com",
"role": "editor",
"scope": { "kind": "ontology", "ontologyId": "ont_cars" }
},
{
"userEmail": "claire@example.com",
"role": "viewer",
"scope": { "kind": "ontology", "ontologyId": "ont_compliance" }
},
{
"userEmail": "claire@example.com",
"role": "role_junior_curator",
"scope": { "kind": "scheme",
"ontologyId": "ont_cars",
"schemeId": "cs_body_styles" }
}
]Level 4 · Business tier
SAML SSO with IdP-group → role mapping.
Your identity provider already knows who's a Senior Curator and who's a New Hire. Don't rebuild that knowledge in Semlify — map it. Connect Okta, Entra, JumpCloud, or any SAML 2.0 IdP. Map a group claim like `engineering-data` to the Editor role, or to a custom role you've defined. Just-in-time provisioning means new hires land in the right role on first sign-in, no manual invite step.
- SAML 2.0 — works with Okta, Entra ID, JumpCloud, Google Workspace
- Map SAML group attributes to Semlify roles, declaratively
- Just-in-time provisioning · first sign-in lands in the mapped role
- Group changes in your IdP propagate on the next sign-in
# Maps the IdP "groups" SAML claim to Semlify roles.
# First match wins. Users without a match cannot sign in.
mappings:
- claim: "groups"
contains: "semlify-owners"
role: "owner"
- claim: "groups"
contains: "data-platform-admins"
role: "admin"
- claim: "groups"
contains: "engineering-data"
role: "editor"
- claim: "groups"
contains: "compliance-readonly"
role: "viewer"
scope: { kind: "ontology", ontologyId: "ont_compliance" }
- claim: "groups"
contains: "junior-curators"
role: "role_junior_curator"Every tier
API tokens carry their own role.
Generate an API token from any workspace; it inherits a role at creation time. Most pipelines only need to read, so the default is the most restrictive role that works. A leaked Viewer token can't write, can't delete, can't see other workspaces. Revoke from the dashboard at any time; the change propagates within seconds. Every token also has a last-used timestamp and IP — spot a leaked token before the auditor does.
- Pick the role at creation · same primitives as user roles, including custom
- One token = one workspace = one scope = one role
- Last-used timestamp and IP exposed in the dashboard
- Revoke is immediate · removed members lose every token they issued
# A Viewer token can read but not write
curl https://api.semlify.com/v1/ontologies/cars/concepts \
-H "Authorization: Bearer ont_pat_viewer_abc123"
# Same token cannot write
curl -X POST https://api.semlify.com/v1/ontologies/cars/concepts \
-H "Authorization: Bearer ont_pat_viewer_abc123"
# 403 Forbidden · role 'viewer' lacks 'concept.write'
# Token scoped to a single ontology cannot reach another
curl https://api.semlify.com/v1/ontologies/compliance/concepts \
-H "Authorization: Bearer ont_pat_viewer_abc123"
# 403 Forbidden · token scope does not include 'ont_compliance'Audit & visibility
Every grant is a record. Every record is queryable.
Role grants live in the same change history as concepts and tags. The Members view is a sortable list of every active grant; the audit log is the full history of who granted what to whom, when, and why.
- Members view — sortable by role, scope, last-seen, granted-by
- One-click revoke; one-click change-role; one-click extend access
- Every grant emits a ChangeEvent — visible in the global audit log
- Audit log API on Business+ — pipe role events into your own SIEM
- Quarterly access review export — auditors download a CSV in seconds
By tier
What unlocks where.
| Capability | Free | Team | Business | Enterprise |
|---|---|---|---|---|
| Four built-in roles | ||||
| Scoped API tokens | ||||
| Workspace-scoped permissions | ||||
| Members view + audit history | ||||
| Custom roles | — | — | ||
| Per-ontology / per-scheme grants | — | — | ||
| SAML SSO with group mapping | — | — | ||
| Audit log export over API | — | — | ||
| Custom role-attribute policies (ABAC) | — | — | — | |
| Identity-provider SCIM provisioning | — | — | — |
Further out
On the radar, not on a date.
- Just-in-time access — request a role grant for the next four hours, with auto-expiry
- Audit-only role with cryptographic read receipts for regulated environments
- Approval workflows on grants — second pair of eyes before a role is created
- Attribute-based access control — predicates over concept properties (e.g. 'department=R&D')
Stop debating who can edit what.
Built-in roles on every tier. Custom roles, per-resource grants, and SAML on Business. Free workspace, no credit card.