Client script to set assignment group automatically ... depending on type ?!

[Zod]

Again I'm struggling with my poor developer knowhow and would appreciate some help.

I'd like to a client script on change of assigned_to that sets the assignment_group if the group is empty and the assigned_to to only belongs to ONE group with a specific group_type ...

>>> this is what I get on change of assigned_to ...

onChange script error: ReferenceError: assignment_group is not defined function onChange_incident_assigned_to_4(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue == '') { return; } if (assignment_group == '') { var gr = new GlideRecord("sys_user_grmember"); gr.addQuery('user',assigned_to); gr.addQuery('group.type','CONTAINS', "incident"); gr.query(); if (gr.getRowCount() == '1'); assignment_group = gr.group; } }

To clarify ... a group could belong to more than one type at a time ... and if the user belongs to more than one group with the specific type - nothing should happen.

[Dave Smith1]

vemffm wrote:

The requirement came direct out of the daily work of the service desk.

Did anyone actually analyse them?   It feels like someone's taken a set of requirements then rushed headlong into implementation without reviewing them for clarity or business value.   I mean: is this the way the service desk actually work?

if during the process it is clear, that mr. X should go ahead working on the ticket,

What makes it clear?   What's the criteria?   Who decides this?

But the form required a group too 

So, has someone made the group field mandatory?   What is the justification behind this decision?

but which one to assign if he is part of more groups???

What's the Service Desk's answer?   What's the criteria they decide upon?

Auto-assignment rules simply automate the decision-making process performed by first line - rather than have a human guess the right group, specific aspects of the ticket should determine the correct functional escalation path, getting the ticket in front of the right group automatically.

If a ticket comes in and the SD need to assign it to MrX AND a group... if they can't justify why they picked a particular group, then (a) you can't create an autoassign rule for it, and (b) why did they pick that group in the first place?

I'm glad you got your task sorted, but it really feels like you've correctly implemented a broken processes.   If it works for you, great stuff!

[Zod]

Hey Dave,

thanks 4 your concern.

I never claimed this to be an overall valid requirement - I mean general best practice ... .

This really depends on the environment at the customer. In this case we are talking about an quite small customer base working with incident management, and a culture where people know each other ... not a big international company with 300.000 people.

The groups are required that tickets do not get lost and for SLA purpose ... but I'm sure the customer could do an similar good job when not using groups at all ... .

So no worries ... I'm quite professional with requirements engineering, process management, itil and also working in software implementation projects since 20 years ... just my development skills where never really required ... so just starting with coding in the service-now area to be able to more or less serve the customer in all needs (as not each role could be stuffed with a new person .... )

Anyhow - thanks for the advise 😉

[Dave Smith1]

vemffm wrote:

I never claimed this to be an overall valid requirement - I mean general best practice ... .

General best practise is:

1. auto-assign a group, let group members determine whom will take on task responsibility
2. manually assign a group, let group members determine whom will take on task responsibility

Assigning individuals isn't considered best practise because assignment rules (generally) don't take into account external factors, e.g.:

• how much work does that individual already have on their plate?
• are they available/unavailable? (holiday, sickness, etc)
• is there something else in the ticket notes that could mean someone else in that group may be better suited?

- in other words, it's creating a SPOF that may go unnoticed.

So, compare that to your requirements... do you think whomever specified the requirement is aware of best practise, or did they simply want a specific practise to be implemented without understanding business value?

This really depends on the environment at the customer. In this case we are talking about an quite small customer base working with incident management, and a culture where people know each other ... not a big international company with 300.000 people.

That's very true; it is pointless over-engineering a solution when "keep it simple" will deliver business value early.   However, I hope you have made the customer aware that whatever small-scale solution currently provided is appropriate for that size - if they don't see themselves growing, they won't have any issues.  

In my experience, I have encountered many client sites that never planned for long-term growth and never took the opportunity (when they had it) to scale up their systems accordingly - and are now finding things creaking because they long exceeded the capacity of the legacy solution and it's limiting their productivity.   Best practise means the design should encompass wider holistic aspects (STAMP: service/tools/architecture/metrics/processes) rather than the narrow "what the customer asked for".

just my development skills where never really required ... so just starting with coding in the service-now area to be able to more or less serve the customer in all needs (as not each role could be stuffed with a new person .... )

I'm not sure that using a customer production system is the most appropriate environment if you are "just starting with coding" - if you're expected to provide this as a chargeable service, attending our Scripting course plus building up some experience and expertise should really be considered a pre-requisite to delivering quality results:   http://www.servicenow.com/services/training-and-certification/scripting-in-servicenow-training.html

Good luck with it!

[Zod]

"I never claimed this to be an overall valid requirement - I mean general best practice ... .   "   >>> meaning this is not to be seen as best practice. And as I sad, the people manually assigning it to someone, know that it is the right guy - as he is sitting 5m away from him and they already talked about it ... . So no need to sent to a group to wait for a dispatcher doing his job ...

[Dave Smith1]

And as I sad, the people manually assigning it to someone, know that it is the right guy - as he is sitting 5m away from him and they already talked about it ... . 

So is the assignment decision based upon whom they talked to, or whom sits closest?   I'm not sure you can create an auto-assignment rule for that logic.

Auto-Assignment works best when 80% of common cases can be defined with clear business logic, then implemented.   I've experienced people deciding upon a rule, implementing it... then suddenly realising another rule and finding the implementation of that rule interferes with the prior one.

I've encouraged them to sit down and properly clarify the exact decision-making process to determine ticket routing, prioritise the ruleset then build a set of test cases that exercise each decision path (and several that should fall through).   It takes time, but it meant it was done properly and worked for a high percentage of cases.

As with anything, every process is as efficient and robust as you design it to be.   Scrimp on design, and don't expect high quality emerging at the other end.

Just to throw another spanner in the works: client scripts work when someone manually opens/amends the ticket... which means any functionality you build client-side may be bypassed if the ticket is raised through the service portal or auto-generated via some alerting system.

Hope that helps - good luck!