Permissions & access control

Access control that governs
every layer of your platform.

Tenant roles, project-level permissions, client portal isolation, API token scopes, and firewall rules — enforced at every level so the right people see the right data, always.

Start free trial See enterprise overview
Access control capabilities

Every access boundary enforced — from UI to API

Six interlocking control layers ensure the right people access the right data with no exceptions and no gaps.

Tenant roles

Owner, Admin, Manager, Member — four-tier hierarchy governing platform-wide access.

Project roles

Project Owner, Manager, Contributor, Reviewer, Observer — fine-grained control per project.

Client portal isolation

Client guard uses a separate auth system — client users never touch the internal application.

API token scopes

Per-tenant API tokens with read-only, read-write, or resource-specific scope sets.

Firewall rules

IP allowlist and blocklist rules evaluated before tenant initialisation.

Visibility flags

Client Visible / Internal Only on every item — projects, tasks, tickets, notes, comments, attachments.

Tenant role hierarchy

Four-tier platform authority from Owner to Member

Tenant roles set the ceiling for every action on the platform. Owner and Admin hold full authority; Manager governs delivery; Member executes tasks — each role scoped precisely.

  • Owner holds unrestricted platform authority including billing and tenant configuration
  • Admin can manage users, settings, and all business data — cannot alter owner-level billing
  • Manager has delivery oversight: projects, contracts, sprints, and team assignments
  • Member accesses assigned work items only — no settings, billing, or user management
  • Only Owner and Admin can access Settings — enforced on every settings route
  • Role elevation requires Owner or Admin approval — no self-promotion path exists

Role Hierarchy

Tenant and project permissions model

Strict RBAC

Tenant Roles

Owner

Full platform authority

Level 1

Admin

Settings and user governance

Level 2

Manager

Delivery and resource control

Level 3

Member

Assigned work execution

Level 4

Project Roles

Project Owner Project Manager Contributor Reviewer Observer
Project-level permissions

Five project roles independent of tenant role

Project roles layer on top of tenant roles to give delivery teams precise control over who can act within each project — from full ownership to read-only observation.

  • Project Owner has full control over the project including role assignments and archival
  • Project Manager can manage epics, sprints, user stories, tasks, and team membership
  • Contributor can create and update tasks and log time against assigned work
  • Reviewer participates in approval workflows — can approve or reject deliverables
  • Observer can view the full project without taking any action — ideal for stakeholders
  • Project role is checked on every action — a tenant Manager cannot bypass a project Observer restriction

Role Hierarchy

Tenant and project permissions model

Strict RBAC

Tenant Roles

Owner

Full platform authority

Level 1

Admin

Settings and user governance

Level 2

Manager

Delivery and resource control

Level 3

Member

Assigned work execution

Level 4

Project Roles

Project Owner Project Manager Contributor Reviewer Observer
Client portal isolation

A separate auth guard keeps clients out of the internal app

Client users authenticate through a dedicated guard against the client_employees table. No shared sessions, no shared routes — the internal application is structurally inaccessible from a client login.

  • Dedicated `client` guard separate from the internal `web` guard
  • ClientUser model backed by the client_employees table — not the users table
  • auth.client middleware enforced on all portal routes under /{tenant}/client/
  • Client and internal sessions are fully isolated — no session sharing is possible
  • Client Admin manages Client Employee accounts without internal team involvement
  • Internal roles, rate cards, SLA formulas, and agent workloads are structurally inaccessible

Client Portal

Nexus Corp · Client view

Live

Platform Rewrite Q1

CON-2024-018 · Bucket-Based

Active
Delivery Progress 42%

Sprint 12

Current

14

Open Tickets

2

SLA Risk

Recent Invoices

Last 30 days

INV-2026-0041

Due Mar 31

$4,136 Pending

INV-2026-0038

Paid Mar 5

$3,890 Paid

Internal notes, rate cards, SLA calculation logic, and team capacity data are never visible here

API token scopes

Scoped, audited tokens for every external integration

Per-tenant API tokens carry explicit scope sets that are enforced on every call to the REST API — no token can exceed the permissions of its owning user or exceed its declared scope.

  • Tokens created and revoked in Settings → API by Owner or Admin only
  • Bearer token authentication on all /api/{tenant}/v1/ endpoints
  • Scope options: read-only, read-write, or granular resource-specific scope sets
  • Scope evaluated on every API call before data is returned or mutation is applied
  • Token cannot grant permissions beyond those of the user who created it
  • Every token creation, use, and revocation recorded in the tenant audit log
GET /api/{'{tenant}'}/v1/projects
200 OK
Bearer token · scope: read Tenant-scoped v1 · JSON:API 48 ms
Response Body application/json 
{
  "data": [
    {
      "id": "proj_01H9X...",
      "type": "project",
      "attributes": {
        "name": "Platform Rewrite Q1",
        "status": "active",
        "budget_hours": 800,
        "logged_hours": 341,
        "completion_pct": 42.6
      },
      "meta": {
        "open_tickets": 14,
        "sla_breach_risk": 2
      }
    }
  ],
  "meta": {
    "total": 12,
    "per_page": 25,
    "current_page": 1
  }
}
Rate limit: 600 req/min X-RateLimit-Remaining: 597
Effigate REST API v1
Visibility flag system

