Tip For Creating Complex Before Query Business Rules

Before query business rules are great! I absolutely love them and use them all the time.

Sometimes though, I do find myself getting into a bit of a twist with the logic in the code.

Before I show you what I do now to overcome it, i’ll quickly explain what a before query business rule is. Put simply, it’s exactly as the name implies. It’s a business rule that runs before querying the database. More specifically, it can add additional query parameters to the search automatically and invisibly to the user.

For example, if a user wants to view all users, they can go to the sys_user table with no query parameters.

The system will essentially do the following code to bring back the results:

var current = new GlideRecord('sys_user');
current.query();

Now, if you want to only allow users to view active users, this is where a before query business rule comes into play. If I gave you the above script and asked you to only return active users, you would amend the code to be:

var current = new GlideRecord('sys_user');
current.addActiveQuery();
current.query();

A before query business rule is no different. You’d create the business rule and add the line current.addActiveQuery() to the body and that’s it (side note, a before query business rule is one where the ‘when’ field is set as before and the ‘query checkbox is ticked’). So essentially, the before query business rule is made to add additional query conditions to the query GlideRecord. The above example can be seen in the business rule called ‘user query’ out of the box on the sys_user table.

Now that’s out of the way, adding a simple parameter like above to a query is simple, but when you have 5/6 different parameters and different conditions for each one, and different values, things gets a little/lot more complicated.

The way I get around that is simple.
Continue reading