Scoped access for customer operations

Give every person and integration exactly the access it needs.

SignalBX keeps ecommerce support work inside explicit tenant boundaries, then applies role-based permissions to members and purpose-built scopes to API keys before protected operations can proceed.

Start your workspace Explore access control

Six system roles

Start with Owner, Admin, Manager, Agent, Viewer, and Bot policies.

50 permissions

Separate reading, creating, sending, exporting, managing, and operating.

Custom roles

Owners can compose tenant-specific roles from the active permission catalog.

Member controls

Add members, assign roles, update profiles, and deactivate access.

Scoped API keys

Issue integration credentials with an explicit subset of caller permissions.

Live authorization

Reload current member and role permissions when a token is authenticated.

Tenant isolation

Reject protected tenant paths that do not match the authenticated principal.

Owner safeguards

Protect the last active owner and lock built-in role definitions.

One access workspace

See who can do what before customer work begins.

Members, role identity, account status, and effective permissions stay tied to the current tenant. Administrators can inspect the roster while owners retain control over custom policy design and owner assignment.

Tenant access workspace Illustrative data · current tenant only

Members2422 active

System roles6built in and locked

Custom roles3owner managed

Permission catalog50active controls

MemberRoleStatus

Aarav Mehta[email protected]

ManagerActive

Nina Kapoor[email protected]

AgentActive

Leo Martin[email protected]

Returns leadActive

Maya Shah[email protected]

ViewerInactive

Permission-level decisions

Separate everyday work from sensitive operations.

Protected routes name the permission they require. A principal must hold every requested permission, and tenant-addressed operations also verify that the requested tenant is the principal’s own.

Keep viewing, sending, exporting, creating, and managing as distinct grants
Apply the same permission check to browser, bearer-token, and API-key access
Use combined checks for operations that cross several protected resources

Messages

message:readmessage:sendmessage:ai_assist

Contacts

contact:readcontact:managecontact:export

Campaigns

broadcast:readbroadcast:createbroadcast:sendbroadcast:managebroadcast:export

Automations

automation:readautomation:createautomation:executeautomation:manage

Commerce

commerce:readcommerce:operatecommerce:manage

Access

member:readmember:invitemember:update_rolerole:readrole:createapi_key:manage

Authorization on the current truth

A signed token starts the check. It does not get the final word.

Member authentication reloads the active member and current role permissions before constructing the principal. A deactivated or unverified member is rejected, and role changes revoke active refresh sessions.

Verify credentialAccept a browser access cookie or bearer token

Signed

Reload memberConfirm the account remains active and verified

Current

Resolve roleLoad the role’s permissions from PostgreSQL

Effective

Enforce requestMatch tenant scope and every required permission

Allow / deny

Custom roles without hidden policy

Compose access from named, reviewable permissions.

Owners can create tenant-specific roles from the active catalog. Invalid permission IDs are rejected, built-in roles remain locked, and a custom role cannot be deleted while members still depend on it.

name description permissionIds tenantId isSystem

POST/api/v1/admin/tenants/tenant_northstar/roles

{
  "name": "Returns lead",
  "description": "Resolve returns without changing access policy.",
  "permissionIds": [
    "message:read",
    "message:send",
    "contact:read",
    "conversation:read",
    "conversation:manage",
    "commerce:read",
    "automation:read"
  ]
}

Useful defaults, deliberate customization

Start with roles shaped around real customer operations.

Every new tenant receives a stable set of system roles. Owners can add narrower custom roles when the operating model needs a boundary the defaults do not express.

Owner

Full tenant ownership, including custom-role controls and owner assignment.

All active permissions

Admin

Operational administration across integrations, channels, data, and workflows without owner-only role controls.

Operations administrator

Manager

Day-to-day messaging, customer, analytics, campaign, segment, and automation work.

Customer operations

Agent

Frontline conversation work, customer context, editable AI assistance, and read access to operating tools.

Frontline support

Viewer

Read-only observation across tenant metadata, conversations, analytics, and operational context.

Read-only observer

Bot

A deliberately narrow integration role for outbound messaging and webhook visibility.

message:send · webhook:read

Machine access with a smaller blast radius

Give each integration its own credential and purpose.

API keys are tenant-bound principals with explicit permissions. Their plaintext secret appears on creation or rotation, while SignalBX stores only a SHA-256 hash and a safe prefix for later identification.

