The customer reported an issue with an agent not getting work items assigned and even slowness in assignments. Issue The customer reported an issue with an agent not getting work items assigned and even slowness in assignments. ReleaseAnyCauseLooking at the interaction example we see the work items were created and routed to the correct queue but they were never assigned. From Splunk log, we do see some AWA assignment exceptions where awa-assignment-lock has expired prematurely. We also see a warning for when awa_work_item_rejection table is queried which has more than 6.6 million records. In addition, there are more than 31K work items in queued state. ResolutionThese are the 2 steps you need to take. I added some questions and answers you may have for each. 1. Can you please change "glide.awa.load_rejection_batch_size" system prop value to something much smaller like 1000? By default, it is 10,000. Try this and see if this works if not we can test by adding a new sys prop "com.glide.awa.lock.assignment.expire_time_ms" and set it to 90000 which increases the lock's expiration time from 1 min to 1 min 30 seconds and see if the issue has resolved. QUESTION: Any performance impact? As this will need to be done on prod we need to know any impact. ANSWER: There shouldn't be a performance impact for increasing the lock's expiration time by 30 seconds but upon looking at the code it would be better if we first attempt to change "glide.awa.load_rejection_batch_size" system prop value to something much smaller like 1000. By default, it is 10,000. Looking at server logs for the transaction ID that displayed warnings for awa_work_item_rejection table being large. We can see that the transaction took about a minute and 4 seconds which exceeded the default 1 min expiration time. When we assign a work item we query for many things and one of them is querying for rejecting agents to generate an agent rejection map that contains information like the agent that rejected, the reason, etc. We first get all of the queued work items. Batch them with the size specified by "glide.awa.load_rejection_batch_size" and for each batch we get the assignment lock for a minute (by default). We then query awa_work_item_rejection table to query for agents that have rejected each of the work items and generate a map.Because your instance has many queued work items (31K+) and many awa_work_item_rejection records (6.6M+) this query is taking longer than a minute. Workaround would be either increasing the lock's expiration time to 1min 30 seconds or reducing the batch size to 1000. We recommend that you start with the latter option first. Reducing the batch size will not affect the total execution time. 2. . You will need to clean up your queued work items as having more than 31K work items will cause delays. QUESTION: How can you do this exactly? Just going to the work item table and closing work items? ANSWER:You will have to make the decision on that. Do they have a business need to keep all these queued work items? Maybe you can clean up the ones that have been queued for more than a couple of weeks? There are two ways to clean up the table.1. One is using the platform one by going to sys_auto_flush table and looking for "awa_work_item" for the table name. There is an OOTB record there which is set to inactive. By default, it is set to delete awa_work_item records that satisfy the "conditions" field. Since it has "Cascade delete" checked, it should also delete corresponding awa_work_item_rejection records as well. 2. Another way would be to close the cases directly. This way it will delete the work item records as well since deleting just the work item records may result in creating new work items for the cases that remain open.