How do I create a Dynamic Group from sys_user table?

[andrew_b]

I would like the ability to create a group in ServiceNow that is dynamically updated based on a user attribute. 

Since I have all my users in our sys_user table, I would like to setup a business rule that runs a query that populates a group in ServiceNow based on an attribute. The end goal is to make three individual dynamic groups that contain faculty, staff and students . (FYI: It's dynamic becasue my sys_user table is updated via a transform map that pulls from our Active Directory) 

Table: sys_user
Field: u_user_type
Type: reference
Reference: u_user_affiliation
Reference Qual: u_active=true^EQ
Max Length: 40

 Possible Values: faculty, staff or student

My assumption is that I would need to make a business rule on the sys_user table to check for the field u_user_type and has the attribute faculty. 

Here is where I need some help. I'm not a developer for service now but I have a some  programming experience. I hate to farm this job out so I'm determined to figure this out for myself. I need some help understanding how to accomplish this task. I have looked at business rules and I think that's the direction that I need to go but I get lost when setting it up. 

Any help would be greatly appreciated. 

Here is what I have put together for the query so far... 

var target = new GlideRecord('sys_user');
target.addQuery('u_user_type',faculty);
target.query(); // Issue the query to the database to get relevant records
while (target.next()) {
// add code here to process the incident record
}

[Allen Andreas]

The BR gets queried to see if it qualifies, but the condition prevents it from actually running...so...I would suspect negligible performance hit from a simple query to see if it should run or not...and I think we're getting in to technicalities when there are far more situations than this one where a reverse suggestion would be considered.

I would imagine that it would be very rare for a student to now become staff or faculty...making their type change in the middle of the day. So again, negligible when this would actually be ran. I would also suspect that access is very important...so this would need to be addressed in the moment that change is made, versus once a day in a scheduled script? Not sure, so I didn't suggest it that way. Anytime access is a concern...in the moment is always better, in my opinion, than a once a day scan.

However...after reading the original post again...if this is all happening after like an LDAP sync...you could consider running this in an onAfter script on your sync...and handling it then instead of doing either of our suggestions of a BR or Scheduled Script.

If your type is being applied then, then you could also handle the group membership then too.

I would suggest taking a look at on onAfter, but you can still use the core of my script, you'd just need to change a few things.

You may also still need to use the BR method...for in the moment changes (if there is ever a chance).

Here's a link with some examples of using that: https://community.servicenow.com/community?id=community_question&sys_id=2fe153eddbdcdbc01dcaf3231f96...

Please mark reply as Helpful/Correct, if applicable. Thanks!