Thank you Kaio for answering in such detail and for sharing your approach.
That makes a lot of sense, and it is really helpful to see how you are handling duplicate prevention through the ANI/contact lookup together with the open ticket check, rather than asking the caller for an existing ticket number.
I also like the way you have kept the IVR experience simple and only reused the ticket when there is exactly one open case, while letting the agent handle the context if there are multiple.
In our case we are using BMC Helix rather than Salesforce, and ANI would probably not be reliable enough for us because the phone number data is often not up to date. We are more likely to rely on the customer ID collected in IVR and use that as the primary lookup key.
Thanks again for sharing the detail.
Original Message:
Sent: 04-05-2026 08:18
From: Kaio Oliveira
Subject: High-level design check for post-answer ticket assignment using trigger/workflow
Phaneendra
In our case the identification is primarily done using the ANI , rather than asking the caller to provide an existing ticket number.
When the call arrives in the inbound flow, we use the ANI to perform a lookup in Salesforce to check if the phone number is already associated with an existing contact.
If the phone number is not registered, we automatically create a new contact record using the phone number only, and the agent later completes the remaining customer details during the interaction.
From there, the ticket logic follows the business rules defined by the customer:
- No existing contact → create the contact and create a new ticket.
- Contact exists but no open ticket → create a new ticket.
- Contact has exactly one open ticket → we surface that ticket to the agent so they can continue working on the same request.
- Contact has more than one open ticket → a new ticket is created.
In this particular implementation, the client chose not to ask the caller to select an existing ticket in the IVR (for example using a collect input step). Their preference was to keep the IVR experience simple and let the agent handle the ticket context if multiple requests exist.
So the ANI lookup combined with the ticket status check ended up being the simplest and most reliable way to control duplicate ticket creation while still keeping the caller experience straightforward.
------------------------------
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 23:17
From: Phaneendra Avatapalli
Subject: High-level design check for post-answer ticket assignment using trigger/workflow
Hi Kaio,
Thanks very much for confirming this and for sharing the detail that is really helpful.
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.
------------------------------
Phaneendra
Technical Solutions Consultant
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
------------------------------