Chat

Chat

Real-time conversation between users, inside the application.

Where to find it

Architect Panel → Communication:

• Manage Chat Engines — the engines defining who may chat with whom

Architect Panel → Security:

• Permissions — who can use chat at all

What it gains you over a separate tool

Context. A conversation happening inside the application is next to the record it is about, visible to the people who work on that record, and retained under your rules rather than a third party's.

The alternative — a general chat tool alongside — means the discussion about a case lives somewhere the case cannot see, and somebody joining later has no way to find it.

What it is not

It is not a replacement for your organisation's general messaging, and trying to make it one produces a poor version of a tool people already have. Chat here earns its place where the conversation is about the work in this system.

Decide retention before enabling

The question people skip. Chat feels ephemeral and is not — messages are stored, discoverable, and disclosable in a subject access request like anything else.

Conversations about identifiable people are records about those people. Decide how long you keep them and apply it, rather than accumulating years of informal discussion nobody has thought about.

Tell people it is retained

Because the interface looks like chat, people write as though it disappears. It does not. A short note in your guidance prevents the kind of remark that reads badly a year later in an unexpected context.

Chat is not a record

The other half of the same problem. A decision reached in chat is not recorded anywhere the system understands — it is not on the record's timeline, does not appear in reporting, and is invisible to somebody reading the case.

Make it a habit that anything decided in chat is written to the record's timeline. Chat is where the conversation happens; the timeline is where the outcome belongs.

Restrict who can use it

Chat is a route for information to travel between people, which is exactly what your permissions exist to control. Somebody who cannot see a record can still be told about it in chat.

That is not a reason to avoid chat — it is a reason to be deliberate about who has it, particularly on external-facing installations.

Worked example

A team enables chat for internal staff only, with a six-month retention and a line in their guidance saying messages are stored and disclosable. Case decisions reached in chat are written to the case timeline as a note — a habit that took a fortnight to establish and means the record still explains itself.

Recommendations

• Set retention before enabling.
• Tell people messages are kept.
• Write decisions to the record, not just to chat.
• Restrict who has it, especially externally.

Chat Engines

A chat engine is a configured conversation channel: who may take part, who may start one, and what may be sent.

Where to find it

Architect Panel → Communication:

• Manage Chat Engines — the engines themselves

Architect Panel → Security:

• Permissions — the groups an engine is offered to

What an engine defines

• A name.
• A recipient mode — who a conversation may be with.
• An initiator setting — who may start one.
• Whether attachments are allowed.

Several engines, different rules

The reason engines exist rather than one global setting. Internal staff chatting to each other and a customer chatting to support are different arrangements with different rules, and modelling them as one produces something wrong for both.

The initiator setting matters most

Who may start a conversation is the control people underestimate. Allowing customers to initiate means an inbound channel somebody must watch; allowing only staff to initiate means customers cannot reach you this way, which may be exactly right or may leave people stuck.

Decide by asking who is expected to be watching. An inbound channel nobody monitors is worse than no channel — people use it and conclude they have been ignored.

Recipient mode is the boundary

It determines who somebody can reach. On an external-facing installation this is a genuine security boundary: getting it wrong can let customers message each other, which is rarely intended and occasionally serious.

Test it as a real external user before going live, rather than reasoning from the setting.

Attachments

Convenient and a route for files into your system that bypasses whatever you have set up around uploads. Consider whether the same scanning and type restrictions apply, and whether an attachment sent in chat ends up somewhere governed.

For an external-facing engine, off is the safer default until you have thought it through.

Keep the number small

Each engine is a set of rules to understand and maintain. Two or three covering genuinely different populations is manageable; a dozen produces a configuration nobody can hold in their head, and rules that quietly contradict each other.

Review who is offered each one

Engines are offered to groups, so group changes change who can chat with whom without anybody touching the chat configuration. Include it when you review access.

Worked example

An organisation runs two engines: staff-to-staff with attachments allowed and either party able to start, and staff-to-customer where only staff may initiate and attachments are off. The second was tested as a customer account before launch, confirming customers cannot reach each other.

Recommendations

• Separate engines for genuinely different populations.
• Only allow initiation where somebody is watching.
• Test recipient mode as an external user.
• Attachments off by default externally.

Enabling Chat for Users

Chat is granted to groups, so enabling it is a permissions decision like any other.

Where to find it

Architect Panel → Communication:

• Manage Chat Engines — the engines being offered

Architect Panel → Security:

• Permissions — the groups chat is granted to

Security groups themselves are managed in the Admin Panel sidebar under User Administration → User Groups; what a group may reach is granted in the Architect Panel.

It is an operational commitment

The thing to understand before switching it on for customers. Chat implies somebody is there — that is what the interface communicates, whatever your wording says.

A chat channel with nobody watching generates messages that go unanswered, and an unanswered chat message reads as being ignored in a way an unanswered e-mail does not. It damages the relationship rather than merely failing to help.

Set expectations honestly

If chat is staffed between certain hours, say so in the interface — not in a policy document. If responses take hours rather than minutes, say that too.

People will accept almost any stated expectation and will not accept an unstated one being missed.

Decide what happens outside hours

Either close the channel or say clearly when somebody will respond. Leaving it open and silent is the worst option, and it is the default if nobody decides.

Start internally

Enable for staff first. It surfaces the practical questions — notification behaviour, how conversations are found later, what happens when somebody is away — at no cost, before customers are involved.

Roll out to one group at a time

Rather than everybody at once. Volume is hard to predict, and a channel that turns out to be popular is much easier to staff if it arrived gradually.

Watch what people use it for

Chat attracts questions that should be tickets, and requests that need a record. If the same question arrives repeatedly, that is a documentation gap; if substantive requests arrive, they need routing into a process rather than answering in a conversation nobody can find later.

Train the habit of recording outcomes

Anything decided or agreed goes onto the record's timeline. Without that habit, a year of chat history contains the answers and the records do not — and nobody reads chat history to understand a case.

Worked example

An organisation enabled chat internally for two months before offering it to customers, then to one customer segment at a time. The interface states staffed hours and a response target. Handlers write outcomes to the case timeline, so the case still explains itself to somebody who was not in the conversation.

Recommendations

• Do not open a channel nobody is watching.
• State hours and response times in the interface.
• Start internally, then one group at a time.
• Record outcomes on the record.