Access And Roles

Sophosic has two major authentication contexts:

• Operators use the console to manage a workspace.
• Customers use the public site and portal to manage their own orders, bookings, billing, tickets, profile, and notifications.

Console Access

Console access depends on two signals:

User session

Identifies the signed-in operator

Selected workspace

Identifies which tenant the operator is managing

The selected workspace is not enough by itself. Every privileged request should be checked against workspace membership.

This distinction matters for agencies and support teams that manage several businesses from the same browser session. A valid signed-in operator can still be unauthorized for the active workspace, so console actions should fail closed when membership, role, or selected workspace state is unclear.

Workspace Selection

The console uses flat admin routes. A path such as /settings/general or /bookings applies to the currently selected workspace.

Before making launch-impacting changes, confirm the selected workspace. This is especially important for agencies, support teams, and users with access to multiple businesses.

Use visible proof before editing: workspace name, slug/domain, known customer record, and one recent order, booking, or setting. If any proof point does not match the business you intend to manage, stop and switch workspace before saving changes.

Operator Roles

Roles determine who can manage workspace settings, bookings, orders, customers, content, integrations, and payments.

The role hierarchy is inherited: Owner includes Admin, Admin includes Manager, Manager includes Agent, and Agent includes Customer-level self-service concepts. Customer portal access is still enforced separately from console membership.

General guidance:

• Owners manage the business and ownership-level settings.
• Admins manage settings, users, integrations, terminal setup, and broad workspace configuration.
• Managers run daily operations, analytics, queues, refunds, and catalog cleanup.
• Agents handle customer work, bookings, orders, communications, and basic sell flows.
• Customers should never receive console membership just to use the portal.
• Former team members should be removed promptly.

Permission Matrix

This summary groups active RBAC categories by the kind of work they protect. Implementation details still live in the RBAC package; use this as an operator-readable permission guide.

High-Risk Permissions

Some permissions can change money movement, access, customer data, or public launch state. Treat these as approval-sensitive:

For launch-impacting actions, pair permission with a human workflow: requested by, approved by, changed by, and verified by.

Customer Versus Operator Access

Do not blur customer portal access and console access:

If a customer needs help, use customer support or scoped management links. Do not promote the customer to an operator role as a shortcut.

Permission Source Of Truth

The shared permission source defines role hierarchy and wildcard grants. Database policies may also use a has_permission function, so RBAC changes need both sides to stay aligned.

Practical rules:

• Use the shared RBAC package when checking console permissions in TypeScript.
• Use database permission checks only for permissions known to the database function.
• Remember that Owner is treated as the highest privilege role.
• Remember that Admin is broadly privileged but does not receive ownership-level workspace billing in the database permission function.
• Customer portal access is enforced through customer ownership and row-level constraints, not by granting customer role checks through the console permission function.
• When a new permission category is added, update docs, UI labels, TypeScript grants, database permission behavior, and drift tests together.

Role Change Protocol

Before changing an operator role:

1. Confirm the selected workspace.
2. Confirm the user’s email and current role.
3. Confirm the target role and reason.
4. Check whether the new role grants high-risk permissions.
5. Record who requested and approved the change.
6. Ask the operator to refresh their session after the change.
7. Verify the user can access intended routes and cannot access unintended routes.

When removing access, revoke workspace membership rather than relying on a lower role if the person should no longer operate the tenant.

Customer Portal Access

Customers use portal sessions for:

• Account overview.
• Profile.
• Notification preferences.
• Orders.
• Billing.
• Tickets.
• Saved items.
• Booking history.
• Reschedule and manage flows.

Portal sessions should only expose records linked to the authenticated customer or a scoped capability link.

Public Capability Links

Some customer actions may use scoped links, such as a booking manage link or payment link. Treat these links as sensitive. They should:

• Scope access to one customer action.
• Avoid exposing unrelated customer records.
• Expire or become unusable when the underlying action is complete when possible.
• Avoid passing sensitive tokens to analytics or advertising tools.

Access Troubleshooting

Safe Operating Rule

When access looks wrong, do not work around it by changing public-site code. Confirm identity, workspace, role, and tenant scope first.

Escalate access issues with the user email, workspace slug, intended role, current route, and timestamp. That packet helps separate a real permissions defect from a stale session, wrong workspace selection, or expected least-privilege restriction.