Workflow automation and low-code apps: a practical guide

Every company has processes that live in email. A purchase request goes to a manager as an attachment, the manager replies “OK”, someone forwards it to accounting, and accounting types it into the ERP. It works until the manager is on holiday, the attachment has the wrong version, or an auditor asks who approved order 4711 and when.

Workflow automation is about moving those processes out of inboxes and into something that routes the work, records every decision and talks to your systems. This guide explains the building blocks, how workflow automation differs from integration and from RPA, when a low-code app is the right answer, and how to compare the tools.

Process automation vs integration automation

The two are often sold together, and they solve different problems:

Integration automation moves data between systems without people: an order from the e-shop becomes a sales order in the ERP, stock levels flow back. It runs in seconds, in the background, thousands of times a day.
Process (workflow) automation coordinates people and systems over time: a request is submitted, someone reviews it, someone else approves it, and only then does a system get updated. It may take days, and it waits for humans at specific points.

The key difference is state over time. An integration flow usually finishes in one run. A workflow must remember that request PR-2026-118 is waiting for Maria’s approval, remind her on Thursday, and escalate to her deputy on Monday. That is why workflow tools have concepts integration tools don’t: tasks, assignees, deadlines, forms and an audit trail.

Most real processes need both. The workflow handles the human part; integration handles “read the supplier list from the ERP” and “create the purchase order once approved”.

The building blocks

1. Forms and screens

People need a way to start a process and to act on it: a request form, an approval screen, a task list. Low-code tools let you build these by dragging fields onto a page instead of writing a web application. Good forms validate input early (a cost centre that exists, an amount that is a number) and pull reference data from your systems instead of asking users to type it.

2. The process model

The model describes the steps, the decisions and who acts at each point: “if the amount is over 2,000 EUR, the department manager approves; otherwise it goes straight to purchasing”. Some tools use the BPMN standard; others use their own visual canvas. Either way, the model should be readable by the business people who own the process.

3. Human tasks and roles

A task is assigned to a role (“approver for cost centre 210”), not to a named person hard-coded in the process. Roles come from your identity system (Microsoft Entra ID, Okta, an LDAP directory), so that when people change jobs the process keeps working.

4. Rules and decisions

Thresholds, routing and eligibility rules change more often than the process itself. Keep them in one visible place, such as a decision table or a configuration value, so the finance team can change “2,000 EUR” without a redeploy.

5. Notifications, deadlines and escalation

People forget. The workflow should notify, remind and escalate: an email or Teams message when a task arrives, a reminder after two days, reassignment after five.

6. Integration with systems of record

The workflow should read from and write to the systems that matter (ERP, CRM, HR) through APIs or integration processes, not by people copying data between screens. This is where workflow automation and integration meet.

7. Audit trail and reporting

Who submitted, who approved, when, with what data. This is often the single most valuable output: it answers auditors, and it shows where requests get stuck.

RPA vs API-based automation

Robotic process automation (RPA) uses software robots that operate an application’s user interface the way a person would: click here, copy that field, paste it there. It is useful when a system has no API at all, such as an old desktop application or a supplier portal with no integration option.

API-based automation talks to systems through their interfaces for software. It is faster, more reliable and easier to secure.

A practical rule: use APIs where they exist, and RPA where they don’t. RPA robots break when a screen changes, and they often need a user account with broad rights. Treat RPA as a bridge to a system you can’t integrate properly yet, not as your integration strategy.

When you need it, and when you don’t

Workflow automation pays off when:

A process involves several people or departments and today runs over email or spreadsheets.
You need to prove who approved what (audits, ISO, public-sector or bank requirements).
Requests get lost or stuck, and nobody can say where.
The same data is re-typed from a form or email into the ERP or CRM.

It is probably overkill when:

The process is fully automatic with no human decision. That is an integration, not a workflow.
One person does the whole thing, a few times a month.
Your ERP or CRM already has a built-in approval feature that covers the case. Use it before adding a new tool.

Citizen developers and governance

Low-code tools let people outside IT (finance analysts, operations managers) build their own apps and automations. This is a real benefit: the people who know the process build the solution. It also creates risk: dozens of undocumented automations, each with its own credentials, that nobody maintains when their author leaves.

A light governance model is enough for most mid-sized companies:

Environments. Citizen developers build in a development environment; IT promotes to production after a short review.
Approved connectors. Decide which systems can be connected and with which accounts. Personal credentials should never run a production automation.
Ownership. Every app has a named business owner and a technical contact.
An inventory. One list of what exists, what it touches and who owns it.
A path to IT. When an app becomes business-critical, IT takes over its operation.

Common mistakes

Automating the mess. If the current process has six approvals because nobody trusts anyone, automating it gives you six faster approvals. Simplify first.
Hard-coding people. “Send to Nikos” breaks the day Nikos leaves. Route to roles.
No path for exceptions. What happens when the approver rejects, or asks for more information? Model it.
Copy-paste integration. If the form asks users to type supplier codes from the ERP, read them from the ERP instead.
Ignoring mobile. Approvers approve on their phones. Test the approval screen there.

How to compare tools

Who builds? Professional developers, IT generalists or business users. This decides how much code the tool should expose.
How much integration is needed? If most steps read or write ERP and CRM data, a tool that sits close to your integration platform saves a lot of work.
Process complexity. Simple approval chains or long-running processes with parallel branches, timers and compensation? The latter favours BPMN-based engines.
Identity. Does it work with your directory for users, groups and single sign-on?
Audit and compliance. Can you export a complete history of every decision?
Licensing model. Per user, per app, per run or per process. Price it with your real number of requesters and approvers, not just builders.
Governance features. Environments, connector policies, an inventory of apps.

Tools in this space

There is no single best tool. These are the ones we come across most often, in alphabetical order.

Boomi Flow. A low-code tool for building workflow apps and screens on the Boomi platform, with a visual canvas for pages, decisions and approvals. It fits best when the workflow needs to read and write data through integration processes that already run on Boomi, because the app and the integrations are built and connected on the same platform.
Camunda. A process orchestration platform built on the BPMN and DMN standards, popular with development teams that want to model complex, long-running processes and keep them in code and version control. It is developer-centric rather than aimed at business users.
Microsoft Power Automate / Power Apps. The natural choice for organisations on Microsoft 365, with a large connector library, approvals built into Teams and Outlook, and a strong citizen-developer story. It includes RPA (desktop flows). Governance needs deliberate set-up as usage grows.
ServiceNow App Engine. Low-code app building on the ServiceNow platform, a strong fit for companies that already run IT or HR service management on ServiceNow and want workflows that share its data, roles and audit model.
UiPath. A leading RPA platform that has grown into broader automation, including orchestration and API automation. Best known for automating work in applications that have no usable API.
Zapier and Make. Easy, cloud-based automation between SaaS applications, with thousands of ready connectors. Great for small teams and simple trigger-action automations; less suited to complex approvals or on-premises systems.

Start with what you already own. If your company lives in Microsoft 365, look at Power Automate first; if your integrations run on Boomi, Boomi Flow avoids a second integration layer.

Where to go next

Two practical articles build the patterns from this guide in Boomi Flow:

A purchase-request approval workflow in Boomi Flow: forms, threshold routing and notifications.
Connecting a Boomi Flow app to integration processes: reading reference data from the ERP and creating the purchase order on approval.

If your workflow will also involve AI assistants, see our guide on AI agents in integration.