How to Set Up Integration Governance for Business Users

IT teams in midsize — and even enterprise — organizations are drowning in integration requests. Project managers want Jira connected to Asana. Finance needs NetSuite connected to Wrike. Sales needs Salesforce to sync with ServiceNow. But with IT having the keys for all these integrations, the requests pile up quicker than they can build integrations to resolve them.

IT isn’t the problem. Neither is the volume of requests. Most organizations default to an approach that breaks as they scale. If you build every integration from scratch, you get overwhelmed as you scale. If you hand everything off to an automation tool like Zapier, you have to deal with shadow IT as business users handle requests autonomously with no visibility from IT. Even enterprise iPaaS like Workato are heavy on implementation and learning curves, meaning it can take significant time for them to get up and running.

Your finance team doesn’t approve every reimbursement one by one, nor do they let everyone spend whatever they want, whenever they want. They set spending limits, define approved vendors, and require receipts.

You can have a similar framework for integration governance. Here’s how.

The four-layer integration governance framework

Layer	What it controls	Why it matters	What happens without it	In practice
1: Authentication	Which tools can be integrated and how it’s done. Includes OAuth scopes and credential management.	Makes the difference between allowing business users to work within IT-defined boundaries or creating potential vulnerabilities and rogue API keys.	Direct API connections are created between tools with no visibility from IT, creating the potential for data breaches.	IT pre-configures approved tool connections, with business users selecting from approved integrations. Tokens are rotated regularly.
2: Authorization	Which fields and work items can be integrated. Excludes sensitive fields at the platform level.	Creates clear guidelines for what data can and can’t be synced, preventing breaches from affecting particularly sensitive data.	Well-meaning users accidentally sync sensitive data out to third-party platforms (e.g., internal cost estimates to a vendor’s project management tool).	IT defines available and restricted fields, as well as which fields are available for one-way vs. two-way sync.
3: Validation	Pre-approved integration patterns by tool pairings and use case.	Keeps IT from having to validate integration requests one by one.	IT’s integration backlog keeps growing as there are no pre-defined models for batch approvals.	IT creates and approves integration templates, including tool pairings, work item types, and field mappings. Business users deploy integrations according to templates.
4: Audit	Visibility into who built which integrations, what data flows through them, and how secure they are.	Satisfies security certifications (e.g., SOC 2 Type 2) and creates a paper trail when integrations break or tools are breached.	Integrations break but no one knows who built them or what projects they involve.	Every integration has a pre-determined owner and changes are logged with timestamps and attribution. IT can pull up records on any integration at any time.

Layer 1 – Authentication: Who can connect what

Authentication is the foundation for your integration governance framework. This is both about defining which tools can and can’t be integrated as well as managing the actual keys (e.g., OAuth scopes, API tokens) involved in integrating these tools. Business users never get access to these keys.

This foundation creates the approach you’ll use throughout this framework: balanced restriction. You don’t want your IT team to have to approve every integration request one by one, but you also don’t want business users to integrate anything and everything at will.

Most self-serve automation tools handle authentication at the individual user level. This gives IT teams little visibility on who’s connecting what, unless they put work into building a reporting layer on top of these tools. Not only that, but credentials and API tokens are scattered across any number of user accounts, spreadsheets, and post-it notes. Revoking access — because someone leaves or changes roles — is complex, if not impossible.

An integration governance model centralizes authentication. At the very least, IT defines which tools can and can’t be integrated, as well as how they should be integrated (i.e., defining access and guidelines). Ideally, though, the IT team should use whatever integration platform the organization has chosen to configure integrations, defining the access levels each integration should have. This gives business users a jumping off point to set up connections without needing the kind of configuration that introduces security risks.

Layer 2 – Authorization: What data can be integrated

This layer is to integrations what role-based permissions are to access control. Authentication is about determining which tools can be integrated and how. Authorization is about defining what data can be integrated. That can be on a field-by-field basis or project by project. For example, in CRMs with a significant amount of customer data, your integration governance framework would determine what data can be synced out of your CRM. In most self-serve integration platforms, there’s no built-in ability to restrict the fields or projects a user can sync, leaving IT with the task of building a framework for doing so.

Another element of authorization? Sync direction. Two-way sync tools can both push data exclusively from tool A to tool B or back-and-forth between them. That said, some workflows shouldn’t be two ways (e.g.,  working with external vendors). Your governance framework should also cover which workflows can involve two-way syncing, down to the field level.

The challenge is many of these guidelines need to be context-specific. Syncing customer data out of your CRM to a vendor’s project management should be restricted; the same isn’t true when syncing data internally.

Layer 3 – Validation: Which patterns are approved

