Is it possible to pass the full json payload from the conversation:transcript:created webhook directly into a servicenow incident record without hitting the 8kb limit on the description field? we are trying to automate ticket creation for digital channels (webchat and sms) and the current setup using the out-of-box data actions is stripping out the agent notes and customer metadata because of the way the payload is flattened.
we have a custom rest message integration in servicenow that expects the transcript in a specific nested json format. when we use the genesys cloud webhook to hit our servicenow rest endpoint, we are getting a 400 bad request error from servicenow because the payload size exceeds the default limit for the sys_attachment table upload process we are trying to mimic. the error message in the servicenow logs says “size exceeds maximum allowed”.
i have checked the genesys cloud documentation on webhooks and it mentions that you can transform the payload using a lambda function or a custom script, but we are not using any middleware. we are sending it straight from genesys to servicenow. the webhook is configured in the routing->webhooks section and is triggered by the conversation:transcript:created event. the payload includes the conversation id, participant id, and the transcript text.
the problem is that the transcript text can be quite long, especially for complex webchat sessions. we need to preserve the entire transcript in servicenow for compliance reasons. is there a way to split the payload or use a different endpoint in servicenow that accepts larger payloads? we are using servicenow version washington dc and genesys cloud version 2023-12.
any help would be appreciated. we are currently manually copying the transcript from genesys to servicenow which is not sustainable for our volume. we are based in london and working on a global deployment.
It depends, but generally… the 8kb limit on the description field is a hard constraint in the servicenow incident table, not a genesys cloud limitation, so flattening the entire conversation payload into that single field will always result in data truncation. the webhook payload from conversation:transcript:created contains nested objects for messages, metadata, and interaction context that exceed this limit quickly when serialized as a single string.
instead of trying to force the full json into the description, you should map the transcript data to a custom table or a related list in servicenow. a common approach is to create a custom table like u_transcript_data linked to the incident via a reference field. then, in the genesys cloud data action, use a transform step to extract only the critical summary fields (like interaction id, start time, and agent id) for the main incident record, and send the full transcript object as a separate payload to an endpoint that inserts records into that custom table.
if you must keep it within the standard incident structure, consider using a base64 encoded string of the json and storing it in a large text field (like work_notes or a custom long text field) rather than the description. however, this makes it unreadable in the ui without a script include to decode it.
here is a sample data action configuration snippet for the transform step:
{
"incident": {
"short_description": "{{interaction.interaction_id}} - Digital Channel Transcript",
"description": "See related transcript table for full details.",
"u_transcript_ref": "{{interaction.interaction_id}}"
},
"transcript_payload": {
"messages": "{{json.stringify(interaction.messages)}}",
"metadata": "{{json.stringify(interaction.metadata)}}"
}
}
ensure your servicenow rest message is configured to handle this split payload. also, check if your carrier or digital channel provider has any specific metadata quirks that might cause null values in the initial export, as this can affect the payload size and structure.
TL;DR: Split payload. Map nested JSON to separate ServiceNow fields. Use Terraform to manage the integration.
It depends, but generally… pushing raw JSON blobs into ServiceNow description fields is an anti-pattern. The 8kb limit is a database schema constraint, not a Genesys Cloud API limit. Flattening nested objects like messages or metadata into a single string causes truncation and breaks parsing.
The solution is to map specific transcript attributes to dedicated ServiceNow fields. For example, map customer_metadata to a custom u_customer_id field and agent_notes to a u_agent_comments field. This avoids the 8kb limit and keeps data queryable.
Here is how to structure the integration using the Genesys Cloud Terraform provider to manage the webhook configuration. This ensures the payload transformation is version-controlled and reproducible across environments.
resource "genesyscloud_routing_integration" "servicenow" {
name = "ServiceNow Incident Creator"
description = "Webhook integration for transcript mapping"
type = "webhook"
enabled = true
config {
endpoint_url = "https://your-instance.service-now.com/api/now/table/incident"
method = "POST"
# Define header mapping for authentication
headers = {
"Authorization" = "Basic ${base64encode(var.sn_user}:${var.sn_pass}"
"Content-Type" = "application/json"
}
}
# Map specific transcript fields to ServiceNow fields
# Avoid sending the full payload. Select only necessary attributes.
body_template = jsonencode({
short_description = "{{interaction.subject}}"
description = "{{conversation_id}}: {{summary}}" # Keep description short
u_customer_id = "{{customer_metadata.id}}"
u_agent_notes = "{{agent_notes}}"
u_channel_type = "{{interaction.channel_type}}"
})
}
Using jsonencode with specific attribute references prevents the payload from being flattened into a single massive string. This approach aligns with CX as Code best practices. The Terraform provider handles the JSON structure validation during plan time, reducing runtime errors.
For complex metadata that exceeds single-field limits, consider creating a related table in ServiceNow and linking it via the incident number. This requires a two-step webhook process or a middleware layer, but it preserves data integrity. Direct mapping to existing incident fields is the most reliable method for standard use cases.