Hey Bryan -
You are most welcome -
I would caution here, based on how you describe the business process that is not how I would describe how iwd works.
The task lives in Genesys. Once it routes to an agent, the agent goes to the source system and completes the work needed, the agent then should come back to Genesys agent desktop and has to mark the task done at that point. (this process captures the agent handle time) At that point, there is no further action needed. An agent can NOT receive a work item and then not work it. The two options that I am aware of are "mark done" or put in a workbin (highly discouraged for a couple of reasons - top 2 that I can think of 1) continues to take up space in the routing services, which limits how many other tasks you can route 2) has no mechanism to be brought out other than manually again by the agent by being not available) At this point, we actually have workbins disabled to avoid both reasons mentioned.
Our use case sounds somewhat similar, so I can imagine what you are thinking that you would want the task to live on in the event an agent receives a work item that they can't actually work on in your source system for whatever reason(too soon, customer not available, etc). In my opinion, there are two ways to do this - 1) you could easily add a button in your source system to restart the work item using the
restart endpoint - ( a few assumptions behind that use though - one major one being that your source system that the agent is working in, is also the same system that is keeping track of the API calls to generate the workitems and is storing the necessary identifiers to later call the API.) 2) The other is that the genesys iwd task and the task in your source system is not a 1:1 relationship. It is actually a many Genesys iwd task to 1 source system transaction. The second way listed is how I am handling this in our scenario. Where for whatever reason, we have to make another attempt at a later time (ie: Customer not available when agent works the workitem). We are actually tracking this attempt counter for each transaction in two places - unfortunately, for us, our source system does not have the capability to reach external API endpoints, so we have to use a middleware solution - So we had to build logic to say okay - source system has 0 attempts made to work this item, create iwd task attempt 1, let that route through iwd to an agent, then the agent takes action in the source system ( either actually does the necessary transaction or notates that they did the attempt), the agent then marks the iwd task done and becomes available again. The logic then works in a loop to say if the source system transaction is still open, and has the 1st attempt done, then create the iwd task attempt #2, (with an estimated future planned start date/time that the next attempt will be successful or the business process requires) and continues this loop of +1 attempt, until the source system transaction has been completed.
Here is the reason I mention these two ways - 1) restarting the work item, while I haven't validated, I would be led to believe that you will lose the original agents reporting as the reporting is on the "last resource".
2) using method 2, you are more accurately stating the true volume of the work, in the case of 100 source system activities, you could be required to actually make 200 iwd tasks, because of 50% contact success when working the task.
3) when using restart, you are essentially "resetting" the worktime, which means it immediately goes back in line, and will be routed immediately again - most likely too soon.
There are a few other things that come to my mind when walking through this solution that should be considered if you haven't already:
- Does the task require you to contact an end customer? If the answer is Yes, you need to ensure you have data point from your source system into the iwd task creation to track this - 1) routing rules need to be added around this to prevent routing a task too early or too late to be worked and B) endpoint segmentation by this data point needs to be done to ensure that if you are getting a constant flow of work from all time zones.
Hope this helps,
-Austin
------------------------------
Austin Brigham
WHIRLPOOL CORPORATION
------------------------------
Original Message:
Sent: 03-11-2021 14:23
From: Bryan Benway
Subject: IWD Task API - Lifecycle
That is extremely helpful. Thank you for that clarification. I am scoping something very similar so that UI change is interesting but not an issue.
For #3 we are using IWD to hand the task to the agent so it is being assigned to them. The info in the task they need to go to a third party system currently to do some work so once that system sees the entry complete, we want to then CANCEL the task but make sure that it will still shown as the agent worked it as it is assigned to them by IWD.
------------------------------
Bryan Benway
Waterfield Technologies, Inc.
Original Message:
Sent: 03-11-2021 13:59
From: Austin Brigham
Subject: IWD Task API - Lifecycle
Hey Bryan -
Jim's rely below is spot on.
However, keep in mind that there is a few "gotchas" here.
1) the only place you will see this differentiated is iwd manager:
"Completed" by itself is when using the cancel API end point. "Completed with the agent icon" is when it was completed by an agent in agent desktop.
*note there are three different versions of viewing the state, the simple version all workitems regardless of how they were completed show "Completed" only.
2) There is not a differentiation in the reporting. We are using this endpoint to close workitems that were addressed through self-service.
3) you mention using this endpoint, versus an agent going and closing it. That is only possible if it was routed to an agent. An agent can't search for a workitem and close it without being routed.
Background - We went live using iWD on 2/24 - I'm using the three basic actions - create - update - cancel. replicating CRUD operations as needed to match our source system. I'm happy to walk you through our setup from end to end as a customer point of view if you are interested. Just send me a message.
------------------------------
Austin Brigham
WHIRLPOOL CORPORATION
Original Message:
Sent: 03-10-2021 14:44
From: Bryan Benway
Subject: IWD Task API - Lifecycle
I am reviewing the documents to allow a third party to push work to IWD for distribution and trying to find one key item that I am not locating anywhere.
Is there any way via the API to set a work item to completed or are we limited to the agent having to mark it manually when they are done?
I am only seeing PUT methods to change properties and trying to confirm if this can be used to set the task to competed to remove a step from the agents having to do so manually.
Intelligent Workload Distribution API - PureEngage Developer Center | Genesys (genesyscloud.com)
#Integrations
------------------------------
Bryan
------------------------------