Business Rule Interview Questions

[Kri]

I'm looking for answers for the below questions in Business Rules

1. Which type of BR shouldn't include current.update() and why?

2. Explain advantages of Asynch BR over After BR or vice versa.

3. Can we call scheduled job from BR?

4. Did you ever called script include in BR? Why we call script include in BR if we can write same script in BR itself?

Real Time Sample Questions:
1. How do you debug BR? What are the different ways to debug BR?

2. Explain any scenario where we can't use Asynch BR?

3. Explain any scenario where we can use Display BR instead of using GlideAjax?

[OlaN]

Hi,

You can start learning these things by following the learning plans on the Developer site.

[Anand Kumar P]

Hi @Kri ,

1. Which type of BR shouldn't include current.update() and why?

• A "Before" and "After" Business Rule should not include current.update() because it runs before the record is saved to the database. When you update current in a "Before" and "After" rule, it can trigger the same rule again, leading to an infinite loop. This loop can cause performance issues and potentially crash the system.
• In case if you want to use current.update in before br then use current.setWorkflow(false).

2. Explain advantages of Asynch BR over After BR or vice versa.

• Advantages of "Asynchronous" Business Rules:

  • They run in the background, minimizing the impact on user experience.
  • Suitable for time-consuming processes like data calculations, sending notifications, or integrations.
  • Ideal for long-running tasks that don't require immediate user feedback.

• Advantages of "After" Business Rules:

  • They execute immediately after a record is saved, allowing for real-time actions.
  • Useful for scenarios where you need to interact with the user interface, such as showing confirmation messages.
  • Better for tasks that require immediate updates visible to the user.

3. Can we call a scheduled job from BR?

• No, you cannot directly call a scheduled job from a Business Rule. Scheduled jobs are independent processes managed by the ServiceNow scheduler. However, you can indirectly trigger a scheduled job by creating a condition in the Business Rule that inserts a record or changes a field that the scheduled job monitors. This way, the scheduled job will execute based on its configured schedule and conditions.

4. Did you ever call a script include in BR? Why do we call a script include in BR if we can write the same script in BR itself?

• Yes, it's common to call script includes in Business Rules. The main reasons are code reusability, maintainability, and modularity. Script includes allow you to centralize and reuse code across multiple Business Rules, scripts, and modules. This approach promotes consistency and reduces the risk of duplicating code. Additionally, script includes can be easily tested and updated independently, enhancing code management and troubleshooting capabilities. Writing the same script directly in a Business Rule may lead to code redundancy, making it harder to maintain and troubleshoot.
• Calling script include in br: var gr=new scriptinclidename().scriptincludefunctionname(any parameters you want to pass)

1. How do you debug BR? What are the different ways to debug BR?

• Debugging Business Rules can involve techniques like:
  • Adding gs.log() statements to log messages to the system log.
  • Setting breakpoints in the Business Rule.
  • Using the "Script Debugger" tool to step through the script.
  • Examining the system logs to trace the execution flow.

2. Explain any scenario where we can't use Asynch BR?

• You might avoid using an "Asynchronous" Business Rule when:
  • Real-time user interaction is necessary immediately after record save.
  • You need to show user feedback, such as pop-up messages, right after an action.
  • The process requires immediate updates that should be visible to the user.

3. Explain any scenario where we can use Display BR instead of using GlideAjax?

