I'm building a portal for clients and need permissions and audit trails

A good client portal usually needs two separate layers:

1. Permissions / access control — who can see or do what
2. Audit trails / activity logs — who actually did what, when, and from where

Here’s a practical way to design both.

1) Permissions model

Use role-based access control (RBAC) as the base, and add resource-level rules if needed.

Typical roles

• Owner / Admin: manage users, billing, settings, all records
• Manager: create/edit most records, view team data
• Member / User: view or edit assigned items only
• Read-only / Auditor: view only
• Support staff: limited access to assist clients

Permission categories

Define permissions by action + resource:

• client.view
• client.edit
• project.create
• project.update
• invoice.view
• invoice.pay
• user.invite
• audit.view

Scope levels

Permissions should also have a scope:

• Own: only the user’s records
• Team: records in the same organization/team
• Client account: all records within a client tenant
• Global: admin-only

Example:

• A standard client user can project.view:own
• A client admin can project.view:tenant
• Your internal support staff can client.view:assigned

Best practice

If the portal is multi-tenant, make sure every record has a tenant_id and every query enforces it.

---

2) Audit trail design

An audit trail should record:

• Who did it
• What changed
• When
• Where from (IP, user agent)
• Before/after values
• Why/trigger if available

What to log

Log sensitive and business-critical events like:

• Login/logout
• Password or MFA changes
• Permission changes
• Record create/update/delete
• Payment or billing actions
• File downloads
• Export actions
• Failed authorization attempts

Audit event structure

A solid audit record might look like:

{
  "event_type": "project.updated",
  "actor_user_id": "u_123",
  "tenant_id": "t_456",
  "resource_type": "project",
  "resource_id": "p_789",
  "timestamp": "2026-09-24T12:34:56Z",
  "ip_address": "203.0.113.10",
  "user_agent": "Mozilla/5.0 ...",
  "before": {
    "status": "draft"
  },
  "after": {
    "status": "active"
  }
}

Audit log rules

• Append-only: never edit/delete audit records
• Tamper-resistant: restrict writes, separate storage if possible
• Queryable: filter by user, date, resource, event type
• Retention policy: keep logs for a defined period
• PII-aware: avoid logging secrets or sensitive payloads

---

3) Recommended architecture

For permissions

• Store users, roles, permissions, and memberships in your DB
• Evaluate permissions in middleware/service layer, not just the UI
• Enforce checks server-side on every request

For audit logs

• Emit audit events from business logic whenever a sensitive action occurs
• Save to:
  • database table for small/medium scale, or
  • event stream / log system for larger scale
• Consider async logging so user actions aren’t slowed down

---

4) UI features clients will expect

In the portal, provide:

• User management
• Role assignment
• Permission matrix
• Activity feed / audit log
• Filters for date, actor, action, resource
• Export CSV/PDF for admins
• Alerting for critical events

---

5) Common pitfalls to avoid

• Relying on frontend hiding buttons instead of backend enforcement
• Using only a single “admin/user” flag
• Logging too much sensitive data
• Allowing audit logs to be edited by normal admins
• Forgetting tenant isolation in queries
• Not recording failed access attempts

---

6) Simple implementation approach

If you want a straightforward setup:

Permissions tables

• users
• roles
• permissions
• user_roles
• role_permissions
• tenant_memberships

Audit table

• audit_events
  • id
  • tenant_id
  • actor_user_id
  • event_type
  • resource_type
  • resource_id
  • before_json
  • after_json
  • ip_address
  • user_agent
  • created_at

---

If you want, I can help you with one of these next:

1. a database schema
2. a permissions matrix
3. a Node/Python/SQL implementation
4. a UI design for admin audit logs