Built for people whose downside is legal and reputational.
The value here is not that we say the right things. It is that you can see it and prove it. This page describes the real controls: enforced in the execution path, recorded immutably, and demonstrable on demand. We state facts, label trajectory as trajectory, and make no guarantees on your behalf.
Compliance in the path, not in a report
The gate runs before the contact is reached.
A compliance report tells you what happened after the fact. A gate decides what is allowed to happen. In Throughline CX, the pre-dial gate is the spine of the engine: every contact passes through it before it is reached, and anything that fails is skipped or rescheduled, never silently dialled.
Suppression and DNC
The contact is checked against suppression and do-not-contact lists before any attempt. A match is recorded as a skip with its reason, not a failure to be triaged later.
Local-time allowed window
The contact's own local time is evaluated against the permitted calling window. Outside the window, the attempt is rescheduled to the next valid time, not dropped, not forced.
Per-contact frequency caps
Each contact carries its own attempt history. When a cap is reached, further attempts are held back automatically, so pacing pressure can never override the limit you set.
Tenant-wide concurrency ceiling
A real, live ceiling bounds how many interactions your workspace can have in flight at once. It is enforced by the engine in real time, not approximated by pacing math.
What this gate does (and does not) do
The platform gives you the tools to operate within your own rules and leaves an auditable trail of every decision it made. It does not make you legally compliant, it does not interpret your obligations for you, and it claims no certification on your behalf. The judgement of what is lawful for your audience remains yours; what we provide is in-path enforcement of the limits you define, and the records to prove they held.
Isolation you can demonstrate
A property you can show, not merely assert.
Multi-tenancy is only as trustworthy as the boundary between tenants. Ours is enforced at the database, on a non-privileged role, so isolation is something you can demonstrate rather than something we ask you to take on faith.
- Row-level isolation
- Tenant boundaries are enforced by the database itself through row-level security, evaluated on every read and write, not applied as an application filter that a bug could bypass.
- Non-privileged role
- Application access runs on a role that cannot escape its own tenant scope. The isolation does not depend on the application behaving correctly; the floor holds underneath it.
- Per-tenant encrypted credentials
- Provider credentials (telephony, voice, email, CRM, webhooks, APIs) are stored encrypted and scoped to the tenant that owns them. One workspace's secrets are never visible to another.
- Scoped API keys
- Programmatic access is granted through keys bound to a workspace and its permitted operations, so an integration reaches exactly what it is meant to and nothing beyond it.
Provability: auditable by construction
Nothing happens silently.
When your downside is legal and reputational, "we believe it worked" is not an answer. The system is built so that what happened is recorded, unambiguous, and reconstructable after the fact.
Login and session auditing
Authentication and session activity are recorded, so access to the workspace is itself a matter of record: who entered, and when.
Immutable activity records
Activity and outcome records are written to be appended, not overwritten. The history of what the engine did is a ledger, not a mutable state you have to trust.
Immutable outcome records
Declared business outcomes are captured as durable, immutable facts, so what an automation achieved can be audited line by line against what it attempted.
Live, unambiguous state
Pause, resume, and stop are honoured by the engine and reflected in real time. The console shows the true state of work in flight, not an estimate.
Reason-coded decisions
Each skip or reschedule carries the reason the gate applied it, so a record is never just an absence; it explains itself.
Reconstructable timeline
Because records are immutable and decisions are reason-coded, a contact's full path through a flow can be traced after the fact, in order.
Reliability you can lean on
The system does not lose its place.
Correctness under failure is part of trust. A program that quietly forgets where it was, or a downstream system that misses an event, is a compliance problem in disguise. The core is built to fail safely.
01
Durable workflow execution
Flow execution is durable. Work interrupted by a restart resumes on another worker from where it left off. A program never silently loses its place, and a contact in mid-flow does not vanish because a process recycled.
02
Reliable eventing
Events reach downstream systems through a transactional outbox into an event bus and on to consumers (webhook, CRM, analytics). Deliveries are signed, idempotent, and a failed delivery lands in a replayable dead-letter path rather than disappearing. Your records of record stay correct.
- Transactional outbox
- An event is committed in the same transaction as the change that produced it, so a state change and its notification cannot diverge.
- Signed deliveries
- Outbound deliveries are signed, so a receiving system can verify that an event genuinely originated here.
- Idempotency
- Consumers can safely receive a delivery more than once without double-counting, so retries are safe by design.
- Replayable dead-letter path
- A delivery that cannot be completed is held and can be replayed, rather than lost — failures are recoverable, not silent.
How we talk about trust
Candour is the point, not a disclaimer.
The same discipline that governs the engine governs how we describe it. This is a stance, stated as a strength.
We invent no proof. We claim no certification we do not hold. We promise no compliance we cannot deliver. We describe the real controls plainly, and we label trajectory as trajectory, so the line between what ships today and where the platform is headed is never blurred.
- No fabricated customers, logos, testimonials, metrics, or ratings.
- No unearned certifications or attestations stated on our behalf.
- No compliance guarantees: the controls are real, the obligation stays yours.
- Forward-looking capabilities are marked On the path so direction is never mistaken for delivery.
Reserved
No third-party audits, attestations, or certifications are listed here yet. This space is held for them, and each will be added only once it is genuinely held.
Controls summary
The control surface, in one view.
Each row is a control that exists in the product today, with a precise description of what it does. No aspiration is listed here.
| Control | What it does | Status |
|---|---|---|
| Isolation | Database-enforced row-level isolation between tenants, on a non-privileged role. | Available today |
| Credentials | Per-tenant encrypted provider credentials, scoped to the owning workspace. | Available today |
| Access | Scoped API keys bound to a workspace and its permitted operations. | Available today |
| Pre-dial enforcement | In-path gate: suppression/DNC, local-time window, frequency caps, concurrency ceiling. | Available today |
| Audit trail | Login/session auditing and immutable activity and outcome records. | Available today |
| Durability | Durable workflow execution that resumes after a restart without losing its place. | Available today |
| Eventing | Transactional outbox to event bus and consumers; signed, idempotent, replayable dead-letter path. | Available today |
See the controls, then have them fact-checked.
Throughline CX is sales-assisted and operator-provisioned today, on your own providers. Request a demo and we will walk your compliance and security owners through the gate, the isolation boundary, and the audit trail, line by line.