> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/product-reference/dialogue-studio/dialogue-studio-example-flows/last-agent-routing.md). # Last agent routing Import a flow for Dialogue Studio that remembers each customer's last agent and skill, and offers to route them back on their next contact. This example builds a "last agent routing" (LAR) pattern. It remembers which agent and skill last handled a customer and, on a later call, offers to route the customer back to that same agent. Use it as a starting point for continuity-of-care routing. ## What it does The flow listens to dialogue lifecycle events, builds an in-memory record per customer that tracks the last skill and agent they spoke with, and checks that record on every new incoming call. If a last agent is known, the caller hears a "welcome back" message and the flow attempts to route them back to that agent. If no record exists, the caller follows the standard welcome and enqueue path. ## Prerequisites * A UCC configured with Dialogue Studio, with the event bus emitting `DialogueStartedEvent`, `DialogueEndedEvent`, `DialogueParticipantAddedEvent`, and `DialogueQueueEnteredEvent`. * A skill named `Support` (or update the flow to use your own default skill name). * Support for the `preferredhunt` action in your environment. ## Preview ![Last agent routing flow](https://2627137428-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FscZpnEdBjDgQmlVn1iLr%2Fuploads%2Fgit-blob-7b4f660ebc65c4f7f2e81de8e2cdd43965586eee%2Flast-agent-routing.png?alt=media) ## Import the flow 1. Log in to your Dialogue Studio environment. 2. Open or create a tab for the flow. 3. From the menu in the top right, select **Import** and add the JSON from [`flows/last-agent-routing.json`](https://github.com/AnywhereNow/atlas-docs/tree/main/product-reference/dialogue-studio/dialogue-studio-example-flows/flows/last-agent-routing.json). 4. Deploy the flow. ## Configure after import * Open the **Filter UCC** switch node and change the placeholder value `ucc-name-example` to your own UCC name, or remove the switch entirely if you want the pattern applied to every UCC. * Open the **any-red-config** node used by the enqueue and preferredhunt action nodes and select your UCC. It is blank by default. * Several comment nodes marked **TODO: Configure UCC config** flag exactly where UCC-specific configuration is expected. * Review the daily cleanup schedule (default cron `00 12 * * *`) and adjust it to a time that fits your operations. {% hint style="warning" %} The saved UCC connection scopes normal callflow events and actions, not generic EventBus payloads. Bus events can include other UCCs on the underlying Core service, not only UCCs connected to this Dialogue Studio deployment. A dedicated port does not isolate them. Keep the UCC filter for a single-UCC design; remove it only for a deliberate multi-UCC design with matching action connections. Not every event includes UCC metadata, so validate the indexer and enricher against the received payloads and keep unresolved events out of UCC-specific processing. See [EventBus event scope](/contact-center-configuration/building-your-callflow/via-dialogue-studio/core-nodes.md#eventbus-event-scope). {% endhint %} {% hint style="warning" %} The cleanup function clears every key in the flow's context store, not only last-agent keys. Confirm no other flow logic shares the same flow context before you enable this schedule in production. {% endhint %} ## How the flow works The flow is organized into four groups: * **Dialogue UCC Indexer**: listens for `DialogueStartedEvent` and `DialogueEndedEvent` on the event bus and caches a `dialogueId -> uccName` mapping in global context, so later events that do not carry a UCC name can still be enriched. The cache entry is cleared when the dialogue ends. * **Create Last Agent Memory**: listens for `DialogueParticipantAddedEvent` and `DialogueQueueEnteredEvent`. A "Dialogue UCC Enricher" function injects the cached UCC name if it is missing, then a **Filter UCC** switch scopes the logic to one UCC. A **Route events** switch splits by event type: * On participant added, a switch checks the participant's role. When the *customer* joins, the flow stores a pending last-agent record keyed by UCC and a sanitized version of the caller's SIP user. When an *agent* joins, the flow updates that record with the agent's SIP URI and display name. * On queue entered (ignoring the IVR stage, `queueId -1`), the flow stores the queue name in the record, but only if no agent is already recorded, so a later queue does not overwrite a completed match. * **Route based on Last Agent**: on a new **Incoming Call**, a function retrieves the flow-context record keyed by UCC and caller. A switch checks whether an `agentUri` is known: * If not known, the caller hears a standard "Welcome" message and is enqueued to the `Support` skill. * If known, the caller hears "Welcome back, we will connect you with ``" and a **preferredhunt** action is used, targeting the last known skill and agent. * **Cleanup LAR Memory Daily**: a scheduled inject node (cron, default noon daily) triggers a function that clears the flow context store. ## Safe fallback behavior The `preferredhunt` action offers routing back to the last known agent; it does not guarantee that exact agent answers, so normal skill and routing rules still apply if that agent is unavailable. When no last-agent record exists (new customer, or the record was cleared by the daily cleanup, or Node-RED restarted since the memory is only stored in flow context), the caller falls back to the standard welcome and `Support` enqueue path, so no caller is left unhandled. ## Verification 1. Call as a new customer and confirm you receive the standard welcome message and are enqueued to `Support`. 2. Complete a call that is answered by an agent, then call back and confirm the "welcome back" message plays and the flow attempts a preferred-hunt to the same agent. 3. Trigger the daily cleanup inject node manually and confirm the flow context is cleared (a following call is treated as a new customer). 4. Where another UCC is available on the same Core service, confirm its bus events do not update the selected UCC's routing records. Confirm events without a resolved UCC do not enter the UCC-specific memory branch. ## Related topics Go to [Dialogue Studio example flows](/product-reference/dialogue-studio/dialogue-studio-example-flows.md) for the full gallery of example flows. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://atlas.anywhere.now/product-reference/dialogue-studio/dialogue-studio-example-flows/last-agent-routing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.