execution order assignment rule servicenow

Handling Assignment Rules in ServiceNow

In ServiceNow, if one is looking for automatic assignments then he can rely on the instance’s ability to assign the tasks automatically to different users and groups depending on the specified conditions. In order to achieve this, ServiceNow has the following modules:

• Assignment Lookup Rules
• Assignment Rules

Assignment Lookup Rules:

This module appears under the ‘System Policy application’ menu. This table is basically generated out of the box as its definition is provided in the ‘Data Lookup Definition’ table in the instance, specifically for field assignments in the incident table. Assignment lookup rules mainly provide the functionality of changing any field value and not just the assignment fields.

Assignment Rules:

This module appears under the ‘System Policy application’ menu. It helps to automatically assign the tasks to a particular user or a particular group using the assigned_to and assignment_group fields respectively, depending on the specified set of conditions. One can define these assignment rules readily for their desired table.

Following are the steps for defining the assignment rule:

• Navigate to System Policy -> Assignment -> New

• From the above figure, one can see that the dot-walking can also be done in the condition builder field. Just select the ‘Show Related Fields’ option in the condition and then select the appropriate attribute.
• Further, in the ‘Assign To’ tab, select the appropriate user and group to whom the task is to be assigned.

If two assignment rules conflict, then the assignment rule with the lowest execution order runs first. The lower the execution order, the higher is the precedence.

Distinguishing Factors between the Data Lookup Rules and Assignment Rules:

Precedence among the assignment rule and business rule:

In certain circumstances, the business rules gain precedence over the assignment rules.

The business rules and assignments rules run in the following order:

• All the ‘before record insert’ business rules having order less than 1000.
• First and foremost, assignment rule with lowest execution order and matching condition.
• All the ‘before record insert’ business rules having order more than 1000.
• All the ‘after record insert’ business rules.

We are pretty sure that this blog must have given an overview of dealing with Assignment Rules in ServiceNow.

Any comments\suggestions are most welcome. We have posted further blogs as well on other topics and will frequently come back with something innovative.

Emergys Blog

Recent Articles

Credit Unions to Accelerate Growth with Cost-Effective Hyperautomation

Credit unions are grappling with evolving customer expectations, economic [...]

Credit unions are grappling with evolving customer expectations, economic uncertainty, and growing competition from fintech [...]

Unlocking the Power of Data Warehouse Migration

HR Analytics: The Blueprint for Effective Organizational Management

An effective HR department is the backbone of any [...]

An effective HR department is the backbone of any organization. They recruit top talent, cultivate [...]

Whether you want to see our solutions in action or just have a few questions, get in touch with us.

You’ll hear back from us within one business day.

Enterprise Solutions

Data & Analytics

Modern Applications

Copyright © 2024 EMERGYS All rights reserved.

Copyright © 2023 Emergys All rights reserved.

Privacy Policy | Terms of Use

• Integrations
• ServiceNow Basics
• Service Mapping
• Scripting In ServiceNow

business rules in servicenow

Table of Contents

Business Rule overview

What is business rule?

A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried.

When business rules run

Business rules run based on two sets of criteria:

• The time that the business rule is configured to run relative to a record being modified or accessed.
• The database operation that the system takes on the record.

How to navigate to business rule in ServiceNow

• Go to System Definitions > Business Rules .
• Click  New .
• Fill in the fields, as appropriate.

Let’s have a closer look on the business rule form and see the purpose of each field.

Note – Delete and Query operations are available only when advanced checkbox is true.

Thanks for reading this article, i hope you liked it, if that so, do like and subscribe my YouTube channel. You can also join our telegram channel to clear your technical doubt.

YouTube Channel

Telegram Group

Facebook Group

Linked-In Group

Types of business rules in ServiceNow

We have four different type of business rules present in our system.

Let’s understand each one of them in detail

Before business rule

Before BR as name itself justify works Before a record is saved to the database. Business rules execute after form submission and before the record update in the database. It runs before the database operation, so no extra operations are required.

As shown in the figure above the user provides an input before BR is executed and then only changes are made to the database.

Scenario – We need to copy the short description from variable present on RITM to the short description of catalog task.

We will start by creating a new Before BR filling all the required fields.

Here is the script to achieve the above-mentioned scenario.

After business rule

