Role hierarchy, permission matrix, and access control.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
Role hierarchy, permission matrix, and access control.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Seedly CRM controls who can see, create, edit, and delete data across the platform. The system is designed for the agency model - with agency-level oversight, brand-level management, and sub-account-level daily operations.
The platform includes four built-in system roles arranged in a strict hierarchy. Users with a higher-level role have broader access and can manage users at or below their level.
| Role | Scope | Purpose |
|---|---|---|
| Agency Owner | Full agency + all sub-accounts | Top-level administrator with unrestricted access to everything, including billing, plans, and system configuration |
| Brand Admin | Brand + assigned sub-accounts | Manages all sub-accounts within their brand, including branding, billing schedules, and integration overrides |
| Sub-Account Admin | Single sub-account | Full access within their assigned sub-account, including user management and settings |
| Sub-Account User | Single sub-account | Day-to-day user with permissions controlled by their role assignment |
A user cannot create or assign a role that is equal to or higher than their own. This prevents privilege escalation.
In addition to the four system roles, you can create custom roles at the agency level or sub-account level. Custom roles let you define exactly what a team member can and cannot do.
You can start from an optional permission template or select permissions module by module.
| Template | Description |
|---|---|
| Full Access | All permissions on all modules |
| Admin (No Billing) | Full access except billing and plan management |
| Sales Rep | Access to contacts, pipelines, conversations, tasks, and calendar - no settings or admin |
| Standard | Common day-to-day permissions for most team members |
| Limited | Read-only access to most modules with create/edit on assigned records only |
Permissions are defined as a matrix of 35 modules and 4 actions:
| Action | What It Controls |
|---|---|
| View | Can the user see records in this module? |
| Create | Can the user create new records? |
| Update | Can the user edit existing records? |
| Delete | Can the user remove records? |
Permissions are configured independently for each of these modules:
| Module | Module | Module |
|---|---|---|
| Dashboard | Contacts | Companies |
| Contact Lists | Conversations | Power Dialer |
| Call Reports | Call Recordings | Call Transcripts |
| Calendar | Tasks | Opportunities |
| Pipeline Configuration | Campaigns | Segments |
| Email Templates | Suppressions | Bulk SMS |
| Workflows | Forms | Social |
| Invoices | Estimates | Subscriptions |
| Products | Documents | Reputation |
| Settings | Users | Billing |
| Sub-Accounts | Files | Reporting |
| Notifications | Audit Logs |
Some modules are grouped under a parent. If a specific sub-module permission is not defined, the system falls back to the parent module's permission. For example, if "Companies" permissions are not explicitly set, the system checks the "Contacts" permission instead.
For modules where it makes sense, permissions include a scope setting that controls which records the user can access:
| Scope | What It Means |
|---|---|
| Own Records | Records assigned to the user |
| Own + Unassigned | The user's assigned records and unassigned records |
| Team | Records assigned to the user's team |
| Team + Unassigned | Team records and unassigned records |
| All Records | All records in the sub-account |
The editor gives each module separate View, Create, Update, and Delete choices, plus one scope selector where record scope applies. In the example above, Contacts has View and Create selected with Own Records as its scope; Update and Delete remain off. Review both the action choices and scope before assigning the role to a user.
Agency owners can create subscription plans that enable or disable entire modules. When a module is gated by plan:
This lets you create tiered product offerings - for example, a "Starter" plan with contacts, conversations, and pipelines, a "Professional" plan that adds workflows and campaigns, and an "Enterprise" plan with everything.
Plans can control access to:
In addition to feature gating, plans can define usage limits that cap how much of each resource a sub-account can consume:
| Resource | What It Limits |
|---|---|
| Contacts | Maximum number of contact records |
| Users | Maximum number of team members |
| SMS per month | Monthly SMS message quota |
| Workflows | Maximum number of active workflows |
| Storage | File storage capacity |
Usage limits are enforced at the backend level. When a limit is reached:
Current usage against limits is visible in the settings area, so sub-account admins can monitor their consumption and plan accordingly.
Plan usage limits are about what a customer bought. A second set of limits exists to contain a runaway automation or a compromised account, and those are yours to adjust rather than fixed:
They live in settings. Raise them deliberately: a workflow repeatedly hitting its daily cap is more often a workflow re-entering in a loop than a cap set too low.
Permissions are enforced at two levels:
Every mutation (create, update, delete operation) checks the user's permissions before executing. If the user does not have the required permission, the operation fails with an authorization error. This enforcement cannot be bypassed from the frontend.
The UI uses permission data to show or hide interface elements. Buttons, menu items, and entire navigation sections are hidden when the user lacks the required permission. This provides a clean experience - users only see what they can act on.
Both layers work together: the frontend prevents accidental unauthorized actions, and the backend guarantees that no unauthorized operation can succeed regardless of how the request originates.
Every permission-checked action is recorded in the audit log, including:
The audit log is searchable and filterable by action type, entity type, user, and date range. It can be exported for compliance and review purposes.
| Capability | Detail |
|---|---|
| System roles | 4 (Agency Owner, Brand Admin, Sub-Account Admin, Sub-Account User) |
| Custom roles | Unlimited, at agency or sub-account level |
| Permission modules | 35 |
| Actions per module | 4 (view, create, update, delete) |
| Scope options | 3 (own, team, all) |
| Permission templates | 5 (Full Access, Admin No Billing, Sales Rep, Standard, Limited) |
| Feature gating | Per plan, per module |
| Usage limits | Per plan (contacts, users, SMS, workflows, storage) |
| Escalation prevention | Users cannot assign roles at or above their own level |
| Enforcement | Dual: backend (mandatory) + frontend (UI filtering) |
| Audit logging | Every mutation, searchable and exportable |