Once you’ve determined which tools and which fields can be integrated, your framework can establish pre-approved integration patterns business users can follow when setting up their integrations. So instead of constantly approving and building integrations between a project management tool and a CRM, IT can approve the template once, defining which fields can and can’t be synced, and make that template available to business users — who set up the integration themselves through the platforms you’ve already approved. Any integration needs that would require a new pattern go through IT review, after which they can be deployed rapidly.

Without this layer in place, IT has to validate every integration request one by one. This creates a massive backlog that will never meaningfully decrease, since your organization’s integration needs will always increase as it grows. Many of these requests will be variations on the same basic tool pairings, meaning they would be easy to approve in batches.

For this layer, ensure that you have robust documentation describing approved templates and a system for submitting requests. From there, business users can consult and deploy approved templates instantly.

Layer 4 – Audit: What happened and who did it

Once your organization reaches a certain size, you need audit trails for everything. If you can’t name every integration your organization runs from memory, you need auditable processes. Integrations are no different.

IT needs visibility into who builds integrations, how they’re built, and the tools they’re integrating. They need a record of modifications made to these integrations, the data flowing through, and more. That means dedicated, detailed change logs. Screenshots of an integration builder aren’t enough.

An audit trail gives your team what it needs to actually govern the way you manage integrations. It gives you data to confirm that policies are actually happening in practice, but it also gives you a foundation for investigating anything that breaks. Not only that, but it’s often essential for complying with data security frameworks like SOC 2 or GDPR.

Without auditability, nobody knows what to do when an integration breaks. The people relying on that integration have half the story while IT has the other half. But those halves don’t always match up without some serious investigation.

So how do you make your integrations auditable? First, every integration needs an owner, and that ownership needs to be documented. Next, ensure the integration platform you use logs changes, updates, and issues with timestamps and user attribution. That allows IT to pull reports of active integrations whenever there’s an issue — or just a compliance check — with full detail. Everything from authentication events to authorization changes and pattern approvals should contribute to these reports.

How Unito supports integration governance

A centralized platform for all your integrations streamlines integration governance. Even better when that platform has enterprise-grade security built into the self-serve model.

That’s where Unito comes in.

Unito is a two-way sync solution with deep integrations for some of the most popular tools on the market, whether that’s project management apps like Asana, software development tools like Azure DevOps, or ITSM platforms like ServiceNow. It syncs data back and forth between them in real-time, and its integrations are easy enough to build that business users can set them up in minutes.

But it also comes with enterprise-grade security measures, from audit trails for each flow to a developer platform for deep customization.

Take control of your integrations

Integration governance doesn’t mean sacrificing IT control for business-user autonomy — or vice-versa. It’s a model you build to address your integration backlog without sacrificing integration quality, prevent data breaches, and give business users the autonomy they need without the risks they don’t. It requires using the right tools, creating the right policies, and giving business users more autonomy without falling into shadow IT.

As SaaS tool counts continue to grow, so will your integration backlog. Build your integration governance framework now and reap the benefits later.

[book a demo CTA]

FAQ: Integration governance for business users

Who owns integration governance, IT or operations?

Integration governance is co-owned by IT and ops teams. IT sets the initial guardrails for integration by determining what can and can’t be synced, choosing tools used for these integrations, and managing credentials. Ops teams are responsible for the day-to-day configuration of integrations, including the identification of new integration needs. The governance breaks down without collaboration between these two business functions.

What’s the minimum viable integration governance framework?

Authentication and authorization are essential elements of a minimum viable integration governance framework. Authentication allows IT to control which tools can be integrated while authorization breaks down what data can and can’t be synced. This prevents rogue credentials and unintended data exposure.

What happens when an integration breaks and nobody knows who owns it?

When an integration has no clear owner, a few things will happen:

• It takes longer to find out the integration is broken.
• IT has to reverse-engineer the integration to figure out who built it and why it broke.
• IT has to investigate the needs solved by the integration all over again, so they know which teams and projects are affected.

That’s why clear ownership and audit trails are essential. An integration’s owner doesn’t have to be responsible for fixing it themselves, but they can answer any questions that come up when it breaks.

Can business users accidentally expose sensitive data through self-serve integrations?

Absolutely, and surprisingly easily. Fields containing sensitive information are rarely protected with self-serve integrations, since most of them require significant permissions from every user. An authorization layer managed by IT is essential for preventing data breaches or exposure.

What’s the difference between integration governance and just using an iPaaS?

An iPaaS centralizes your integrations, allowing you to build them all in a single platform, usually without writing a single line of code. While using an iPaaS can make governance easier, it doesn’t completely replace it. Integration governance covers how you use integrations, no matter how they’re built.

View the full article