When an email is being sent with multiple actions on, the event bridge sents the following events (and timestamp of the event):
user.start (2024-10-21T13:20:56.727Z)
user.end (2024-10-21T13:20:56.902Z)
I would assume that the order should be in the opposite because the conversation (and user) is still connected the the conversation.
Why is the user.start the first event and not the last?
The user.start event is when the agent starts handling the conversation and the user.end is when the agent releases the conversation. They appears to be in the right order to me, although the agent sure didn't spend much time handling that email.
Hello Crespino,
Have you tried it? These two events are fired each time an agent sents a email with multiple actions on. They always appear in this order.
Like you said. You would suggest that the agent released the conversation. But it doesn't. It is still assigned. This (only) happens with multiple actions settings on for the email.
I'm sorry, I missed the fact that this was an email with multiple actions. Based on that, and the documentation, then things are working as designed because each action is a separate session, per this documentation: Reply to or forward an email message interaction - Genesys Cloud Resource Center
Note : If your admin enables Enable Multiple Actions, each email that an agent sends before they wrap up the interaction counts as a separate session with its own handle time. For example: An agent sends an initial response to an inbound email message, and the handle time is 10 minutes. If the agent then forwards the message to another participant, the timer starts over, and the handle time for this section is 2 minutes.
So if the agent first replies to the email, then when they send that reply you get a user.end event for that session, and a user.start for the next session. Then if they forward the email as a second action you'll get a second pair of events. And so on.
Note, event order is not guaranteed, so although you might expect to get a user.end and then a user.start event in this scenario that may not happen, and based on the implementation it may never happen as Genesys Cloud may prepare the additional session before the email service has had a chance to complete the prior action (i.e. actually sending the reply).
Hello Crespino!
Thank you. This makes kinda more sense.We'll look into this session a bit more to correctly handle te status of the conversation.
FYI. The receiving order of events is indeed not guaranteed, but the event time in the event-data is; and these are always in the order as shown above. Probably one of the reasons why there are microseconds :-).