Journey Analyser

1What it is

Journey Analyser is journey analytics in the shape of Genesys Journey Management, run over the flow-execution traces of your own Genesys Cloud CX call flows. For every call that passes through a flow with capture execution data switched on, Genesys records what the flow did step by step — which menu played and which option the caller landed on, which data action ran and which result path it took, which bot was invoked and what it recognised, where the call was sent. Alongside it, the conversation’s analytics record says what happened after the IVR: whether a queue was reached, whether an agent answered, and how the agent wrapped the call up. Journey Analyser harvests both for the flows you watch, keeps them, and derives from each call an ordered list of journey events drawn from twenty event types. In the Journey Builder you place a card for an event type, narrow it with attribute filters, connect cards in the order callers should meet them, and read unique callers on every card and Moved Forward, Dropped Out and Conversion Rate on every connector — the four metrics Journey Management shows.

What is different from Genesys Journey Management

• Branches on a card. Most event types declare one attribute that splits what happened next — a data action’s result, a menu’s choice, a bot’s verdict, an outcome’s value, a queue result. A card shows those values as branches, each with the callers who took it, and a connector can leave from a single branch. Get Contact By ANI is one card; Success and Failure are its two branches, never two cards.
• What happened next. With a card or a branch selected, the left pane lists the events those callers went on to, ranked by how many did — discovery rather than guesswork. One click adds the row as the next card, already connected.
• Live calculation. There is no Calculate step. Every edit — a filter ticked, a card moved, a time limit set — recomputes the whole journey within a moment.
• Prompt-, data-action- and menu-level events. The trace lets a card stand for a prompt the caller heard, a decision block’s case, a collect-input step’s result or a specific data action, not only flow-level starts, outcomes and ends.
• Harvested history. Watching a flow schedules a daily harvest, so history accumulates from the day you start and any window you later open is already populated. Genesys itself retains execution data for only about ten days.

What it cannot do

• No web, external or survey events. Only voice flow execution and the conversation’s queue and agent record are harvested. Web sessions, external data sources and survey responses are not event types here.
• No identity across channels or calls. A “caller” is one conversation. The same person ringing twice in the window is two callers; there is no customer identity stitched across calls, channels or devices.
• Only what the trace contains. Traces never carry the digits pressed — a menu choice is the option landed on, a collect step only whether input was accepted. Calls through flows without capture execution data have no trace and cannot appear.

2Signing in

Journey Analyser authenticates with a Genesys Cloud OAuth Client Credentials grant, the same convention as the other QVCCS tools. On the sign-in screen:

1. Choose your Region — the Genesys Cloud region your organisation lives in.
2. Paste the OAuth client’s Client ID and Client Secret.
3. Press Sign in. The app exchanges the credentials for a token, reads your organisation’s name and opens the Home page. The connected organisation and region are shown in the header, with a Sign out button.

Credentials are held encrypted on the server for the lifetime of your session and never sent to the browser; the secret is never written in plain text. Sessions end after a period of inactivity. If the token exchange fails you will see the error and, where the app can tell, the permission that was missing (“Missing scope: …”).

Permissions the OAuth client needs

3Concepts

Harvest and window