Tenant API keysHashed secrets · explicit scopes

NamePrefixPermissionsLast usedStatus

Order notifierCreated by ownerprism_sk_V7m2…message:sendwebhook:read4 min agoActive

Analytics exportExpires 30 Sepprism_sk_A4q8…analytics:readanalytics:exportYesterdayActive

Legacy syncRotated integrationprism_sk_H1d9…contact:read12 JulRevoked

Access questions, answered in policy

Make authorization decisions predictable before they become incidents.

Frontline work

“Can agents reply without exporting customer data?”

Grant message and conversation operations while leaving the separate contact-export permission out of the role.

Independent operational grants

Leadership

“Can someone monitor performance without changing anything?”

The Viewer role combines read-only tenant, channel, message, analytics, customer, and operations permissions.

Read-only observation

Specialists

“Can returns staff see orders without managing commerce connections?”

Create a role with commerce read access and conversation permissions, excluding commerce operation and management controls.

Custom least-privilege role

Integrations

“Can an API key send without reading the inbox?”

Issue a key with message:send and only the other permissions its exact workflow requires.

Purpose-built key scopes

Offboarding

“What happens when a member is deactivated?”

Authentication rejects inactive members, and active refresh sessions are revoked as part of deactivation.

Account and session cutoff

Ownership

“Can the final owner remove their own safety net?”

No. Role reassignment and deactivation protect the tenant from losing its last active owner.

Last-owner protection

Access control with operational guardrails

Tenant-bound, current, revocable, and difficult to over-grant.

Customer operations touch messages, profiles, exports, integrations, and outbound actions. SignalBX keeps identity and permission checks explicit across those boundaries.

Tenant matching: Tenant-addressed routes reject a requested tenant that differs from the authenticated principal.
Current permissions: Member authentication reloads the member and their role permissions instead of trusting stale role claims alone.
Member cutoff: Inactive or unverified members cannot authenticate, and deactivation revokes their active refresh sessions.
Role-change cutoff: Member role changes and custom-role policy changes revoke affected refresh sessions.
Owner-only policy: Custom role creation, updates, and deletion require the Owner role in addition to route permissions.
Locked defaults: System roles cannot be edited or deleted, preserving a known tenant policy baseline.
Hashed API keys: API key verification compares a stored secret hash, with expiry and revocation checked before access.
Browser safeguards: Browser sessions use host-only cookies and CSRF checks on unsafe cookie-authenticated requests.

Scoped access questions

What teams need to know about roles, members, and API keys.

What built-in roles does SignalBX provide?

Every tenant receives Owner, Admin, Manager, Agent, Viewer, and Bot system roles. Their policies are seeded from the application permission catalog and kept in sync, while the role records themselves cannot be edited or deleted.

Can we create roles for our own operating model?

Yes. Owners can create custom tenant roles with a name, description, and selected active permission IDs. Owners can later update the policy or delete an unassigned custom role.

Are permissions limited to the inbox?

No. The catalog covers tenant settings, API keys, channels, messages, analytics, profiles, members, roles, contacts, conversations, AI intelligence and assistance, CRM, commerce, webhooks, campaigns, segments, automations, and development mock controls.

Can a custom role modify another role?

Custom-role creation, updates, and deletion require the authenticated principal to be an Owner. A role permission alone does not bypass that owner check.

Can an API key receive more access than its creator?

No. API key creation and permission updates reject any requested permission the caller does not currently hold. Each key must also have a non-empty permission list.

How are API key secrets stored?

The plaintext secret is returned when a key is created or rotated. SignalBX stores its SHA-256 hash for verification and exposes only metadata such as prefix, permissions, expiry, last use, creator, and revocation state.

What happens after a member’s role changes?

The member’s active refresh sessions are revoked. On authenticated requests, SignalBX also reloads the member’s current role and permissions before authorizing the operation.

How does SignalBX prevent a tenant from losing all owners?

Before deactivating an active owner or assigning that member a different role, SignalBX counts the tenant’s active owners and rejects the change when only one remains.

Access that follows responsibility

Let the team move quickly inside boundaries everyone can explain.

Bring tenant isolation, role-based permissions, member safeguards, and purpose-built integration credentials into the same ecommerce customer operations platform.

Start your workspace Contact us