Workflows and routing
Most problems on this page are caused by configuration, not by a fault in Graia CCaaS, and a customer administrator can fix them in the portal. Each section names who can fix the problem. Where only Graia support can act, the section says so.
Before you change a customer-facing workflow, clone it and test your change on the copy first. Remember that workflow changes only affect conversations that start after you save (see Workflow changes don't affect waiting conversations).
Announcement upload fails or the old prompt still plays
Seen as an error related to file upload or validation, a file that can't be saved in a workflow node, a converted file that doesn't play, or a new prompt that uploads fine while callers still hear the old one.
Who can fix it: customer administrator.
The audio file is in the wrong format
This is by far the most common cause, including when the upload seems to succeed but callers still hear the old prompt. Depending on your tenant's configuration, Graia CCaaS accepts either:
- WAV encoded as A-law, 8 kHz, mono, or
- MP3.
A WAV file with another encoding, such as 16-bit PCM or stereo, isn't accepted, even though it's a WAV file. A file that was only renamed to .wav isn't converted.
Fix: convert the file with an audio editor as described in Audio files support, listen to it, and upload it again. If you don't know which format your tenant uses, ask Graia support.
An announcement bundle file is missing or misnamed
For queue position, callback offer and expected wait time announcements (Voice › Announcements), the file names are fixed and case sensitive. If a required file is missing or misnamed, Create shows an error related to the bundle's required files.
Fix: check the names against Announcements. For a callback offer bundle, offer.wav and confirmation.wav are both mandatory, so upload them together. Look out for doubled extensions such as offer.wav.wav.
You changed the wording of a greeting
An uploaded audio file is a recording; changing the text means recording a new file. Upload it in every Announcement node that plays that greeting, then save the workflow. If the node uses text-to-speech, edit the text instead.
Out-of-hours behaviour is wrong
Seen as callers hearing the open greeting after closing time, calls or chats going to agents outside business hours, calls getting the closed announcement during business hours, or a holiday that isn't applied.
Who can fix it: customer administrator.
Opening hours, holidays and exceptions are set per channel, together with the channel's time zone: Voice › Channels for voice, and the Business hours step of each chat, email and social channel. The workflow then checks them with the Check opening hours node, which has three outputs: Open, Closed and Holiday.
Check these in order:
- The workflow has no Check opening hours node. Without it, the channel's opening hours are never evaluated and every call goes to the queue. Add a Check opening hours node near the start of the workflow and connect
ClosedandHolidayto your closed announcement or redirect. - The channel time zone is wrong. A new channel can be left on UTC, which doesn't follow daylight saving, so the channel opens or closes an hour off after the clock change. Set the channel's time zone to your region (for example Europe/London). Region time zones switch to and from daylight saving automatically; the portal doesn't show the change. Then check the opening hours again.
- The hours for one weekday were changed. Opening hours are set per weekday, so a change to one day is easy to miss. Check every weekday on the channel. To find out who changed them and when, open Administration › Audit Logs and look for Channel > BusinessHoursConfiguration entries (see Audit logs).
- The holiday or exception isn't on every channel. Holidays and exceptions are per channel. When you add a holiday or temporary holiday hours, update every channel that should close, including WhatsApp, Facebook, Instagram and other social channels. A channel you miss keeps its normal hours. Equally, check that no channel has today's date set as a holiday by mistake.
- You've just changed the hours. Changes to opening hours take up to 10 minutes to apply. Wait 10 minutes and test again before you change anything else.
:::tip Chats that arrive late in the flow A chat workflow checks opening hours only where the Check opening hours node is. If customers spend several minutes in a bot or a menu, a chat that passed the check just before closing time can still reach the queue after closing. Add a second Check opening hours node right before the Queue node. :::
If you need a schedule that differs from the channel's opening hours inside one workflow, use Calendar events with a Switch node, or a Time-based redirect node, instead of creating extra channels.
Calls that arrive on a holiday are still received and appear in reports, flagged as holiday calls, even though the workflow ends them. That's expected.
Callers hear a busy tone or the call never connects
Who can fix it: customer administrator, unless stated otherwise.
| What you see | Likely cause | Fix |
|---|---|---|
| Every call to the number gets a busy tone | No workflow is assigned to the voice channel. | Assign a workflow to the channel in Voice › Channels. |
| Calls sometimes end without a message at busy times | The queue's Max Queue Size was reached and the Size Limit Reached output ends the call. | Raise Max Queue Size, and connect Size Limit Reached to an announcement (and a redirect or voicemail) before the call ends. |
A number forwarded by your carrier gets a busy tone, 486 Busy Here or a not-available message | The called number in the forwarded call isn't the channel's number, so Graia CCaaS doesn't recognise it. | Add the number as an alternative number on the channel, or ask your carrier to send the channel number. |
For SIP response codes and number format problems between your carrier or SBC and Graia CCaaS, see Telephony and SBC.
Calls stay in the queue or end after the greeting when no one can take them
Seen as callers waiting in the queue instead of hearing the "no agents" announcement, or after-hours calls that should be redirected being disconnected after the greeting.
Who can fix it: customer administrator.
Before a call enters a queue, the Queue node checks these outputs in this order (see Queue entry logic):
| Output | Used when |
|---|---|
No Agent Logged In | No agent at all is logged in across the tenant. |
No Staffed Agent Logged In | Agents are logged in, but none of them has the queue's required attribute and free work item capacity. |
No available staffed agent | Agents with the right attribute are logged in, but none of them is available. |
Size Limit Reached | The queue is at its Max Queue Size. |
EWT Limit Reached | The estimated wait time is above the queue's limit. |
The common mistake is to connect only No Agent Logged In. In a tenant with several teams, someone is almost always logged in, so that output rarely fires and the caller goes to the queue.
Fix: connect your announcement, redirect or voicemail to No Staffed Agent Logged In and No available staffed agent as well. An output you leave unconnected ends the call. To decide before the caller goes through a long menu, use a Check queue state node, which has the same outputs.
Announcement is cut off when the call is answered
Seen as a second announcement that stops halfway when an agent becomes free.
Who can fix it: customer administrator.
Everything in the queue treatment stops as soon as an agent is available, because the queue treatment is only for waiting. An announcement in the queue treatment is therefore cut off whenever an agent frees up while it plays.
Fix: move any message the caller must hear in full (a greeting, a GDPR notice) into an Announcement node before the Queue node. Keep music, position and comfort messages in the queue treatment.
Two more queue treatment points to check:
- Steps don't wait for the audio to finish. Each step moves on after the time you set, so set each step's time longer than its file.
- Long Announcement nodes delay queuing. A call enters the queue only after the nodes before it finish, so a long welcome message (for example one that sounds like queue music) makes callers wait while agents are idle. Keep announcements before the queue short.
A callback offer isn't played if the caller already has a callback request, or when the call is already ringing at an agent.
Forwarded or redirected calls fail
Who can fix it: customer administrator; your carrier for caller ID rules.
Both parties hear silence after a redirect
A call redirected to an external number right at the start of the workflow, before it was answered, can connect without audio.
Fix: put an Announcement node before the Redirect to phone node, so the call is answered first, then redirect.
The redirect is rejected by the carrier
By default, a Redirect to phone call presents the customer's number in the FROM header and the channel number in the P-Asserted-Identity header. Some carriers reject calls that present a number they don't own.
Fix: turn on Use channel number as dialing number (Administration › Configuration › Voice) so the channel number goes in the FROM header, or ask your carrier to accept the original caller ID. This setting is tenant-wide and also changes the number shown on agent legs and transfers; check the table on that page before you change it. To pass the caller's number on as well, add it in a custom SIP header on the Redirect to phone node.
For agents who need to transfer to a few fixed external numbers, add them to a contact directory linked to the agent workspace.
Customers still get a satisfaction survey
Seen as survey calls or survey emails that keep coming after you removed the survey.
Who can fix it: customer administrator.
The survey is usually connected to the Agent Disconnected output of a Queue node. A workflow often has several queues, and the survey (Customer satisfaction node, or a Send email node) is still connected in one of them.
Fix: check the Agent Disconnected output of every Queue node in the workflow. Remove the survey nodes, connect the output to End (or Transfer to channel), and save. Also check that you edited the workflow the channel actually uses.
Calls aren't distributed evenly
Seen as some agents getting most calls while others sit idle.
Who can fix it: customer administrator or supervisor.
Routing prefers the agent with the higher attribute level for the queue's required attribute. Idle time only decides between agents with the same level. If levels differ, the higher-level agents get calls first, even if others have been idle longer.
Fix: open Agents › Agents (or the Attributes menu) and compare the levels of the queue's attribute across agents. Set equal levels for even distribution. Use the historical tasks report to compare how many tasks each agent received.
Routing uses the agent's state in the agent application only. Status in Microsoft Teams or a CRM doesn't count.
Calls or emails don't reach available agents
Seen as items waiting in the queue, or showing on the wallboard, while agents show Available.
Who can fix it: customer administrator. Only Graia support can remove a call that is stuck in a queue.
Check these in order:
- Required attribute. The queue's Attribute Requirements must match an attribute that is assigned and enabled on the agents. Two similarly named attributes (for example with swapped word order) are a common trap: the agent and the queue use different ones. Keep one and use it in both places.
- Business units. An agent only gets conversations from channels whose business unit is assigned to them (see Business units and routing). Check that the channel, its workflow and the agents use the same business unit. Having no business unit counts as a business unit of its own, so a channel without one doesn't reach agents who only have named units.
- Agents switched their business units off. If Allow agents to select business units is on, agents can deselect units and then receive nothing from them. Turn it off in Administration › Configuration › Agents if agents shouldn't choose.
- Work item limits. Default work item thresholds set how many tasks an agent handles at once, overall and per media type. With an overall limit of 1, an agent on a call gets no emails. Raise the limits, or set Override work item thresholds on individual agents.
- Preferred agent. An email that returns to the queue can be tagged for the agent who had it. Without a Preferred agent timeout on the queue, it waits for that agent indefinitely. Set the timeout on the Queue node.
- Agents on break. No task of any kind, including callbacks, is offered to an agent on a break. A task waits while the only qualified agent is on a break and is delivered when they become available.
A queue keeps loading
A queue that keeps loading instead of showing its name or counts has one of these causes:
- The queue was deleted. Remove it from wherever it's still referenced, such as the team's Performance Dashboard Queues.
- The queue was just created. A background process sets up new queues. Wait for it to run, then check again.
- The business units don't match. The channel, its workflow and the agents must use the same business unit (see step 2 above).
If none of these explains it, a single stuck call can block a queue. See Agent calls and connection and contact Graia support with the time and the queue.
After you delete a workflow or queue, remove it from each team's Performance Dashboard Queues (see Teams). Otherwise agents keep seeing tasks they can't pick up. Agents then log out and back in.
Transfer fails because no staffed agent is available
The transfer fails with an error that no staffed agent is available.
Who can fix it: customer administrator.
The target queue has no logged-in, available agent who has the queue's required attribute and the right business unit. Often only one agent qualifies, and they're busy.
Fix: give the attribute (and business unit) to more agents. If transferred calls come back to the original queue, check the target workflow: its No Staffed Agent Logged In and No available staffed agent outputs may be connected back to the original channel.
Estimated wait time announcements are inaccurate
The estimated wait time is a statistic. Graia CCaaS calculates it from queue and agent data of the past 10 minutes (see Expected wait time). If more agents become free than in the last 10 minutes, callers are answered sooner than announced, and the other way round. This isn't a fault.
Queue position can also change, because conversations in higher-priority or emergency queues are served first.
Callbacks are served before waiting calls (or the other way round)
With SLA-based routing (Administration › Configuration › Miscellaneous › Conversation sorting mode), the conversation closest to or past its SLA target goes first. A lower SLA threshold reaches 100% sooner, so it gets priority sooner.
Who can fix it: customer administrator.
Fix: to give inbound calls priority, set the callback campaign's SLA Threshold (in the campaign's Queue properties tab) higher than the SLA Threshold Time of the workflow's Queue node. Lower it to favour callbacks.
Workflow changes don't affect waiting conversations
A saved workflow change applies to conversations that start after you save. Conversations already in a queue keep the routing they had: for example, emails routed automatically before you switched a queue to manual routing are still assigned automatically. Wait until those items are handled.
A queue's routing mode (automatic, manual or hybrid) can't be changed after the queue is created. Delete the queue and create it again with the new mode.
The Clone button is greyed out
Save the workflow first, then clone it. The designer can't save while there are validation errors (warning triangle on a node), so fix those first. When you clone, select a business unit for the copy if asked.
Related
Was this page helpful?