Connecting a Boomi Flow app to integration processes

In A purchase-request approval workflow in Boomi Flow we built an app that collects a request and routes it for approval. Two things were still manual: the supplier list was static, and after approval someone had to type the purchase order into the ERP. This article explains how a workflow app should talk to back-end systems, then connects the app to Boomi Integration processes that read suppliers from the ERP and create the purchase order.

The problem: apps that talk to the ERP directly

The quick way is to let the app call the ERP’s API from each screen. It works for a demo and causes trouble later:

ERP logic leaks into the app. Company codes, document types and field rules end up spread across pages and decisions, where workflow designers have to maintain them.
Every app repeats the same work. The purchase app, the expense app and the returns app each implement “create a document in the ERP” slightly differently.
Credentials multiply. Each app holds its own powerful ERP account.
Errors surface in the wrong place. An ERP timeout shows up as a broken screen with no retry and no log.

The pattern: the app asks, integration does

Split the responsibilities:

The workflow app owns people, screens and decisions. It asks for business operations in business terms: “give me the active suppliers”, “create a purchase order for this approved request”.
Integration processes own the systems. They know how to call the ERP, map the data, handle errors and retry.
Between them is a small service contract: named operations with a request and a response, nothing ERP-specific.

Flow app ──► "List suppliers"          ──► integration process ──► ERP
         ──► "Create purchase order"   ──► integration process ──► ERP

The same contract can serve other apps, and the ERP can change without touching the flow. It is the same idea as an API facade, applied to apps. (See Exposing your ERP as a REST API with Boomi for the API version.)

Two rules make the contract work:

Read operations are fast and safe. “List suppliers” returns small, filtered data and changes nothing.
Write operations are idempotent. “Create purchase order” receives the request ID (PR-2026-118) and checks whether a PO already exists for it. If the user clicks twice or Flow retries, you still get one PO.

Building it in Boomi

Boomi connects Flow and Integration with a few dedicated pieces:

a Flow Service component in Boomi Integration, which defines the operations (message actions) the app can call;
integration processes that start with the Boomi Flow Services Server connector and implement each operation;
the Boomi Integration Service connector in Boomi Flow, which points to the deployed Flow Service.

Exact labels and options can change between releases; the order of work below stays the same.

Step 1: Design the two operations

Write the contract down first, as JSON:

// List suppliers: request
{ "category": "IT equipment" }

// List suppliers: response
{ "suppliers": [ { "supplierId": "S-0381", "name": "Techno Hellas SA" },
                 { "supplierId": "S-0412", "name": "Office Point" } ] }

// Create purchase order: request
{ "requestId": "PR-2026-118", "supplierId": "S-0381", "costCentre": "210",
  "description": "3 laptops for warehouse", "amount": 2450.00, "approvedBy": "k.nikolaou" }

// Create purchase order: response
{ "requestId": "PR-2026-118", "poNumber": "PO-77815", "status": "Created" }

Create a JSON profile in Boomi Integration for each request and response.

Step 2: Build the integration processes

For List suppliers:

Create a process whose Start shape uses the Boomi Flow Services Server connector with the Listen action.
Query the ERP for active suppliers (with the ERP’s connector or the HTTP Client connector), filtered by category.
Map the ERP result to the response profile and end with a Return Documents shape.

For Create purchase order:

Same start configuration, with the create request profile.
First look up whether a PO already exists for requestId (for example in a reference field on the ERP document). If it does, return that PO number instead of creating a new one.
Otherwise map the request to the ERP purchase order format and create it.
Return the PO number. On failure, return a clear status and message rather than letting the process error out silently, so the flow can show something useful.

Step 3: Create the Flow Service component

Create a Flow Service component and give it a path, for example /purchasing.
Add two message actions, List Suppliers and Create Purchase Order. For each, select the request and response profiles and the process from step 2.
Deploy the Flow Service component and both processes to the same runtime environment (Atom, Molecule or Atom Cloud). The service only works when everything is deployed together.

Step 4: Install the connector in Boomi Flow

In Boomi Flow, add a Boomi Integration Service connector.
Choose the runtime and enter the path of the Flow Service (/purchasing). Authenticate with a dedicated integration user and token, not a personal account.
Install it. Flow reads the service definition and creates types from your profiles, plus the actions you can call.

Step 5: Use the actions in the flow

Load suppliers. Before the request page, add a Message element that calls List Suppliers and stores the result in a list value. Bind the supplier combobox on the request page to that list.
Create the PO. After the Approve outcome (and the Auto-approved path), add a Message element that calls Create Purchase Order with Current Request. Store the returned poNumber on the request.
Handle failure. Add a Decision after the call: if status is not Created, route to a page or notification for the purchasing team, instead of telling the requester everything went well.

Step 6: Test end to end

Open the request page and check the supplier list matches the ERP.
Submit a 2,450 EUR request, approve it, and check the PO exists in the ERP with the right supplier and amount.
Trigger the create action twice for the same request ID and confirm only one PO exists.
Stop the ERP connection (or point to a wrong host in test) and confirm the failure path works.
Check the process executions in Boomi’s process reporting for each test, so you know where to look in production.

Before you go live

Least-privilege ERP account. The integration user only needs to read suppliers and create purchase orders.
Watch response times. A Message element that waits on a slow ERP leaves the user staring at a spinner. Keep read operations small, and consider caching reference data that changes rarely.
Long-running writes. If creating the document can take long, design for it: let the flow continue and update the status when the process finishes, rather than holding the user’s screen. Check the Flow Service documentation for how your version handles long executions.
Log the request ID everywhere. It links the flow state, the process execution and the ERP document.
Reuse the service. The next app that needs suppliers should call the same Flow Service, not build its own.

Summary

Keep the app focused on people and decisions, and let integration processes own the systems. In Boomi, a Flow Service component publishes the operations, processes implement them, and the Boomi Integration Service connector makes them available to the flow. Make writes idempotent and failures visible. For the bigger picture, see Workflow automation and low-code apps: a practical guide, and for retry strategies in the processes behind the service, see Error handling and retries in Boomi.