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).
When a team is created, Edlink provisions four default roles:
| 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 administrative privileges such as managing roles or billing plans. |
| Developer | Broad read and write access to developer-focused areas such as integrations, sources, applications, flows, onboardings, and API keys, with limited access to team administration and billing. |
| Viewer | Read-only access to team resources. |
The Developer role is intended for engineers building and operating Edlink integrations. It includes create/read/update on product entities (applications, sources, integrations, credentials, tokens, and related children) and read-only access to team settings, roles, and audit log sessions. It does not include billing grants or any *.delete verbs.
These default roles can be used as-is, or you can 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 Team Roles section lists each role on your team and the permissions assigned to it. Members with sufficient access can create new roles, edit existing roles, or delete custom roles that are no longer needed.
When creating or editing a role, select the permissions that role should include. The All System Permissions section below the role list shows every available permission along with a short description of what it grants.
Only members with team_roles.create / update / delete can mutate roles. Members with team_roles.read can still view the role list and available permissions.
Assigning Roles to Members
Roles are assigned when you invite a team member or when you change an existing member's role from Settings > Members. Each member must have exactly one role at a time.
Members with memberships.update / memberships.delete and invitations.* can change another member's role, remove members, and manage pending invitations.
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. 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 a role to another member instead of sharing a single owner account.