How to Amend a default Team

[Ann-MarieHolloway]

Hi Hornbill Experts,

I have a query and can't find any related topics on the forum.

My query is regarding analysts who create a call via a workflow that uses the following in a node:
&[global["flowcode"]["customer"]]
&[global["flowcode"]["createdBy"]]

When the call is raised the customers team is set by default, which is fine unless that customer is a member of a number of teams within Hornbill.
Is there a way to set a default team to ensure their call comes to our call queue?

The Set Home Organisation is greyed out

And I am unable to set it on the Details page

Many Thanks for any assistance
Ann-Marie

[Steve Giller]

The "Home Organisation" on a User Account can only be set to a Company.

There is no concept in Hornbill of a "Default Team"

 

[Ann-MarieHolloway]

Hi @Steve Giller is the Home Organisation pulled from our LDAP import, as the fields are greyed out?

[Steve Giller]

If it's greyed out that would suggest you don't have any Companies defined, as would only having "None" in the dropdown - although there's nothing in your post that indicates where you're seeing this button.

[Ann-MarieHolloway]

Hi @Steve Giller,

Apologies for the omission, the Home Organisation field is in the User Information under 'Details'

 

There is also a Set Home Organisation button on the Organisations tab.

 

It doesn't seem to matter which order I add this users teams, the home team always appears at the bottom of the list, whether it's added first or last.

But the picker always chooses the team at the top of the list.  Therefore when this type of call is created, it automatically assigns it to that user, but in the wrong call queue.

[Steve Giller]

The Set Home Organisation button becomes active when the checkbox next to an Organisation of type Company is ticked.

As mentioned, the Home Organisation dropdown in your screenshot only has "None" in it - this is because you do not have any Organisations of type Company defined. As you can see from my Instance, I have one Company:

and on the Organisations tab if I check that company I see:

 

Just to reiterate, this will have no affect at all on a default Team as this is not something that Hornbill offers.

Take the scenario that UserA is in TeamA and TeamB, and TeamA is their Default Team.
TeamA supports ServiceA and TeamB supports ServiceB
You raise a Request against ServiceB and assign it to UserA

You have told the Workflow to assign to UserA in their Default Team (TeamA) which does not Support ServiceB and cannot be assigned that Request, so things break.

 

[CraigP]

Hi @Ann-MarieHolloway

This has been a frustration for our organisation too. However this thread brought it to the forefront of my mind again and I had an idea that I'm now currently trialling.

I'm not sure if you are using these for something else, but there are custom attribute fields on the user accounts. I've used one of these fields to store the group ID of the "default team" for users who have multiple teams.

Now in the BPM where the owner is assigned, I've first included a "Get User Custom Attributes" node (SM > Application > Users) and then a decision node with a branch checking if the "default team" Attribute field is set. If it is set then it assigns to the user and the team using the group ID in the attribute field, otherwise it just assigns to the user as normal (which will default to their first team alphabetically).

Obviously you need to make sure you don't put anything other than a group ID in that attribute field on any user accounts, and I suppose it's possible (as Steve pointed out above) that the team you have in the attribute field doesn't support the service the request is in, but for us that is not currently a problem because we don't have any users in multiple teams which support different services.

[Emily Patrick]

@CraigP thanks for your suggestion above, as I have tried to do a default team assignment similar to what @Ann-MarieHolloway was asking above, but other than setting the default team in the Workflow, it wouldn't work for our 2nd line team who cover for us, and aren't part of the default team.  

Will have a look at your suggestion and see if it works for us.  Thanks. 

[Ann-MarieHolloway]

On 09/10/2023 at 10:05, CraigP said:

Hi @Ann-MarieHolloway

This has been a frustration for our organisation too. However this thread brought it to the forefront of my mind again and I had an idea that I'm now currently trialling.

I'm not sure if you are using these for something else, but there are custom attribute fields on the user accounts. I've used one of these fields to store the group ID of the "default team" for users who have multiple teams.

Now in the BPM where the owner is assigned, I've first included a "Get User Custom Attributes" node (SM > Application > Users) and then a decision node with a branch checking if the "default team" Attribute field is set. If it is set then it assigns to the user and the team using the group ID in the attribute field, otherwise it just assigns to the user as normal (which will default to their first team alphabetically).

Obviously you need to make sure you don't put anything other than a group ID in that attribute field on any user accounts, and I suppose it's possible (as Steve pointed out above) that the team you have in the attribute field doesn't support the service the request is in, but for us that is not currently a problem because we don't have any users in multiple teams which support different services.

Hi @CraigP this is really useful, thank you.
I'll give it a go with my team and if the rest of ITSM agree I'll roll it out to all analysts.

[CraigP]

Glad to be able to help.

I've done a little more testing and found that the assignment node doesn't fail if you give it a team that doesn't support the Service. In fact, the way "default teams" currently work in Hornbill (if no team is provided to the assignment node, it defaults to the user's first team as it appears alphabetically) seems to also go ahead and assign the team even if that team doesn't support the service.

I'm not 100% certain that it does not cause hidden issues elsewhere, but from my limited testing it seems the owner can still see the call while anyone else in that team (who doesn't support the service under another team) can't see it. The assignment tab's dropdown is blank, but the team field in the database table has the assigned team populated.