live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Automating Salesforce Omni-Channel Agent Status using the Omni Toolkit API
Mar 4, 2026
Show More Show Less
View Video Transcript
0:08
Hello everyone. In this video we are
0:10
going to see how to automate Salesforce
0:14
omni channel agent present status using
0:18
Omni toolkit API.
0:21
The use case what I had was whenever
0:26
the agent's workload is changed
0:30
and uh if the agent workload is equal to
0:34
the configured capacity
0:37
then the agent's status should become
0:41
busy.
0:43
Let's say they close a work item because
0:48
of that the capacity is released. Now
0:50
they have additional capacity
0:54
so that they can work on additional work
0:57
items. In this case the omni channel
1:00
present status should automatically
1:02
change it to available.
1:06
In order to achieve this uh use case, in
1:09
order to automate the Salesforce agents
1:12
omni channel present status changes, I
1:15
am making use of lightning omni toolkit
1:18
API and omni channel workload changed
1:22
event.
1:24
I am making use of lightning aura
1:26
component because omni channel workload
1:30
changed event is not yet available in
1:33
Salesforce lightning web component
1:37
in the best practices and recommendation
1:41
I have documented it when you view this
1:45
uh video first check whether this
1:50
particular event
1:53
omni channel workload changed the event
1:55
is available in lightning web component
1:58
web component. If it is available try to
2:00
go with the latest Salesforce lightning
2:03
web component instead of lightning aura
2:06
component.
2:07
Okay. In my lightning aura component I
2:11
making use of lightning omni toolkit API
2:14
using aura handler. I'm listening to
2:17
lightning omni channel workload changed
2:20
event. Whenever the Salesforce agents
2:23
workload is changed, then it will invoke
2:26
on workload changed
2:30
in this JavaScript method.
2:33
I have hardcoded the busy status ID and
2:36
available status ID.
2:38
Try to try not to hardcode. I have added
2:42
that also in my
2:45
best practice and best practices and
2:47
recommendations.
2:51
So using
2:53
Omni uh so so using uh the toolkit. So
2:57
this Omni API is the toolkit.
3:04
So here I'm using component.find. Omni
3:07
toolkit. So from my from my component
3:10
I'm getting this uh omni toolkit using
3:14
which I'm making use of get uh service
3:18
present status ID. I'm trying to find
3:20
out what is the current present status
3:22
of the agent.
3:25
Then I am checking
3:28
uh then I'm making use of
3:37
so from the since it is an event from
3:39
the event I'm using get params method
3:42
and then from the from there from that
3:45
I'm getting the new workload previous
3:47
workload and configured capacity. So
3:50
this event
3:52
omni channel workload changed event will
3:55
uh have uh new workload previous
3:59
workload and configured capacity in
4:01
their params. So using the event or get
4:03
params I'm getting all those values and
4:05
then I'm checking whether their current
4:07
workload is greater than or equal to
4:09
configured capacity and also I'm
4:12
checking whether their current status ID
4:14
is not equal to busy status ID. If they
4:16
are already in busy status, I don't want
4:18
to make use of set agent present status
4:21
from my helper
4:23
uh JavaScript and set the status to busy
4:26
status ID. So in my helper I am making
4:29
use of the omni toolkit method set
4:33
service present status where I am
4:35
passing the status ID and then it will
4:37
be updating it. So if the agent's
4:40
workload is under their configured
4:42
capacity then
4:45
it will check whether the current status
4:48
ID is not equal to available status ID.
4:51
If they're already uh available and uh
4:54
if their status is available then I
4:56
don't want to uh again invoke this set
4:59
agent present status and update their
5:01
status. I wanted to update only when
5:03
they are not in available status. uh
5:05
let's say uh if uh my configured
5:08
capacity is two and uh the work item
5:10
capacity is one first time when I
5:13
receive work item
5:15
um I will be in available status. So
5:17
instead of again setting my status to
5:19
available using this uh uh JavaScript I
5:22
should avoid that instead of duplicating
5:24
my all duplicating my status again to
5:28
available. Same thing for setting it to
5:31
busy. If I get
5:34
um any
5:37
work item and if I'm already in busy, I
5:40
don't want to set my status again to
5:42
busy. I wanted to check it
5:45
uh if my status is not busy, then invoke
5:48
the helper method and pass the busy
5:50
status ID. Same thing is available for
5:54
available status. If if my status is not
5:57
available now, if I am busy or if I'm in
5:59
different status, then it will invoke
6:01
this method and then it will set my
6:03
status to available.
6:07
And uh in my service console app, I
6:11
added the lightning aura component. I
6:14
have set start automatically enabled so
6:17
that whenever they log in whenever the
6:19
page is loaded this lightning aura
6:20
component will be invoked and then uh
6:23
the event listener will start listening
6:25
to workload changed event.
6:31
So as of now in my presence
6:33
configuration the capacity is two. I am
6:35
making use of default presence
6:36
configuration. The capacity is two
6:40
and I have two cases that are in high
6:43
priority cases. Q the as per the uh
6:47
routing configuration the capacity for
6:49
each work item is one.
6:52
So now
6:54
let me go to inspect
6:58
console. Let me clear it. So now if I go
7:03
available for case
7:07
um two work items will be assigned to my
7:10
omni channel widget so that I will be
7:12
able to assign. One important thing to
7:14
note here is
7:17
the agent workload will be changed
7:23
when the work item is
7:26
assigned here in the omni channel
7:28
widget.
7:30
It won't get fired when they accept it.
7:35
Though the agent didn't accept the work
7:38
item, the workload changed event will be
7:41
fired. Their capacity would have been
7:43
already um um um deducted or applied
7:49
based on the work item routing
7:51
configuration capacity
7:54
and then it will invoke workload changed
7:56
event. So this is an important thing to
7:58
note. uh let me go available in case and
8:01
then we will see that in action. So here
8:04
if I go available uh as case two work
8:08
items will be um assigned one with uh
8:13
previous workload zero current workload
8:15
one configured capacity two. Second time
8:18
the second work item the previous will
8:20
be one current workload is two and the
8:24
configured capacity is uh two. So it is
8:26
equal. So it should set my status
8:29
directly to busy. So that's my
8:32
automation here. Uh if I um
8:37
decline a work item in my omni channel
8:39
um widget then it should release one
8:42
capacity because I didn't accept it. It
8:44
was just assigned to me but I didn't
8:46
accept it. So my status should be set
8:49
back to case. Let's see that in action.
8:53
So I'm setting my status to case.
8:57
It's it set my status to busy because
9:02
the agent cannot accept more work. So it
9:05
came to it came here. Agent cannot
9:09
accept more work and my current status
9:11
was available for case and it is not
9:14
busy. So it invoked set agent present
9:17
status from the helper and in the helper
9:20
with the help of set agent present
9:22
status method. Sorry. Set service
9:25
present status. Omni toolkit API method.
9:28
I was able to set the status to busy.
9:33
So new workload is one. Previous is
9:35
zero. Configured is two. Again the
9:37
workload changed because the second work
9:39
item was assigned. Previous work
9:41
workload was one. Configured is two. New
9:43
workload is two. So both are same. The
9:46
current status is this one. The new
9:48
status ID is this one. So it changed my
9:51
status from case to busy. Now if I
9:55
decline or if I accept and close the tab
9:59
because I'm making use of tab based
10:01
capacity model not status based. So if I
10:04
decline it should again trigger this
10:08
workload changed event and my cap and
10:11
then it should show the previous
10:13
workload should be two new workload
10:15
should be one and the configured
10:16
capacity is two. uh new workload and the
10:19
configured capacity are not same and
10:21
then it is less. So it should change my
10:24
status back to case. Let's see that. So
10:26
I'm declining it.
10:29
New workload is one. Previous workload
10:31
was two. So one was uh uh deducted and
10:36
the configured capacity is two. They are
10:38
not um equal and it is less. So the
10:43
current status ID is busy. Agent can
10:46
accept more work. So that's the reason
10:48
my status is changed to this new case
10:51
status ID. Sorry. Yeah, new present
10:53
status ID which is case. So it changed
10:56
and uh I was able to fully automate this
10:59
based on the workload changed event uh
11:02
information.
11:12
Please check the video description. In
11:14
the video description, I have shared my
11:16
blog post. From the blog post, you
11:18
should be able to get the lightning aura
11:20
component which we discussed in this
11:22
discussed in this video. And also, if
11:25
you are planning to make use of this
11:26
code and if you are planning to make use
11:28
of this approach, make sure to go over
11:30
the best practices and recommendations
11:33
for production ready code.
11:42
I hope it was helpful.
11:54
Thank you for watching.