Permissions & Roles

Overview

Seedly CRM provides a comprehensive permission system that 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.

---

Role Hierarchy

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.

How the Hierarchy Works

• Agency Owners can see and manage everything across the entire agency, all brands, and all sub-accounts
• Brand Admins can manage any sub-account within their brand, but cannot access other brands or agency-level settings
• Sub-Account Admins have full control within their sub-account, including managing users and configuring settings
• Sub-Account Users have granular, configurable permissions - they see and do only what their role allows

A user cannot create or assign a role that is equal to or higher than their own. This prevents privilege escalation.

---

Custom Roles

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.

Each custom role starts from a permission template and can be fine-tuned per module.

Permission Templates

---

Permission Matrix

Permissions are defined as a matrix of 30 modules and 4 actions:

Actions

Modules (30)

Permissions are configured independently for each of these modules:

Sub-Module Fallback

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.

---

Scope Control

For modules where it makes sense, permissions include a scope setting that controls which records the user can access:

Scope applies independently to each action. For example, a sales rep might have:

• View: All (can see every contact)
• Create: All (can create contacts)
• Update: Own (can only edit contacts assigned to them)
• Delete: None (cannot delete contacts)

This gives you precise control over data access without creating an overly complex role structure.

---

Feature Gating by Plan

Agency owners can create subscription plans that enable or disable entire modules. When a module is gated by plan:

• The module does not appear in navigation for sub-accounts on that plan
• Backend operations for the module are blocked, even if the user's role would normally allow access
• Upgrading the plan immediately enables the module

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.

Gated Capabilities

Plans can control access to:

• Individual modules (contacts, pipelines, workflows, campaigns, etc.)
• Specific features within modules
• Integration access
• Advanced automation features

---

Usage Limits

In addition to feature gating, plans can define usage limits that cap how much of each resource a sub-account can consume:

Usage limits are enforced at the backend level. When a limit is reached:

• The user receives a clear message explaining the limit
• The operation is blocked
• The sub-account admin or agency owner can upgrade the plan to increase limits

Usage Tracking

Current usage against limits is visible in the settings area, so sub-account admins can monitor their consumption and plan accordingly.

---

Enforcement

Permissions are enforced at two levels:

Backend Enforcement

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.

Frontend Enforcement

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.

---

Audit Trail

Every permission-checked action is recorded in the audit log, including:

• Who performed the action
• What action was taken (create, update, delete)
• Which record was affected
• What changed (before and after values)
• When it happened

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.

---

Summary