After a record is saved to the database. Business Rules execute after form submission and after the record update in the database.

Scenario – We need to close the task if the respective RITM moves to Closed incomplete.

We will start by creating a new After BR filling all the required fields.

Async business rule

Async Business Rules run after records are inserted/modified/queried. Async and after works similar the only difference is async run asynchronously as Scheduled Jobs. Async BR are queued by the scheduler to run as soon as they can be fit in. This allows the current transaction to finish without waiting for the rule and give the control back to user to continue working.

Tip – Use async Business Rules instead of after Business Rules whenever possible.

Scenario : Attachment add to a particular variable in a certain catalog item should get attach to the record as well.

We all are aware that attachment made to a variable in any catalog item is not attached to the record itself and make it somehow difficult to send the same attachment via notification for the respective record. So, to achieve the same we are using Async Business Rule. Now, why async not after BR the answer is attachment might take time to get attach to the record so to make this smooth and without blocking user experience, we will be using this.

We will start by creating a new Async BR filling all the required fields, here we want this BR for a particular catalog item, so we are mentioning the same under filter conditions.

Display business rule

Display Business Rules run after the data is read from the database and before the form is presented back to the user. Display Business Rules execute when a user requests a record form.

Scenario – We need to set certain values on incident form if the logged in user is member of a particular group.

To achieve this use case, we first need to create a Display BR and then call the same in our client script. Please refer to the below attached screenshots.

Here is the BR to fulfil our work at server side.

Now, moving onto the client-side scripting to see how this g_scratchpad is called, and our requirement is achieved.

Before Query Business rule

Other than the four above mentioned rules we have Before Query rule. It is a type of business rule in ServiceNow that we can use to limit that what all records users can access from a given table. In other words, we can also say that it is used for data segregation on an instance. To understand this more clearly see the scenario mentioned below.

Scenario – We need to restrict the visibility of incident on our instance in such as way that user should only be able to view them if he is a part of the assignment group to which that incident is being assigned or is the caller for that incident.

We will start by creating a new Before BR and selecting the query operation then filling all the required fields.

Here is the script to achieve the above-mentioned scenario. In this you can see we have used the condition under advanced section to disable this rule if the user is ‘admin’.

Why should we use Before Query instead of ACL?

With the concept of before query first question which comes to our mind is that why we actual need this when we have ACL for restricting any kind of record in system. The answer is when Query BR restrict the access than user will not see any message at the bottom of page related to access restriction but if the same record is restricted from ACL than message such as “Numbers of rows removed from the list by Security constraints: 20” displayed to user.

So, for smoothening the user experience query BR is preferred over ACL.

Order of execution of different Business Rules

The above image show use how database is being updated once something is entered by user. We can clearly see the execution order of the different business rule and how they work one by one based on the conditions and operation selected.

QUERY > DISPLAY > BEFORE > AFTER

This is in simple words to make you understand the flow. First, the query rule runs to restrict the access of the data being presented to the user. Then the display rule is executed. After that Scripts are configured to execute before the database operation works. And finally, async and after is carried out. 

Best practices for a Business Rule

• Prevent recursive business rules – We should avoid using update() in a business rule script. The update() method triggers business rules to run on the same table for insert and update operations, leading to a business rule calling itself over and over.
• Enclose your script in functions – We should always enclose our script in functions because when a code is not enclosed inn functions it is available to all server side scripts.
• Write specific business rule – Always avoid writing complex rules as they will be difficult to debug.
• Know when to run business rule – There should be clarity about when to use Business Rule and specify the same in conditions for running your BR.

Advantage vs disadvantage

• Performance. When running code on the server, it often has a faster load time and   processing time than a client script.
• Can perform complex database lookups.
• Can dot-walk many levels, however three levels is often a recommend maximum.

Disadvantage

• They are not as user friendly as client scripts.

What is async business rule in servicenow?

What is before business rule in servicenow?

What is after business rule in servicenow?

What is display business rule in servicenow?

What is before query business rule in servicenow?

Get latest update from runjay patel.

We don’t spam! Read our privacy policy for more info.

You’ve been successfully subscribed to our newsletter!

RELATED ARTICLES MORE FROM AUTHOR

Barcode or qr codes generation in servicenow, how to become a certified system administrator (csa), servicenow versions / release, leave a reply cancel reply.

