Grant Access to Workflows, Not to Systems or Data

By Mike Fitzmaurice

Pretend you have a teenage son who just got his driver’s license. Which thought makes you more comfortable: (a) allowing him to drive your car to/from soccer practice on weekday afternoons, or (b) allowing him to drive your car anywhere, anytime?

If your approach to integration boils down to granting access to data, you might as well have chosen (b).

It happens all the time: Employees, departments or even third-party entities request access to business applications so they can perform important tasks. Or they ask for access to data sources to drive an integration project. It makes sense to grant permission, because everyone wants to help drive productivity. However, creating more accounts on the CRM system, or offering direct access to a SQL server somewhere, may not be the best way to proceed.

Instead, consider doing some research to find out what they want to do. Next, create a workflow to help them do it. And then grant access to that workflow, instead of to the application or database.

Let us consider the example of a request by a manager, Pat, for limited access to the human resources system in order to facilitate vacation scheduling for her complicated and critical department. That department has constraints regarding cross-training and coverage, as well as a seniority system for choosing prime vacation dates. That means Pat often needs information about several peoples’ already-scheduled vacations, mandatory training dates, and accumulated leave, before granting a vacation request for key employees.

The department manager makes a very compelling argument that granting her direct access to the HR application would streamline the process and also reduce HR’s workload in supporting those requests. Everyone wins, right? You want to help Pat out. Is giving her access to the HR system the right way to proceed – or even the most efficient? I’d argue, probably not. Let’s consider the issues.

Many Enterprise Applications Require Training

You can’t simply set Pat up with an account on the HR system and say, “Here you go.” Whether you use home-grown or off-the-shelf HR solutions, it’s complicated. Pat is going to need training and on-going support on the HR system in under to use it effectively.

There may also be issues about who is going to use the HR system. Pat, the manager, made the request, but the department’s administrative assistant, Charlie, is the one who would normally be tasked with running down the vacation data for a specific request. Best practices and corporate policies require that Charlie must have his own account on the HR system — and training and support. The cost is multiplying.

There Are Security Issues

You may be shaking your head: What, you’re going to give a departmental administrative assistant access to the HR system? Exactly right. It’s a terrible idea to give Charlie access. It’s also a bad idea to give Pat access. Neither of them needs to be on a system that might potentially show employees’ salaries, benefit plans, home address, names and ages of dependents, status of background checks – or whether pay is being docked to cover alimony, child support, and back taxes. Not only does access need to be carefully restricted to protect data integrity, but also there may be considerable legal questions about providing access to the HR system at all.

There Are IT/Programming Issues

Yes, on many enterprise applications, accounts can be created that offer limited access to data. That’s tricky to do on a fine-grained level, of course: You don’t want to merely restrict Pat and Charlie to see only vacation information, you want them to see vacation information about their department only. How easy is it to create accounts with that tiny bit of access? You’re now talking programmer time, which must be allocated from other projects, as well as the time it takes to test and troubleshoot their work. That work may require consultants. And do you really want to mess with the HR system?

What’s more, you may have similar requests from other departments – similar, but not exactly the same. It’s crazy to continue patching the HR system for this.

Offer Workflow Access, Not Application Access

The answer is easy. Pat and Charlie are asking for access to the HR platform, but what they are really asking for is the ability to gather information. In their mind, it’s easiest to use the HR software. What would be even easier would be to create a workflow that accesses precisely the data that Pat and Charlie require — and no more. Perhaps that workflow does little more than run a predefined report from an authorized HR system account (or from a background agent with the appropriate privileges) and deliver the results.

No Programming, No Security Concerns

So: An authorized HR system user creates a workflow that runs the appropriate report for Pat and Charlie, with the results emailed or otherwise distributed to them. The report runs using the appropriate privileges. Pat and Charlie are given permission, through the workflow platform (not the HR platform, which they cannot access), to run that workflow whenever necessary. The vacation request bottleneck is eliminated, and everyone wins.

Use Workflows for Systems Integration

A similar situation can occur when programmers or consultants are seeking to write new software that integrates data from multiple applications to create new functionality. A good example is when creating mobile apps that amalgamate data from backend data sources.

The typical scenario has the mobile developers requesting direct access to those data sources, which might be databases for customer information, inventory levels, or order status. Accessing those databases directly seems quickest, but can run into difficulties similar to that in the HR example above: The data can be encoded and complex to interpret; there may be more fields in the data that the app (and its programmers) should not be authorized to access; and it may take a lot of ongoing support to help the mobile programmers. And that’s only for read-only data. For any writes back into the databases, allowing external apps to make changes would bypass all the checks-and-balances already coded into existing backend software, could result in data integrity and security issues.

Stored Procedures? No, No.

One solution would be to add stored procedures into the databases to accommodate those remote accesses – but that doesn’t solve the security and complexity issues, and could create instability in the underlying software.

The better solution here would be to continue to use workflows to utilize the existing enterprise applications and supply data to the mobile application. This eliminates the need to bypass those existing applications, and can leverage their logic. Similarly, any potential writes back into the databases should be run as workflows into the existing enterprise applications, which preserves their logic, checks-and-balances, and logging systems. Not only that, but those workflows should be faster to create and debug than writing database access code – and safer besides.

About Mike Fitzmaurice

Mike Fitzmaurice is the Vice President of Workflow Technology for Nintex, the world leader in workflow and content automation, and is its subject matter expert and chief spokesperson for workflow, business transformation, and technology matters.

More About Mike