Hello Henri1. I know your resolution indicates you found a solution, even if it was not ideal. Have you done any more research on this particular use case? We have a similar need to interrupt the idle timers so an interaction can be placed "on hold". I was going to use your suggestion, but ended up going down a different path.

I ran into similar issues running down the inner workings of the whole chat interaction and was equally frustrated with finding a link between those binding records and the actual interaction. However, I think I might have found the link. Looking into the interaction xml, I found that there are these two fields; channel_metadata_document and channel_metadata_table. When looking at the xml, I see the table is set to sys_cs_conversation and the document is a sys_id. Which, is handy to have since that sys id is referenced on sys_cs_session_binding in both the topic and session_topic fields. I thought of doing something on binding directly, but after mapping it out I came up with what I think is a much simpler solution. The IdleChatHandler script include is just doing a simple lookup to build the conversations array within that getAllConversations function, and that is then used in the other functions to determine timer handling on the identified chat sessions. The query is only looking for topic.state in chatInProgress or autoPilotInProgress. So, my solution was to just cause the check to inherently fail by adding an On Hold state to the conversation table.

Unfortunately the conversation table's state choice list doesn't include an on hold option, so I went ahead and added one. From there I built out a business rule on Interaction that checks for a state change to On Hold, and then pushes an  update to that conversation record to set the conversation.state field to On Hold. When the agent changes it back to in progress it pushes that update back to set the conversation back to chatInProgress.

tl/dr

To allow for interactions to be On Hold

Create a new choice record for sys_cs_conversation, On Hold (on_hold), I used sequence 7.

Create an on after, update business rule on Interaction that checks for the advanced condition current state changes to On Hold or previous state is On Hold and current state is Work In Progress

update the sys_cs_conversation.state field to on_hold, and then flip it back to chatInProgress for the inverse.

In testing, it is working to the point that the idle timer is now interrupted, however once I move the interaction to On Hold then the chat window is hidden from view in the workspace for the agent. It returns once I move the interaction back to In Progress. Another NOW Mystery to unravel, so I'll need a new box of scooby snacks, but at least the idle timer can be interrupted. Hope that helps.