Assigned to and Assignment Group

[David Yearsley]

In the next few weeks Incident will be implemented. There is a new issue that is causing problems. There are very strict rules regarding Assigned To and Assignment Group. This information is critical to reporting. Some of the programming is now creating issues. There is too much programming on these fields.

On these fields we have data lookup and Business rules with field overrides.

The first programming is a Data Lookup that populates various fields. The Data Lookup has created several issues. Is Data Lookup a recommended way to populate data? Is there a better way to populate the fields.

In the end what we want to happen is when the Incident is first populated, it should default to a group value that is stored in another table. (This is done with a data lookup). Then if the user clears out the group and types in a user the Assignment group is restricted to the users groups.

Finally there is an issue if the select a template. The big issue is when a template is selected certain programming should not run. When you use a template is there any information captured that indicates you used a template.

I know this is confusing, the issue with templates is the most pressing.

Thanks

[TrevorK]

"Then if the user clears out the group and types in a user the Assignment group is restricted to the users groups."

I believe for this you will need to add the BackfillAssignmentGroup function:
http://wiki.servicenow.com/index.php?title=Reference_Qualifiers#Examples
This will constrain the assignment group to those of the assigned to user.


As for your template question, sorry, I do not use templates. I would assume the easiest solution is to just create a field on Incident to store the "Template Used" value and manually populate it every time a template is used (such a field does not appear to exist in our instance). This field would not be visible to the user or anything, just a field that you use for your record keeping. I'm not sure if there are more advanced solutions, however this would obviously meet your needs as you'd have a value to filter on when you run your business rules (I assume that's where "certain programming" you refer to occurs). Storing it in a field would allow you to continually use it throughout the life of the incident as well as report on it.

[Daniel Draes]

Hi,

trying to comment the whole set of questions 🙂

a) is data lookup a preferred way ?
If data lookup is implemented in onChange events on the Client side - NO! We try to avoid this as this is considerable impacting the responsiveness of the UI to the user. However, there are certain occasions where you need it.

b) The automatic assignment of an assignment group is typically done via Assignment Rules. This should help as it only runs if the assignment group is empty and does not need and lookup code.

c) Limiting the assignment groups to certain groups
If I understand your question correctly, than you have at least two types of groups in the system. Probably assignment groups and privilege groups. Pretty common scenario. The way to filter on the field in the form is via a dictionary filter. You can add a reference qualifier for any field on the sys_group table like 'u_is_assignment=true'.

d) template: yes, the GlideForm does know if it is populated via a template or not. E.g. if you run a script onChange of a field it will get the parameter isTemplate. So you should be able to react based on the information template yes/no.

Hope that helps.

[David Yearsley · Accepted solution]

Changed the Data Lookup to only run on the initial load and then the business rules to run later.