Save my name, email, and website in this browser for the next time I comment.

EDITOR PICKS

Popular posts, access control list – acl, software asset management servicenow – sam-pro, customer service management (csm), popular category.

• ServiceNow Basics 22
• Scripting In ServiceNow 20
• Integrations 4
• Service Mapping 2
• Terms & Conditions

Control the Execution Order of Request Items in an Order Guide

Lately I’ve been doing some service catalog work for a couple of clients and I’ve come across a requirement that I really haven’t had to address before. The requirement deals with order guides…specifically with the ability to control the execution order of individual items within an order guide. You’re probably aware that ServiceNow provides complete control over the ordering of tasks within a catalog item, but what do you do with an order guide that needs to have one item complete before the next 2 items can start? There’s not a simple way to control this behavior by default so I came up with a way and I’ll share it here.

Initial setup

A ll of this depends on having the ability to identify whether or not an order guide is associated with an item that has been ordered, and which order guide that is. As such, your first step will be to make sure that you are recording the order guide used against the parent request record. This setup is not provided by default but you can add it by following the instructions in this article .

NOTE: This is recorded for you automatically in the Helsinki release and beyond! The instructions below reflect these changes as of the Helsinki release.

Establishing an execution order

Once you’ve validated that the order guide is being populated correctly you’re ready to set up the execution order for your items within that order guide. The solution is actually pretty simple and only requires 2 pieces, both of which are implemented in the workflow for the respective items within an order guide.

Example: In order to illustrate this setup, I’ll use a simple example. Let’s say that you have an order guide for new hires that includes 2 items; ‘Computer Workstation’ and ‘Computer Software’. Both of these items need to be ordered and delivered as part of the new hire process, but they need to be delivered in a specific order. The ‘Computer Software’ item cannot be started until the ‘Computer Workstation’ item has finished because we need to have a workstation to be able to install the software.

The first step is to modify the graphical workflow associated with item 1 (the ‘Computer Workstation’ catalog item). The workflow should run through the same process whether or not the item is ordered as part of an order guide, but at some point in the workflow (probably right before the end) we need to check if the item is associated with an order guide and then tell the next item to start. The next item in this case is ‘Computer Software’.

We don’t have direct access to the next item, but we can easily set up a ‘Run script’ workflow activity to query for that item and set a value there telling the item that it can start. I’ve found that the simplest way of doing this is to set the ‘State’ field on the next request item record to ‘Work in Progress’. The script below can be used in your ‘Run script’ activity in your workflow. Just replace the name of the ‘Computer Software’ item below with the name of the item in your system.

This script works great, but it’s only part of the puzzle! Unless you tell item 2 (Computer Software) to wait for item 1 (Computer Workstation) then your script isn’t going to work the way you need it to. So, the second configuration change you’ll need to make is to add a ‘Wait for’ activity to the graphical workflow associated with item 2 (Computer Software). The ‘Wait for’ activity placement should probably be the first activity in the item 2 workflow, but will depend on your specific workflow. It should only apply if an order guide is associated with the parent request and the state is ‘Work in Progress.

If you’ve followed the instructions above correctly, you should now be able to order your order guide item and execute the items in the order you’ve specified in the workflows. You can handle any order guide execution order scenario by repeating the same steps in the workflow for each item. If you have multiple items that need to start when item 1 is finished, then simply add those items to the script from item 1 and add the wait for condition to items 2, 3, 4, etc…

Bonus! Copying variable values from one item to another

Because your items are associated under a single order guide, it might also be necessary to pass variable values from one item to another. In order to do this, you’ll need to make sure that each item sharing variable values this way has an identically-named variable to place the value in. Once you’ve got that you could execute the following script inside a workflow ‘Run script’ activity.

Mark Stanger

Date Posted:

August 23, 2011

Share This:

15 Comments

I had a similar requirement in the past to be able to choose an existing requested item and copy all the variables into a new request. I used JSON to build a string with all the name/value pairs and then set the form with the client script.

Script Include (findItemVariables)

Catalog Client Script

Awesome. Thanks for sharing this. If I needed to populate the variables in a client script I would definitely use something like this. If I needed to populate the variables in a workflow or business rule I could use a script like mine above.

