#Omni Channel14 discussing

Hi, 

Let me break down both symptoms you're describing.  

Symptom 1 — New cases not appearing without toggling status or refreshing

This usually points to one of these: 

• Stale AgentWork / PSR state. When a case is routed via Omni-Channel, a PendingServiceRouting (PSR) object is created as a transient routing record. It gets deleted once an agent accepts the work. If a previous session ended uncleanly (browser tab closed, session timeout, etc.), the PSR can get into a stuck state where the routing engine thinks the agent is still being offered work — so new items queue up but don't surface. Toggling offline/online forces the engine to re-evaluate.
• Capacity not being released properly. Check that the agent's capacity settings in the Presence Configuration align with the routing configuration's capacity thresholds — specifically, the "Units of Capacity for In-Progress Work Items" in the routing config should be less than or equal to the agent's presence capacity. If a previously closed case didn't release its capacity unit (e.g. because the case was closed externally rather than via the agent widget), the agent appears full to the router even though they feel available.
• Page refresh logging them out. If an agent refreshes the Omni-Channel widget page while they're online or busy, they're logged out and must log back in to continue working. Accidental refreshes mid-session cause exactly this symptom.

When an agent goes offline and back online, the system re-evaluates all work items in the queue, and agents who had previously been considered for a declined item are included again. If that old case was closed by the agent

of Omni-Channel (e.g. editing the Case record directly rather than using the widget's close/wrap-up action), the AgentWork record associated with it may not have been properly marked complete — so Omni-Channel still sees it as active work and re-surfaces it. 

1. Check AgentWork records via SOQL: SELECT Id, Status, WorkItemId FROM AgentWork WHERE UserId = '[agent user ID]' ORDER BY CreatedDate DESC — look for records in Opened or Assigned status tied to cases the agent considers closed.
2. Check Presence Configuration — confirm the agent's capacity is high enough and that "Automatically decline requests" or push timeout isn't silently routing items away.
3. Check the Service Channel config — specifically the "Check agent capacity on reopened work items" and "Check agent capacity on reassigned work items" settings, as these can directly impact routing behaviour in the scenario you're describing.
4. Omni Supervisor — use the Queues Backlog and Agent Work tabs to see in real time what the router thinks the agent's state is. This is your best diagnostic tool.

The offline/online toggle works as a workaround because it forces a full presence session reset, but the fix should be upstream — either in capacity config or ensuring cases are closed through the proper Omni-Channel flow so AgentWork records are correctly finalised.

Hi @Sven Riemer

, 

I am also at same situation and I tried reverting Embedded Service Deployment to v1 but still no luck. Did you manage to get this working with v1, if so was there any additional change needed? 

Thank you.. 

Manoj

Hi, 

omniUpdateDataJson() updates the DataJSON but doesn't trigger UI re-render on OmniScript elements — their local state stays stale. 

Fix: Use omniApplyCallResp(payload) instead — it updates the JSON and forces UI refresh.

const addr = {
  AddressLine1: '123 Main St',
  City: 'Noida',
  PostalCode: '201301'
};
this.omniApplyCallResp(addr);

Requirements:

• LWC must extend OmniscriptBaseMixin
• Payload keys must exactly match OmniScript element names (case-sensitive)
• For nested step data, use { StepName: { FieldName: value } }

If still not refreshing, chain both:

this.omniUpdateDataJson(addr);
this.omniApplyCallResp(addr);

@Duru Zerdali screenshot shows you are already in the right place:

App Manager -> Ursa Major Solar Service Console -> Utility Items -> Add Utility Item

If Omni-Channel is not appearing in that list, it usually means Omni-Channel has not been enabled yet in the org.

Go to: Setup -> Omni-Channel Settings -> Enable Omni-Channel -> Save

Then refresh the App Manager page and come back to: Ursa Major Solar Service Console -> Utility Items -> Add Utility Item

Now search for Omni-Channel again and add it.

Salesforce’s help confirms that Omni-Channel must be enabled first: 

https://help.salesforce.com/s/articleView?id=service.omnichannel_enable.htm&type=5

Trailhead’s step then asks you to add Omni-Channel from the app’s Utility Items section: 

https://trailhead.salesforce.com/content/learn/projects/set-up-the-service-console/set-up-web-chats-for-your-console

Also make sure you are editing the Ursa Major Solar Service Console Lightning app, not a standard app. Your screenshot shows the correct app, so the missing piece is most likely the Omni-Channel enablement step.

@Naveen Kumar S these are two issues. The Insufficient Privileges page on Telephony Provider Settings

usually points to access/configuration, not an Amazon Connect outage. Make sure the Salesforce user has the correct Service Cloud Voice / Partner Telephony permission sets and is added as a user on the Contact Center. Also check the Amazon Connect side. Salesforce permission sets do not automatically give the user Amazon Connect admin/security profile access. 

Found a similar thread:

For the SAML login issue, I would also check whether the contact center SSO connected app access changed, whether the SAML certificate expired/changed, and whether the Salesforce user still maps correctly to the Amazon Connect user. Salesforce docs say Salesforce users with the Service Cloud Voice permission set should be automatically logged into the associated Amazon Connect instance when SSO is configured correctly. 

For the inbound call issue, since outbound works, the softphone/browser side is probably okay. I would check the inbound path: Amazon Connect phone number, contact flow, queue, routing profile, agent availability, Omni presence, capacity, and whether the VoiceCall record is created in Salesforce. If VoiceCall records are created but not routed, focus on Omni/routing config. If no VoiceCall is created, focus on Amazon Connect/contact flow/Salesforce integration.

Also confirm you are not mixing Amazon external routing and Salesforce Omni-Channel Unified Routing in the same contact center. Salesforce docs say to use only one routing system per contact center.

@Heather Hanson

:  Thank you so much for coming back and posting your solution. 

While I don't think this helps me right now, I will make note of it for the future.  

A lot of our issues have to do with the order in which things happen (i.e. the Case is created before the eMail Message record) and cross-reference issues.  I did find in my org, an ancient Workflow Rule that was reassigning cases.  Deactivating that made a big difference for us.