Hi all, apologies if this is a rather elementary question, but we’re running into a strange issue with our predictive dialing campaigns and I’m hoping someone can point me in the right direction. The script seems to hang after the call completes, specifically during the after-call work step. Agents report they can’t proceed to the next task - it’s like the system is waiting for something.
It’s intermittent, which makes it tricky. I’ve checked the historical reporting and it appears to correlate with a higher call volume - maybe a resource contention issue? We had a similar problem with Data Actions a while back, and the INDEX_SCHEMA_DRIFT error was the culprit then - it was a mismatch between the payload and the profile schema. This feels a little different though.
The Architect flow is fairly standard - Predictive Dialer → Transfer → After-Call Work. We’re using the standard after-call work form, nothing custom. The issue isn’t consistently reproducible, so gathering detailed logs is proving difficult. I’ve got some console output from the agent desktop, but it’s… incomplete.
Here’s what we’ve tried so far:
Verified the script is published and active.
Confirmed the after-call work form is associated with the campaign.
Increased the campaign concurrency slightly - no change.
Reviewed the Agent Desktop version - v27.0.77.37606
Checked the campaign’s dialer strategy - we’re using standard predictive dialing.
The logs show a ‘ScriptCompleted’ event firing, but then… nothing. No ‘AfterCallWorkStarted’ event, no errors. It just sits there. It’s frustrating because it appears to be a common issue, but tracking down the root cause is difficult. If it helps, we are on Berlin time.
Any thoughts on what might be causing this? It’s impacting agent productivity, and the queue’s getting backlogged.
That’s right - intermittent issues are the worst. We’ve seen similar things with after-call work scripts.
The problem is usually the data action itself - it’s either timing out or getting stuck on a network issue.
You can check the data action logs directly in the Genesys Cloud UI - look for errors or long execution times. It’s not always obvious, but sometimes it’s a simple timeout.
If it’s a timeout, you can try increasing the timeout value in the data action configuration.
Here’s an example of how to adjust the timeout using Terraform:
resource "genesyscloud_data_action" "example" {
name = "example-data-action"
action_type = "HTTP"
url = "https://your-endpoint.com"
timeout_seconds = 60 #Increased from default
}
For what it’s worth, 60 seconds is usually enough, but if your endpoint is slow, you might need to go higher.
Also, is the data action doing any kind of database write or other operation that could be causing a lock? That can cause hangs too.
Can you confirm if the script is failing for all agents or just some? That might help narrow down the problem.
That’s right, and also - the DATA ACTIONS are often the culprit. Specifically, the POST requests.
The problem isn’t usually the timeout VALUE, it’s the DATA ACTION’s configuration of the HTTP client itself. It defaults to a very short connection pool size - one.
One connection means each POST request blocks until the backend service responds. Intermittent hangs suggest the backend is slow-to-respond, and the DATA ACTION isn’t handling the blocking gracefully.
Fix: Increase the CONNECTION POOL SIZE in the DATA ACTION configuration. It’s buried deep in the ADVANCED settings.
Five should be sufficient. Monitor the DATA ACTION logs after the change. Look for “connection refused” errors, which indicates the backend service is overloaded.
fwiw - we’ve seen this surface more frequently with deployments using Lambda functions for the backend service, so if that applies, double-check the Lambda’s allocated memory and concurrency limits.