Core Concepts

Five vocabularies meet in this module, and the mistakes people make with it come from assuming they are one. A contact in the contact centre is not a customer; an agent is not an employee; a lead is not a quotation; an engagement is not a campaign; an event is not a registration page. This page defines each term as the applet that owns it defines it, with the table it lands in.

People and organisations — four records, not one

Term	What it is	Owned by
Customer	A trading counterparty with credit terms, a credit limit, tax identity, addresses and a credit status (`OK` / `BLACKLISTED`) — an entity flagged as a customer	Customer Maintenance — Core
Entity	The underlying person or company record a customer, supplier, employee or engagement client is built on	Entity — Core
Contact (contact centre)	The person on the other end of a conversation — a phone number, a social handle, an e-mail address. Created from an inbound message or typed in Contacts. Contact Merging links it to a customer or entity, a membership card or a platform login; until it is merged it is nobody in the rest of the product	Unified Contact Center
Organisation (sales force)	The company behind a lead or a deal — a CRM organisation record, created from the applet’s Organization menu or the lead form’s picker. The lead register classifies organisations, it does not trade with them. The applet also has its own address-book contact register, separate from the contact centre’s contacts and from the customer master, and its screens are not in the build a tenant is served	Sales Force Automation
Agent	A contact-centre role attached to a platform login subject — the thing a task is assigned to. Not an employee record. The routing rules hand a task to a user only through that user’s agent link to the contact-centre applet, so a user without one is skipped by automatic assignment	Unified Contact Center
Team	A group of agents. Stored as a platform group and therefore visible to the rest of the product	Unified Contact Center → Configurations → Teams
Employee	The staff record behind engagement roles, fiscal-year-end assignments and an event’s PIC — an entity flagged as an employee. Calendar members and event participants are not employee records: they are logins on your tenant, added by login e-mail	Employee Maintenance — Core

The practical consequence: a customer who WhatsApps the shop is a contact first. Their purchase history, cart and e-invoice appear in the conversation side-panels only once that contact has been merged with their customer record.

Conversation, task, queue, rule, action — how the contact centre works

A conversation is one thread on one channel with one contact. Conversations, messages, sessions, e-mail threads, social posts and voice calls are stored in a per-tenant MongoDB database, not in the tenant’s PostgreSQL schema. Only the contact centre keeps data there, and it is why conversation data does not appear in any SQL report.
A task is the unit of work a conversation, e-mail or voice call generates. It is a PostgreSQL row with a target type of CONVERSATION, EMAIL or VOICE, and one of the back end’s five statuses — CREATED, TEAM_ASSIGNED, AGENT_ASSIGNED, COMPLETED, CANCELLED. The desk also shows IN-PROGRESS and UNASSIGNED, which exist only in the front end.
A queue holds tasks waiting for assignment. The Inbox’s All Tasks / My Team Tasks / My Tasks and the Task Queue’s All / Team / My listings are views over the same rows; the Outbound family is the same shape for work the centre initiates.
A rule belongs to a queue and an automation-rule set, has a priority, conditions and an action. When a task arrives, the skill-based assignment processor fetches the rules in priority order, takes the first whose conditions match, writes a RULE_MATCHED event and runs the action. If nothing matches, or the matched rule’s action fails, the default rule of the skill-based assignment rule set runs; only when there is no default rule does the task go to any agent with the fewest tasks — a default rule whose own action fails leaves the task where it is. Twelve action types are declared; nine are handled by the inbound engine’s STANDARD switch (assign to available / any agent with least tasks, at random, to an available team agent with least tasks, to a team and keep in queue, keep in queue, and three OCR / web-mail processors). ASSIGN_TO_TEAM, ASSIGN_TO_AVAILABLE_AGENT and CREATE_ISSUE are not in that switch, so a STANDARD rule carrying one fails and the default rule runs instead — but a CUSTOM rule is executed from its target rather than its action code, and so can assign to a team or to one named person. Outbound routing is a separate engine and supports ASSIGN_TO_TEAM only.
A skill is a label on an agent that a rule condition can test. Virtual contacts and their per-channel endpoints are the centre’s own identities — the number, page, bot or mailbox and its provider credentials — and a project groups them.

A task, once created, is never closed by expiry. The expiry chain is installed — its first processor is a default clock that runs at 03:00 every day and queues old tasks — but the processor at the end of it, the one that would close them, has its body commented out with a note that it broke the platform. It was switched off on purpose, and it has not been switched back on. Tasks are closed by an agent completing or cancelling them, or not at all.

Lead, organisation, source, stage, type — the sales-force register

A lead is a prospective sale recorded before any sales document exists: a title, the organisation and the contact’s name, phone and e-mail, a probability and a priority, and four classifications drawn from lists the administrator defines in the applet’s settings — the project it belongs to, the source it arrived through, the stage it has reached and its type. Each of the four is a code / name / description register with no ordering and no transition rule: the stage list is the pipeline, and “won” or “lost” is whatever stage name you give it. Saving a lead also writes one SALES_LEAD_CREATED event with the current user as reporter and assignee.

The older build of the applet also carries deals — an opportunity keyed in from a lead, with activities, comments, work logs, calendar events and closed-won / closed-lost lists — and qualification criteria and ratings. There is no endpoint that converts a lead into a deal. Whether a tenant sees deals depends on which build it is served; and on the newer build a lead, once saved, cannot be reopened from the listing — the edit screen is not routed (recorded on the applet page).

None of this is a document. There is no server document type for a lead or a deal, no status engine outside the stage list you define, and no posting. Turning a lead into a quotation is a person opening Sales Quotation (Internal) and keying it in — the applet page found no knock-off from a lead to any sales document. The one automatic consumer of a lead is the older build’s CSV import, which can raise a Unified Contact Center outbound task per imported lead.

Engagement and fiscal year end — the practice’s client file

An engagement is one client file in an audit, assurance or tax practice: the customer entity it is for, the company and branch that bill it, a code and name, a free-text engagement status, the staff holding each engagement role, and — when the client is tracked by financial year — one fiscal-year-end record per year with its own staff. An engagement category is a code / name list the listing can show. The backend validates far more on update than on create: creation checks only that the code is not already taken, while an update also requires the company, branch, customer and billing entity to resolve, a code and an engagement status to be present, and assigns the running number if there is none. So an engagement created empty from the + button is invalid until those are filled — which is why practices load engagements in bulk through the ETL endpoints.

If your business is a retailer, you are the client in somebody else’s engagement register; the applet is in this module because it is customer-facing master data, not because it markets to anyone.

Calendar, event, participant — and where an event’s cost comes from

A calendar has members (logins on your tenant, added by their login e-mail, who can see it). An event belongs to a calendar, has a required company, a start date, a person in charge (an employee record), participants (picked from the calendar’s members), linked companies and agenda attachments. It is master data plus links: no status beyond ACTIVE / INACTIVE, no approval, no notification. The Event Expense Report is a read over the claims module: a staff claim line carries the event, and the report sums the lines tagged with the event — approved ones and, unless you filter by status, those still pending approval, pending document review or on hold. Nothing in the events applet tags a claim — that happens on the Claim side.

What none of them is

No record in this module is a generic document: ServerDocTypes has no entry for a conversation, task, lead, deal, engagement, calendar or event, so none of them has a FINAL, a posting status, a journal or a stock effect. The nearest documents — the shopping cart an agent opens from a conversation, the quotation raised for a lead, the claim that carries an event’s cost — all live in other modules and are documented there.