Advanced Work Assignment (AWA) Manual Assignment Question

[Gemma4]

Hi Everyone,

We are currently testing Advanced Work Assignment (AWA) manual assignment using a queue configured with:

• An Assignment Rule/Assignment Eligibility where "Enable auto assign work items" is not selected
• Assign by Most Capacity is selected
• A basic configuration that allows members of a specific assignment group to accept or reject Priority 3 incidents

During testing, technicians were receiving the following error message every time they selected Accept an incident:

"An item in your inbox was assigned to another agent so no action is needed."

After investigation, our developer determined that the awa_work_item ACL needed to be marked active, which resolved the issue.

Question 1: Has anyone else experienced this error in a manual assignment configuration, or does anyone have suggestions on what might have caused it? We did verify that the test incidents were only displayed in one inbox and not duplicated. 

We are also seeing a second issue. If a technician does not click Accept and instead closes the incident before it is assigned to them, the closed incident continues to appear in their AWA Inbox.

Question 2: Is there an out-of-the-box solution to prevent closed incidents from remaining in the Inbox in this scenario without affecting native UI behavior?

A business rule has been created as a potential solution, but before moving forward I would like to understand whether there is a supported out-of-the-box approach. I also want to ensure that any customization does not create unintended impacts to the native UI or have downstream effects elsewhere in AWA.

Any guidance or experiences would be appreciated. Thanks!

[boteeuwen]

The ACL explanation makes sense, especially because the message shown in the inbox can be a bit misleading. If the agent cannot update the awa_work_item record because of an inactive or restrictive ACL, AWA may treat the failed update like the work was already picked up somewhere else. Checking the OOTB ACLs first is definitely a good place to start before looking at custom logic.

For the closed incidents, I would also prefer using the Service Channel configuration instead of a Business Rule. Keeping the abandonment or stop conditions inside AWA should make the behavior more consistent with the rest of the routing process and avoids directly changing the work item state from the incident table. It should also be easier to maintain after upgrades.

If this helped you, could you mark it as a solution or helpful?