User Criteria Issue for Certain Users

[Jackie23]

My company has recently had a reorg where smaller departments have now come together into one large department. Within the department, there is a new Service Desk and Mgt assignment group who will take the ServiceNow tickets assigned to the new group.

They prefer to put in tickets for certain catalog items, mainly purchasing hardware items, because most users don't know what they need/can afford.

For the catalog items they don't want them to see, we have created a user criteria for all the users that fit under this department (using division codes) and put them under the Not Available For tab. The issue is that these new Service Desk and Mgt group also technically belong under these division codes. We have scripted in the user criteria that if they are in either of these two groups they should still see the catalog items. It works for some users in the group, but not all of them.

Also, we have been using the user criteria diagnostics for testing and continuously clearing our cache. Any advice? Even if it is a whole new method on how to approach this.

Simpler terms: We are trying to say 'not available for' users under certain division codes UNLESS you belong to these 2 assignment groups (that happen to have users who are under these division codes which we just said shouldn't see the catalog items).

[johnfeist]

Hi Jackie23,

Based on your description it is hard to know exactly what you have set up.  Including code and screen shots makes it much easier for you to get the answer you need.  Based on what you describe, I'll take a shot.

You must be scripting the criteria since division is not one of the criteria that you get OOTB.  I'm also assuming that you need to do two lookups, one for division and one for group membership.  With those values someone not in one of the divisions in question gets access, someone in one of the divisions who is a member of one of the exception groups gets access and someone who is in one of the divisions but not the exception group doesn't get access.  Are you doing that in two steps in the script or just passing the user to a script include that can return true/false? 

That your current setup is working for some users would indicate that you might be looking at a data level issue.  Since determining group membership should always work, is it possible that you may have one or more divisions mischaracterized?  The only other approach I can suggest is embedding debugging messages in your scripts so that you can track values while impersonating a user for whom everything works and one for whom it doesn't.

[Jackie23 · Accepted solution]

Turns out we had an additional user criteria that was counteracting the one we needed for this new group. We didn't realize the users we were using for testing were also students, so we have removed that user criteria and now it works. 

Thanks for you help!