BackfillAssignmentGroup() - why is this so popular?

[scottatah]

Hey Everyone,

We had a partner company aide us with our implementation of ServiceNow and one of the things they did was create a global business rule to both constrain the assignment group based on type as well as constrain it according to the assigned to.   Similar functionality to what ServiceNow explains here:   Reference Qualifiers - ServiceNow Wiki So my question is, why is this so popular?   The folks that helped with our implementation were very smart, and I suspect that much of what they did prepared us for down the road, but I don't always understand why or how up front.   Hopefully y'all can help and explain what the common benefits of constraining the assignment group by assigned to are?  

While I do need to constrain the assignment group by type, I've never been a huge fan of the assignment group being constrained by the assigned to.   It's a pain in the...when trying to reassign an incident, for example.   It's also causing me some issues with some more recent development plans where i'd like to make the assigned to on the problem table read-only, call it the Problem Owner, and have it filled automatically based on the assignment group.   Problem is, because the assignment group is constrained by the assigned to and it's value is read-only, we can't really change the Assignment Group after it's been set.

My plan B was to disable the global business rule (which constrains the assignment group based on assigned to and by group type), use a simple reference qualifier on the assignment group to constrain it to the appropriate group type and then create a client script on the task table to be inherrited by all child tables to clear the assigned to field on change of the assignment group.

Thanks,

Scott

[aaron_damyen]

Hi Scott Kolenc,

My instance has been using the BackfillAssignmentGroup business rule/reference qualifier for the last six years.   We have had to do some training with some of our users coming from other systems who are having troubles using this functionality.

Basically, the purpose for the business rule is to help enforce a common business practice: assigning tasks to groups instead of individual people.   We use groups to represent people who have similar skills (like Windows Server administrators, or ERP application support) with the notion that anyone in the group could perform the work needed for the task or be able to direct the task to the correct person.   We don't have groups for very broad distinctions, like the IT Department or all people in a region/site.

So, when tasks are created, they are assigned to a group (we actually have Assignment Group as a mandatory field).   Normal resolvers are able to see all of the tasks assigned directly to them and those in the group queue (Assigned To is Empty) from their homepage through the gauges.   Thus, they have a list of what they are working on and what work is still available/unclaimed.

Our struggle with this concept has been with certain sites.   As our company has grown from a garage to global enterprise, there are still many who would prefer to assign each task to a single person.   But, the drawbacks are pretty significant.   Users who are on vacation have tasks sitting.   None of the other team members can see that the task is there (most non-managerial users filter out any tasks directly assigned to others).   For customer experience, this becomes a huge problem very quickly.   Customers seemed to be more receptive to an unfinished task sitting in a queue than sitting assigned to someone (ownership seems to imply activity).

We have had some significant wins with this practice.   Managers have been able to create trend reports for the number of tasks assigned to a group but not a person.   This trend report represents a burn-down list for them and helps them gauge the velocity of their team (how well they are keeping up with demand).   Additionally, anyone who has a lot of tasks assigned to them are reviewed to understand why they are not able to complete the tasks, like a personal velocity.

The biggest win, however, is that the people who are creating the tasks do not need to know a specific person.   Turnover is highly disruptive in a smaller company as there is a greater chance for employees to know others by name and have knowledge of their skills.   In large companies or global enterprises, this just isn't practical.   Thus, informing everyone in the company and changing their perceptions is significantly more difficult than changing the membership of the Group.   For those scientists, O(number of company employees) versus O(1).   Our practices have shown that we change groups (splitting one large one into two or combining two into one) happens once every 2 months (175 groups), but our user turnover is a lot higher (over 50 today).

Hopefully this helps understand why we use the backfill business rule.   The needs and operational patterns for our company may not be appropriate for yours.   If Business Scalability is going to be concern soon, analyzing the use of Groups and assignments will be helpful in determining whether you will need the business rule.

Aaron

[Uncle Rob]

I think its popular for two reasons:

1)   Consistent Accountability

Say Joe is a member of Group A.   The ticket is assigned to Joe with an assignment group of Group B.   Who's going to be accountable for the work?   Joe sees that its Group B's problem (as evidenced by Assignment Group).   Group B sees its Joe's problem (as evidenced by Assigned To).   By ensuring group and user are dependent on each other, we essentially have two scales of accountability.   "This ticket is being managed by Group X, and within that group it belongs to Person X"

2)   Better resource allocation.

"Who do I assign this task to on your team"?   Answer:   YOU don't worry about that.   You assign it to my team and we'll split the work up as we see fit.   Otherwise, your most popular resources will find they're assigned everything.   Assignment should always start at the group level.   Once in the group, that group decides how to allocate.

But the UI still sucks

Yes.   It can still be confusing to people used to systems with only one tier of assignment.   It can also feel "tangled" when I've got a user and I need to switch the group.   "Oooops, I forgot to null out user first".   So this is what I usually do.   I usually take a hardline stance on assignment.     DON'T assign to an individual - that is the exclusive privilege of the group they belong to.   Go ahead and re-assign tasks to groups all you like.   Don't use the backfill group rule, but instead impose a different rule that auto-nulls the Assigned-To if you change the group value.   That removes the friction of re-assignment to groups AND keeps the primary benefits of 1 & 2.

[Kristian Johns3]

There's also the benefit that this feature acts as a reverse lookup for group names. If you need to reassign a ticket to person X's group, but you don't know the name of that group, you can fill in person X as the "assigned to" and then select from the filtered list of groups. What we do is make the assignment group mandatory, and when the assignment group is changed, the assigned_to is automatically Nulled out. This can be annoying for those that really want to just assign it to a single person, but for the cost a few extra clicks to those people (when filling out the "assigned to" a second time), it becomes a lot easier to enforce group assignments and to make them accurate.