Outcome. A ticket routes to a language-matched pool with the language it was routed on stamped directly onto the ticket record, giving reporting a reliable, ticket-level field to group by, instead of always having to look up the associated contact's language after the fact.
flowchart TD
A[Ticket created] --> B[Copy contact_language into ticket_language]
B --> C{ticket_language value?}
C -->|fr| D[Rotate to French-speaking pool]
C -->|nl| E[Rotate to Dutch-speaking pool]
C -->|de| F[Rotate to German-speaking pool]
C -->|es| G[Rotate to Spanish-speaking pool]
C -->|en / unknown| H[Rotate to English/general pool]
D --> I[Set routed date]
E --> I
F --> I
G --> I
H --> I

When to use it, when not to
- UseUse it as the reporting-friendly version of language-based routing: if you only need the routing decision itself and do not need a ticket-level property for dashboards, tickets-sla-014 already covers that more simply by branching directly on the contact's property.
- UseUse it when tickets get reported on by language independently of the contact record, for example a dashboard segmenting SLA performance by language pool, which is easier to build from a property that lives on the ticket itself.
- SkipDo not use it alongside tickets-sla-014 without deciding which one owns the actual rotation; running both on the same ticket risks two separate rotate actions competing for the same assignment.
- SkipDo not use it if a contact's stated language is unreliable or frequently wrong for your customer base; a ticket-level copy of a bad value is still a bad value, just harder to notice since it now looks authoritative on the ticket.
or the tickets and sla pack, 39 EUR
One-time, excl. VAT. 30-day refund, no questions asked. Founding prices until 31 October, then 199 and 59 EUR. Includes every spec added later, up to the full 500, and the one-click installer on the full library. Building on client portals? The agency licence at 449 EUR covers unlimited client portals.





