Query Business Rule Servicenow
Janita Locklin
Well, yes it can be achieved by a query business rule, but a query business rule goes for all queries to the table - so it is not just for a list. It means no one will be able to see incidents assigned to other groups than their own - no matter where they look. I would rather think you can get your view by just adding a filter to a module by having "assignment group is (dynamic) one of my groups".
Also please remember to include that the caller, opened_by or others can see an incident, so you just don't only create a rule about the assignment group, but think about all stakeholders that should be able to view the incident(s).
I think you shouldn't be using query BR for this requirement, if you use query BR then each and every user will be able to see only incidents which are assigned to their group which is not good process wise. There are many other users who needs to see incidents even if they are not part of group.
This blog will take us on a deep dive into Query Business Rules. This guide is going to attempt to explain what Query Rules actually do, stepping through every part of the form and explaining what each part does (and doesn't) do.
The thing that really sets this apart from other Business Rules is that it doesn't always run in the context of a record, but can run in the context of a list! The context is the query, which is a very important concept to wrap your head around when playing around with Query Rules.
We need to remind ourself that these rules are run in the context of a Glide Record Query, not a record like every other Business Rules. Does it even make sense for a Before Query rule to have conditions? Maybe it will add that to the query?
When I started writing this blog, I felt that they didn't even belong under the category of Business Rules. After all, filter conditions and set values don't do anything and often break your rules completely. Order isn't really necessary as generally you only need one Query rule, however, I do think it is good practice to create one rule per role that you are applying the query to. They are very different from every other type of Business Rule and I thought they would have made more sense as being a special rule on the Table itself.
After exploring the many facets of Query Rules, it makes perfect sense for them to be Business Rules. I wasn't thinking about Query rules the wrong way - I was thinking about Business Rules the wrong way! They are not rules that are performed on a record, but rules applied to the GlideRecord object, which could be just one record - or a query of record(s). Then it starts to make more sense.
I feel it would just be easier if ServiceNow provided the option for ACL's to obscure the number of results the user can't see. As far as I can tell, that would eliminate the need for Query rules altogether.
Query business rules let you run code and possibly modify a query before/after the query is executed. This is useful if you don't want anyone to see inactive users. There'a OOB business rule doing this for non-admins.
I've recently encountered the same situation. I solved the problem by setting the reference qualifier on the variable to "activeANYTHING". Inside the "User Query" business rule I do something similar to:
I am creating a before query Business Rule that restricts record access based on if the current user has a matching role that the current assignment group also has. I have a strictly basic understanding of scripting so I have started by creating the following Business Rule which is currently working for showing the user only the records of the groups they belong to or if they are the customer of the record:
Thank you all, I have opted to use a specific Assignment group type for this. For each department that needs to be separated, I have created a type that I have applied to the entire department's groups and I am matching the department specific role to the type in the business rule like so:
You would need to run a gliderecord, query pretty much everything and loop through each record. In a single loop, you would need to check for the assignment group and get all the roles, then compare it to the user roles to find a match. If they match, add the record's sys_id to an array. After looping through the entire query, you should have an array of sys_id's. You would then do something like this:
This would be a performance hog though. It would have to run through this each time someone tried to access any record on the table this business rule is on, and if it has a lot of records, it would take even longer.
I recently had to explain to someone the difference between Query BR and ACLs and realized that this is an ongoing debate topic for many people. Opinions on which method of restricting access is preferred are quite divided.
The ACL way of showing records can be annoying for users who sometimes have to click through a lot of empty pages to get to the records they want to see. It also makes bulk editing from list difficult.
Edit (based on fredjean's comment below): You should avoid using ^NQ (master OR) operators in Query BR queries. This can cause issues mentioned in the below article: =kb_article_view&sysparm_article=KB0564887
I use both of these methods depending on the specific case. For sure, if you decide to go with Query Business Rules, it helps to have them properly documented somewhere, as it is a much less natural and obious place to look for any access restrictions.
Let me add one more thing - Query BRs can be put to good use to restrict the visibility of Modules/Applications to some users, if advanced/scripted conditions are required. Still, make sure to document this and make all admins aware where to look.
Very interesting topic and a helpful breakdown. I am a senior engineer in ServiceNow's performance support team. Regarding the topic of Performance impact, I would add that, while there is a potential for a Before Query Business Rule to improve performance, there is also a great possibility for them to cause performance issues.
Every year I am involved in multiple account level performance escalations where custom business rule logic from query business rules is the primary cause of the performance issues. Here's some general ways that I've seen this unfold:
To summarize; Roles, ACL's, Domain Separation and other out-of-box security features are the preferred and recommended method of applying data security and/or segregation to ServiceNow data. They are optimized for performance and cause less technical debt than a custom scripted Query Business Rule. Ideally, if you are attempting to achieve data security/segregation in a way that will result in some logical evaluation before every single call to a frequently accessed table, you should try very hard to use something other than a Before Query Business Rule. It should probably be a last resort when features that are actually designed to accomplish the same goal have been exhausted.
Sorry to beat a dead horse, but just yesterday I was involved in another severe performance degradation due to a custom Before Query Business Rule. A new rule was added to restrict task visibility to only those tasks that are from the same location as the user. The customer had done their due diligence, testing in lower environments, but wasn't able to predict the impact when run at scale on production.
So true. I will certainly escalate that idea. As you may be aware, ServiceNow is currently in the midst of rolling out new UI's that leverage web components . I will escalate this to that team in the hope that eventually the new UI can accommodate this.
I am really a big fan of the above plugin and would really recommend it to anyone seriously considering splitting data and process, but if you absolutely must do this on your own, do not use Query Business Rules for that, however tempting it might appear. It is not a good idea and will seriously impact your instance performance.
Hah, this is probably a topic for another big discussion elsewhere. I don't see a problem using it internally, depending on the requirements - but you sure need to know what you are doing with DS I saw a few cases of DS gone horribly wrong.
So even though I HATE the idea of duplicating the ACL logic in a Query BR, in some cases there currently is no good workaround it seems. So we will have both Query BR and ACLs on same table, firstly because scoped apps require ACLs, and secondly, because I am not risking putting my access checking logic into one BR script which some junior dev can accidentally break.
Good point about pairing BRs with ACL sometimes. Quite often Query BRs are used together with ACLs, especially to remove the warning at the bottom of a list about restricted records/not to force users to click through empty pages. It's good to double check that the users either do not have access to the base table, or to ensure ACLs are in place too.
Again, love the article! Thanks so much for writing it. I'm gonna jump in again with another warning. There is a design problem with using Before Query Business Rules instead of ACLs. It can lead to unexpected behavior in your business logic. The problem is this:
Suppose you have a Script Include that uses a GlideRecord query that collects a group of task records. The code then loops through the results and updates some of them. The script include gets triggered by a Scripted REST Web Service that runs as a certain integration user and has no reason to apply security. It won't be blocked by ACLs since a GlideRecord call from script doesn't get limited by ACLs.
If your Script Include was previously updating any task records where the company was not the same as the integration user, then your Script Include will stop working like it did before! This is just one small example of the type of unexpected behavior that can occur when Before Query Business Rules are used for access control. It all happens because they were never intended to be used as security measures and therefore they execute in contexts where security was not meant to be applied.
4a15465005