Client Visible / Internal Only enforced at the server — not just the UI

Every record carries a visibility flag evaluated before data leaves the server. No URL manipulation, API call, or client-side trick can surface an Internal Only record in a client session.

  • Visibility flag on projects, tasks, tickets, notes, discussions, comments, and attachments
  • Flag is evaluated at the API layer before any record is serialised or returned
  • Delivery team controls the flag at item level for per-record granularity
  • Default visibility is configurable per project — set the safe default once
  • Internal Only covers rate card amounts, SLA formulas, internal notes, and billing conditions
  • Audit log records every flag change with actor, timestamp, and previous value

Visibility Controls

Client Visible vs Internal Only policy

Server Enforced

Task

TSK-0142: OAuth provider fix

Internal Only

Note

Rate negotiation context

Internal Only

Task

TSK-0138: API performance work

Client Visible

Comment

Fix deployed to staging

Client Visible

Attachment

contract-amendment-draft.pdf

Internal Only
Client users never access internal notes, rates, or SLA logic internals Visibility Matrix
Access configuration workflow

From user creation to fully governed access in four steps

A clear, repeatable flow ensures every user, client, and integration operates within precisely defined boundaries.

  1. 1
    Step 01

    Assign tenant role

    Set the platform-wide role for each internal user — Owner, Admin, Manager, or Member — establishing the ceiling for all their actions across the tenant.

    • Four-tier hierarchy
    • Owner approval for elevation
    • Settings access gated
  2. 2
    Step 02

    Set project role

    Assign a project-specific role for each team member on each project they participate in. Project roles layer on top of tenant roles for fine-grained delivery control.

    • Five project roles
    • Independent of tenant role
    • Observer to Owner spectrum
  3. 3
    Step 03

    Configure client portal access

    Provision client users through the dedicated client guard, set Client Visible flags on the items clients should see, and configure Client Admin permissions for the client organisation.

    • Separate auth guard
    • Per-item visibility flags
    • Client Admin self-service
  4. 4
    Step 04

    Review API token scopes

    Issue API tokens for integrations with explicit scope sets, review the audit log for token activity, and revoke any tokens no longer required.

    • Scope set enforcement
    • Audit trail
    • Instant revocation
Role-based value

Access governance built for every team

IT Security Teams

Firewall rules and a full audit trail give security teams pre-tenancy IP enforcement and complete visibility into every permission change.

Delivery Managers

Project role granularity lets delivery managers grant Reviewer and Observer access to stakeholders without exposing operational controls.

Client Account Managers

Client portal isolation means clients see live delivery status and invoices with zero risk of internal data exposure.

Finance & Compliance

Scoped API tokens and an immutable audit trail satisfy compliance requirements and give finance teams a trustworthy integration path.
Integration ecosystem

Connect access events to your security and communication stack

Push access events, security alerts, and audit notifications to the channels your security and delivery teams already use.

Slack

Receive access event alerts and firewall trigger notifications in Slack channels for your security team.

Security alerts

Email

Deliver security notifications, token creation alerts, and audit summaries directly to responsible inboxes.

Notifications

Microsoft Teams

Notify security and account teams when firewall rules trigger or API tokens are created or revoked.

Notifications

GitHub

Issue scoped API tokens for GitHub integration to link commits and pull requests to tasks and tickets.

API integration

GitLab

Connect GitLab via scoped API tokens to associate merge requests and commits with Effigate work items.

API integration
Frequently asked questions

Questions about permissions and access control in Effigate

Effigate operates a two-layer RBAC model. At the tenant level, four roles — Owner, Admin, Manager, and Member — govern platform-wide access including settings, billing, and user management. At the project level, five independent roles — Project Owner, Project Manager, Contributor, Reviewer, and Observer — control what each team member can do within a specific project. The two layers are evaluated together on every action, so a Member with no project role cannot act on a project even if they can see it.

Yes. The client portal uses a dedicated authentication guard entirely separate from the internal application. Client users authenticate against the client_employees table and cannot access any internal route, regardless of URL manipulation or session sharing. The client and internal sessions are completely isolated — there is no scenario in which a client user gains access to internal data through the portal.

API tokens are created per tenant in Settings → API and carry an explicit scope set: read-only, read-write, or resource-specific scopes. Every API call to /api/{tenant}/v1/ validates the Bearer token and evaluates its scope against the requested operation before any data is returned. Tokens are revocable at any time and every creation, use, and revocation event is recorded in the audit log.

Every project, task, ticket, note, discussion, comment, and attachment carries a visibility flag. The flag is evaluated server-side before any data is serialised — it is not simply hidden in the UI. An Internal Only record will never appear in a client session regardless of direct URL access, API calls, or any other technique. Delivery teams toggle the flag at item level for granular control, and the default visibility is configurable per project.

Firewall rules are IP-based allowlist and blocklist entries configured per tenant. They are evaluated before tenant initialisation — meaning a blocked IP address cannot reach any tenant route, API endpoint, or client portal page. Rules can be scoped to specific CIDRs and are applied in priority order. Firewall changes take effect immediately without requiring a deployment or restart.

Get started

Access control that governs every layer of your platform

14-day free trial. Full RBAC, client portal isolation, API token scopes, and firewall rules from day one.

Start free trial View pricing

Related features

Client Portal AI Integrations Automation Reporting & Analytics