Security and Access
Access you can read off a grid
A per-tenant role matrix with 11 permission categories, 41 permissions and one column per role. An audit log that records the user and the IP address, API keys hashed at rest and scoped to one tenant, and row-level tenant isolation in every service.
14-day free trial · no credit card required
Quick answer
What you get
Everything in one workspace
A role matrix per tenant
11 permission categories, 41 permissions and one column per role, edited per tenant. Access is a grid you can read, not a role name you have to trust.
Roles down to booking viewer
Platform admin, partner admin, admin, supervisor, team lead, agent and booking viewer. The narrow roles matter as much as the wide ones.
Audited impersonation
Platform admins can impersonate a user to reproduce a problem, and the impersonation is written to the audit. Support access that leaves a trace.
Audit log with IP
A per-tenant audit log recording the action, the user and the IP address it came from. The question at review time is who and from where, and both are recorded.
Hashed, tenant-scoped API keys
API keys are hashed at rest and scoped to their tenant. A leaked database does not hand over working keys, and a key cannot reach another tenant.
Per-tenant encryption of channel secrets
Channel secrets are encrypted per tenant, so one tenant's WhatsApp or carrier credentials are not protected by the same key as everyone else's.
PII redaction in transcripts
Personal data is redacted in transcripts, so a card number spoken on a call does not sit in plain text in a searchable record.
CSV injection safety on exports
Exports are made safe against CSV injection, so a hostile value in a lead field cannot become a formula that runs when someone opens the file.
Row-level tenant isolation
Tenant isolation is enforced at the row level in every service, not filtered in the interface. A missing filter in one screen cannot leak another tenant's rows.
Partner scoping
Partner admins see only the tenants they own. A reseller's view stops at their own book of business.
Login rate limiting
Login attempts are rate limited, which is the cheap control that stops credential stuffing from being worth anyone's time.
Password reset and recovery
Password reset and forgot-password flows are built in, so account recovery does not run through someone's inbox by hand.
The roles
Seven roles, including the narrow ones
Every one of these is a column you can edit in the permission matrix for your own tenant.
Platform admin
Runs the platform itself. Can impersonate a tenant user, and every impersonation is audited.
Partner admin
Runs a book of tenants. Sees only the tenants they own, never the rest of the platform.
Admin
Runs one tenant: campaigns, users, numbers, integrations and settings.
Supervisor
Runs the floor: monitoring, queues, reporting and the live view.
Team lead
A narrower supervisor, scoped to their own team.
Agent
Takes and makes calls from the agent desktop. Nothing more.
Booking viewer
Sees bookings and nothing else. For the person at the front desk who should never reach a campaign.
Single sign-on is on the roadmap; today access is per-user with role permissions and API keys. Multi-factor login is planned.
Audit log
Who did it, and from what address
The audit log is per tenant and records the action, the user behind it and the IP address it came from. That third part is the one people forget to ask for and then need.
Impersonation is in the same log. A platform admin can step into a user's session to reproduce a problem, which is how support actually gets done, and the fact that they did is written down rather than remembered.
- Per-tenant audit log with the user and the IP address on every entry
- Impersonation by platform admins is audited
- Remediation and administrative actions land in the same record
- Login rate limiting, plus password reset and forgot-password flows
Keys and secrets
Hashed at rest, scoped to one tenant
API keys are hashed at rest and scoped to the tenant that created them. Neither half is optional. Hashing means a copy of the database is not a set of working credentials; scoping means a key that does leak cannot walk into another tenant.
Channel secrets get per-tenant encryption, so one customer's carrier or messaging credentials do not share protection with the rest of the platform. Transcripts are PII-redacted, and exports are hardened against CSV injection.
- API keys hashed at rest and scoped to their tenant
- Per-tenant encryption of channel secrets
- PII redaction in transcripts
- CSV injection safety on exports
How it compares
| Roles as fixed labels | DialerBee security and access | |
|---|---|---|
| Defining access | Three or four fixed roles | A per-tenant matrix of 11 permission categories, 41 permissions and one column per role |
| Support access | Someone borrows a password | Impersonation by platform admins, written to the audit |
| The audit trail | An action list without context | Per-tenant audit log recording the user and the IP address |
| API keys | Stored so they can be shown again | Hashed at rest and scoped to the tenant |
| Tenant separation | A filter in the interface | Row-level tenant isolation in every service |
| Reseller visibility | Everything or nothing | Partner admins see only the tenants they own |
Frequently asked questions
What is Security and Access in DialerBee?+
It is the access-control side of the platform: a per-tenant role matrix of 11 permission categories, 41 permissions and one column per role, an audit log recording the user and IP address, API keys hashed at rest and scoped to their tenant, per-tenant encryption of channel secrets, PII redaction in transcripts and row-level tenant isolation in every service.
What roles exist?+
Platform admin, partner admin, admin, supervisor, team lead, agent and booking viewer. Booking viewer is deliberately narrow, for someone who should see bookings and never reach a campaign.
Do you support single sign-on?+
Single sign-on is on the roadmap; today access is per-user with role permissions and API keys. It is worth raising early if your security review requires it.
Is there two-factor authentication?+
Multi-factor login is planned. Today login is protected by rate limiting, with password reset and forgot-password flows for recovery.
Can support staff see my data?+
Platform admins can impersonate a user to reproduce a problem, and every impersonation is recorded in the audit log with the user and the IP address. Access happens through a recorded route rather than a shared password.
How are tenants kept apart?+
Tenant isolation is enforced at the row level inside every service, not by a filter in the interface. Partner admins additionally see only the tenants they own, so a reseller's view stops at their own book of business.
How are API keys stored?+
Hashed at rest and scoped to the tenant that owns them. A key cannot be read back out of the platform and cannot reach another tenant's data.
What protects data that ends up in a file or a transcript?+
Transcripts are PII-redacted, so personal data spoken on a call is not left in plain text. Exports are made safe against CSV injection, so a hostile value in a lead field cannot execute as a formula when the file is opened.
Walk the role matrix and the audit log on a demo tenant
A 30-minute walkthrough on a demo tenant, in English or Arabic.