Access control
Who can see, edit, and delete team launch bundles
On team workspaces, Linky derives three roles from your Clerk org role and gates the dashboard around them. The defaults keep a team safe; admins can adjust by renaming a role in Clerk.
The three derived roles
| Role | Can do | Cannot do |
|---|---|---|
| admin | View, edit, delete, manage API keys, view insights | — (full authority on the team's bundles) |
| editor | View, edit, view insights | Delete a bundle, mint or revoke API keys |
| viewer | View the dashboard list + insights | Edit, delete, manage API keys |
Personal workspaces have no roles — you are always admin of your own launch bundles.
How Linky reads your Clerk role
Linky looks at the role on your membership row and maps it to one of the three derived roles above. The mapping is:
org:admin→ adminorg:member→ editor- Any custom role whose slug starts with
linky:editor→ editor (e.g.linky:editor:reviews,linky:editor:incidents) - Anything else → viewer (conservative default)
Privilege escalation to admin only happens through org:admin. A custom role cannot claim admin authority by naming itself linky:admin:* — Linky ignores the prefix and that role falls through to viewer.
Changing someone's role
Open your team in the Clerk dashboard, pick the member, and change their role. Linky picks up the change on the next webhook delivery (seconds, not minutes). You do not need to do anything inside the Linky dashboard.
If you need a power-user role that is not a Clerk admin, create a custom role with a slug starting with linky:editor. Every slug under that prefix maps to editor regardless of suffix — useful when you want Clerk's own access model to distinguish linky:editor:reviews from linky:editor:incidents even though both have the same Linky authority.
What deleting a bundle actually does
DELETE is restricted to admin on purpose. The action is soft: the row stays in the database, the launcher at /l/:slug returns 404, and the edit history in linky_versions survives. Recovery is a one-line SQL update an admin can run from the Neon console. That tradeoff buys a safer default: an editor cannot permanently strip tabs from a team bundle that a teammate depends on.
API keys and roles
Team API keys act as the team itself, not as the human who minted them. They default to the editor effective role — they can view and edit team bundles, but they cannot delete or manage other keys. This keeps an automation credential from escalating past what a human editor could do, even if an admin minted it.
If you need an automation that can manage keys, pair a team admin with a personal API key scoped to keys:admin. See the CLI guide for how to store and use keys.
What viewers of your launcher see
None of this applies to the public /l/:slug page — any viewer can open any Linky the launcher URL points at. Roles gate the owner-facing dashboard surfaces only. Personalized tab sets for viewers are controlled by the resolution policy, not by team roles.