Make Business rule to run as System

[Harish74]

Hi there,

I'm trying to run a business rule to run as 'System' or at least the changes happened through the business rule should be updated as system. In the before update business rule, I'm using the following code. However, it is working fine, when an admin user calls the business rule. But for non-admins it is showing their own user ID for 'Updated by'. 

(function executeRule(current, previous /*null when async*/ ) {

    if (gs.isInteractive()) {
        current.sys_updated_by = 'system';
    }

})(current, previous);

  One more issue is, In the activity logs, though the updates done by script it is showing as user.

[Daniel Borkowi1]

Hi @Harish74 , I'm not sure why you should do this, because you will lose any traceability in the system, I strongly not recommend to do this. But it seems that this is a ACL topic. Please check if your normal user are allowed to update this field. if you want only hide these information on UI, please consider other approaches e.g. https://www.servicenow.com/community/csm-forum/hide-the-agent-name-from-the-activity-stream-on-the-p....

Greets Daniel

[Riya Verma]

Hi @Harish74 ,,

Hope you are doing great.

First ofa ll m we should not be implementing this kind of requiement as it will lose te functionality for audit and tracing which user has updated the record. 

But still if you want this to be implemented , you can use below code for reference

(function executeRule(current, previous /*, ...other parameters*/) {
 
  if (!gs.hasRole('admin')) {
   
    var systemUser = gs.getUserByID('system');

    // Set the 'Updated by' field to the system user's ID
    current.setValue('sys_updated_by', systemUser.getID());
  }
})(current, previous /*, ...other parameters*/);

[Jonathan V]

Hi @Harish74 ,

I had a similar requirement. We have a condition to create evaluations based on some data in the user profile, so every time one of these key fields are modified, the BR verifies if there is an existing evaluation, if there is not, the system will create it automatically. After initial roll out, we found that some duplicate evaluations were getting created. the reason for this is because not every user has read access to such evaluations and because the BR was running as the user, then the Query BR on the evaluations table was preventing our validation to failed. In order to fix this issue we needed to, at least, run the query validation as an admin so we wouldn't hit any read restrictions.

The solution was to add an impersonate line in our BR so the system will run the query as one of our admins, then impersonate back the current user and if needed, created the evaluation as the current user. this solution helped us to prevent the read access issue but still be able to keep audit and tracing on.

Example:

var originalUser = new GlideImpersonate().impersonate('admin_sys_Id');

-> code to run as an admin

new GlideImpersonate().impersonate(originalUser); // Revert Back to original user.

-> code to modify records and keep history.

Please keep in mind that we are running an async BR withing the Global Scope, so not sure if it will work as a before/after BR. Also this won't work for scoped BRs as the Scoped API doesn't include the GlideImpersonate class.

Hope it helps.