• "Display" Business Rules are useful when:
  • You want to dynamically show or hide fields, sections, or related lists on a form based on specific conditions without a server request.
  • Display Business Rules execute their logic when a form loads and a record is loaded from the database. They must complete execution before control of the form is given to a user. The purpose of a display Business Rule is to populate an automatically instantiated object, g_scratchpad. The g_scratchpad object is passed from the display Business Rule to the client-side for use by client-side scripts. Recall that when scripting on the client-side, scripts only have access to fields and field values for fields on the form and not all of the fields from the database. Use the g_scratchpad object to pass data to the client-side without modifying the form. The g_scratchpad object has no default properties.
    
    Type Use case

  • Display Business Rule in ServiceNow:
    Code written in display business rule get executed before the form is presented to the user and just after the data is read from the database.

    For e.g. you have written the code that when xyz user click on information box then only data related to that user specific country will get displayed to user. It means that user from US can see US specific data and user from India can see India specific data.

    
    Before Business Rule in ServiceNow:
    Code written in before business rule get executed when user submits the form and data is not saved in database.
    Let’s say User click on submit button --> Before business rule code executes --> information will save in database.

    For e.g. Let’s say you have written the code that when user click on submit button then some extra information which in not filled by user such as user current location, user manager name and user past activities will get save when user click on submit button.

    After Business Rule in ServiceNow:
    Code written in after business rule get executed when user submits the form and data saved in database.
    Let’s say User click on submit button --> data saved in database --> Now after business rule code get executed.

    For e.g. there is parent incident and child incident and you want that related child incident will get closed automatically after the parent incident get closed by user.

    
    Async Business Rule in ServiceNow:
    Async business rules are like after business rule but it runs in the background simultaneously with other processes. Means async business rule run after the data is saved into the database.
    Running on background means that use can proceed with other functionality and code will run on the background which will not impact the user while doing other transitions.

    For e.g. Incident ticket is in pending customer action status and will be auto closed after 5 days if user did not provide any update on incident ticket.

  •  

  • display	Use to provide client-side scripts access to server-side data.
    before	Use to update information on the current object. For example, a business rule containing current.state=3; would set the State field on the current record to the state with a value of 3.
    after	Use to update information on related objects that need to be displayed immediately, such as GlideRecord queries.
    async	Use to update information on related objects that do not need to be displayed immediately, such as calculating metrics and SLAs.

Please mark it as helpful if its works so it can benefit the community.
Thanks,

Anand

[Astik Thombare]

Hi @Kri ,

Answers to your questions:

1. What type of BR shouldn't include current.update() and why?

Ans :https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0715782

2. Explain advantages of Asynch BR over After BR or vice versa.

Advantages of Asynchronous BR over After BR:

• Asynchronous BRs do not block the user while they are executing, which can improve the user experience.
• Asynchronous BRs can be used to perform long-running or resource-intensive tasks without impacting the performance of the system.
• Asynchronous BRs can be used to implement complex business logic that would be difficult or impossible to implement with an after BR.

Advantages of After BR over Asynchronous BR:

• After BRs are simpler to write and debug than asynchronous BRs.
• After BRs execute immediately, so you can be sure that the changes they make are reflected in the system immediately.
• After BRs can be used to enforce data integrity constraints.

3. Can we call scheduled job from BR?

Yes, we can call a scheduled job from a BR. To do this, we can use the SncTriggerSynchronizer.executeNow() function. This function takes a GlideRecord object for the scheduled job as input and executes the job immediately.

4. Did you ever called script include in BR? Why we call script include in BR if we can write same script in BR itself?

Yes, we can called script includes in BRs. There are a few reasons why we might want to do this:

• To reuse code. Script includes can be used to encapsulate common functionality that can be reused in multiple BRs.
• To make code more readable and maintainable. Script includes can be used to break down complex logic into smaller, more manageable pieces.
• To improve performance. Script includes can be used to cache data or perform other operations that can improve the performance of BRs.

5. How do you debug BR? What are the different ways to debug BR?

There are a few different ways to debug BRs:

• Use the BR Debugger. The BR Debugger is a tool that allows you to step through the execution of a BR line by line.
• Use the System Log. The System Log contains information about all errors that occur in the system, including errors that occur in BRs.
• Use the BR Tester. The BR Tester is a tool that allows you to test BRs in a sandbox environment.

6. Explain any scenario where we can't use Asynch BR?

If you need the changes made by the BR to be reflected in the system immediately, you cannot use an asynchronous BR. For example, if you are using a BR to validate a field before it is saved, you must use an after BR.

7. Explain any scenario where we can use Display BR instead of using GlideAjax?

A display BR is a BR that is triggered when the value of a field changes. A GlideAjax action is a type of action that can be used to call a server-side script from a client script.

We can use a display BR instead of a GlideAjax action if we need to perform a simple operation on the data in the current record, such as updating a field or setting a flag. A display BR is more efficient than a GlideAjax action because it does not require the client to make a network call to the server.

Here is an example of a scenario where we could use a display BR instead of a GlideAjax action:

// Display BR
When: incident.state changes
Script:
if (incident.state == 'Resolved') {
  incident.close_code = '1';
}

This BR will update the close_code field to 1 whenever the state field of the incident is changed to Resolved.

We could also implement this logic using a GlideAjax action, but the display BR is more efficient because it does not require the client to make a network call to the server.

If it help mark helpful or correct.

Regards,
Astik Thombare