Advanced Work Assignment: (Un)Set Agent's Availability automatically

[Maik Skoddow]

Over the past few months, I've answered a similar question several times in the community about how to automatically set an agent's availability. Mostly people asked how this could be triggered while the agent is logging in. In rare cases, it was also asked how the automatic setting can be done when the agent is using the Agent Workspace for the first time during the session. And with help of this article I want to answer these questions.

Table of Contents Tracking the Agent's Availability Set Agent's State to "Available" automatically Set Agent's State to "Offline" automatically

Tracking the Agent's Availability

The current state of an agent is tracked at table awa_agent_presence: 

For users with the roles "awa_manager", "awa_admin" and of course "admin" the value at column "Current presence state" can be changed to "Available" manually. This might be necessary in case an agent with open chat sessions suddenly fails and the service desk manager needs to kick that agent out manually.

Set Agent's State to "Available" automatically

Option (1): During Login

To react on a login action, we can "catch" the change of the field "Last login time" at table sys_user.

For this purpose, we just have to implement the following business rule:

Table	sys_user
Advanced	true
When	async
Update	true
Filter Conditions
Condition	gs.tableExists('awa_agent_presence') && gs.hasRole('awa_agent')
Script	(function executeRule(current, previous) { var grPresence = new GlideRecord("awa_agent_presence"); if (!grPresence.get("agent", current.getUniqueValue())) { grPresence.initialize(); } grPresence.setDisplayValue("current_presence_state", "Available"); grPresence.update(); })(current, previous);

After the next login, the presence state at the Workspace Inbox should display "Available" as well as the assigned Service Channels:

Option (2): First usage of the Agent Workspace

The underlying argument for this approach is that agents may be performing other activities in the system before opening a workspace and being ready for their work.

But it is not easy to identify such an event and the only way I could figure out so far is watching the Transaction Log table. After some tests, a good "candidate" seems to be the URL /api/now/awa/presence_query_history/create_or_update?api=api

If you really want to react on the URL, you could implement a Business Rule (I suggest "async" as type) on table syslog_transaction.

However, I can't really recommend this, as the Transaction Log table is one of the most frequented tables and any additional business logic may have performance implications.

Set Agent's State to "Offline" automatically

Basically there is no need to configure/script anything as there is a Scheduled Script "AWA - Set Inactive Agents Offline" which runs each minute and checks whether the agent is still subscribed to the AMB inbox channel. If not, it sets the presence state accordingly:

If you want to reduce the time between two runs, it is not enough to modify the value at field "Repeat interval". You also have to set the system property com.glide.awa.agent_inactivity_threshold_seconds accordingly. That property is set to "60" (seconds) per default.

For an even more timely response in case the agent has logged out explicitly, you also could implement another Script Action which reacts on the "logout" event:

[User657582]

Hi Maik,

Thank you for this article. what lead me to it is looking into an issue where offline users are sometimes not detected (if the close the browser, and shut down the PC, it still shows them as  "Available"). have you noticed this behavior? our configuration and script is OOB.

This is not as much of a problem for using AW for chat, as it bounces from agent to agent when it times out.

It is a problem however now that we plan on using Incident channel, without a timeout on tickets. This could mean someone may get assigned tickets while they are away because they show as  "Available".

any insight would be appreciated!

[Lavern Towne]

I'm especially stayed aware of the article and I will get many benefits from it. Subsequently, thank you for sharing it. That vitalizes the amazing bone! Here clearly accepting I endeavor an article I can pull off a couple of additional spaces!

epayitonline

[Eric24]

I have noticed the same behavior and am looking for a solution to this. Ideally, we would need an option or a script that detects browser is closed and set presence to offline in that situation.

[dc20]

Any ideas on an event when the user closes the browser?

[Marcio9]

I tried this out on the tokyo release and it only works for a minutes, then it auto sets them back to offline.

[Reid1]

This method works, however, the mailbox icon does not turn green as it does when the agent sets themselves available through the UI. Any thoughts?

When you toggle between Away and Available through the UI, the class highlighted toggles between -available and -away which changes the color.

When using the script there's no event handler and the class doesn't change.

 

[Maik Skoddow]

Hi @Reid1 

As you can see in the article, my method works server-side and it was working fine in the agent workspace at the time the article was written. With the new workspaces, there still seems to be some sort of notification missing that is then received in the workspace and acted upon accordingly. But what exactly that can be, I am unfortunately not able to explain at the moment.

Maik

[Research]

Hi @Maik Skoddow 

Same above scenario once the agent logins- After 10 minutes I want to set their status as Available

with the reference of (last login time in user table) after 10minutes I want to set the status into Available in AWA (Advanced work Assignment).

Can any you guide me script 

Thanks

[teduard]

@Maik Skoddow thank you very much for the article posted!
could you please advise, having awa_manager role security constrains prevent me to change the status manually 

[Kelvin Ward]

I did some testing on this today, but was more focused on timeouts. I am on Xanadu for reference and the workspace in this situation was Service Operations Workspace, but we also use CSM/FSM configurable workspace and I would expect the same behavior regardless of workspace. 

• Auto available via async business rule works on login fine, but you have ~1m to open workspace or it moves you back to offline (I had to use a sys_id for my presence state as I have multiple available options)
  • Backing out of workspace after already available does not have this same effect.
  • Impersonate does not trigger auto available, but can be manually tested with the right permissions by modifying the last_login_time on the sys_user record
• Default timeout of AWA Available presence is 5m, but is configurable down to 1m with com.glide.awa.agent_inactivity_threshold_seconds
• A logout triggers the 5m timeout the same way a session timeout does (Session timeout being defined by glide.ui.session_timeout)
• A window closure is the same as logout/session timeout and also triggers the 5m timeout on AWA.