There are more than 1 ways of achieving task load balancing based on user’s online presence.
It needs some logic to be defined which will differ from one client to other and even one workflow to other. Here are few of the driving factors.
- What system are you going to depend on while detecting that the user is online or not. Is it Salesforce, Skype for Business etc.
- If more than one user is online at this time, within that subset of online user in a group, how do you distribute work. Is it based on work load, seniority, skill etc.
- With presence based allocation, one thing to keep in mind is that users presence detection can be misleading at times as you will go by active session and as you are aware that system like Salesforce will keep user session active for 2 Hrs or whatever is session expiry even if you close the browser so user might be gone and closed the browser but if you detect presence by just his session you might not be 100% accurate. Ofcourse if as part of policy you make user logout from Salesforce at end of day, you can reduce the possibility of wrong presence being detected but still there would be people who forget to logout.
- There might be other factors as well driving this for e.g. if amount is greater than 50K then choose user A instead of user B.
So as you can see from above, there is no one size fits all kind of solution to doing work allocation based on just presence. Some BPM products might claim they can detect presence but in reality what they do not make clear is that just presence was not sufficient to get to a unique user as explained above. However AgilePoint already provides more than 1 ways of handling this. I have explained 3 of the options below but there can be more as well. Please remember all these are just one time development effort
Option 1 – Custom Webservice: We touched on this briefly the other day. With this option, you would write a custom Webservice where you pass in the group name as input parameter from the workflow and Webservice makes Salesforce call, detects unique active sessions in Salesforce, runs the business logic to identify the unique individual from that subset based on approval limit, skill, seniority etc. and then just send one name back to workflow which is stored in variable which is then used in the next manual activity as participant. This is a common pattern in BPM where approvers are selected based on external logic.
If you are detecing presence based on Salesforce session, you can get list of current logged in user from SOQL query and check return results against group members
Similar API’s are available for Skype for Business and other systems
Here is sample configuration
I have a Webservice call before manual activity to get active user as per my business logic/approval matrix
In the Webservice, I pass group name
As a return parameter I get online username as per my custom business logic which I can store in a workflow variable
Now on manual activity, instead of assigning task to a group, I would assign that to the variable which holds online username at that time.
I just used one of the dummy WebServices I had but your custom Webservice might look similar in terms of configuration.
Option 1 is what most clients use as business logic might differ from one workflow to other so this approach is more under their control.
However if you have a private installation of AgilePoint server i.e. AgilePoint NX in Private cloud or OnPremises, you have few more options to extend the base platform itself which are explained below
Option 2 – Reusable Custom Human Activity: If you think that the business logic you have to detect online user based on factors mentioned earlier is generic enough to be used across all workflows you create, you can turn that into a reusable custom workflow activity instead of Webservice which will have a simpler UI to configure and exposed to all your workflow designer just like any OOTB activity. This is done using our server side SDK which is available through a Visual Studio add-in which we call as AgilePoint Developer. Though honestly even option 1 is easy enough to configure as shown in screeenshots.
However this option comes in handy when you have specific kind of reusable business rules in mind. For e.g. if you wanted to detect presence based on rules just like Salesforce Omni-Channel, you can do it this way provided you are using AgilePoint NX OnPremises or Private cloud model which allows you to extend platform by adding your own workflow activities.
For those of you not familiar with Salesforce Omni-Channel, it does distributions of tasks within the group based on predefined rules and once all users reach max workload limit, it stops assigning work to them but instead keeps the task in queue till one of them becomes available. Here is a quick overview of how Omni-Channel routing works
https://help.salesforce.com/articleView?id=omnichannel_routing.htm&language=en_US&type=0
Now in order to achieve similar functionality in AgilePoint, you could write a custom human activity which is by default assigned to a group. However in the human activity, you could listen to AssignWorkItem event which is raised by engine before task is inserted in database and at that point, check the online presence in Salesforce querying AuthSession object or UserServicePresense API and get least loaded user who is online and if his count is less than max threshold force assignment to that user. If you find that all users are above task threshold, let task get assigned to group i.e. don;t take any action so that it still shows up to them InQueue and user or his manager still has option of manually taking assignment. However as soon as one of the user completes the task which brings him below activity threshold, engine would raise a CompleteWorkItem event and based on that you can check that if for that activity and process combination, any task is still InQueue, take assignment for the task oldest task with highest priority from Queue and assign to the user.
This is a pretty straightforward development but by doing this you could implement your presence based routing logic as per your own business rules in a reusable way and hence by just changing configuration, you can have same workflow activity behave differently for different workflows and different groups. Platform extension is a pretty nifty feature which you get with AgilePoint.
Configuration of my sample custom human activity might look something like this
In the above screenshot for my custom activity, I setup participant as a group and specified max threshold of tasks for a user. I also added an additional feature where even if task was forced to user’s list, he has option to put it back in the queue for system to reassign it to someone else which comes in handy if user has some urgent work like a dentist appointment and has to leave. You do not want important task to be stuck just because user was leaving. Alternative would be to listed to Overdue event in your custom activity and automatically move task to InQueue.
Again just to be clear this is just an example I took for the discussion and your business rules and presence based system could be totally different.
Option 3- Extend engine with your business logic : If you do not wish to create a new workflow activity or Webservice but want to apply this to standard OOTB activity in a private installation, even that can be done. AgilePoint is an event driven environment which allows you to listed to events raised by the engine which in this case would be for task assignment and lets you override engine behavior for particular workflow activity/process which lets you run your own business logic and force assignment as per your logic. This component is called AgileConnector. It can listen to WorkItemAssigned event –> Run business logic to identify unique online user –>Forcefully assign task to him. Please remember this extension is only available in a private installation of AgilePoint server and not in shared hosted environment.
There are more options as well like instead of workflow make Webservice call before submitting previous form etc.
Typically I see clients prefer option 1 as it is pretty straightforward and will run in shared as well as private environments.