Demystifying Advanced Work Assignment (AWA)SummaryUnsure where to start when troubleshooting Advanced Work Assignment? This article provides information about AWA architecture that may help resolve your issue. Advanced Work Assignment (AWA) was introduced from around Madrid release onwards. AWA has little complex configuration and there are lot of moving components in its architecture and hence it appears as one of the complicated applications to troubleshoot in case of issues. This article is designed to help you understand the architecture and internal working of AWA so that you can more easily troubleshoot any AWA issues you may encounter. Following is the simple architecture diagram of the AWA, The AWA is used to assign cases, incidents, etc automatically to the available agents. Also, it is used on Agent Chat(Workspace chat) application to assign the chat records (interaction) automatically. Hence, learning AWA will also help you with troubleshooting Agent Chat as well. Table of contents Terms used in AWAAWA ConfigurationOther ComponentsAWA RoutingAWA AssignmentBasic flow in AWAHow to enable AWA logging Terms used in AWA Work item: A record in awa_work_item table used by AWA for routing and assignment.Document: In the context of AWA, a document is the record such as "interaction" or "case" or "incident" that we want AWA to route and assignWork item card: a UI component presented to the agent on Agent Workspace that represents actions. Looks like this: Routing: create a work item associated with a document, and assign it to a queue.Offering: The work item assigned to the queue is assigned to an agent with state as "pending_accept".Workload: Also known as "capacity in use", represents the current amount of work assigned to an agent. Note this is different than the "capacity", which is the maximum capacity the agent is able to handle. These 2 fields exists on awa_agent_capacity table. AWA Configuration A simple out-of-box configuration for the chat service channel can be created by installing the com.glide.interaction.awa plugin with demo data. Following are the steps to verify that AWA is properly configured: Check there's a navigation module called Advanced Work AssignmentNavigate to Collaboration->Chat Setup, the Fulfiller UI (Global/ITSM/HR/CSM) should be set to Agent Workspace.System property "glide.awa.enabled" set to trueNavigate to Advanced Work Assignment->Service Channels. A service channel corresponding the document you want AWA to handle should be listed. There should not be more than one service channel that overlap. E.g. no two service channel for table=interaction and interaction.type="chat". The form UI will warn when a service channel is created that overlaps with another one.Open the service channel under investigation, and ensure that in the related list for "Queue" that there's at least one queue listed that's active.Open queues from above and check: The schedule is blank (i.e. available all the time), or set to a correct scheduleThe queue condition is as expected. For CSM chat queues, queue selection could be based on conditions such as accounts or categories.There's at least one entry in Assignment Eligibility related list. Open the assignment eligibility entries from above and open the group associated with the assignment eligibility. Ensure all members of the group have the awa_agent role, and has permissions to access the document (e.g. can read/write to interaction) Other components Now we know the terms used in AWA and the configuration needed, let's learn a little more about other internal components involved, so that we can understand the flow easily. Record watcher responders: When you activate the "Service Channel", the system will automatically create 3 record watcher records per channel as shown below in sys_rw_action table, these record watcher responder records will be deriving the conditions from the "Service Channel's" condition, Asynchronous Message Bus (AMB): AMB is the internal message transfer mechanism which helps to transfer the message across various clients and server in real-time. You can see the AMB traffic on the network tab of the browser as shown below, Now we know most of the terms, configuration & other components, let's go through a couple of easy flow diagrams before getting into the complete flow. AWA Routing For the document created, if that qualifies with the "Service Channel" condition, it will become eligible for routing. Routing is nothing but, the system creates the work item for the document and assigns it to the queue. Hence, when you see a work item is created for the document, that indicates that most of the Channel/queue configuration is correct. Following flow diagram briefs about the routing. Here the above green box ("(Re-)Route it to a queue") is detailed in the following flow diagram, AWA assignment After the routing (i.e. work item got created and assigned to the queue), AWA will try to find the best available agent and then assigns the work item to that agent with the state "pending_accept", which is called as "Assignment" process. Here, the best available agent is identified based on the "Assignment rule" configuration. Does there have to be an available agent for a work item to be created in the work items table and then only it is queued? No. As long the queue is in schedule, the work item will be created and be in Queued state. Once any agent becomes available, it will then be offered to them. Basic flow in AWA A document is created and meets the eligibility criteria for the "Service channel" for this type of document. Out-of-box eligibility criteria for Chat "Service channel" would be any interaction record with type=chat, and state in either New, On Hold, Work In Progress.Record Watcher(sys_rw_action) Responder with the name "awa-eligibility-responder" for this service channel condition is triggered and "pokes" the AWA worker thread to wake up and do work.AWA worker thread starts the routing process. If a queue is found, a work item is created and associated with a document, with state=queued. Work item's state is set to "pending_accept", and assigned_to set to the agent it was offered to AWA worker thread starts the assignment process. AWA engine attempts to identify the best agent (based on presence, availability, affinity, skill, etc), and a work item is offered to an agent. The agent's capacity in use is increased. A Record Watcher Responder with the name "awa.work_item" gets triggered from a work item that' assigned to an agent, and fires of an AMB message to the agent's workspace page in the browser.The agent is presented with a work item card in the workspace.Agent accepts a work item. A GraphQL API call is made to the server that sets the work item's state to "accepted", and the document's assigned_to field to the agent When the work is done, that is, the agent or requester closes the document (e.g. interaction). The document state is set to an ineligible state per the "Service Channel".A Record Watcher Responder with the name "awa-workload-responder", on the document table (e.g. table=interaction) is triggered from the document being closed. The agent's capacity in-use is decreased. This whole basic flow is put together on the following flow diagram for easier understanding, How to enable AWA logging In addition to the understanding of the above-mentioned flows, with the AWA logging, we will be able to narrow down the issue. AWA logging can be enabled as per below steps, In the navigation filter, enter sys_properties.list.In the System Property [sys_properties] table, click New and add the com.snc.awa.syslog.enabled property: Name: com.snc.awa.syslog.enabledDescription: Log AWA work item routing and assignments in the system log.Type: true | false Set the Value to true.Click Submit. Logging for the AWA assignment engine is enabled in the syslog table. To view the system log, navigate to System Logs > System Log > All and perform a search where the Source is AdvancedWorkAssignment.Related LinksKB0952786 - How to troubleshoot AWA(Agent Chat) assignment issuesKB0951909 - How to troubleshoot AWA round robin assignment issue