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 granular and scoped to specific areas of the platform, such as integrations, sources, billing, or team administration.
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 read and write permissions for integrations, sources, applications, flows, onboardings, products, secret keys, publishable keys, service accounts, public data, and privacy settings. It also includes read access to audit logs and team settings, but it does not grant permissions to administer the team, manage roles or memberships, or modify billing.
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 the Administer Team permission can create, update, or delete roles. Members without that permission 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 the Administer Team permission can change another member's role, remove members from the team, and manage pending invitations. Members without that permission cannot promote another member to a role that includes administrative privileges they do not hold themselves.
Permission Levels
Most resource types use a consistent set of permission levels:
| Level | Typical access |
|---|---|
| Read | View existing resources and their configuration. |
| Write | Create, update, and delete resources within that area. |
| Admin | Perform administrative actions beyond standard create/update/delete, such as managing advanced configuration or elevated settings. |
Some areas only expose a subset of these levels. For example, public data has a write permission but no corresponding read permission, because that data is already public.
Available Permissions
The following permissions are available when configuring team roles.
| Permission Name | Read | Write | Admin | Notes |
|---|---|---|---|---|
| Audit Logs | View Audit Logs | Modify Audit Logs | Administer Audit Logs | |
| Secret Keys | View Secret Keys | Manage Secret Keys | — | |
| Publishable Keys | View Publishable Keys | Manage Publishable Keys | — | |
| Integrations | View Integrations | Modify Integrations | Administer Integrations | Covers integrations, materializations, transformations, rules, overrides, previews, tasks, SSO, requests, and jobs. |
| Sources | View Sources | Modify Sources | Administer Sources | Covers sources, syncs, notifications, enrichments, links, and linked resources. |
| Team | View Team | Modify Team | Administer Team | Administer Team adjusts roles and permissions, manages invitations and memberships, and manages blocks. |
| Products | View Products | Modify Products | — | |
| Applications | View Applications | Modify Applications | Administer Applications | Covers applications, validation rules, feeds, and clients. |
| Flows | View Flows | Modify Flows | Administer Flows | |
| Onboardings | View Onboardings | Modify Onboardings | — | |
| Billing | View Billing | Modify Billing | Administer Billing | Covers billing plans, subscriptions, and invoices. |
| Public Data | — | Modify Public Data | — | No read permission; data is already public. |
| Privacy | View Privacy | Modify Privacy | — | |
| Service Accounts | View Service Accounts | Manage Service Accounts | Administer Service Accounts | Covers service accounts and service account tokens. See Service Accounts. |
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 View Integrations and View Sources, but not write or admin access to either area.
Avoid assigning Administer Team broadly. Members with that permission can change roles, manage membership, and control who else has administrative 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.