Did you know about User Criteria?

[Danny Mortense1]

Did you know?

Did you know that Service Catalog and Knowledge Base applications share a feature called User Criteria?

User Criteria allow administrators to control access to content in a service catalog or a knowledge base.

Administrators can create User Criteria so that control of access to content can be applied with the user criteria records. User criteria can be applied to a knowledge base, knowledge article, service catalog item, record producer and/or a service catalog category.

Catalog and knowledge managers and editors can apply existing user criteria for items, categories, knowledge articles, and knowledge bases to which they are assigned. However, managers and editors cannot create or edit user criteria directly, only an administrator can create or edit user criteria records.

This is an awesome feature for administrators, as it means that they are not stuck with the job of setting up a service catalog or knowledge base security determined by the owners of the service catalog or knowledge base.

Managers and editors of a catalog or knowledge base can apply User Criteria. Sure, administrators are still required to set up the User Criteria records in the User Criteria table, but the managers and editors are able to apply these criteria to give access to the appropriate groups of users.

For example, if a manager of HR information in Hong Kong wanted only staff in Hong Kong to be able to see particular HR information in a knowledge base, then the manager can select the appropriate User Criteria that will allow access to users located in Hong Kong. The administrator will set up the specific User Criteria record, but the manager can select this record to make a knowledge base or knowledge article available to users in Hong Kong only.

Still not sure what User Criteria are? Have a look at our docs site for a quick overview.

NOTE: This is one of a series of Did you know posts by me. I will be picking random snippets of information that I feel are useful to know, but may not be common knowledge amongst newer users of ServiceNow.

If you find this information useful then please let me know by making a comment and marking the post as useful.

[Danny Mortense1]

Hey Tim,

Here is a feeble attempt at a script to get you started. It worked fine when testing as a business rule but my minimal testing with User Criteria wasn't that successful and I don't have time to figure out why. Perhaps one of the many JavaScript gurus in the community can help further. Anyway, this may or may not help.

Try this out by selecting the Advanced check box and pasting this into the Script field of the User Criteria.

NOTE: This only checks the first level of the hierarchy, but you can get clever and check multiple levels by splitting the code into more reusable functions that cycle down through the tiers of departments if required.

/*

This script will take the departments listed in the department list type field and check if

they have any child departments.

This script will only check for one level of depatments in the hierachy.

If there are child depatments then the script will check each child department and see if the

currenly logged in user is a member of the department.

If the script finds a user and child department match the result of this script will be true.

NOTE: There is no need for the script to check if the user has a parent department assigned

because this is handled by the Departments List type field on the form above.

This script only checks the first level of child departments.

*/

answer = false;

if (matchDepts(current)) {

answer = true;

}

function matchDepts(current) {

// Is there a deparment in the department list?

if (current.department == '') {

return false;

}

matchFound = false;

// See if the currently logged in user has a deparment assigned

var loggedInUser = new GlideRecord('sys_user');

loggedInUser.addQuery('sys_id', gs.getUserID());

loggedInUser.addQuery('department', '!=', '');

loggedInUser.query();

if (loggedInUser.next()) {

// Place the parent sys_id's from the User Criteria record into an array

var parentDept = [];

var currentDeptList = current.department;

parentDept = currentDeptList.split(',');

// Loop through the parent departments array to check if they have children

for (var i=0; i< parentDept.length; i++) {

var childDept = new GlideRecord("cmn_department");

childDept.addQuery("parent", parentDept[i]);

childDept.query();

// Loop through child departments and check if the user is in that department

while (childDept.next() && !matchFound) {

// Check if the user is in this department.

if (loggedInUser.department == childDept.sys_id) {

matchFound = true;

return true;

}

}

}

}

}

[Tim Owen]

Thank you for the followup information on this. I will try your suggestions soon.

[Danny Mortense1]

Though I wasn't successful with my limited Service Catalog testing, the script did work fine when I tested it with Knowledge base articles. I just need to set up a better test scenario, but I'm confident it works.

If I get time I'll see if I can get a multi-level script working, though I'm hoping someone else jumps on the opportunity to who off their guru JavaScript skills.

*** If you find this or other posts helpful then please click 'Yes' for Helpful and like this post. Thank you.

[Fabrizio Mainar]

Hi Danny,

have you reached this goal?

I'm investigating how to obtain the same behavior and I really really appreciate if you can share your script...

Thank you!

Fabrizio