Auto resolution

[LawesD]

We have a few jobs that are set to auto-resolve based on the outcome of a task -  it leads to an update status node set to resolved (resolution text and closure category already being set).

 Until recently these worked without fault. Now they are only consistently resolving when they have an analyst accept them beforehand. These used to work after only being assigned to a team.

 

 

[Steven Boardman]

Hi @LawesD i've run a basic test and in a scenario where a request is assigned only to a team, and a team member completes a task the outcome branches and then automatically adds a resolution category and in turn sets the status to resolved. 

Could you share your business process where you are having this issue - could you explain after the task outcome is it all automatic actions to set resolution text, category and then update the status?

Also reading your description does this fail to update the status every time there is no owner (only team), or does it sometimes complete when there is no owner?

 

[LawesD]

Thanks for taking a look, and yes they are all automatic actions. 

I've attached the downloaded bpm file of a test I made when we thought it may have been the order of the nodes causing the issues. I just attached it to our simplest PCF (adobe activation).

So four variations each auto-resolving (see picture). I logged 4 jobs choosing a different path each time, every one of which stayed open when completing the task.

I then logged 4 again, assigned the jobs to me first,  and then completed the task. They all resolved. 

We've got this in a few BPMs and it seems consistent in its behavior to leave the jobs open. 

 

 

auto-resolve-test.bpm.txt

[Steven Boardman]

@LawesD i've taken your process and tweaked the teams, mailboxes, closure categories etc to work with the data set on my instance, but i have left the whole structure of the process in tact.   

I have raised both Incidents, and Service Requests using this process both from the user app (Agent) and as an end user on My Services and on every occasion the process completes and resolves the ticket.

* As you can see below there is no owner on the tickets, the process simply assigned it to my 1st Line Support team.

* The task was also assigned to my 1st line support team 

* I have tried each outcome to the task (1-4) and again they all resolve the tickets when there is no owner on the request.

 

It is a bit puzzling for sure. 

A couple more questions if i can

* When there is no owner assigned, do any of the automated actions occur? i.e updating of the closure category?  I am trying to understand if the process moves forward before the task node?

* The 'team' you have the task assigned to, is this a grouping defined as a team, or perhaps something else like a department, division, general etc?

 

if you could run this through again could you open the developer console on the browser and let us know if any errors are shown when you select an outcome on the task when there is no owner on the request?

To do this on chrome, use the three dots in the browser bar > more tools > developer tools > then find Console by looking at the >> arrow drop down.  If you then clear the console content using what looks like the no entry sign.

Once here can you choose an outcome to the task and let us know if an error is then shown in the console area below?

 

let us know how you get on

Steve

[LawesD]

Hi Steve, 

I know this is not going to be much use to you but it seems every node has done its job.

The resolution notification is already input, and the description and closure category are both updated. All there is to do after assigning an analyst is clicking on the resolve button. 

It is specifically a team the jobs are assigned to. 

Nothing whatsoever pops up in the developer console when trying these.

I'm a little stumped.

 

[Steven Boardman]

@LawesD this is a strange one, i've done some more testing and i just can't seem to get it to fail at all   i've reached out to some colleagues in the support team and have asked them to take a look at this thread tomorrow, see if they can spot anything i may have missed. 

[James Ainsworth]

Hi @LawesD

In my testing I found that this Service Manager setting..

is being respected by the BPM status change.  With this setting switched to On the request consistently was set to resolved, and with this set to Off it was left open.  I will check with development to see if there has been any changes in the logic.  The difference in behaviour might be due to this setting being set to Off on your instance.  However, I would like to think that the BPM operation for changing the status shouldn't use this setting as the the workflow itself can take care of the logic around resolving with or without an owner.  I'll speak with our development team.

Regards,

James

[LawesD]

Hi @James Ainsworth

Thanks for the suggestion we do have this setting turned to off but do not wish our analysts the ability to resolve jobs without first assigning it. 

Is this switch a new addition in an update and the functionality is encompassing automated actions as well as manual ones? 

 

 

[James Ainsworth]

The setting has been there for some time.  I'm not aware of any changes, but if there were it might be that somehow the BPM operation for updating the status was changed to check this setting.  We have a defect raised for this and hopefully a Service Manager update will be provided soon.  As a workaround, you could add a check in your BPM workflow to make sure an owner is assigned, and either add a Suspend and Wait for owner, or just add an owner.