Every member of an Edlink team is assigned a role. A role is a named collection of permissions that determines what that member can view and change in the Dashboard. Permissions are CRUD grants on a specific Meta entity (applications.read, sources.delete, team_roles.create).
Every team includes three default roles that Edlink manages:
| Role | Summary |
|---|---|
| Owner | Full access to all team resources and administrative actions, including billing and role management. |
| Editor | Broad read and write access to team resources, without role/block administration or team create. |
| Viewer | Read-only access to team resources. |
These managed roles are shared across teams, so they cannot be edited or deleted. The person who creates a team is assigned Owner. You can also create custom roles with a specific mix of permissions that better match your organization's needs.
Managing Roles
To view or manage roles, open Settings from the navigation header and select Roles from the sidebar.
The Managed Roles and Custom Roles sections list Edlink's shared catalog roles plus any custom roles on your team. Managed roles cannot be edited or deleted. Members with sufficient access can create custom roles, edit those custom roles, or delete custom roles that are no longer needed. Use About Roles in the page header for more documentation.
When creating or editing a role, select permissions in purpose-grouped tables (Team, Applications, Sources, Integrations, Identity & Access, Onboarding, Chats, Public Data, Billing, Privacy). Each table lists entities as rows with Read, Create, Update, and Delete checkboxes.
Owners and members with View and Edit access can create, update, or delete custom roles. Edlink managed roles (Owner, Editor, Viewer) cannot be changed. Members with View Only access can still view the Managed Roles and Custom Roles lists. Role mutations also require the matching team_roles.create / update / delete grants on the member's assigned role.
Members and access levels
Team membership still uses a legacy access level on Settings > Members: Owner, View and Edit, or View Only. View Only members cannot open the role editor or invite people. Creating, updating, or deleting a custom role also requires team_roles.create / update / delete on the member's assigned role.
Named team roles (Owner, Editor, Viewer, and any custom roles) are configured on Settings > Roles. Changing a member's legacy access level from the Members page is separate from editing the permission set on a custom role.
Members with View Only access cannot invite new people. See Inviting Team Members for the invite flow.
Permission Levels
Every team-managed entity exposes the same four verbs:
| Verb | Typical access |
|---|---|
| create | Insert a new row of that entity. |
| read | View existing rows and their configuration. |
| update | Patch an existing row (and non-delete actions such as resend or validate). |
| delete | Remove or soft-destroy a row. |
Slugs are {entity}.{verb} — for example applications.read, sources.delete, invoices.update. Child resources have their own entity (clients, syncs, rules) rather than inheriting a parent area grant.
Available Permissions
The role editor lists every {entity}.{verb} pair from the Meta catalog (GET /api/v2/teams/:team_id/permissions). Entities include teams, memberships, team roles, invitations, blocks, identity providers, applications and their children (credentials, publishable keys, clients, feed subscribers, origin policies), sources and their children (syncs, extractions, enrichments, links, transformations, overrides), integrations and their children (materializations, rules, flows, previews, jobs), onboardings, products, chats, audit log sessions, tokens, public-data claims, billing (invoices, subscriptions, plans), and privacy (agreements, policies, parties).
Best Practices
When designing custom roles, grant only the permissions a member needs to perform their job. For example, a member who only needs to monitor integration status may need integrations.read and sources.read, but not create/update/delete on either entity.
Avoid assigning team_roles.* and memberships.delete broadly, and avoid granting View and Edit or Owner access unless the member should change roles or membership. Those grants control who else has access on the team.
If a member leaves your organization, update or revoke their membership promptly rather than relying on shared credentials. Roles make it easier to transfer responsibilities by reassigning access to another member instead of sharing a single owner account.