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.
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.
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
Tenant Roles
Project Roles
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
Tenant Roles
Project Roles
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
Recent Invoices
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
{
"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
}
}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 is enforced server-side — not just hidden in the UI.
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
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
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
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
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
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.
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 alertsDeliver security notifications, token creation alerts, and audit summaries directly to responsible inboxes.
NotificationsMicrosoft Teams
Notify security and account teams when firewall rules trigger or API tokens are created or revoked.
NotificationsGitHub
Issue scoped API tokens for GitHub integration to link commits and pull requests to tasks and tickets.
API integrationGitLab
Connect GitLab via scoped API tokens to associate merge requests and commits with Effigate work items.
API integrationQuestions 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.
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.
Related features