How Connect works
Every piece of work in Connect follows the same path, whichever channel it arrived on: something happens, the workspace is resolved, a canonical record is written, the work is classified and grounded, the rules decide whether it may proceed, an action is taken through a provider, and the result is written back to the relationship and to the audit trail.
The path#
This sequence is worth learning once, because every workflow page in this manual is the same thirteen stages with different contents.
- Trigger — a mail arrives, a phone rings, a follow-up falls due, a person asks.
- User or external event — the raw thing that happened, from a provider or a browser.
- Authentication and workspace resolution — whose is this, and which workspace does it belong to?
- Ingest — the provider's own shape, stored as the adapter received it.
- Canonical record — the workspace's own thread, call, person or follow-up.
- Classification, research and reasoning — what is this, what does it need?
- Knowledge, memory and rules — what does the business already know and require?
- Autonomy and approval — may this happen now, or must a person say yes?
- Action through a provider — the send, the spoken reply, the API call.
- Result — the provider's evidence, or the failure and its class.
- Relationship, timeline and memory — what this changes about the person.
- Audit, usage and Needs You — what was recorded, what it cost, what a person must now decide.
Why the workspace is resolved before anything is read#
A workspace is the isolation root: nearly every record carries its identifier and is filtered by it automatically. Resolving the workspace first is not bookkeeping — it is what makes the rest of the pass correct. A handler that reads settings before entering the workspace reads the wrong settings, and this system has the scar to prove it: a switched-on phone line was once answered with the goodbye message because the voice settings were read outside the workspace scope, and the carrier logged a completed, charged call for a conversation that never happened.
Isolation is then enforced three more times: an allowlist decides which paths a customer session may call at all, the object layer filters every query by workspace, and the database refuses rows from another workspace through row-level security. Three independent layers, because any one of them can be got wrong by a single line of code.
Two mail models, one engine#
Mail exists twice on purpose. What a provider adapter fetches is stored in its own tables, in the provider's shape. The canonical thread, message and contact records — the ones the engine and every screen read — are written from them by a bridge. The engine never reads the provider's tables, which is why adding a provider does not change how anything downstream behaves.
Where a person sits in the path#
The autonomy stage is the only place a person is required, and it is configurable per channel and per scope. Everything before it happens regardless: mail is still read, calls are still answered, drafts are still written, research is still done. What changes is whether the outbound step runs immediately or waits in the queue.
That split is deliberate. A system that asks permission for everything gets switched off inside a week; a system that asks for nothing is unusable in a business that has to answer for what it said. The useful setting is the one where low-risk work proceeds and the reserved decisions wait.
What is recorded#
- The canonical record
- The thread, call, prospect or follow-up itself, with its own state.
- The relationship
- The person and company the work belongs to, and their timeline.
- Memory
- Anything durable learned, at the tier it belongs to.
- The audit trail
- What was decided, by what, under which rule, and what happened.
- Usage
- What the work consumed against the workspace's allowance and budget.
The audit entry is what makes the question "why did it say that?" answerable months later. It is written whether the action succeeded or was refused, because a refusal is a decision too.
Questions#
Does every channel really use the same path?
Yes, and the differences are contained in two stages: ingest, where each provider has its own adapter, and action, where each provider has its own send. Everything between them is shared.
What happens if a stage fails?
The work stops at that stage with a recorded reason, and — if a person can do anything about it — an item appears in Needs You. Nothing silently continues past a failure, and nothing is retried in a way that could send twice.
Where does the AI model actually appear?
At the classification and reasoning stage, and at the action stage on a live call. It never decides whether something is permitted — that is the autonomy stage, which is ordinary code and database rules.