Genesys Cloud - Main

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Hi Jeff,

If the Conversation is in a `disconnected` state. Then the next inbound message should trigger the flow again, no matter. It would bypass the flow, if the conversation stayed connected for some reason. "In Queue Flows" do add a little complexity here, and there could possibly be a bug with some usages there, if you are using those. If you are not, then you should see no change in existing behaviors you had before that feature was released. I would suggest you open a customer support case here for more investigation.  

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Hi Jeff,

If the Conversation is in a `disconnected` state. Then the next inbound message should trigger the flow again, no matter. It would bypass the flow, if the conversation stayed connected for some reason. "In Queue Flows" do add a little complexity here, and there could possibly be a bug with some usages there, if you are using those. If you are not, then you should see no change in existing behaviors you had before that feature was released. I would suggest you open a customer support case here for more investigation.  

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Andy,

When you say "Agent idle" that means they are still connected to the conversation. Unless i am misunderstanding what you are saying. So in that case you are correct, Flow is not executed again, because agent and conversation is still connected.

Hi Jeff,

If the Conversation is in a `disconnected` state. Then the next inbound message should trigger the flow again, no matter. It would bypass the flow, if the conversation stayed connected for some reason. "In Queue Flows" do add a little complexity here, and there could possibly be a bug with some usages there, if you are using those. If you are not, then you should see no change in existing behaviors you had before that feature was released. I would suggest you open a customer support case here for more investigation.  

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Andy,

When you say "Agent idle" that means they are still connected to the conversation. Unless i am misunderstanding what you are saying. So in that case you are correct, Flow is not executed again, because agent and conversation is still connected.

Hi Jeff,

If the Conversation is in a `disconnected` state. Then the next inbound message should trigger the flow again, no matter. It would bypass the flow, if the conversation stayed connected for some reason. "In Queue Flows" do add a little complexity here, and there could possibly be a bug with some usages there, if you are using those. If you are not, then you should see no change in existing behaviors you had before that feature was released. I would suggest you open a customer support case here for more investigation.  

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?

Hi All,

Just wanted a sanity check on our web messaging configuration and recent change in behaviour.

Up until recently, replies to an existing web messaging interaction (that had been disconnected by the agent, but is still within the 72-hour message threading timeline) would return to the 'Inbound Message' Architect flow (as configured in the Message Configuration section)

So for example, this is how it used to work

- new web messaging interaction typed by customer, this does go into the Inbound Message flow for pre-treatment (check schedule, if existing interaction, bot flows, etc), then is transferred to ACD
- messaging interaction answered by agent and responded to, then disconnected within 1-2 minutes if no immediate customer reply
- when customer did reply (within 72 hours), the reply would still be related to the existing interaction (as per Message Threading) and would return in via the Inbound Message flow
- we would perform the pre-treatment again (check schedule, check if it was an existing interaction or not) in the Inbound Message flow before transferring it back into the ACD queue

However, we've just noticed that message replies are now bypassing the 'Inbound Message' flow and don't even touch it - so all of the pre-treatment checks and bots are just bypassed.

Is this now expected behaviour since the release of the 'In Queue Message' flows, or has something gone awry?