Roles and permissions for a link workspace
Who can create, who can edit, who can add a domain. A small permission model prevents most link accidents.
By ShortFreeURL Team · 28 July 2026
The three actions worth separating
Creating links, editing existing links, and administering domains and members are different risks. Creation is cheap and reversible. Editing a live link changes what an audience already trusted. Adding a domain determines which hostnames your organisation can publish under. A permission model that does not distinguish these is not doing much work.
A model that fits most organisations
Owner controls billing and can delete the workspace. Admin manages members, domains and settings. Member creates and edits their own links and can view team analytics. Read-only sees links and reports but changes nothing. Four roles cover the overwhelming majority of real needs, and adding more usually creates confusion rather than safety.
Scope permissions by domain, not just by role
The domain printed on your packaging deserves stricter control than the one used for internal test links. Let admins grant a team access to specific domains. This is the single most useful refinement beyond basic roles, because it lets you say yes to a wide group of creators without exposing the domain that matters most.
Read-only access is the underrated role
Executives, agency partners and adjacent teams usually want to look at numbers, not create links. Giving them read-only access removes the two worst alternatives: sharing a password, or someone exporting screenshots into a slide deck every week. It also means the analytics everyone quotes come from one place.
Separate teams when the work does not overlap
If two brands or two regions share a workspace, their link lists become a shared mess and their reports need constant filtering. Separate teams inside one organisation, each with its own domains and members, is cleaner than a single flat list with tags. Use tags for cross-cutting concerns like campaign or quarter, and teams for organisational boundaries.
Offboarding is the test of the model
When someone leaves, you should be able to remove their access without breaking a single live link. That requires links to be owned by the team rather than the individual, and it requires nobody to be logging in through a shared account. Run the thought experiment now: if your busiest link creator left tomorrow, what would break?
Keep an audit trail and look at it occasionally
Record who created each link, who changed a destination and when. The point is not surveillance; it is that when a link points somewhere unexpected, the fastest route to an explanation is knowing who last touched it. Review the log after any incident and once a quarter otherwise.
