<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=151938321911395&amp;ev=PageView&amp;noscript=1">

How to Manage 'Execute as Admin' Workflows

Last week, in response to an increasing number of questions from our NetSuite customers, we showed you how to manage scripts that execute in the Administrator role. You can find that post here. One thing it didn't cover, however, was workflows that execute as Administrator.

The process for resolving this with Strongpoint or Flashlight is similar — watch the video for a walkthrough. But there are some additional considerations that merit discussion in this post, particularly if you want to avoid material deficiencies on audit. 

What Are Admin Workflows?

When a workflow is created in NetSuite, the Administrator or developer can set or change a flag that causes the workflow to execute under the Administrator role, rather than under the same role as the user.

While workflows do not have the same scope as scripts, a workflow executing as Admin has broad permissions well beyond what a single role would normally permit a user to do. Like scripts, developers often use them for testing purposes; the downside of this is that, as we mention in the earlier post and video, they can allow users to do things they could not normally do.

Do Auditors Care? Should I?

We've found that auditors usually aren’t as concerned with workflows executing in the Administrator role. Many do not fully recognize the similarity to script deployments. However, there is a wide variety of experience out there, and auditors learn from each other. 

A number of our customers have seen auditors come back with tighter and tighter questions in recent years that plainly show that they are more familiar with the platform. In the words of one of our customers:

"Counting on getting an uninformed auditor is not a good strategy."

 

While it's true that workflows have fewer rights than scripts, they are still very broad. The same concerns, including the potential for Segregation of Duties violations, still apply.  Even if it doesn't come up at audit, being proactive is better than scrambling to address an issue after the fact — or potentially exposing your organization to risk. 

How to Manage the Risk

To manage risk and stay proactive, you need to create and maintain a list of all Admin Workflows in your account. Here's how to do it. 

Step One: Find Admin Workflows

Unfortunately, this first step isn't possible without Strongpoint, since the "Execute as Admin" flag on a workflow is not otherwise searchable. Only our products advanced documentation allows you to work around this problem.

Using Strongpoint or our free product Flashlight, you can quickly build a search that will flag all workflows executing as admin. Here are the settings:

This search will give you a list of all workflows in the Customization Library that are executing as Admin. You'll also exclude workflows that have no fraud/SOD risk, such as:

  • Workflows from managed bundles
  • Any workflows that don’t touch standard fields or custom transaction body or column fields 

In our production account, these two filters eliminate 90% of the workflows — making it considerably faster and easier to proceed with step two. 

Step Two: Review and Clear the Workflows

Once you have the list, you need to check the workflows for anything that would cause concern or violate segregation of duties. This involves reviewing the criteria, states, transitions and actions in every workflow to see what it does. Fortunately, Strongpoint's searches put the information you need to perform this analysis right at your fingertips:

  • Date Last Used 
  • Standard and custom field dependencies
  • Related scripts and workflows

The first thing you are going to want to look at is the Date Last Used. This shows the last time the workflow ran. If the workflow is not running, then you may be able to resolve the concern by disabling the workflow.  Please see the Strongpoint User Guide for best practices for analyzing Date Last Used values.

If the workflow is running or if you are unsure, you will be able to see all of the fields that the workflow touches in the Data Sources column.  This will often resolve the issue since it will be clear from the fields touched that the script does not touch any sensitive fields (ie., those that have direct or indirect GL impact). 

Finally, you may well end up needing to review the logic of the workflow to establish that the code doesn’t create or change transactions in a way that violates segregation of duties.

The Bottom Line on Admin Workflows

There is nothing inherently wrong with Admin workflows. The risk comes from what each workflow touches. When you can see what a workflow touches, you can determine whether or not it poses a risk — and demonstrate that analysis to auditors.

For more on compliance readiness, check out our blog post on monitoring transactional administrator behavior, or contact us directly to arrange a demo:

Book a Meeting