.png)
Most business automation discussions focus on the connections between systems: how data moves from the ERP to the CRM, how an order gets processed automatically, how a supplier gets notified without a person sending an email. That layer is critical, and it's where tools like n8n do the heavy lifting.
But there's a second layer that often gets overlooked: the human interface. Not every step in an operation can or should be fully automated. Approvals require judgment. Exceptions require context. Ops leaders need visibility dashboards that don't exist in their ERP.
This is where Retool fits.
Retool is a low-code platform for building internal tools: dashboards, data entry interfaces, approval queues, reporting views, and operational apps that your team uses internally. It connects directly to databases and APIs, which means the tools you build in Retool work with the same data your automations are processing, in real time.
The alternative to Retool is usually one of three things:
Retool sits between those options. It's faster to build than a custom app, more connected and functional than a spreadsheet, and purpose-built for internal operations work rather than adapted from an ERP module.
Retool provides a drag-and-drop interface for assembling components: tables, charts, forms, buttons, filters, and input fields. Each component can be connected to a data source, either a database query, an API call, or a webhook endpoint.
When a team member loads a Retool app, it queries the connected systems in real time and displays current data. When they take an action (click approve, submit a form, trigger a workflow), Retool writes back to the connected system or fires a webhook that triggers the next step in the automation.
A developer configures the data connections and the logic behind each action. Once built, non-technical team members use the app without needing to understand the underlying systems. The interface shows them exactly what they need to see, with exactly the actions available to them, and nothing else.
In a manufacturing or distribution operation using n8n for workflow automation and Google Cloud Functions for complex logic, Retool serves two roles:
1. Human-in-the-loop interfaces When an automated workflow reaches a step that requires a human decision, the workflow pauses and surfaces the decision in a Retool interface. The person sees the relevant context, takes an action, and the workflow continues. This is cleaner than email-based approval chains and creates a logged, auditable record of every decision.
2. Operational visibility Retool dashboards aggregate data from multiple systems into a single view for operations leaders. Instead of logging into the ERP, the 3PL portal, and the CRM separately to understand what's happening, a COO or VP of Operations sees a consolidated view built exactly for their needs.
Purchase order approval queue Procurement POs that exceed an auto-approve threshold surface in a Retool queue. The buyer sees the item, current stock level, proposed order quantity, supplier, and estimated cost. They approve, reject, or modify the order with one action. The approval is logged, and the automation continues.
Shipment exception dashboard Orders that have been in fulfillment-pending status past a defined threshold, orders where a 3PL shipment confirmation failed to sync to the ERP, or shipments where the customer notification bounced. The ops team sees the exceptions, not all shipments, and can act directly from the dashboard.
Inventory replenishment review For items below reorder point where automatic replenishment was paused for review (sole-source items, high-value components, items with variable lead times), the buyer sees a prioritized list with days of stock remaining, proposed order quantities, and action buttons. No ERP navigation required.
Customer account management interface For B2B operations, a Retool interface where the sales or account management team can view and update account-specific settings: notification contacts, pricing tier, credit limit status, or special handling requirements. Instead of asking IT or an ERP admin to make these changes, the account team does it directly through a controlled interface.
Operations reporting dashboard A daily or weekly view pulling from the ERP, CRM, and any other connected systems: order volume, fulfillment rates, open POs and their status, supplier performance metrics. Built once in Retool, always current, available to anyone with access.
New account onboarding workflow When a new wholesale customer is approved, an ops team member walks through a Retool form that collects the account setup details, assigns the pricing tier, and triggers the downstream automations (catalog assignment, welcome sequence, CRM record creation) without the team member needing to touch multiple systems directly.
Data correction interface When an automated workflow flags a data discrepancy (order quantities don't match between systems, a customer record has a missing field required for processing), a Retool interface presents the issue with context and lets the ops team correct it directly, with the fix propagating to the source system.
This is the most common question when Retool comes up. The ERP already has an interface. Why build another one?
The ERP interface is designed to be comprehensive. It shows all fields, all record types, all navigation options. That's necessary for the people managing the ERP. It's too much for the people who need to do one specific thing with one specific piece of data.
A buyer approving replenishment POs doesn't need to see the full ERP record for each item. They need to see five fields, with two possible actions. A Retool interface built for that task is faster, less error-prone, and doesn't require the buyer to have ERP training or permissions beyond what their role requires.
The same logic applies to dashboards. The ERP has reports and standard views. Those views are generic, requiring customization per query, and they don't aggregate data from other systems. A Retool dashboard is built once for a specific operational role, pulls from all relevant systems, and shows exactly what that role needs.
There's also a permissions dimension. Retool apps can expose specific data and specific actions to specific users without granting them broader ERP access. A warehouse supervisor can see and update shipment statuses without having full warehouse management module access in the ERP.
A Retool app for a specific use case follows this pattern:
For straightforward use cases (an approval queue, a simple dashboard), the build is lean. For complex interfaces with multiple views, conditional logic, or multi-system writes, it's more involved but still faster than equivalent custom development.
In most manufacturing automation stacks, n8n and Retool work together:
They communicate via webhooks and API calls. When a Retool user approves an item, Retool posts to an n8n webhook, and n8n continues the workflow. When n8n identifies an exception that needs human review, it posts to a Retool database table, and the exception appears in the relevant Retool dashboard.
Google Cloud Functions fill in the gaps where n8n's built-in logic isn't sufficient: complex calculations, multi-variable business rules, or data transformations that require custom code.
Together, the three tools cover the full automation stack for a mid-market manufacturing or distribution operation, without requiring enterprise software licensing or a large development team to maintain it.
.png)
