In many companies, leave requests, approvals and recurring reports still run as chains of emails and spreadsheets: a request is emailed, forwarded by hand, noted in a list and painstakingly reassembled at month end. Low-code tools promise to build exactly these workflows without classic programming — and increasingly it is not IT doing the building, but the department itself. That is an opportunity and a risk at the same time. Done cleanly, real manual work disappears; without a solid data connection and a few guardrails, islands emerge that nobody but the person who built them understands. This article sets out where departments can sensibly build for themselves, where the line to IT runs and what governance looks like when it protects without slowing things down. Where the handovers to existing systems are drawn cleanly is shown by our process automation.
Key takeaways
- Low-code is moving into the business units: by 2026 around 80 percent of low-code tool users will sit outside IT, up from 60 percent in 2021 (Gartner). That is not a loss of control but a shift that can be shaped.
- Self-build pays off for well-bounded workflows without sensitive data flows: leave requests, internal approvals with an amount limit, simple reports and checklists. There, a guided form saves real manual work compared with email and spreadsheet.
- A self-build becomes an island the moment it writes customer data, holds prices or stock, or is meant to connect several systems. Those cases belong to a reliable source of data and therefore in the hands of IT.
- Governance needs no request bureaucracy, just a few guardrails: a register of all self-builds, one binding source of data per figure, two named owners per workflow and a review each quarter (project experience).
- The data connection decides between island and building block. A form that pulls its data from the system of record and writes back to it is a building block; one with its own side list is a second version of the truth.
Why low-code is moving into the departments
Low-code describes tools that let you build forms, approval paths and small applications largely through building blocks and configuration, rather than programming every line by hand. The approach is not new, but its weight is growing noticeably: according to a Gartner forecast, by 2025 around 70 percent of new applications will use low-code or no-code technologies, compared with less than 25 percent in 2020 (Gartner). This shift is no longer carried by IT alone — by 2026 around 80 percent of low-code users are expected to work outside the classic IT department (Gartner).
The cause is rarely a fashion; it lies in daily practice. Requests pile up in IT, skilled staff are scarce, and a leave-request form ends up in the queue behind matters of greater consequence. At the same time, pressure grows in the business units: leave requests, approvals and reports still run in many places as Excel and email chains that cost time every day. Anyone who can remove that friction themselves does not wait for a project. This is exactly where low-code steps in — and exactly where it is decided whether it becomes a gain or a building site.
The trend towards so-called shadow IT reinforces this. Gartner expects that by 2027 around 75 percent of employees will acquire, modify or build technology that sits outside the visibility of IT, up from 41 percent in 2022 (Gartner). In large organisations the number of people building outside IT already clearly exceeds the number of professional developers (Gartner). The decisive question is therefore not whether departments build, but whether they do so in an orderly way. A blanket ban only pushes the building into the unseen; it is more sensible to make it visible and connectable.
Low-code is a tool, not a process
Where self-built workflows save real manual work
There is a clearly defined zone in which department self-build tends to work well and provides quick, tangible relief. The markers are: the workflow is bounded, only a few people are affected, no sensitive data is written, and the result stays internal at first. In this zone a guided form replaces an email chain, and a simple status replaces the shared list that nobody keeps up to date.
Leave and absence requests
Request, approval and overview in one guided flow instead of email and calendar side by side. The manager sees remaining leave and overlaps at once, and the approval is documented and traceable.
Internal approvals with an amount limit
Small purchases, expenses or material requests with a clear rule: up to an amount one approval is enough, above it two are needed. The record sits in one place, not across several inboxes.
Reports and checklists
Defect reports, maintenance lists, shift handovers or safety walks as a short form with mandatory fields. What was reported is findable — not scattered on notes on the pin board.
Simple status and shared overviews
A shared list of open items that everyone involved can see, instead of a spreadsheet passed around by email that exists in five versions. Ideal for tasks that need no connection to a system of record.
The common thread across these cases: they do not create a truth that is already managed elsewhere. A leave request does not compete with the ERP, a defect report does not compete with the inventory system. So the damage is small when something snags, and the gain is felt immediately. Starting here builds experience with the tool in an uncritical spot — a good basis before larger workflows are touched. A related question is whether the effort is worthwhile at all: when automation pays off sets out the typical thresholds.
Where low-code turns into islands and shadow IT
As clear as the good zone is, so is the tipping point. A self-build leaves the safe area the moment it touches data that is already held elsewhere. If a form creates new customers, changes prices, books out stock or is meant to make two systems talk to each other, then the department is no longer building an aid but a second source of data alongside the first. This is exactly where the problems arise that become expensive in daily work as media breaks and duplicate entry — described in eliminating duplicate data entry and spotting media breaks in your company.
On top of the practical risks come operational ones. A self-built tool often hangs on a single person: they built it, they know the silent assumptions, and with their holiday or departure the workflow stops. Frequently there is no backup, no test environment, and nobody knows who is actually allowed access. Where personal data is processed — and a leave or approval form does that — data protection is affected too; the legal requirements are set out in data protection when digitising processes. None of this is an argument against low-code. It is an argument for drawing the line deliberately.
Four warning signs of an emerging island
The line: what belongs in the department and what in IT
Instead of debating every single case anew, a simple check along a few markers helps. It answers the question not with a gut feeling but with traceable criteria — and can be run through in a few minutes per project. The comparison below sums up what is, in experience, well placed in the department and what belongs in IT.
| Marker | Department builds it itself | Belongs in IT |
|---|---|---|
| Data direction | Only reads or records internally | Writes back to systems of record |
| Kind of data | Uncritical, affects the team only | Personal, financial or customer-facing |
| Systems involved | One system or none | Several systems need to work together |
| Number of people | One team, manageable | Cross-department or site-wide |
| Consequence of an outage | Small, brief fallback to paper | Operations stop or data drifts apart |
| Maintenance effort | Rare, manageable in the team | Ongoing, versioned, with backup |
The line is not a wall but a handover point. Much sensibly begins as a small self-build and then grows into IT responsibility because it proves itself and gains more users. What matters is that this transition happens deliberately and not unnoticed: a tool meant for three people and now used site-wide needs different commitments on availability, backup and data protection than on day one. Whether a case needs a connection at all or whether manual work remains the cheaper answer is weighed up in interface or manual work.
Governance without bureaucracy: guardrails, not bans
Governance has a poor reputation in many companies because it is associated with requests, forms and waiting times — exactly what low-code was meant to bypass. Effective steering does not need that. It consists of a few guardrails that are barely noticeable in daily work and yet prevent helpful tools from turning into uncontrolled islands. The following five steps are enough for most mid-size companies (project experience).
Step 1: Set up a register
Every self-build is recorded in one place: who built it, what it does, which data it touches, who covers in case of illness? The register is not an approval but a map. Without it, nobody knows what is running in the business at all — and that is the heart of the shadow-IT problem.
Step 2: Fix the source of data
For each important item — customer, article, price, stock — exactly one system of record applies. A self-build may read from it but must not quietly keep its own version. This one rule prevents most of the later contradictions between lists.
Step 3: Name two owners per workflow
Not the person who built it alone carries the workflow, but two named owners, so that holiday and illness do not suspend it (project experience). They know the assumptions, keep the short guide up to date and decide on changes.
Step 4: Check data protection briefly
As soon as personal data is involved, a few sentences record: which data, for what, who sees it, how long it stays. This short check does not replace legal advice, but it makes visible when such advice is needed.
Step 5: Review regularly
Once a quarter the register is reviewed (project experience): what has grown, what now belongs in IT, what is no longer used and can go? This short review keeps the stock healthy instead of letting it sprawl.
Every self-build is recorded in one place: who built it, what it does, which data it touches, who covers in case of illness? The register is not an approval but a map. Without it, nobody knows what is running in the business at all — and that is the heart of the shadow-IT problem.
For each important item — customer, article, price, stock — exactly one system of record applies. A self-build may read from it but must not quietly keep its own version. This one rule prevents most of the later contradictions between lists.
Not the person who built it alone carries the workflow, but two named owners, so that holiday and illness do not suspend it (project experience). They know the assumptions, keep the short guide up to date and decide on changes.
As soon as personal data is involved, a few sentences record: which data, for what, who sees it, how long it stays. This short check does not replace legal advice, but it makes visible when such advice is needed.
Once a quarter the register is reviewed (project experience): what has grown, what now belongs in IT, what is no longer used and can go? This short review keeps the stock healthy instead of letting it sprawl.
A register entry need not be extensive. The few details that matter fit on half a page:
- Name and purpose of the self-build in one sentence, understandable to outsiders too.
- The sources of data used and whether it only reads or also writes.
- Two named owners and the rule for cover.
- Whether personal data is processed and who is allowed to view it.
- Where the short guide lives and when the self-build was last reviewed.
Enable instead of ban
The data connection decides between island and building block
The difference between a useful application and an expensive island is rarely the interface, but almost invariably the data connection. A form that pulls its master data from the system of record and writes its result back there is a building block: it fits into the existing data flow instead of opening a second one. A form with its own side list, by contrast, creates a second truth, and from the first contradiction between the two lists onwards the manual work begins that you actually wanted to abolish.
Technically the path runs via an interface or a small mediation layer that carries data cleanly back and forth between the self-build and the system of record. Where several systems are involved, an orderly data integration ensures that each item has exactly one origin and that changes in one place arrive everywhere. The effort for this is the real reason such cases belong in IT: it is not the form that is difficult, but the reliable connection behind it.
An application is worth as much as its data connection. Without it, the finest form is just another list that someone has to reconcile with the truth at month end.
Example: from the email chain to a guided approval
A common entry point is the internal approval of small expenses. Before, it runs as an email chain with a hand-kept list; after, as a guided form connected to the system of record. The following shortened example shows the difference not in the look but in the data flow — and that is exactly what decides whether a building block or an island emerges.
Before: approval by email and spreadsheet
1. A staff member emails their manager
2. A short "fine" comes back, often from holiday
3. An assistant types the case into a list by hand
4. Accounting asks for the record at month end
-> status scattered across inbox, spreadsheet and hallway
After: guided approval (low-code, connected)
1. The form pulls name, cost centre and budget from the system
2. Rule: one approval up to 500 EUR, two above that
3. The result is written back to the system of record
4. Accounting sees the record where the booking lives
-> one source of data, one traceable historyThe visible gain is the saved manual work; the real gain is traceability. Who approved, under which rule and on what basis sits in the same place as the later booking. With that the second list disappears, and at month end accounting no longer reassembles what is scattered. How approvals can be mapped cleanly in general is deepened in digitising approval workflows; how stubborn spreadsheet workarounds can be replaced is shown in replacing spreadsheet workarounds.
What a business can prepare itself
The larger part of an orderly low-code practice lies in the preparation, not in the tool. Much of it can be done without external support — and clarifying it in advance means starting under much better conditions. The following order has proven itself.
- Gather existing self-builds once: who uses what, and which data does it touch? This stocktake typically surfaces one to two dozen tools that nobody knew centrally (project experience).
- Write down the source-of-data rule: name exactly one system of record for each important item, from which all others read.
- Define the permitted cases for self-build and equally the cases that belong in IT — using the markers from the comparison.
- Name two owners per self-build and firmly plan their time for maintenance and questions (project experience).
- Introduce a short data-protection check for all forms with personal data, with a clear route to a professional assessment.
- Put a fixed date each quarter for reviewing the register in the calendar before the first self-build goes live.
How an orderly rollout lands with the team, without staff bypassing the new form, is described in bringing staff along with new workflows. What runs permanently afterwards — backup, small adjustments, fault handling — belongs in managed operations and maintenance and not in the remaining time of a project phase; the documentation for it finds its place in a well-kept process documentation. Anyone working in parallel on legal obligations will find adjacent topics in the e-invoicing mandate 2027 and AI in back-office work.
Related Articles
Verification of payee in payment runs: handling mismatches
Since October 2025, banks check name and IBAN before every credit transfer. How supplier master data, payment blocks and call-backs handle the bank's responses.
Interim Payments and Variations on Building Sites
How a stage of completion becomes an interim invoice, why a variation is a case with a deadline of its own, and how that produces a final account that can be checked without rework.
Packaging reporting driven by the item master
Which field is missing on the item, how packaging weights per variant and shipping carton are maintained, and how delivery note quantities become a defensible reported tonnage per material type.