I previously raised a concern about this issue here, but it remains unresolved. Providing further details with more explanation now in the hope of facilitating a resolution.
I've established a workflow, utilizing it as a target to activate a process automation related to the topic v2.detail.events.conversation.{id}.acw. The purpose is to identify when an agent exits the conversation, enabling me to prompt the end user with rating questions about the agent's performance.
The issue arises when the same conversation is reopened (if a user with the same ID wishes to speak with the agent again).
Upon reopening, the configured workflow is triggered immediately. This is unexpected, as the workflow should ideally only be triggered when the agent closes the conversation, not upon every reopening.
Additionally, upon closing the conversation, the workflow is triggered twice. Subsequently, if the same conversation is reopened and closed for the third time, the workflow is triggered three times, and this pattern continues.
I'd like to understand if these occurrences are expected behaviors. If they are, kindly inform me accordingly. If not, please guide me on whether there might be any errors in the processes I've followed.
Triggers are completely stateless, and operate on each event message independently. A single conversation that reaches a specific lifecycle point (which thereby generates an analytics detail event for that milestone) multiple times looks no different to the trigger than multiple conversations reaching that milestone once. For certain topics, like the attributes topic, there are opportunities to "mark" the conversation as having been already evaluated (using an attribute to say something like "automation_processed": true), which can be leveraged in the match criteria to tell the trigger to ignore that message; but in order to do this, the information needs to be on the event message/in the event schema so the trigger is able to evaluate it as part of the match criteria.
Depending on what other triggers are configured within the org, it is certainly possible, and may even be expected, that a workflow executes multiple times for a single conversation. It's also important to note that triggers are designed to process "at least once", in order to make themselves as resilient as possible ("exactly once" is a much harder feat from an engineering perspective, and is generally less fault tolerant, which isn't really great for cloud architecture, which relies on distributed workloads that are run independent of the rest of the system). In most scenarios, a trigger will only fire once; if you're seeing duplicate processing consistently, then it's more likely there are either duplicate source events, or multiple triggers that are matching.
I get that none of this directly resolves your concern, but hopefully the background information helps to solution things from your end (as I certainly don't have all the context needed to make more specific recommendations at this time).
Based on Richard comments, I would say that the v2.details.events.conversations.{id}.acw fires when at least one agent participant in the conversation has a wrap-up code. In the cases you provide, and based on the way the Genesys conversation model works for messaging, the conversation is "long-lived" and can have various agents work on it that are added to the participants array. When a second or third agent works on that long-lived messaging conversation, then you end up with multiple agents with wrap-up codes in the array and Genesys triggers for each one.
So, you'll likely have to analyze the conversation to recognize if you've already processed that conversation for that agent and wrap-up code, and if you've had then you'll just need to ignore that event in the future.