Skip to content

Configuration

There is no module-wide setup. Each of the four applets has its own short list of things that must exist first, and two of the lists start outside the applet. This page collects them in the order a new tenant meets them; the applet pages carry the field-by-field detail.

1. Core master data — every applet in the module reads it

WhatWhereNeeded by
Companies and branchesOrganisation AppletAn engagement’s billing company and branch (both checked to exist on update); the required Company on an event
Customers and entitiesCustomer Maintenance, EntityThe client an engagement is raised for; the record a contact-centre contact is merged with
EmployeesEmployee MaintenanceEngagement roles and fiscal-year-end staff; an event’s PIC. Calendar members and event participants are logins, not employee records
Login subjects and rolesTenant AdminA contact-centre agent is a role on a login subject; server-side permission families (TNT_API_CMS_CALENDAR_*, TNT_AAT_CLAIM_REPORT_*, the alg/cc and sfa families) are granted here or through each applet’s permission screens

2. The contact centre — what it cannot create for itself

The Unified Contact Center depends on two pieces of platform data that have no screen inside the applet:

PrerequisiteWhere it livesWhat happens without it
The messaging channel you want (WhatsApp, Telegram, SMS, e-mail, …) must exist in the channel registerPlatform data — no screen in the applet; ask support to add a channelEndpoints, contacts and broadcasts all pick from this list; nothing can be received or sent on a channel that is not in it
A notification subscription with topic code UCC_MESSAGE_RECEIVEDPlatform data — no screen in the applet; ask supportBrowser push registration silently does nothing
Issue category groups in namespace WF_CATEGORYWorkflow / issue label listsThe Issue Tracker panel has no categories to offer

Then, inside the applet, in this order — each step is a Configurations menu entry:

  1. Project — a Virtual Contact cannot be saved without one.
  2. Virtual Contact with one Endpoint per channel — the number, page, bot or mailbox and its provider credentials. This is the step that makes a channel live.
  3. Agents — one per login subject who will be assigned work.
  4. Teams — stored as platform groups, so they are visible outside the applet.
  5. Skills, Queues, Rules and Actions — only needed for automatic routing. Without them every task falls through to any agent with the fewest tasks, which is a working configuration for a small centre.

The one applet setting that does something is Application Settings → Issue Category: up to eleven category-group slots, each optionally mandatory, that build the Issue Tracker panel’s drop-downs. Field Settings renders eight document-style toggles bound to nothing, and Default Selection cannot save — both are recorded on the applet page. Do not spend time on them.

3. The sales-force register — lists before leads

Sales Force Automation classifies every lead by a project and then by the types, sources, stages and ratings that belong to that project. Every one of those drop-downs is filtered by the project you chose, so a project with no rows of its own leaves the lead form unsaveable. An organisation is required too, and comes from the Organization menu or the lead form’s Select Organization picker.

The screens that create all of this are not on the main menu. Projects come from Project Settings, which you open from Settings → Project Configuration — the top-level Project route and its menu item are both commented out. The four registers come from there, or from settings/lead-settings and settings/deal-settings, which have no link anywhere and are reached by typing the URL. There is no rating-settings route at all, so the commented-out menu entry of that name would 404 if it were restored. Show whoever sets this up where Project Settings lives before you plan the rollout.

Nothing else is configurable, and in the installed build nothing on the settings screens works at all: Field Settings has no form binding and no save handler, and Default Selection never loads, throws when you pick a branch, and emits its save to nobody; the applet page has the detail.

4. The engagement register — load, do not type

The Engagement Applet’s Main form has read-only Code and Engagement Name fields, and no code path in the applet writes them. Practices load engagements through the applet’s ETL load endpoints (see the applet page) with the code and name set, then maintain roles, fiscal year ends and categories on screen. Before the first load:

  • the client customer entity, the billing company and branch and the employees for each role must exist. The update validation checks the company, the branch and the customer and billing entities — creation checks none of them — so an engagement whose references do not resolve passes creation and fails its first edit. The employees on the roles are separate records and are not checked by the engagement header;
  • the engagement’s running number is not given at creation: the first edit assigns it from the tenant’s ENGAGEMENT_NO counter, so a freshly loaded engagement shows none until somebody saves it once;
  • Engagement Category entries, if the listing column is to show anything — the Main tab has no category picker, so categories are attached from the category side.

Consider turning on HIDE_ENGAGEMENT_CREATE_BUTTON: the + button creates an empty engagement immediately — record status ACTIVE, engagement status DRAFT — and no sweeper removes the stray rows.

5. Calendars and events — members, then events

In the Event Management Applet, create a calendar and add its members (logins on your tenant, by their login e-mail) before any event — an event’s participants are picked from them; the applet settings hold the calendar new events default to. An event needs its Company and Start Date; End Date is not validated against Start Date on either side, so check it by hand.

The Expenses tab and the Event Expense Report are served by the claims report endpoints and gated by TNT_AAT_CLAIM_REPORT_OWNER / _ADMIN / _CREATE — calendar permissions do not cover them. Grant the claim-report permission to whoever will read event costs, and note that the read is behind a _CREATE code because the report endpoints are POSTs. Costs appear only when a claim line is tagged with the event on the Claim side, and both screens list claims that are still pending approval, pending document review or on hold beside the approved ones — read the Claim Status column, or the approved tile, before you quote a figure as the event’s cost.

6. What success looks like

  • Contact centre. Send one message to the endpoint you configured. It should appear as a task in Inbox → All Tasks with status CREATED, then TEAM_ASSIGNED or AGENT_ASSIGNED once a rule (or the fallback) has run. Open it, use Contact Merging to attach the sender to a customer, and confirm the side-panels fill.
  • Sales force. Save one lead against a project, source, stage and type; confirm the listing shows Org Name, Contact Name, Type, Lead Source, Stage and the dates. On the newer build do not expect clicking the row to open it — that screen is not routed.
  • Engagement. Load one engagement by ETL with code and name set; open it, change the branch, save. A clean save proves the company, branch and entity GUIDs resolve.
  • Events. Create a calendar with yourself as a member, add an event, and confirm it appears on the calendar view. Tag one claim line with the event and confirm the Expenses tab shows it.

What there is nothing to configure for

No SLA timers, no sentiment or churn models, no drip sequences, no event registration pages, no frequency caps, no opt-out links. See what the module has no engine for.