Skip to content

Best Practices

Each item below is a consequence of something recorded on an applet page. If the product changes, the item goes with it.

Contact centre

  • Close tasks deliberately. The expiry chain’s deletion step has its body commented out, so a task that nobody completes or cancels stays open indefinitely and the Task and Agent reports count it. Make complete or cancel the last step of every conversation, and use the queue listing’s bulk COMPLETE / CANCEL actions to clear the backlog at the end of a shift.
  • Merge before you serve. A contact created from an inbound message is a phone number or a handle; the CRM, cart, transaction-history and e-invoice panels fill only after Contact Merging attaches it to a customer, entity, membership or login. Merge first, then look things up.
  • Route with the actions the rule type you chose can actually run — the two behave differently. A STANDARD rule is executed from its action code, and the inbound engine’s switch handles nine of the twelve declared codes: the six assignment and queue actions and the three OCR / web-mail processors. ASSIGN_TO_TEAM, ASSIGN_TO_AVAILABLE_AGENT and CREATE_ISSUE fall through that switch, are logged as unmatched, and the rule is treated as failed. A CUSTOM rule never reaches the switch: the engine reads the rule action’s target instead, so a CUSTOM rule pointed at a team or at one person does assign to it — which is exactly how Contact-centre automation builds these chats go to that team. Outbound rules run on a separate engine that supports ASSIGN_TO_TEAM only.
  • Keep the fallback in mind when writing rules. Rules run in priority order and the first match wins; a task that matches nothing goes to any agent with the fewest tasks — including agents on other teams. If a queue must never spill, give it a default rule.
  • Do not configure what is inert. Field Settings and Default Selection in this applet save nothing. The one working setting is the Issue Category slots.
  • Name teams for the whole product. Contact-centre teams are platform groups and are visible wherever groups are used.
  • Broadcast is a single send. One channel, one endpoint, a contact list, one message. There is no schedule, no frequency cap and no opt-out mechanism in the applet; consent and cadence are yours to manage outside it.

Sales force

  • Define the registers before the leads. Project, source, stage and type are administrator-defined lists; the lead form’s required drop-downs are empty until they have rows, and the stage list is the pipeline. Agree the stage names once and change them rarely — a lead carries one stage value and one creation event, so there is no stage history to reconstruct from.
  • Treat the lead register and the customer master as two things. An organisation in the lead register is not a customer; raising the first quotation means creating the customer in Customer Maintenance with its credit terms. Decide who does that and when. Nothing converts a lead into a customer or a quotation; the Lead-To-Deal tab builds a deal in the browser and marks nothing on the lead, so press it once.
  • The build you are served is a 2022 one. A newer rebuild exists but cannot be installed or opened. Several screens — Address Book, AB Contacts, Categories, Application Settings — are not in the served build either. Check your own menu before planning around any of them, and read the applet page’s warning callout first.
  • Budget for the screens off the main menu. Projects, and the types, sources, stages and ratings under them, are created on Project Settings, which is opened from Settings → Project Configuration rather than from the main menu; Lead Settings and Deal Settings are reached only by URL. Nothing on the lead form works until they exist.
  • Do not edit an organisation on the Organization screen unless you have to. Its save does not send the Org code, and the platform has no partial update, so saving blanks it — silently, under a success toast.

Engagement register

  • Load, do not type. Code and Engagement Name are read-only in the form and nothing in the applet sets them; the practice loads engagements through the bulk-load API and maintains roles and year ends on screen.
  • Hide the + button (HIDE_ENGAGEMENT_CREATE_BUTTON) once loads are the routine. Each press creates an empty ACTIVE engagement that no sweeper removes.
  • Agree the status vocabulary out of band. The engagement status is free text validated only for not-blank; the fixed list is commented out of the form.
  • Fix GUIDs before the first edit. The create validator does not FK-check company, branch, customer and billing entity; the update validator does. A row loaded with a stale GUID fails on its first save.

Events

  • Announce events yourself. Creating or changing an event sends no e-mail, SMS or push; the notification queue table has no processor.
  • Tag claims on the claims side. An event’s cost is the sum of the claim lines that carry its GUID. Brief claimants to pick the event on the claim line; nothing in the events applet can tag a claim after the fact.
  • Give the cost readers the claim-report permission. The Expenses tab and the Event Expense Report are gated by TNT_AAT_CLAIM_REPORT_*, not by calendar membership.
  • Check End Date by hand. Neither side validates it against Start Date.

Across the module

  • Credit control is in Core and it is retrospective. The BLACKLISTED status is applied by a batch sweep from outstanding-versus-limit and ageing-versus-terms, and no CRM applet reads it. If the contact centre must refuse service to blacklisted customers, that is a lookup the agent makes, not a rule the centre enforces.
  • Nothing here posts. Any figure a finance reader wants from this module — the cost of an event, the value of a pipeline — is either a claims-module number or a spreadsheet.