It is reassuring to hear you have implemented a very similar pattern successfully in production, especially using participant data as the bridge between Architect and Workflows.
In our case, we are not using Salesforce our ticketing platform is BMC Helix, and I have been building the customer/ticket integration on the BMC side.
Just to clarify on the duplicate ticket part are you checking for an existing open case based on the customer identifier and case status/category, rather than asking the caller for an existing request number?
I was curious how you approached that part in practice, as we would typically have the customer/staff ID from IVR, but not necessarily an existing ticket/request number.
Original Message:
Sent: 04-04-2026 22:57
From: Kaio Oliveira
Subject: High-level design check for post-answer ticket assignment using trigger/workflow
Hi Phaneendra
I have implemented a similar pattern in production using Genesys Cloud integrated with Salesforce, and the architecture you described aligns very well with what we used.
In our case, the case (ticket) creation happens directly in the Architect inbound flow. During the IVR we collect the customer identifier and perform a lookup in Salesforce. The flow also checks if there is already an open case to prevent duplicate ticket creation.
We also apply some routing logic at this stage. For example, we verify if the customer is categorized or assigned to a specific account manager. If so, the call can be routed to a queue using Preferred Agent routing, so the interaction is prioritized for the agent responsible for that customer.
Important values such as the case number and request identifiers are stored in participant data, which allows them to persist throughout the interaction lifecycle.
For the post-answer logic, we rely on Workflows triggered by conversation events. This allows us to read the stored participant data and update the ticket depending on the interaction outcome. For example:
- Updating the case if the interaction is abandoned while still in IVR or queue.
- Updating ownership or interaction metadata when the call reaches an agent.
- Handling other lifecycle scenarios like caller drop-offs or flow exits.
Using participant data as the bridge between Architect (interaction orchestration) and Workflows (event-driven processing) has proven to be a clean and scalable production pattern for us.
------------------------------
Kaio Oliveira
GCP - GCQM - GCS - GCA - GCD - GCO - GPE & GPR - GCWM
PS.: I apologize if there are any mistakes in my English; my primary language is Portuguese-Br.
Original Message:
Sent: 04-04-2026 22:07
From: Phaneendra Avatapalli
Subject: High-level design check for post-answer ticket assignment using trigger/workflow
Hi everyone,
We are working on a high-level design for end-to-end ticket creation from a Genesys inbound voice flow and wanted to check whether others have implemented something similar in production.
Our current approach is:
- collect the customer/staff ID in the inbound flow
- perform the lookup and create the ticket from the inbound flow
- store key values such as ticket number, request key, and other ticket-related values in participant data
- after answer, use a trigger/workflow to identify the actual answering agent
- read the stored values back in the workflow and then assign/update the ticket there
- start with one queue first before expanding further
For the post-answer step, we are looking at using the trigger topic:
v2.details.events.conversation.{id}.user.start
Then in the workflow:
- use the conversationId from the trigger
- get conversation data / participant data
- confirm the queue
- continue with ticket assignment/update logic
The main reason for this design is that we do not know the answering agent while the call is still in IVR or queue, so the post-answer workflow seems like the cleanest place to do the final assignment.
Has anyone implemented a similar pattern for ticket / CRM / ITSM creation from Genesys Cloud, especially where the ticket needs to be assigned to the actual answering agent after the interaction is connected?
At a high level, does this sound like the right architecture, or is there a cleaner production pattern others have used?
Thanks in advance
#Architect #Triggers #Workflows #ParticipantData #InboundFlows #Queues #API #Integrations #Automation
#ArchitectandDesign
------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------