What Happens When Everyone Can Build Their Own Automation?

In 2021, a configuration setting exposed around 38 million records across 47 organizations using Microsoft Power Apps portals. The affected organizations included American Airlines, J.B. Hunt and the Indiana Department of Health.

UpGuard researchers found that certain portal lists could be accessed anonymously because the required table permissions had not been enabled. Microsoft subsequently changed the default settings for new portals and released a tool to help identify misconfigured existing ones.

UpGuard documented the findings in August 2021.

The incident illustrates what can happen when building an application becomes easier than checking how its data is protected.

Low-code tools make it possible for people close to the work to build useful applications and automations quickly. The finance team can simplify a recurring export. The warehouse can improve a hand-off. Sales can create a workflow that saves time every week.

But every new application or flow also raises practical questions: who can access its data, who maintains it, and who notices when something goes wrong?

Those questions become harder to answer when each team builds independently.

Who is already building these automations?

Low-code and no-code tools put flows, portals and small applications within reach of people outside IT departments.

They know the work. Finance knows which month-end export takes too long. The warehouse knows which hand-off causes delays. Sales knows which report nobody fully trusts.

The people closest to a problem can often build a useful fix faster than they can get a formal development project underway. When the result works, colleagues may adopt it too.

That can be valuable. Teams solve real problems, and IT doesn't have to build every small workflow from scratch.

The challenge emerges as these solutions become part of everyday operations.

An automation can start as one person's shortcut and gradually become a process that other people rely on. Its importance grows, even if nobody formally records who owns it or what systems it can access.

What goes missing first?

The overview of what has been built, what it can access and who is responsible for it.

In April 2026, security vendor Nokod published a survey of 200 enterprise CISOs. More than 80% of respondents said their security teams lacked full visibility into applications and AI agents built by business users. More than half also agreed that business users were creating applications supporting business-critical processes.

These figures come from a survey commissioned and published by a security vendor, so they should be read in that context. The underlying issue is straightforward: business-built applications and automations can become operationally important before the organization has a complete picture of them.

Read Nokod's 2026 survey announcement.

The same pattern can appear even when no low-code tool is involved.

In one of our projects, sales representatives reported customer visits in different ways. One sent an email, another updated a spreadsheet, and another used a different format. The information wasn't connected to the ERP system, so managers could see what had been reported but couldn't reliably establish what had happened across the team. The gaps surfaced during a monthly audit.

Each representative had developed a routine that worked from their own perspective. The company, however, lacked a consistent picture of the underlying activity.

This was not a low-code incident. It illustrates the same wider challenge: when people create their own ways of working, the organization can lose visibility across the whole process.

Low-code tools add another dimension. A personal workaround can become an application or automated flow that keeps running, potentially accessing data and supporting work long after its original purpose has changed.

What happens when the person who built it leaves?

Consider a Power Automate flow created using its owner's personal account and connections.

Microsoft describes flows without a valid owner as orphaned flows. If a flow relies on connections tied to the former owner's account, some actions can fail when that identity or connection is no longer valid. Microsoft recommends identifying orphaned flows and assigning appropriate new owners or co-owners to maintain continuity.

Microsoft's documentation explains how to manage flows when an owner leaves.

The business impact depends on what the flow does.

If it moves order information into an ERP system, a failure may affect order processing. If it transfers a finance file, the next team may be left waiting for information that never arrives.

The original builder may have left the organization months earlier. The team depending on the flow may have no idea who can fix it.

This is why ownership matters as much as functionality. A working automation needs someone accountable for its operation, access and maintenance.

How do you regain the overview without slowing everyone down?

Start with the systems the business already depends on.

Instead of relying entirely on a register that employees must remember to update, compare what people say they have built with the activity recorded in the systems those automations touch.

For example, begin with the ERP or CRM.

First, identify the accounts that can write data into the system.

Include individual users, integration accounts and service accounts. Where the system supports suitable activity or audit logs, examine which accounts have actually made changes during a defined period.

Keep in mind that available records depend on the system and its configuration. In some environments, audit logging must be enabled before the necessary history is available.

Next, establish who is responsible for each account and process.

Record who owns the automation, who can maintain it, and who can take over if the primary owner leaves or becomes unavailable.

Then compare the system records with the list of known automations.

Look for accounts with no identifiable owner, multiple automations performing similar tasks, and processes that write to important systems without a documented purpose.

The gaps are useful findings. They show where the organization needs more information before it can make informed decisions about access, maintenance or continued use.

Finally, introduce a proportionate review process.

Automations that write to the ERP or CRM, handle sensitive information, approve transactions or send data outside the organization should receive additional scrutiny before they are put into production. Smaller personal productivity workflows can follow a lighter process, provided their access and ownership remain clear.

The goal is to make important automations visible without making every small improvement a lengthy IT project.

So: what happens when everyone can build their own automation?

The organization can gain useful automation while losing track of what has been built.

An exposed portal, an orphaned flow and two versions of the same process are different examples of a similar oversight gap: the people responsible for the wider operation lack a complete picture of individual solutions.

The answer is to keep the freedom to build while making ownership, access and operational impact visible.

Start with one system - the ERP or the CRM.

Identify which accounts have written data into it over the past month. Compare that activity with the automations your teams know about. Establish who owns each important process and who can take over when needed.

Then ask one question:

For every account writing to this system, can someone explain what it does, why it needs access and who is responsible for it?