A harvest enumerates every conversation that touched a watched flow in a window — a range of whole UTC days, from → to — and fetches the execution trace and analytics record for each. Traces are stored once per conversation for the whole organisation and re-used by every later window and flow, so a harvest only fetches what is new. Findings, Stories and the Journey Builder work over the same kind of window, but read its days in the organisation’s time zone rather than UTC (see Days are the contact centre's days): every count it shows is for the conversations stored for that flow between those two days.

Traced caller

A conversation in the window that has a stored execution trace. Traced callers are the population of a journey — the denominator for every share shown as a percentage “of all”. A call that touched the flow but has no trace (capture was off, or the trace had aged out by the time of harvest) is counted on the run page as “without a trace” and takes no part in journeys.

Event type

One of twenty kinds of moment a call can contain: Call start, Flow start, Menu, Data action, Bot end, Flow outcome, Transfer to queue, Queue result, Wrap-up, Call end and so on. Each call is reduced to a time-ordered list of occurrences of these types. §7 lists them all.

Attribute

A named value carried by every occurrence of an event type — the Action and Result of a data action, the Menu and Choice of a menu, the Queue of a transfer. Filters are always on attributes: a card matches an occurrence when, for every attribute you have filtered, the occurrence’s value is one of the values you ticked. Matching ignores case.

Branch

The attribute an event type declares as the one that splits what happened next — marked ⑂ in the inspector. A card shows the values of its branch attribute among the callers who reached it, each with a count, a share of the card and a → handle. A connector may leave from the whole card or from one branch. Not every type has a branch: Prompt played, Transfer to queue, Agent handled and Flow milestone, among others, have none.

Card

An event type plus attribute filters, placed in a Step column on the canvas. A card without filters counts every occurrence of its type, which is rarely what you want; the canvas says so in amber until you choose a value. A card may carry a label of your own; otherwise it is titled from its type and first filter (“Data action: Get Contact By ANI”). A journey may hold up to 50 cards.

Connector

An arrow from a card (or one of its branches) to another card, meaning “and then”. It defines the order in which the target must follow the source and carries the four metrics. It may have a time constraint. A card may have up to 20 connectors leaving it.

Root card versus connected card

A root card has no incoming connector. A caller reaches it if a matching occurrence exists anywhere in their call; the moment of reaching it is the first such occurrence. A connected card is reached only by a caller who reached one of its source cards and then has a matching occurrence at or after the moment they reached that source — on the named branch if the connector leaves from one, and within the time limit if one is set. With several incoming connectors, the earliest qualifying occurrence is the one that counts. Sources are always evaluated before their targets, whatever column they sit in.

Unique callers

Every number in the Builder is a count of distinct conversations, never of occurrences. A caller who hears the same prompt three times, or whose data action runs twice, counts once on that card. Because a caller is a conversation, a branch’s counts always add up to the card’s callers, and one caller can be “moved forward” on two different connectors leaving the same card.

4Home & harvesting

Check coverage

Before you trust a window, prove it is complete. On Home, set the window and click Check coverage beside the flow. For every day in the window the app asks Genesys how many conversations touched the flow and shows that number beside the number held here:

Home is titled Flows. It is where you decide which flows to analyse, how far back to harvest and how often; it refreshes itself every few seconds while open. It has three parts: the Watch a flow card with the harvest window, the table of watched flows, and Recent harvests.

Watching a flow

1. Open the Choose a flow… list. It shows every published flow of the journey-relevant types — inbound call, in-queue call, secure call, bot and digital bot — with the type in brackets.
2. Pick the inbound flow whose journey you want and press Watch. It appears in the table below with a daily schedule already set.

You do not need to watch bots separately: bots reached from a watched inbound flow appear in the same conversations and are traced with them, so Bot start, Bot intent and Bot end cards are available for them automatically.

The harvest window

To the right of the flow picker are two date fields, Harvest window from → to, in whole UTC days. They default to the last seven days (today and the six before). Both Harvest and Journeys use whatever is set there, so set the window first, then act on a row. The harvest reads the dates as UTC days; Journeys reads the same dates as days in the organisation’s time zone (see Days are the contact centre's days). A single harvest covers at most 92 days and its end is clamped to now; longer history is harvested in consecutive requests. Because traces are kept once per conversation and re-used, harvesting a window that overlaps one already stored fetches only the conversations not yet traced.

The daily schedule

• Watching a flow sets its schedule to daily. From then on the app harvests the flow once a day without further action, so history accumulates and any window you later build a journey over is already populated. Change the drop-down to every 6 h, every 12 h or manual as you prefer.
• The schedule is checked every ten minutes. A flow is due when at least its interval has passed since its last scheduled run and no harvest for it is currently running.
• A scheduled run harvests the trailing window ending now — the schedule interval or 24 hours, whichever is longer — so a daily run re-scans yesterday and today and fetches only what is new.
• Scheduled runs need a signed-in session for the organisation. If nobody from your org is signed in when a run falls due, it is skipped and picked up at the next check after someone signs in.
• Scheduled runs appear in Recent harvests exactly like manual ones.

Harvest runs

Recent harvests lists the last twenty runs for your organisation, newest first: flow, window (UTC), a status badge (done, error, or the phase in progress), conversations, traced (with “N no trace” when applicable) and start time. Click a row to open its run page.

The run page streams the harvest as it happens. The heading shows the flow and window; beneath it a status badge and a phase line — “Enumerating… N conversations” while conversations are being listed, then “Tracing done / total” with a progress bar and a running “traced · without trace” count — and below that the scrolling log, one line per catalogue refreshed, per gap enumerated and per warning. You can leave and come back; the log is replayed. While a run is in progress an Abort button stops it at the next safe point, keeping everything saved so far. When it has finished the phase line reads, for example, “12,480 conversations · 11,902 traced (9,300 re-used) · 578 without a trace”: 12,480 calls touched the flow in the window; 11,902 have an execution trace, of which 9,300 were already stored from earlier runs; 578 have none. Two buttons then appear: Re-derive events and Build a journey, the latter opening the Journey Builder on this flow and window.

Re-derive events

Every stored trace is kept raw, and the journey events you see are derived from it together with the flow designs and organisation catalogues (data-action names, queue names, prompt text). Re-derive events on a finished run rebuilds the events of every conversation in that run’s window from the raw traces already stored: it refreshes the catalogues, re-fetches the designs of the flows and common modules those traces passed through, and re-reads each trace. No trace is fetched from Genesys again, and the raw traces themselves are untouched. It reports “N traces re-derived” beside the button and the Journey Builder picks up the result on its next recalculation.

Use it when:

• the application has been updated to read traces differently, so older harvests should benefit;
• outcome cards are named simply “Outcome”, or data actions carry a generic name, because the design or catalogue was unavailable at harvest time;
• a permission has been granted since the harvest — sign out and in first, then re-derive so the newly readable names and prompt text are used;
• a flow or common module has been republished and you want steps named from the current design.

Stories

Open Stories from Home. It is the plain-English front door to a flow, built only from the kinds of step every Genesys flow is made of (menus, bots, collect inputs, decisions, data actions, outcomes, transfers, the queue and the agent), so it works for any imported flow in any organisation.

• Two choices per flow, suggested for you. Where callers say what they want: the menu or bot whose answers read like requests (the app suggests the one most callers reach with the most varied answers). Why a call went to an agent: a participant-data field the flow sets (suggested when one is set on at least a third of agent calls), or the last thing the caller did before the transfer. Change either and the page recalculates; the choice is remembered for the flow.
• Caller stories. Every call summarised as what the caller wanted, the first thing that went wrong (a bot that returned a failure or a request for a person, a failed collect input, a failed data action, an outcome that can fail and did), and how the call ended — ranked. Example caller walks through a typical call from that story step by step; Callers lists them with links to their transcripts.
• Where a caller's time goes. Average seconds inside the IVR by what the caller was doing, then the median time before the queue, in the queue and with the agent, and how many times callers were asked something.
• Why callers reached an agent, What callers wanted, and what they got (each intent against the five ways a call can end), The decisions that decide the call (the forks whose branch says most about how the call ends; a fork that only repeats another, such as a switch testing a bot's result, is left out) and Where the minutes go (caller-minutes held by each step).

5Findings

Findings is the first thing to open after a harvest. It reads every traced call in the window and produces a ranked list of what is failing in the flow, where, and for how many callers, with the evidence behind each item, the callers it affected (one click to a transcript) and a plain recommendation.

Impact score

Findings are ordered by one comparable number: hang-ups × 3 + failures × 1 + caller-minutes lost ÷ 10. A step that makes callers give up outranks one that fails quietly, and a slow step that touches thousands of callers still surfaces. Severity is high at 300 or more, medium at 60 or more, otherwise low.

What the rules look at

How calls end and velocity

Above the list, How calls end shows the share of callers answered by an agent, hung up in the IVR, abandoned in queue, transferred out or ended by the flow. Velocity gives median seconds from call start to the first prompt, identification, the first bot, the queue transfer and the last thing the flow did, for each of those groups, plus queue wait. Reading the two together shows where time is lost and by whom.

Use Excel for the full list with evidence, velocity, endings and every affected caller. Use Journey builder to follow a finding's path by hand.

6The Journey Builder

Start from the Architect flow

The quickest way to a journey is to import it. On an empty canvas choose the design version (the list shows every version your harvested calls ran, with call counts; the default is the version most calls used) and the scope, then click Import flow. The canvas is seeded from the flow's design in design order: its decisions and switches with their cases, data actions with their Success, Failure and Timeout branches, menus with their options, collect-input steps, flow outcomes, transfers and disconnects. Every bot flow the design calls, every common module it runs and every flow it transfers to is walked as well, so the seeded journey has no gaps.

Counts are overlaid immediately. Blocks no caller reached in the window show 0; Remove unreached in the header removes them all at once, or delete cards one by one. The import is a starting point, not a fixed picture: rename cards, add filters, connect branches differently, and add cards from “what happened next” for the things the design does not predict, such as callers hanging up.

Open the Builder with Journeys on Home or Build a journey on a finished run. It works the way Genesys Journey Management does, over the traces you have harvested: cards for the moments you care about, connectors for the order, filters to say exactly which menu, action, bot or queue you mean — and the four metrics on every connector. Unlike Journey Management, nothing waits for a Calculate button: counts are unique callers and are recalculated as you edit.

The three panes

Across the top is the header: the journey’s name (type over Untitled journey), an amber unsaved badge while there are changes not yet saved, a line reading “N traced callers · from → to (time zone) · each caller’s arrival at a card is credited to one link…” (once calculated, “N callers counted” replaces “N traced callers”; the time zone is the organisation’s), the two date fields that set the window, the saved journeys selector (＋ New journey plus every journey saved for this flow with its card count), and the Save, PDF, Excel and Delete buttons — the last three only once the journey has been saved. Beneath it are three panes.

Placing the first card

An empty canvas says Place the first card. With nothing selected the left pane shows What calls start with: every event type and value that occurs in the window, ranked by callers, with the share of the population beside each — Call start · 0808 157 0123 · 12,480 · 100%, Flow start · Main IVR, Call end · Handled by agent · 61% and so on. Click the row you want to begin from — usually the call start or the flow start. It lands in Step 1 as a root card, already filtered to that value, and becomes the selection.

Selecting a card or a branch

Click a card’s blue heading to select the whole card: it gains a blue ring, the inspector shows its count, filters and branches, and the left pane becomes After card. Click a branch row on the card to select that branch instead: the inspector heading reads type › branch, the count is the callers who took that branch, and the left pane becomes After card › branch — what only those callers did next. The selection decides where the next card is placed and connected from, so selecting a branch is how you follow, say, the Failure path on its own.

Adding the next card

With a card or branch selected, the After … list shows, for the callers at that point, the first later occurrence of each event type and identifying value — Data action · Get Contact By ANI · 11,870 · 95%, Prompt played · “Please hold while I look up your account…”, Bot end · Account Number Capture, Call end · Hung up in IVR · 4%. The identifying value is the attribute that names the occurrence: the action for a data action, the menu for a menu, the bot for bot events, the queue for a transfer, the text for a prompt. Up to twenty rows are shown, and prompts are listed only when at least 5% of the callers at that point heard them. Click a row: a new card of that type, filtered to that value, is placed in the next Step column and connected from the selection (from the branch, if a branch was selected). The new card becomes the selection, so you can keep clicking down the journey one step at a time.

When nothing at all follows the selected point the list reads Nothing follows this point — normal for a Call end card, which is always the last event of a call.

Adding an event type and filtering it

The What calls start with / After … list offers what callers actually did. To place a card from the model instead — a Transfer to queue whatever the queue, a Wrap-up you will filter by code, a Flow outcome you want to narrow by both name and value — click the type in the Event types list. An unfiltered card is placed (in the next column, connected from the selection, if there is one). It counts every occurrence of its type and says so in amber: Unfiltered — every data action counts. Choose action on the right.

Filter it in the inspector. The Filters row has a chip per attribute; the branch attribute is marked ⑂, and a chip shows (n) once it has values ticked. Click a chip and the list beneath fills with the values that attribute takes, each with a count of callers; type in the Search box to narrow long lists. Tick one or more values. Filters on different attributes must all match; several values on one attribute mean “any of these”. The card retitles itself from its first filter, or use the Label field to name it yourself.

Connecting by hand

Cards added from the left pane are connected for you. To add a connector yourself press Connect → in a card’s footer (to connect from the whole card) or the → handle on one of its branches (to connect from that branch). The source turns amber and reads click target…; the canvas hint says so too. Click the heading of the target card. Pressing the same Connect → or → again cancels. Connecting a card to itself, or repeating a connector that already exists, does nothing; a card may have at most 20 connectors leaving it. Click a connector’s line to select it: the inspector shows its metrics, time limit and a Remove connector button. Removing a card with ✕ or Remove card removes its connectors with it. Use ‹ and › to move a card between Step columns; columns are purely visual — a connector’s direction is what decides the order in which events must happen.

Time constraints

Select a connector and set The next event must happen within: no limit (the default), 30 seconds, or 1, 2, 5, 10, 30 or 60 minutes. With a limit, a caller reaches the target by this connector only if the target event happened within that time of reaching the source, and Moved Forward is counted under the same rule. It answers questions such as “how many callers who were sent to Billing were answered within five minutes?” — Transfer to queue: Billing → Queue result: Answered with a 5-minute limit. Without a limit the only requirement is order: the target at or after the source.

Reading the numbers

• On a card: the large number is unique callers who reached it; the percentage beside it is their share of all traced callers in the window. The inspector adds median N s into the call — the median time from the start of the call to the moment the card was reached.
• On a branch: callers who reached the card by an occurrence whose branch value is this, and their share of the card. Branch counts sum to the card. The canvas shows the eight largest; the inspector shows them all as bars.
• On a connector: the headline number is callers who took this link next — their very next card on the canvas was the target — with the conversion rate beside it and N dropped below. The inspector adds Reached the target later by another route (Journey Management's looser “eventually reached” figure, kept separately so it can never inflate a link), Went elsewhere from here, Median time between and By flow version. When the connector leaves from a branch, Callers at source is the callers on that branch, not the whole card. See §8 for the exact definitions.
• Callers per day: a bar per day (in the organisation’s time zone) in the window for the selected card (shown when the window spans more than one day), so a change on one day stands out. Click it, or Open full chart, for the full-screen version: bars stacked by branch, the share of that day's callers on a right-hand axis, a 7-day rolling mean, weekends shaded, a hover read-out for any day, legend chips that hide or show a branch, summary tiles (total, share, mean per active day, peak day) and the table behind the chart.
• Callers (or Callers on this branch): lists up to 200 of the conversations behind the selection — the short conversation id linking to its transcript, when it started and how the call ended. The Excel export lists up to 5,000 per card.

Saving, loading, PDF and Excel

Save stores the journey — name, cards, filters, labels, connectors and time limits — for this flow, visible to everyone in your organisation. It is disabled while the canvas is empty. The first save gives the journey its identity and the PDF, Excel and Delete buttons appear. The amber unsaved badge shows whenever the definition differs from what is saved. To load a journey, pick it in the saved journeys selector; ＋ New journey starts an empty one. Delete asks for confirmation, removes the current journey and opens a new empty one.

Both exports are computed afresh from the saved definition and the current window when you press the button, so save first — an unsaved edit is not in the export.

Worked example: from the call arriving to the queue outcome

The flow identifies the caller by their number, falls back to a bot that captures the account number, and sends them to a queue. The journey to build is Call start → Data action “Get Contact By ANI” → Bot end “Account Number Capture” → Transfer to queue → Queue result → Call end.

1. Step 1 — Call start. On the empty canvas the left pane shows What calls start with. Click Call start · 0808 157 0123. A root card filtered to that number appears in Step 1 with, say, 12,480 callers · 100%, and is selected. (To cover every number dialled, add Call start from Event types instead and leave it unfiltered.)
2. Step 2 — the data action. The left pane now reads After Call start: 0808 157 0123. Click Data action · Get Contact By ANI. The card lands in Step 2 connected from Call start, and because Result is the branch attribute of a data action it shows two branches: Success · 9,240 · 74% and Failure · 3,230 · 26%. The connector reads 12,470 · 99.9% with 10 dropped — ten callers hung up before the action ran.
3. Step 3 — the bot, from the Failure branch only. Click the Failure row on the data-action card. The inspector shows 3,230 callers took “Failure” and the left pane After Data action … › Failure. Its first row is Bot end · Account Number Capture · 3,180 · 98%; click it. The Bot end card lands in Step 3, its connector leaving from the Failure branch, and shows its own branches — the bot’s verdict: succeeded, succeeded after retries, failed, caller hung up.
4. Step 4 — the queue. Select the Bot end card as a whole (click its heading) and click Transfer to queue · Customer Service in the After list. If callers go to several queues, click Transfer to queue in Event types instead, then tick every queue you want on the Queue chip in the inspector; one card, any of those queues. Transfer to queue has no branch.
5. Step 5 — the queue result. With the transfer card selected, click Queue result · Answered in the After list, then in the inspector untick nothing — or, to see all outcomes on one card, add Queue result from Event types with no filter: its branches are Answered, Abandoned in queue, Left to another flow and No further outcome, each with counts. Select the connector into it and set within 5 minutes to measure answers within service level.
6. Step 6 — Call end. Select the Queue result card and click Call end · Handled by agent, or add an unfiltered Call end to read the full split: Handled by agent, Hung up in queue, Hung up in IVR, Transferred out and the rest.
7. Compare the Success path. Back on the data-action card, select the Success branch and add its own Transfer to queue in Step 3 (use › to align it with whatever column you like), then connect it with Connect → to the same Queue result card. The Queue result card now has two incoming connectors — one per identification path — each with its own Moved Forward, Dropped Out and Conversion Rate.
8. Name the journey Identification to queue, press Save, then PDF for the picture and Excel for the figures. Widen the window in the header to see the same journey over a month.

7Event types reference

Each call is reduced to a time-ordered list of occurrences of these twenty types. Trace-derived types come from the flow-execution trace; the three Queue & agent types and the queue-related values of Call end come from the conversation’s analytics record and are placed after the last trace event. Bot flows contribute only the three Bot types — a bot’s inner prompts, menus and data actions are not emitted as separate events. The identifying attribute is the one the What happened next list names and filters on; the branch is the attribute shown as branches on the card, marked ⑂.

8The four metrics

These are the definitions the Builder computes, in the same terms Genesys Journey Management uses. Throughout, “reached” means the card’s reach rule in §3: anywhere in the call for a root card; at or after the source moment, on the connector’s branch if any and within its time limit if any, for a connected card.

Two supporting figures use the same reach moments: the card inspector’s median … into the call is the median, over the callers who reached the card, of the time from the first event of their call to the moment they reached it; the connector inspector’s Median time between is the median, over the callers who moved forward, of the time between reaching the source and reaching the target.

9One call: transcript and replay

Aggregates tell you where; a single call tells you why. Every card’s Callers list in the Builder links to the transcript of a conversation, and the transcript links on to its step-by-step replay.

The transcript

Titled What this caller heard and did, the transcript reads the stored trace as a script. The heading shows the conversation id and start time (UTC) and a disposition badge — agent, contained, queueAbandon, transferred or abandoned. Each line carries an offset from the start of the call in minutes and seconds, a speaker and the text:

A band marks each change of flow — pale blue for a flow, violet for a bot — so you can see where the caller crossed from the IVR into a bot and back. Lines are tinted by tone: green for success and accepted input, amber for no-input, no-match and warnings, red for failures. Hide system events folds the event lines away except transfers, disconnects, outcomes and flow boundaries, leaving the conversation itself. Step-by-step replay opens the raw trace view.

The step-by-step replay

The replay shows the same call from its raw execution trace, with an Analysis tab (each flow instance in turn with what it did) and a Diagram tab (the path drawn, with a legend), beneath a summary of the call. It uses the trace stored at harvest; for a conversation that was never harvested it fetches the trace live from Genesys, which works only while Genesys still holds it (about ten days) and only for flows that capture execution data — otherwise it says No flow execution trace for this conversation. If Genesys is still preparing the detail you will see Execution detail still preparing; reload in a moment. Step kinds the replay does not specially model are listed under Unrecognised step kinds and shown with their raw detail rather than dropped.

10Stored data, and deleting it

Stored data, in the header, shows everything the Journey Analyser holds on the server for the OAuth client you signed in with (its region and client id). It is the same for everyone who signs in with that client id, and anyone who can sign in with it can delete it. Nothing of any other client is shown or touched.

• Watched flows and their harvested data: for each watched flow, the days harvested, the calls, their journey events (including the parts inside common modules and bots) and raw traces, the harvest runs and saved journeys. Stop watching and delete removes the flow from the watch list and deletes its runs, coverage, settings, saved journeys and designs, and every harvested call no other watched flow needs. A call is stored once however many watched flows it passed through, so a call that also passed through another watched flow is kept, whole, for that flow; the table says how many are shared.
• Calls no watched flow needs: calls left over from a flow that was unwatched earlier. They can be deleted on their own.
• Everything else: the number of records of each kind held for this client, including the reference data (names of queues, flows, data actions and data tables, and the prompt library).
• Signed-in sessions: each session signed in with this client, which holds the client id, the client secret (encrypted) and the current access token. Sign out the other sessions ends all but yours. Scheduled harvests run only while at least one session for the client exists.
• Delete everything held for this client: type the organisation name to confirm. Every row for this client is deleted, every session signed in with it is ended (including yours), and you are signed out.

Deleting is refused while a harvest of that flow (or, for everything, any harvest for the client) is running, or while missing flow designs are being fetched: stop it or let it finish first. Deleted content is overwritten, so no copy of it remains. Deletion cannot be undone.

11Troubleshooting

The Builder header says 0 traced callers, and every event type is greyed out

There are no traced conversations for this flow in the window. Check the dates in the header, then Home → Recent harvests for a run covering them. If the run shows conversations but few traced, the calls’ execution data had aged out before harvest (Genesys keeps it about ten days) or the flow does not have capture execution data switched on. Harvest closer to the day, and keep the daily schedule on.

A card shows 0 callers

For a root card, no caller in the window has an occurrence matching its filters — check the value list in the inspector (it shows the values that exist, with counts). For a connected card, remember the order rule: the event must happen at or after the source moment, on the source’s selected branch if the connector leaves from one, and within the time limit if set. An event that happens before the source — a Call start connected after a Menu, say — can never be reached. Check the connector direction, remove any time limit to test, and look at After … for the source card to see what actually follows it.

The values list is empty “after the previous card”

The inspector restricts values to callers who reached the previous card and its branch. An empty list means none of those callers have this event type after that point. Either the type is wrong for that position, or the connector leaves from a branch on which nobody continues. Select the previous card or branch and read its After … list; it shows what those callers did next.

A card is amber and says “Unfiltered”

The card counts every occurrence of its type. That is sometimes intended (an unfiltered Queue result shows all outcomes as branches); if not, pick an attribute chip and tick values.

Outcomes are named simply “Outcome”, or data actions have generic names

The flow design or catalogue was not available when the traces were harvested. Open the run on Home and press Re-derive events; if a permission was missing, sign out and back in first. The Builder shows the new names on its next recalculation.

Queue result, Agent handled and Wrap-up are greyed out, and Call end shows “Sent to queue (no queue data)”

These come from the conversation’s analytics record, which is captured for harvests made from 8 September 2026 onwards. Conversations harvested before that carry no queue result, agent or wrap-up detail, and Re-derive events cannot add it because it is not in the trace. Journeys over windows harvested since that date have all four types.

Moved Forward on the connectors leaving a card adds up to more than the card’s callers

Expected: a caller who reached two different targets moved forward on both connectors. Each connector’s Dropped Out is relative to its own source population.

“A card can have up to 20 connections”

The fan-out limit. Remove a connector, or split the card into two.

Save is disabled

The canvas is empty, or a save is already in progress. A journey needs at least one card.

The PDF or Excel does not reflect my latest change

Exports are built from the saved definition. Press Save first — the amber unsaved badge tells you when it is needed.

“No transcript” / “No trace stored for this conversation”

The conversation was enumerated but its trace was never fetched (it is among the run’s “without a trace”). The replay page will still try Genesys live; if the data has aged out there is nothing to show.

“Missing scope: …” at sign-in or in an error

Add the named permission to the OAuth client’s role, sign out and back in, then harvest or re-derive. See §2.

12Glossary

Attribute

A named value on every occurrence of an event type; what filters and value lists work on.

Branch

The value of a card’s branch attribute, shown as a row on the card with its callers; a connector may leave from one. Marked ⑂ in the inspector.

Branch attribute

The one attribute an event type declares as splitting what happened next (Result, Choice, Verdict, Value, Exit reason, Kind, Wrap-up code, How).

Callers at source

The population a connector’s metrics are relative to: callers who reached the source card, or its selected branch.

Card

An event type with attribute filters, placed in a Step column. Up to 50 per journey.

Connected card

A card with at least one incoming connector; reached only after a source, in order.

Connector

An arrow from a card or branch to a card, carrying the four metrics and an optional time constraint. Up to 20 leaving a card.

Conversion Rate

Moved Forward ÷ Callers at source.

Customers / callers

Unique conversations that reached a card.

Disposition

The badge on a transcript: agent, contained, queueAbandon, transferred or abandoned.

Dropped Out

Callers at source minus Moved Forward.

Event type

One of the twenty kinds of journey event (§6).

Harvest

A run that enumerates a window’s conversations for a flow and fetches the traces and records not already stored.

Identifying attribute

The attribute that names an occurrence in the What happened next list and becomes the new card’s filter (Action, Menu, Bot, Queue, Text…).

Inspector

The right-hand pane: filters, branches, trend and callers for a card; metrics and time limit for a connector.

Journey

A named, saved set of cards and connectors for one flow. Figures are computed for whatever window is open.

Journey event

One occurrence of an event type in one call, with its attributes and time.

Moved Forward

Callers at source who reached the target at or after the source moment, within the time limit if set.

Population

The traced callers in the window; the denominator for “of all” shares.

Re-derive events

Rebuilding a run’s journey events from the stored raw traces with refreshed designs and catalogues, without fetching traces again.

Root card

A card with no incoming connector; reached by any matching occurrence anywhere in the call.

Step

A column on the canvas. Visual only; connectors define order.

Time constraint

On a connector: the target must occur within 30 seconds to 60 minutes of the source.

Traced caller

A conversation in the window with a stored execution trace.

Transcript

One call read as a script: what the flow said, what the bot said, what the caller did.

Watched flow

A flow added on Home; the unit of harvesting, scheduling and journeys.

What happened next

The left-pane list of event types and values that followed the selected card or branch, ranked by callers; on an empty canvas, what calls start with.

Window

A from → to range of whole days: UTC days for a harvest; days in the organisation’s time zone for Findings, Stories and the Journey Builder.