Auto Assign and Assign to Creator

[SimonSheldon]

Morning All

I've recently modified our BPM's so that they auto assign based on most available agent but with a caveat that if the call is logged via the "Analyst" method it assigns to the Creator instead.  This is causing us some issues in that if a call is logged by some one not in the "1st Line" team, or by someone in the 1st Line team who doesn't have "Assign to" set to on  the BPM fails - is there a way of checking and reacting to this? I have changed the "Assign to Team" in the BPM Node to "Auto" but I'm presuming it takes the default Assign to Team from settings?

[Bob Dickinson]

Hi @SimonSheldon

If you are using the "Assign to Request Creator" node, then you DO have to specify a default team (e.g. 1st Line Support) - this is only really suitable if you know that whoever is raising the request that will be using this particular Business Process will be a member of this team AND be available to be assigned a ticket. 

If you have scenarios where this won't be the case, then we do not have a "Get Creator Details" style node that can check this unfortunately. But we do have another method where you can assign to the request creator regardless of the team they are a member of. Please see this post:
 

Hopefully this could be an option for you?
 

In regards to the error message you posted above....Is that related to this particular issue? It looks as though that is to do with a task creation rather than an assignment - and also trying to assign the task to one of our default system accounts. Was this a ticket that was created via Email Routing Rules?

Kind Regards

Bob

[SimonSheldon]

Thanks Bob - yes the error occurs when it can't assign to the creator (as they don't have the Assign To set) and when it then tries to create the task for the Owener (For Tasks) in the BPM the error appears... which then stops the BPM in its tracks with lots of big red lines! :-)

I'll have a look at what you've posted above and see if that works and let you know.

Cheers

Simon

[SimonSheldon]

OK - changed as per your previous post and still failing when it goes to assign the first task based on Owner (for Tasks).

This is the error in Analyst portal - fails on task creation and note the owner is set to "No Owner" even though I've modified to use variable... 

Task assignment in BPM that this is failing on is below:

[Bob Dickinson]

Hi @SimonSheldon

So the reason the task causes an error is clear - as you mentioned, it trying to assign it to an Owner has not yet been set. 

So to troubleshoot this, we need to focus a bit more on WHY the owner has not yet been set - you have a check point saying that the Owner has been assigned, but it hasn't so we have a issue here. 
So if you can provide the following we might be able to assist:

1) Who is raising the request? (Which Analyst - and are they a member of at least one team of which they are an assignee?)
2) Who are they raising this? Is it from the Shared Mailbox, or using one of the "Raise New" buttons?
3) A screenshot of your current BPM config for this stage - specifically the configuration you have around the assignment and how this has been configured (or you can PM me the definition for this BPM if you prefer)

Kind Regards

Bob

[SimonSheldon]

Hi Bob

This call was logged by me and I'm a member of the 1st Line team but with No Assignment set - I am however a member of 2 other teams with assignment set to on.

This was logged from the Raise New button - this is the only option we allow the call to be assigned to creator - any other method (Self Service/Email) it assigns based on Most Available agent and that seems to work no problem.#

I'll PM the definition now for you....

Cheers

Simon

[SimonSheldon]

This all works OK if logged by an Analyst from Raise New who is set to Allow Assign in the 1st Line group as below - is the issue that we're assigning the call to a Team (1st Line) before we then do the auto assign?

 

 

[Bob Dickinson]

Hi @SimonSheldon
 

6 minutes ago, SimonSheldon said:

This all works OK if logged by an Analyst from Raise New who is set to Allow Assign in the 1st Line group as below - is the issue that we're assigning the call to a Team (1st Line) before we then do the auto assign?

This is spot on. The "Assign to Owner" variable you have now added will automatically set a default team only if an existing team has not been set against the request. 
Because its already been set to 1st Line, it appears to be causing a conflict as the creator does not existing as an available assignee in this team. 

You don't actually have any need now to include the below highlighted nodes, and the following assignment options should do it all for you - so try removing these (and the checkpoint itself in the stage details) and performing your tests again:



Kind Regards

Bob

[SimonSheldon]

Still getting error and still showing as No Owner once I've removed those steps... Timeline is being stamped with manual update stating its been assigned to owner so that node is running.... 

[Bob Dickinson]

Hi @SimonSheldon

Having had a close look and a test of this, I believe you have discovered an issue that I didn't realise existed previously. 
When using the "Assign to Owner (Variable)" node in your Business Process, Hornbill will look at which teams that person is a member of - and assign the ticket to that person in the first of these teams that it finds. However, it appears that this does not take into account the Assignment availability of this person - so in your example, it finds 1st Line Support as the first support team you are a member of, it does not take into account the fact you cannot be assigned requests in this team, and tries to assign it to you here anyway. 

The timeline of the request states that this has happened - but in actual fact, the assignment rules have been honoured, and instead its assigned to to this (first) team but without an owner (to prevent the ticket from erroring). 
So regardless of how the functionality would be desired to work, the key issue is that the timeline has given us incorrect information - I have raised this with our Product team, and this will be investigated as a defect. 

So unfortunately there isn't a graceful way to achieve what you are after here, but I do have a couple of workarounds:

1) Add a "Suspend Wait for Owner" node

I have added another "Get Request Details" node, and if this issue occurs (i.e. the Owner is not set) we have a Suspend Wait for Owner - this means that the analyst would need to manually select the team and assignee (themselves) in order to progress the request. But by the time it reaches the task, it would have an owner and would no longer error. 

2) Loop back to the "Auto Assign Analyst"



In the same vein, this one looks to see if an owner has been set - and if it hasn't it treats the request as if it had been logged via the portal - ensuring that its automatically assigned to someone, but it would not be the creator  . 

I appreciate neither of these solve the original requirement exactly - but our development team are now aware so hopefully we can make some improvements to this in the future.

Kind Regards

Bob

 

[SimonSheldon]

Good to know and have now done the 1st Option as this is probably the better one for us and it works well for what we need.. I'll keep an eye out for a fix when its available.

Thanks again Bob!

Cheers

Simon

[Logan Graham]

@Bob DickinsonApologies for posting on a old thread but I was wondering if there has been any progress in the ability to either set a default/primary team for users or have this ignore certain teams?

Thanks,

Logan G

[Bob Dickinson]

Hi @Logan Graham

Hope you are well! 

Unfortunately we havn't added anything in this area recently to accomodate a "primary team" as such, it still will select the first team in finds associated to this user if they are a member of multiple teams. I'll follow this up with our development team to see if this is something in the pipeline. 

Kind regards

Bob

[HGrigsby]

+1 for me too please if it helps! 

Just been asked the same, the ability to set a primary team would be really useful.

thanks Helen