End-to-end workflows
Every workflow page here follows one chain of twelve stages, from the trigger to the audit entry, and documents the same four things at each: what you see, what Connect does, what data changes, and what can fail. Read the chain first, then jump to the stage that matches your question. The index further down groups every flow by the channel or surface it belongs to.
One chain, filled in differently each time#
A workflow page is not a tour of a screen. It is one path through the application traced end to end, and it is traced against the same chain every time so that two flows can be compared without re-learning the vocabulary.
- Trigger — what starts the flow: a message, a due follow-up, a person clicking, a crawler asking.
- User or external event — what happened outside Connect, and what evidence of it arrives.
- Authentication and workspace resolution — who is asking, and which workspace the work belongs to. This happens before any setting is read.
- Ingest or request — the provider's own shape, normalised by the one adapter that speaks that dialect.
- Canonical record — the row the rest of the application reads: a thread, a message, a call, a follow-up, a prospect.
- Classification, research or reasoning — what the work is, what it needs, and what the model is asked.
- Knowledge, memory and rules — what the workspace has told Connect, resolved narrowest-first and rendered under fixed budgets.
- Autonomy and approval — whether Connect may act alone, must ask, or must refuse.
- Action through a provider — the outbound step: a mail provider, a carrier, a messaging provider, an HTTP response.
- Result — what actually happened, with the provider's own acknowledgement where one exists.
- Relationship, timeline and memory — where the outcome lands on the person and the business.
- Audit, usage and Needs You — the decision record, the metered cost, and anything a person now has to look at.
What each stage is answerable for#
Not every stage matters to every flow. A page documents the stages that carry weight for that flow and says plainly when one is a formality. What a page may not do is skip a stage that failed.
| Column | What it answers | Why it is there |
|---|---|---|
| What you see | The visible change on a screen, or the absence of one | Several stages change nothing visible, and saying so stops a reader hunting for a screen that does not exist |
| What Connect does | The decision or the call made at that stage | Separates a decision from its effect, which matters when the effect is refused |
| What changes | The rows written, updated or deliberately not advanced | A cursor that does not move on a refusal is a design decision, not a fault |
| What can fail | The failure modes, and which of them are retried | A page that only describes success is half a page |
Retry and idempotency belong to the stage they govern. A request a flow cannot afford to lose is retried through a restart or a proxy error; a 4xx is an answer and is never retried. Where a flow has an idempotency key, the page names it and says what a duplicate does.
How to read one of these pages quickly#
Find the stage your question is about in the chain at the top of the page.
Result The chain is in flow order, so a question about why nothing was sent lands at autonomy and approval, not at ingest.
Read that stage's row in the stage table.
Result The failure column tells you whether what you saw is a known failure mode of that stage.
If it is, follow the link from that row to the capability or troubleshooting page that owns the fix.
Result Workflow pages describe the path; they deliberately do not duplicate the settings pages.
The reverse direction works too. If you already know which screen the problem is on, start at Troubleshooting and come back here when you need to know what happened before the screen.
The flows documented in this manual#
- Phone
- An inbound call, an outbound call, a browser call, escalation, recovery and the tuning cycle.
- Inbound mail, reply approval, mailbox repair and a quota refusal.
- Revenue
- Prospect discovery, research, outreach and reply handling.
- Machines
- An MCP tool call, public documentation search, agent discovery, a public API call and webhook delivery.
- Conduct
- First response, a request Connect cannot fulfil, a complaint, an interruption and a data request.
- Routine
- Reviewing calls, reviewing mailbox health and proving a change broke nothing.
Where a workflow page stops#
A workflow page describes what Connect does, not what your business should do about it. It will tell you that a complaint is detected, queued and attributed; it will not tell you who in your team should own it, because that is a decision the workspace makes and records as a standing instruction.
Nor does a workflow page carry settings. Autonomy modes, allowances and mailbox roles have their own pages, and duplicating them here would give a reader two places to be told two different things.
Everything in this section#
159 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| A channel provider going down | What happens when a channel's provider stops answering: how the failure is detected, what stops attempting, what carries on regardless, and how recovery works. |
| A commercial decision reaching a person | What happens when a customer asks a price, a warranty or a deadline that Knowledge does not support: the refusal, the escalation, the human decision and the reply. |
| A developer calling the public API | A developer calling Connect over HTTP: how a key is issued and scoped, what one request looks like, how errors are shaped, and what a rate limit means. |
| A do-not-contact reaching every channel | One do-not-contact directive that reaches email, WhatsApp, SMS, phone and prospect outreach: where it is stored, why it holds, and what the audit trail shows. |
| A fact learned on a call, end to end | Following one spoken fact from the moment it is said, through the checks that decide whether to believe it, to the email where it is used a week later. |
| A lapsed plan and its recovery, end to end | The whole arc of a lapse: what stopped, what queued rather than failed, and the order in which work resumes once the workspace is live again. |
| A plan lapsing, end to end | What a lapsed plan actually stops: which work is refused, which is held, why the mail cursor stays where it is, and what returns on settlement. |
| A promised call-back, end to end | A call-back promised out loud becomes a dated commitment and then a ring: how the time is read, when it is refused, and when it is too late to place. |
| A provider quota breaker opening and closing | What a provider breaker does when a model account starts refusing: which work is skipped, which is still attempted anyway, and how the breaker closes. |
| A search crawler fetching a page | What a search crawler receives from this site, what it does not, how policy differs for search, user fetches and training, and how a bot proves who it claims to be. |
| A support case, end to end | A customer problem from the message that raises it to the resolution and the memory it leaves: every stage, what changes, and what can fail at each. |
| A website enquiry, end to end | A public-site enquiry from the submitted form to an answered person, and the stage where having no workspace decides everything that follows. |
| A WhatsApp follow-up, end to end | A scheduled WhatsApp follow-up from due to sent: the composition, the autonomy and consent checks, the window, and the template fallback when Meta refuses. |
| A WhatsApp opt-out, end to end | A WhatsApp opt-out followed end to end: the STOP word, the three records it writes, what changes for every pending message, and the START that reverses it. |
| Adding a colleague, end to end | How a second person gets into a workspace: membership, their own Google sign-in, the role that gates configuration, and what is recorded per person. |
| Adding a Knowledge source, end to end | From choosing a file to a passage that answers a question: every stage of adding a Knowledge source, with the status the record carries at each. |
| Advancing an IMAP cursor safely | The rule that decides when an IMAP read position may move: what must be recorded first, what refusal holds it, and how advancing early loses mail for good. |
| An agent discovering Connect | How another agent finds Connect: fetching the Agent Card from its well-known URL, reading the published skills, and sending a message to one of them. |
| An AI client calling a Connect MCP tool | How an AI client discovers a Connect workspace tool, authenticates with an integration key, and has the call scoped, gated and recorded like any other action. |
| An AI client searching the public documentation | The unauthenticated MCP path: which documentation tools any AI client may call without a key, what they return, and the limits that make them safe to publish. |
| An AI search engine citing a page | The chain from crawl to citation to referral: what has to be true at each step, which steps can actually be measured from this side, and which cannot. |
| An email follow-up, end to end | A dated commitment becoming a sent email: where the follow-up came from, which gates it passes, and why a retry cannot send it twice. |
| An inbound SMS, end to end | An inbound text message followed from the provider webhook to the person it belongs to and the decision about answering it, with what can fail at each stage. |
| An inbound WhatsApp message, end to end | One inbound WhatsApp message followed the whole way: Meta's signed webhook, the stored record, the draft, the autonomy decision and the timeline entry. |
| An outreach sequence, end to end | Cold outreach from first contact to the reply that stops it, with every compliance gate named and the point where a stranger becomes a conversation. |
| An SMS STOP, end to end | A stop request followed from the word in the message to the suppression, the audit entry and the confirmation, including what is deliberately skipped. |
| An unsubscribe request, end to end | What happens between somebody asking to be left alone and the record that proves it: the suppression, its scope, and the one entry nobody clears casually. |
| Answering a commercial question, end to end | A customer asks what it costs: the grounded answer, the refusal, the escalation, the human decision, and how the same question stops recurring. |
| Answering a customer's data request | What Connect can produce when somebody asks for their data: which records, in what format, from where — and the limits, including what sits outside a workspace by design. |
| Applying a suppression, end to end | What happens when an address or a person is suppressed: where the entry is recorded, which gate reads it, what refuses afterwards, and who is allowed to clear it. |
| Approving a follow-up, end to end | How a follow-up Connect may not execute on its own reaches a person, what the approver is allowed to change, and what runs after the yes. |
| Approving a held action, end to end | A held action from the moment it reaches the queue to the provider's acknowledgement: who may decide, what an edit changes, and what the log keeps. |
| Asking the Assistant a question, end to end | A question typed into the Assistant, followed all the way to a grounded answer: what runs at each stage, what it costs, and where an answer loses its citations. |
| Asking the Assistant to do something, end to end | From an instruction to an audited change: how a writing tool becomes a proposal, what the confirmation buys you, and where autonomy re-enters the path. |
| Assembling a Customer 360, end to end | Every store a Customer 360 reads to build one person's whole history, and why the cost of assembling it is counted in database statements. |
| Assigning a mailbox role, end to end | Giving a mailbox a role, from the click to the first message it re-routes: what is stored, what routing changes, and which conversations are deliberately untouched. |
| Assigning priority to a thread, end to end | How a conversation gets its priority, what happens when a person overrides it, and why that correction changes what Connect works on rather than how a list is sorted. |
| Auditing what an answer was based on | Taking one sentence in a sent reply and following it back to the passage, the authority and the person who allowed it to be said. |
| Binding a Google identity to a person, end to end | How a Google account becomes a person in Connect: binding on the first non-empty subject, adopting a row that predates them, and refusing a later mismatch. |
| Blocking a contact, end to end | One tag on one memory row, and what it stops across email, WhatsApp, SMS and voice — including the browser line a colleague dials from. |
| Building the timeline, end to end | How a person's timeline is put together from the records that own each event, why it is ordered by when things happened, and what it leaves out on purpose. |
| Capturing evidence for a prospect, end to end | How one fact about a business travels from a public source to a stored piece of evidence to the claim it supports — and what stops it on the way. |
| Catching up after a Gmail history gap | When Gmail can no longer serve the history a mailbox was reading from: what a gap is, what Connect re-fetches instead, and why order and duplicates are handled first. |
| Changing a document, end to end | Changing a stored document from end to end: which version is read, what the proposal shows, what the new version records, and what the old one keeps. |
| Changing a provider, end to end | Swapping the carrier, the mail provider or the messaging provider underneath Connect: which layer changes, what has to be re-proved, and what may never be assumed. |
| Changing plan, end to end | What a plan change alters the moment it lands, what it deliberately leaves alone, and why a lowered ceiling never removes anything you already have. |
| Changing the model, end to end | Moving Connect to a different model: what to check first, what changes on the wire during the switch, and which numbers prove afterwards that it was worth doing. |
| Changing what Connect may do, end to end | Changing an autonomy rule end to end: what takes effect at once, what the change cannot reach backwards, and where the change itself is recorded. |
| Changing what the agent is told | Changing the words Connect is given: the six layers a prompt lives in, what extra characters cost on a live call, how to measure it and how to undo it. |
| Checking the Assistant's screen context | The Assistant is told which screen and record you are on. That claim is checked against the database before it is trusted, and dropped when it does not hold. |
| Classifying a prospect's reply, end to end | What Connect does with an answer to cold outreach: the classes it sorts replies into, what each one stops or starts, and which ones a person must confirm. |
| Closing a deal, end to end | What changes when an opportunity is marked won or lost: the stage rules, the stored value, the follow-ups that stop, and what picks the person up next. |
| Communicating during an interruption | What Connect says to customers during an interruption, what it keeps internal, who is told first, and why a cause and a restoration time are held back. |
| Configuring a channel, end to end | The shape every channel setup shares in Connect — identity, credentials, routing, rules, verification — and the specific places email, WhatsApp, phone and SMS differ. |
| Connecting a phone line, end to end | Connecting a number to Connect: the line record, the carrier link, and the four verifications that separate a configured line from an answering one. |
| Connecting an IMAP mailbox, end to end | Connecting a plain IMAP and SMTP mailbox: what you supply, the two separate proofs that must pass, and what a half-working connection looks like. |
| Connecting Gmail, end to end | Connecting a Google mailbox from the consent screen to the first synced thread, with the evidence that proves each step actually happened. |
| Connecting WhatsApp, end to end | Connecting WhatsApp from a Meta credential set to a first verified inbound message, the QR alternative, and the checkpoint that proves each half of the chain. |
| Continuing on a different channel | Continuing a conversation on a different channel: what history carries over, what has to be re-established, and the identity check that decides both. |
| Continuing one conversation on another channel | What happens when someone who emailed last week rings instead: how the same person is recognised, and exactly which context follows them. |
| Correcting Connect from a conversation, end to end | From a wrong answer to changed behaviour: how a correction typed in conversation becomes a memory at a tier, and what proves it actually took effect. |
| Correcting what Connect knows, end to end | From a reply that was wrong to a corrected memory to changed behaviour: every stage, what changes at each, and the three places a correction fails to stick. |
| Creating a conversation thread, end to end | From one arriving message to a conversation with a person and a company attached: what is matched, what is created, and what is decided once and kept. |
| Creating a customer workspace, end to end | From a first Google sign-in to a workspace that can actually receive mail: what is created, what is not, and the three things still missing afterwards. |
| Creating a document, end to end | From asking for a document to a produced file sitting on the right record: what is resolved, what is proposed, what is written, and what is deliberately left blank. |
| Creating a follow-up, end to end | From a promise made out loud to a scheduled row: the guard on the time, the channel decision, the duplicate test, and what each stage records. |
| Creating an opportunity, end to end | From a sentence in a conversation to a deal on the board with its first commitment: every stage, what changes, and what can fail on the way. |
| Deciding whether two records are one person | From the signals that suggest two records are one person to the human decision and the merge itself, with what survives on both sides. |
| Delivering an outbound webhook | The outbound webhook interface Connect publishes: the signed envelope, at-least-once delivery, the retry and pause rules — and why nothing is being delivered yet. |
| Discovering prospects, end to end | One discovery run followed from the brief to a qualified list: every stage, every gate that can stop it, and what exists afterwards. |
| Drafting and approving a reply, end to end | From an arriving message to a sent reply, with the autonomy gate in the middle: what is drafted, what is held, who releases it, what proves it went. |
| Editing a record in the grid, end to end | One cell, changed: what the grid sends, which service decides, what comes back into the row, and the audit entry that survives the browser tab. |
| Editing many records at once, end to end | Selecting many rows in the Data grid and changing them together: how a selection becomes one service call per record, and what a partial result means. |
| Enforcing an allowance, end to end | The moment a daily allowance runs out: how the approach is checked, what the refusal says, what is held rather than lost, and how the work resumes. |
| Entitlement and runtime choice, end to end | Two separate gates decide whether Connect acts: what the plan permits, and what a person has switched on. Both must agree, and they fail differently. |
| Escalating a call to a person | When a caller asks for a person: what is queued, what the caller hears, what a colleague can do on the live call, and what a completed transfer still depends on. |
| Escalating a complaint, end to end | How a complaint is recognised on any channel, who it reaches, what Connect commits to on the business's behalf, and what it deliberately refuses to promise. |
| Escalating to a person, end to end | What happens when Connect decides it should not answer: how the refusal becomes a person's decision, and how that decision gets into future work. |
| Establishing a session, end to end | What a session actually is in Connect: what the server keeps, what the browser holds, what it resolves to, and what can be ended from which side. |
| Executing a follow-up, end to end | From due to placed, held or refused: the drain's rate, every gate in order, the outcome written back, and the lateness rule that ends it. |
| Executing one Assistant tool call, end to end | One Assistant tool call from argument to audit entry: what validates the arguments, which service does the work, the gates it passes, and what is recorded. |
| Finding a contact address, end to end | How Connect finds an address to write to, what it records about where the address came from, and why it will not construct one from a naming pattern. |
| First outreach to a prospect, end to end | The first message to a prospect, followed from readiness through the compliance check, the draft, approval and the send that only counts with provider evidence. |
| First response to a new contact | How Connect decides whether to answer a new contact immediately, draft and wait, or refuse — and what the person on the other end experiences while that is decided. |
| From a call to a customer relationship | What survives a phone call: the person, the company, the timeline entry and the next action, and the rules that stop each of them being invented. |
| From an email to an opportunity | The reply that turns into a deal: which records change, in what order, and what keeps the pipeline honest about where the evidence came from. |
| From client to support, end to end | What carries over when a deal is won: onboarding, the first support case, and the continuity that depends on one person record rather than two. |
| From first contact to a person record | A stranger writes or rings on any channel and becomes a canonical person: every stage, what changes, what can fail, and what happens on the second channel. |
| From prospect to client, end to end | One relationship followed from a discovered name to a paying client, naming every record that is created, changed or left behind on the way. |
| Google sign-in, end to end | From the Google consent screen to a working session: what Google proves, what Connect binds it to, and the mismatch it refuses rather than resolves. |
| Granting a permission, end to end | Granting or removing a permission in a workspace: who may do it, when the change takes effect, what it does not widen, and the record it leaves. |
| Handing a won deal to onboarding | What happens when an opportunity is won: which records carry over untouched, what is newly created, and the two mistakes that split a customer in half. |
| Handling a bounce, end to end | A bounced message from the notification to the record: how permanent and temporary failures are told apart, what changes on the address, and what is never retried. |
| Handling a demo request, end to end | From a customer asking to see the product to a dated commitment somebody will actually keep: the record, the confirmation, the reminder and the outcome. |
| Handling a prospect's reply, end to end | What happens between a prospect's reply landing and the record it changes: classification, the stop rules, and when a relationship is created. |
| Handling a request Connect cannot fulfil | What happens when somebody asks for something Connect must not answer: how it is recognised, how it is refused, who it reaches, and what the customer is told. |
| Handling a spam complaint, end to end | A spam complaint from the moment it arrives: how the recipient is identified, what is suppressed, and what it should change about the way a workspace sends. |
| Handling more volume, end to end | What binds first when volume rises — worker capacity, plan allowance, model quota, query cost — and the order in which to change them without guessing. |
| Hitting the daily allowance, end to end | What Connect does when the day's allowance is spent: what is held, what is refused, why the read cursor stays where it is, and how work resumes. |
| Importing a prospect list, end to end | An import followed from the file to usable prospects: what each stage does to a row, what is merged, what is refused, and what the summary is for. |
| Importing records, end to end | Bringing records in from a spreadsheet: how a file becomes validated rows, how duplicates are matched, and what happens to rows that do not qualify. |
| Inbound email, end to end | Every stage between a message landing at the provider and Connect acting on it: fetch, bridge, thread, triage, and where mail can be lost. |
| Inbound phone call, end to end | A call arriving on a Connect number, stage by stage: what the caller hears, what is written, which provider acts, and what fails where. |
| Ingesting a burst of mail, end to end | Hundreds of messages arriving at once: how they are taken in, the order they are processed, what the allowance holds back, and why no wave of replies follows. |
| Ingesting a Knowledge source, end to end | What happens between adding a document and an answer being grounded in it: reading the file, refusing dangerous ones, extraction, and when it becomes usable. |
| Keeping a good prospect you cannot email | An organisation fits your criteria and publishes no address. What stays on the record, what Connect proposes instead, and the four ways it can become reachable later. |
| Making a call from the browser | A person dialling from the browser: the SIP registration, the invite that does not dial the number in it, the bridge, and what is recorded as human-owned. |
| Merging duplicate people, end to end | From a duplicate proposal to one merged record: every stage, the human decision in the middle, and how to verify the result afterwards. |
| Metering usage, end to end | How Connect counts what a workspace uses: which dimensions exist, when each is reserved or merely tracked, and what the daily ledger is actually for. |
| Moving a deal from stage to stage, end to end | Every stage change on an opportunity: what is checked before it, what is written after it, and the side effects a move sets off downstream. |
| Moving a relationship through its lifecycle | Every lifecycle stage change: what triggers one, how the requested word is normalised, what the move records, and the things it deliberately leaves alone. |
| Onboarding, end to end | Onboarding from the won deal to steady state: the stages, who does what between them, and the failures that leave a new customer waiting. |
| Outbound phone call, end to end | Placing a call: the reason it exists, the gates it passes, the dial itself, and what is written whether or not anybody answers. |
| Preparing for DLT, end to end | Preparing for DLT in India: what a business gathers, in what order the three registrations must be obtained, and what Connect stores once they are granted. |
| Producing a grounded answer, end to end | A customer question turned into a defensible reply: scopes, retrieval, the sufficiency gate, drafting under labelled context, and the citations kept. |
| Producing a new version of a file | Changing a file produces a new version rather than overwriting one: what each version carries, how it links back to a record, and what the chain proves later. |
| Proving a change did not break anything | Proving a change did not break anything: the verification ladder, which rung proves what, and the two audiences every screen change has to be checked as. |
| Proving a workspace is isolated, end to end | A layer-by-layer check that one workspace cannot reach another's records, what each of the three layers catches, and what each of them cannot see. |
| Publishing a documentation change | How a documentation change reaches the public site: one source, the gate, generated HTML and Markdown, the manifests, the sitemaps, and IndexNow last of all. |
| Qualifying a prospect, end to end | How evidence gathered about an organisation becomes a score, how the score becomes a decision, and what happens when a person disagrees with it. |
| Recovering a failed call | Every way a call can fail on this path and the recovery for each, in the order the failures are detected — from admission control to a late provider webhook. |
| Regenerating a draft, end to end | Asking Connect to write a reply again: what is thrown away, what survives untouched, what the second attempt is given that the first was not, and when to stop. |
| Removing a workspace, end to end | What removing a workspace actually does: how access ends, which records stay outside it by design, and which parts of it can never be undone. |
| Repairing a broken mailbox, end to end | Detecting that a mailbox has stopped working, finding which half broke, reconnecting without creating a second row, and proving the repair held. |
| Repairing a workspace with no primary mailbox | A workspace whose primary mailbox is missing: how the gap shows itself, the two repairs, and why one of them cannot run from a browser request at all. |
| Researching one prospect, end to end | One candidate followed through research: what is read, how a claim earns its place on the record, and what happens when nothing can be proved. |
| Resolving conflicting Knowledge, end to end | From a contradiction being detected to a source that answers again: what is compared, what is refused, and the decision only a person can take. |
| Resolving which workspace a request belongs to | How a request is tied to exactly one workspace before any handler runs, and the three independent places that resolution is enforced afterwards. |
| Responding to a suspected access problem, end to end | What to do when access to a workspace looks wrong: contain first, establish scope from evidence, then rotate — in that order, with what each step proves. |
| Retrieving Knowledge for one reply | How much of your Knowledge actually reaches one answer: how the question is formed, what the budget allows, how material is chosen, and how to see the choice. |
| Reviewing account security, end to end | A working review of one workspace's access: the sessions, the provider grants, the stored credentials and the audit trail, with the question to ask of each. |
| Reviewing an incident, end to end | After something goes wrong: which records to open and in what order, the questions that decide whether it is fixed, and what belongs in the write-up. |
| Reviewing calls as a routine | A weekly pass over the call record: which fields to read first, what each pattern points at, and which findings a setting can fix rather than the model deciding. |
| Reviewing everything Connect knows about a person | The audit anyone can run on one person's record: the four tiers, the tags, the identities behind them, and the decisions that follow from what you find. |
| Reviewing mailbox health as a routine | A routine check of every mailbox: why connected is not health, the states worth watching, the pattern that hides a mailbox entirely, and the action for each. |
| Rotating a provider credential, end to end | Replacing a provider credential in a workspace: what happens on save, how to verify a value you can never read back, and what becomes of work in flight. |
| Routing a request for the Owner or a customer | One implementation, two doors: how a request is rewritten for a customer, checked against an allowlist, and refused in the two ways that both fail closed. |
| Running deep research, end to end | When a second, deeper research pass is run on one prospect, what decides that it is worth paying for, what it produces, and where the output is attached. |
| Sending with provider evidence, end to end | Every state a message passes through between the decision to send and the provider's acknowledgement, including the third state that is neither sent nor failed. |
| Setting up a workspace, end to end | Taking a workspace from empty to working: the business profile, the channels, what Connect is allowed to say, and what it may do unsupervised. |
| Signing in for the first time, end to end | From the Google consent screen to the first working screen: what a session is, how one workspace is resolved, and what a first sign-in does not do. |
| Signing out and replacing a session | The two ways a session ends on one browser — signing out, and signing in as somebody else — and why neither of them touches your other devices. |
| Stopping Connect, end to end | The runtime switch end to end: what stops the moment you use it, what was already handed to a provider, and what is waiting when you switch back on. |
| Submitting changed URLs to IndexNow | Submitting changed URLs to IndexNow: how the changed set is derived, the three rules the tool enforces, the response codes, and why submission runs last. |
| Superseding a memory, end to end | Replacing something Connect believes without losing the record of what it used to believe: the new version, the kept history, and how each option reads later. |
| The AI budget guard, end to end | The AI budget guard on the voice path: when it is asked, what it refuses, what a caller hears instead of silence, and how a call gets through again. |
| The readiness check before outreach | Every gate an outreach message passes before it leaves, in the order they are evaluated, and what a refusal at each one looks like from the screen. |
| Tuning the voice, end to end | Changing how the voice sounds and behaves, then proving the change: the two kinds of control, the test call, the review, and the findings no setting can fix. |
| Turning Connect on or off at runtime | What the runtime switch actually stops, what finishes anyway, what happens to work that was scheduled, and what the people on the other end experience. |
| Turning on the realtime engine, end to end | Switching a workspace to the speech-to-speech engine: the trunk, the dispatch rule, the worker and the console steps that have no API at all. |
| Undoing an action, end to end | Undoing an Assistant action: the three outcomes — reversed, compensated, or recorded only — and how to tell which one your action will get. |
| Uploading a file and answering from it, end to end | The whole path from dropping a file into Connect to reading an answer grounded in it: validation, safe parsing, extraction, grounding and the citation. |
| Verifying a channel actually works | The one test that proves each channel is really working, what each test does not prove, and why a saved setting and a green screen are not evidence. |
| Verifying a customer payment, end to end | How a customer payment is verified and a plan activated: deterministic evidence, a fail-closed match, and why this flow sits outside every workspace. |
| Verifying published documentation | Every check run before and after a documentation change ships: the gate, the link graph, structured data, the built tree, and the fetch-as-a-crawler probe. |
| What Connect changes in your Gmail after a reply | The step that reaches back into Gmail after a reply: what it writes, why it runs last, why its failure is allowed to pass, and which state flows which way. |
| Working on a file with the Assistant, end to end | Attaching a file to the Assistant and working on it: validation, extraction, the answer, the new version, and where the file ends up linked. |
| Working the Needs You queue, end to end | One full pass through Needs You: how the list is ordered, what each kind of item wants from you, and what an empty queue does and does not prove. |
| Writing a memory, end to end | How something worth remembering becomes a stored memory: the trigger, the tier it lands on, what the row carries, and the first reply that changes because of it. |
Questions#
Why are the stages the same for a phone call and a webhook?
Because the questions are the same. Both have a trigger, both have to decide which workspace they belong to before reading a setting, both have a point where an action is permitted or refused, and both end with something a person may need to see. One chain makes the difference between two flows visible instead of hiding it in two different layouts.
Some pages leave a stage almost empty. Is that an omission?
No — it is the honest answer for that flow. Documentation search over the public corpus touches no workspace at all, so its workspace-resolution stage is a single line saying so. An empty stage that is labelled empty is more useful than a stage padded to look complete.
Do these pages describe the Owner's experience or a customer's?
Both, over the same implementation. Where the two audiences genuinely differ the page says which is which; where it says nothing, the behaviour is identical and the only difference is that a customer workspace has plan allowances and the operator's workspace does not.