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.