One of the recurring realities of Salesforce architecture is finding yourself rebuilding capabilities that seem like they should be native to the platform.
(the image is just showing Claude hallucinating when I was researching the issue below 😜 )
A recent example: preventing Omni-Channel agents from going Offline while they still have active chat work.
Towards the end of their shift, some agents set themselves to Offline to prevent another chat/voice call and cause the current chat to drop.
You would expect a hard native block for that but there is none as far as I know.
What Salesforce gives you:
⚙️ Presence statuses (defines a Busy status that stops new routing but does not protect active sessions)
⚙️ Presence configurations (controls capacity, auto-accept, decline behavior, and push timeout status transitions, but nothing restricting status transitions while work items are open)
⚙️ After Conversation Work (applies only after a conversation ends and is overridden if the agent goes offline)
⚙️ A confirmation prompt added in Spring '24 that works for Voice, not Chat
What we would need:
☁️ A true pre-change hook, or
☁️ A cancellable event before status changes, or
☁️ A declarative setting to lock presence during active work
So the workaround becomes custom engineering for a platform gap.
One option is a detect-and-revert pattern:
1️⃣ listen for the status change (after it happens: lightning:omniChannelStatusChanged or lightning:omniChannelLogout)
2️⃣ check for active AgentWork (getAgentWorks())
3️⃣ immediately set the agent back to the previous status (setServicePresenceStatus({statusId})) or issue an alert
Last I checked, Omni tooling is still Aura-based, so you end up building an Aura wrapper around lightning:omniToolkitAPI to patch behavior that we would reasonably assume is standard. And that solution is reactive, not preventive. The customer loses the chat context without User Verification.
A more robust solution seems to be to replace the native widget entirely with a custom status component. That looks safer, but now you are maintaining your own presence-management UI because of the lack of out-of-box enforcement points.
So instead of building a differentiator, we end up just rebuilding a missing guardrail. Such limits do not just induce technical debt creation, they redirect delivery time away from business value and into "defensive" architecture.
Some ideas that may be worth probing further:
👉 Some "custom solutions" in Salesforce are really just missing product controls.
👉 These platform workarounds will have a maintenance cost after few years.
