So I’m seeing a very odd bug with our Data Action invoking the ServiceNow REST API for automated ticket creation. The flow consistently throws a 504 Gateway Timeout despite the payload matching the schema in Genesys Docs. Verified the SNOW endpoint is reachable via curl, so this looks like an internal timeout configuration issue.
2 Likes
This happens because the default timeout configuration for outbound HTTP requests within Genesys Cloud Architect data actions, which is significantly lower than the processing time required by ServiceNow instances under load. The 504 Gateway Timeout indicates that the Genesys platform did not receive a response within the allotted window, typically three seconds for synchronous calls. To resolve this, navigate to the Data Action configuration in Architect and locate the ‘Timeout’ field. Increase this value to 10 or 15 seconds to accommodate the latency introduced by ServiceNow’s orchestration engine. It is also advisable to verify the ServiceNow endpoint performance using the conversation detail views to ensure the delay is not stemming from server-side queuing rather than network issues. Adjusting the timeout allows the platform to wait for the full lifecycle of the ticket creation process before returning control to the flow. This adjustment aligns with best practices for integrating with external CRM systems that require substantial processing time for record creation.
2 Likes
Pretty sure the timeout field in HCL is timeout_ms. Setting it to 30000 usually resolves 504s for SNOW.
genesyscloud_data_action {
...
timeout_ms = 30000
}
Verify the value in the deployed config. The default is often too low for ticket creation payloads.
i’m not the OP, but i can confirm the timeout_ms fix is solid. that said, if you’re seeing intermittent 504s even after bumping the timeout, it’s usually a DNS resolution lag on the Genesys side rather than the payload size.
i’ve run into this with high-throughput services calling external APIs. the platform’s internal resolver sometimes caches bad records or takes a beat to resolve new CNAMEs.
if the timeout tweak doesn’t fully stabilize it, try hitting the ServiceNow IP directly in the URL instead of the hostname. it’s a bit ugly but bypasses the resolver entirely.
// example of what i do in go to test this theory locally
// replace the hostname with the resolved ip
req, _ := http.NewRequest("POST", "https://<SNOW_IP>/api/now/table/incident", payload)
also, make sure you’re not hitting rate limits on the SNOW side. a 429 can sometimes manifest as a timeout if the platform waits for a response that never comes. check your SNOW logs for rejected connections.
just a heads up, hardcoding IPs is a maintenance nightmare if SNOW rotates them. maybe use a health check endpoint to verify resolution before the main call.
the timeout_ms adjustment is the standard fix, but i’ve seen cases where the timeout is set correctly and it still fails because the request payload exceeds the internal buffer limits for data actions.
check the size of your JSON body. if you’re pushing full incident records with rich text fields, it can choke the outbound connector. try stripping non-essential fields or using a chunked approach if the payload is massive.
also, verify the endpoint isn’t doing any synchronous validation that takes longer than your new timeout. if SNOW is querying LDAP or other downstream systems synchronously before returning 201, you might need to increase the timeout even further or switch to an asynchronous pattern.
genesyscloud_data_action {
name = "Create ServiceNow Incident"
timeout_ms = 45000 # Increased from 30s to handle downstream LDAP checks
# Ensure Content-Type is explicitly set
headers = {
"Content-Type" = "application/json"
"Accept" = "application/json"
}
}
i usually wrap these calls in a retry block in Architect just in case the gateway drops it on the first attempt. it’s annoying to debug, but it saves the flow from failing completely.
1 Like