Glossary
This glossary holds one definition per term in Connect's product vocabulary — workspace, Needs You, autonomy, memory, identity, relationship — and it is the only place any of them is defined. Every other page links here rather than explaining a word again, so a term means the same thing on a phone page as it does in the developer reference.
The rule this page exists to enforce#
A page about held email replies may say a draft is waiting in Needs You. It may not stop and explain what Needs You is. It links to Needs You and carries on with its own subject. The effect is that a definition changes in one place, and every page that leans on it is correct the moment it does.
The list of names is not a matter of taste. A registry of canonical terms is read by the documentation check, and a page that invents a second name for something already named fails the build. The in-app assistant is the Connect Assistant — not a chatbot, not an assistant bot. The decision queue is Needs You — not an approvals inbox. A human in a workspace's relationships is a Person; the address they wrote from is an Identity. Those are two records and two words, and this corpus never swaps one for the other.
How the vocabulary groups#
The terms fall into six groups. Reading a group end to end is usually faster than reading one page, because most confusions in this glossary are between neighbours rather than between distant words.
| Group | Terms | The distinction the group turns on |
|---|---|---|
| The product | Connect, Digital employee | A role that works a queue, not a feature you invoke |
| The container | Workspace, Owner, Tenant, Customer-safe | Isolation, and which of two audiences a session belongs to |
| Work waiting | Needs You, Approval, Follow-up | A decision, a held action, and a dated commitment |
| What Connect knows | Memory, Knowledge, Fact, Rule, Standing instruction | Learned, supplied, extracted, constraining, or directed |
| Who it talks to | Person, Identity, Company, Relationship | One human, one address, one organisation, one connection |
| Permission | Autonomy, Audit, Entitlement | What may happen, what did happen, and how much is left |
What is deliberately not defined here#
Protocol and technology terms have been removed from this glossary. SIP, IMAP, OAuth, PSTN and the rest each have a page under Technology reference or Protocol reference that explains the standard and then answers, explicitly, whether Connect uses it. A two-line glossary gloss of a protocol is the kind of writing that leaves a reader believing Connect implements something it merely speaks to, so the gloss is not offered.
Screens are not glossary entries either. Conversations, Phone and Plan & Usage are documented where they are used. A word earns a page here when it appears in prose across several sections and would otherwise be redefined in each.
How to read an entry#
- The answer
- One or two sentences that stand alone. If you only read this, you have the definition.
- In Connect
- Which screen, which record and which module the term names. This is where a general word becomes specific.
- Commonly confused with
- The neighbouring term and the consequence of mixing them up. Most support questions in this vocabulary start here.
- Related
- Where the term is actually used, including at least one page outside the glossary.
Everything in this section#
41 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| Allowance | An allowance is what remains of a period's permitted volume. Some are refused at the limit, some are ceilings on what may exist, and one is only counted. |
| Approval | An approval is one held action waiting for a human yes or no — what holds it, what the recipient sees meanwhile, and what a rejection does. |
| Audit | The audit trail records who did what, in what capacity, to what, and whether it worked — including the refusals, because a refusal is a decision too. |
| Autonomy | Autonomy is the per-channel rule for what Connect may do without asking: four channels, four modes, four scopes, narrowest scope wins. |
| Carrier | A carrier is the telephony provider specifically — the company that reaches the public phone network, and the authority for a call's duration and cost. |
| Channel | A channel is a medium Connect communicates over. Four carry autonomy rules, one more exists for calls you make yourself, and the word is not the provider. |
| Company | A company in Connect is an organisation you deal with — never your own business, which is the workspace — and it is what people are attached to. |
| Connect | What the name Connect covers: the product, the operator behind it, the work it does across four channels, and the names it is not. |
| Conversation | A conversation is Connect's channel-agnostic unit of exchange — one continuing exchange with one person, whether it arrived by email, WhatsApp, SMS or phone. |
| Customer 360 | Customer 360 is one person's whole history assembled across every channel — built when you ask for it, not stored as a separate record. |
| Customer-safe | The allowlist that decides which API paths a customer session may call, how it differs from the rewrite that happens in the browser, and what its 403 means. |
| Deal | Deal is the everyday word for an opportunity. Both appear in Connect because the screens speak plainly and the model and API do not. |
| Digital employee | The role-shaped definition of a Digital Business Employee, and the line that separates one from a task agent, a copilot or an automation. |
| Disposition | A disposition is what a person decided a call was — stored apart from the engine's guess, and never overwritten by a model or a late carrier update. |
| DNC | Do not contact is the strongest block a workspace can set on a person: every channel, no exceptions, and not something the Connect Assistant may clear. |
| Entitlement | An entitlement records what a workspace's subscription permits: which features it reaches and what daily volumes it may use, as two separate questions. |
| Fact | A fact in Connect is one grounded statement with provenance, extracted from knowledge or a conversation — and correctable on its own. |
| Follow-up | A follow-up is a dated commitment to make contact on a named channel, with the reason recorded — including one channel that never sends anything. |
| Identity | An identity is one address on one channel that resolves to a person — and it is not your own mailbox, not a sign-in, and never guessed. |
| Knowledge | Knowledge is the source material a workspace supplies for answers to be grounded in — what counts as a source, and why it is not the same as memory. |
| Lead | A lead in Connect is a contact captured from a conversation you were already having — a different record from a prospect, and from a person. |
| Lifecycle stage | A lifecycle stage says how far one relationship has got, in six words — and the transition into client is the one Connect may not make alone. |
| Mailbox | A mailbox is one email account connected to a workspace, with its own role, signature and autonomy — and it is not the same thing as an identity. |
| Memory | Memory in Connect is what it knows about a business and its people, held at four tiers and resolved narrowest-first — readable and erasable at each one. |
| Needs You | Needs You is the ranked queue of decisions, approvals and operational problems waiting for a person — what qualifies for it and how it empties. |
| Opportunity | An opportunity is one commercial deal on the pipeline, with a value and one of five stages — and winning it is a change only a person confirms. |
| Outcome | An outcome is the engine's verdict on a call, derived from the conversation — and it decides whether anything is scheduled to happen next. |
| Owner | Owner in Connect means the platform operator's own workspace and session — what that changes, and the three things that are correctly operator-only. |
| Person | A person is the canonical human record in Connect: one human however many addresses they use, and the thing every conversation resolves to. |
| Prospect | A prospect is an organisation research found and kept as a candidate — held deliberately even before any contact address for it exists. |
| Provider | A provider is the external service behind a channel — the mail host, the messaging platform, the carrier. Connect keeps their shape out of its own records. |
| Relationship | A relationship is the ongoing connection between a business and a person or company — everything that has happened, across channels and years, in one record. |
| Rule | A rule in Connect constrains behaviour rather than granting permission — where rules are written, and how they differ from filters and from autonomy. |
| Standing instruction | A standing instruction is a durable direction a person gives Connect — how it differs from a memory, from a rule and from an autonomy setting. |
| Support case | A support case is one post-sale thing a customer needs sorted out, with a state and an owner — and deliberately not a helpdesk ticket. |
| Suppression | Suppression is a standing block on contacting an address or number. It outranks every other reason to send, and its origin decides whether it can be lifted. |
| Tenant | Tenant is the engineering word for a customer workspace: where it appears, why the product says customer instead, and what it is not. |
| Thread | A thread is the email-shaped conversation in Connect: what joins messages into one, what does not, and the triage state the engine reads from it. |
| Voice Lab | Voice Lab is where a workspace tunes how Connect sounds on the phone and reviews finished calls against measurements the worker took on the wire. |
| Workspace | The isolation root in Connect: what belongs to one workspace, how the boundary is enforced three times, and what deliberately sits outside it. |
| Workspace kernel | The layer that filters every database query by workspace, why it is not the same thing as row-level security, and what an empty workspace stamp does to a record. |
Questions#
Why does the same word sometimes appear in the product and in engineering with different weight?
Because two audiences read the corpus. *Tenant* is the engineering word for a customer workspace and appears in route names and isolation code; *customer* is the same thing in prose a business owner reads. Both are defined, and the entry for each says which register it belongs to.
If a page contradicts this glossary, which is right?
The glossary. A definition lives in exactly one place so that a contradiction is a bug in the other page rather than an open question, and the documentation check is what catches most of them before publication.
Can I use a term from here in an integration without checking anything else?
For prose, yes. For field names, no — the API has its own identifiers and its own stability rules, and the public data model is the authority for those.