Business Rule doesn't trigger when record is Inserted into a table

[Anish Somadevan]

Hello,

I am fairly new to ServiceNow and have a requirement to send event from Incident table to a 3rd party application. I have a Business Rule set to execute (after) on Incident table which sends information to the application on Create, Query and Update operations. I have created a new user (web-service access only) and assigned the itil role to it. However, when an Incident is created through REST API using an Oauth client and credentials of the user, the Business Rule doesn't get triggered. The Incident gets created successfully. The Business Rule triggers when I (admin permission) create/update an Incident through ServiceNow UI or through API using my credentials. I checked the logs in Debug Business Rules and didn't find any errors when the rule wasn't executed.

I tried adding the role to Business Rules Role conditions, but that didn't work either.

Can someone please let me know if there is any specific role to be added to the user in order for the Business Rule to be executed when an action is performed on the table through REST API? Or is it to do with ACL settings on the table, if so can you provide me the steps to check that.

Regards,

Anish

[Anish Somadevan]

The issue was due to the fact of a lookup in the script to CredentialProvider to get the credentials, which the user didn't have permission to. I have now created the credential as a System Property of type Password2 and use it in the script through gs.getProperty(<name>) to get the credential. We could also use RESTMessageV2 and Authentication Profile if needed.

[Ahana 01]

There could be several reasons why a business rule is not triggering when a record is inserted into a table in ServiceNow. Here are some possible causes and solutions:

1. **Business Rule is Inactive**: Ensure that the business rule is active. You can check this by navigating to the business rule and checking the 'Active' checkbox.

2. **Incorrect Filter Conditions**: The conditions specified in the business rule may not be met. Check the 'When to run' section of the business rule and ensure that the conditions are correct.

3. **Order of Execution**: The order in which the business rule is executed may be causing the issue. If there are other business rules on the same table, they may be affecting the record before your business rule runs. You can change the order of execution by modifying the 'Order' field in the business rule.

4. **Incorrect Table**: The business rule may be on the wrong table. Ensure that the business rule is on the correct table.

5. **Script Errors**: There may be errors in the script that is being run by the business rule. Check the script for any errors and correct them.

6. **Access Control**: There may be access control rules that are preventing the business rule from running. Check the access control rules for the table and ensure that they are not preventing the business rule from running.

7. **Debugging**: Use the Debug Business Rules module to see if the business rule is being triggered and to identify any issues.

8. **Async Business Rule**: If it's an asynchronous business rule, there might be a delay in execution. Check the system logs to see if the rule has been executed.

Remember to test any changes in a sub-production instance before applying them to your production instance.

[Anish Somadevan]

Thank you Ahana.

The issue was due to a lookup to CredentialProvider in the script, which the user doesn't have permission to. I have created a system property instead of type Password2 and use that in the script, and it works as expected.

Regards,

Anish

[Amit Verma]

Hi @Anish Somadevan 

Please have a look on the below post:

https://www.servicenow.com/community/developer-forum/resolving-incidents-via-rest-api-does-not-trigg...

https://www.servicenow.com/community/developer-forum/rest-service-debug-logs/m-p/1701697

Probably, the write ACLs on the Incident table is creating a problem.

Thanks & Regards

Amit Verma