This is great. I’m doing something similar, but I’m opening the flood gates after the User Creation RITM is complete on a New Hire. We have to wait for the user to be created in LDAP, sync’d to ServiceNow and update the “Requested For” so it becomes accurate on the Desktop, Software, Phone requested items, etc.

I implemented this and works perfectly. However, given that the “next items” are waiting for the first one to complete IF approved (in my case), how do I get to cancel the workflows for these “next items” if the first one is not approved, as these others depend on this approval?

Thanks in advance for your input.

Cheers, Luis

You’ll have to query for the other items and close them (which should cancel the workflows). If it doesn’t then you can force the workflow cancellation as shown here… https://servicenowguru.com/scripting/business-rules-scripting/canceling-executing-workflows-task-closure/

Hi Mark, This is fantastic, thank you. Any ideas on how to set the variable in Step 2 in the latest Eureka release? request.order guide isn’t a variable I can choose… I can plug in parent.tasktype and use that as a Request, but that assumes that every REQ is going to be part of an order guide… bit messy?

Cheers, -Adam

Have you followed the initial setup listed above? In order to get the ‘request.u_order_guide’ field you have to create it by following the instructions included in the article I link to above.

Of course not! I’m a user and only half-read everything :) I’ll give it a crack tonight and see how I go, thanks for being polite about it!

Hi Mark, Do you know if Geneva or Helsinki has any sort of OOB functionality for this, or are you still using your custom approach with clients?

There’s nothing new in Helsinki or Geneva to do this as far as I know.

Just to validate, do all of the request items still get created at the very beginning? Does this just control when certain request item’s states gets set to “work in progress” as dependent items are completed?

All of the requested item records will always get created right at the beginning regardless of what you do. This helps to control the workflow so that they only get opened and put into people’s work queue when they’re supposed to.

I’m a bit confused on the second step. Based on the provided example, it looks like it will wait on the “wait activity” even when the request isn’t made from an Order Guide.

Are you saying there should be a “conditional if activity” before the “wait activity” checking if the Order Guide is set on the request?

Yes, the example shown above would really only apply if the second item was always part of the order guide. A conditional activity in your second item would allow the flexibility of handling multiple types of flows.

The script to pass variables between various catalog item should be written in which workflow..I tried putting it in the 1st Requested item but it didnt work… The other scripts work as expceted.

Comments are closed.

• Using Import Sets for REST Integration in ServiceNow August 26th, 2024

Achim says:

Jacob Kimball says:

• Announcements
• Architecture
• Business rules
• Client scripts
• Content management
• Email Notifications
• General knowledge
• Generative AI
• Graphical workflow
• Integration
• Knowledge Management
• Miscellaneous
• Performance
• Relationships
• Script includes
• Service Portal
• Single Sign-on
• System Definition
• Web Services

Related Posts

Easily Move Customer Updates Between Update Sets

Condition Builder Attributes That Pack a Punch

Demystifying Cryptography in ServiceNow: A Comprehensive Guide to Secure Data Transmission

Fresh content direct to your inbox.

Just add your email and hit subscribe to stay informed.

Since 2009, ServiceNow Guru has been THE go-to source of ServiceNow technical content and knowledge for all ServiceNow professionals.

• Using Import Sets for REST Integration in ServiceNow
• Customize the Virtual Agent Chat Button in Service Portal
• Leveraging Joins in GlideRecord Queries

© Copyright 2009 – 2024 | All Rights Reserved

ServiceNow Application Development by Sagar Gupta

Get full access to ServiceNow Application Development and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Execution order of scripts

Scripts in the ServiceNow platform are executed in the following order:

• Before business rules : Business rule scripts, with an order less than 1,000, configured to execute before the database operation
• Before engines: Workflow, approval, and other engines
• Before business rules : Scripts configured to execute before the database operation but with an order greater than or equal to 1,000
• Database operation: Insert, update, delete, or query operation
• After business rules : Scripts with an order less than 1,000 configured to execute after the database operation
• After engines : Text indexing and workflow engines (for deferred workflows)
• E-mail notifications : Notifications sent on an insert, update, or delete and event-based ...

Get ServiceNow Application Development now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

Your browser or one of your plugins is not allowing JavaScript to be run. This is a bummer since the ServiceNow Developers Site is dynamic and depends on JavaScript to function. If you want to visit this site, please disable the plugin, activate this site for JavaScript or use another browser.