Workflows that run the same way every time

A process fires when a webhook arrives or a schedule ticks. It looks up a record, transforms it, writes to three systems in order, and if the third write fails it has to undo the first two. No person is in that path, the logic is fixed, and it has to run the same way every time.

That kind of process should not need an AI model in the loop, and it should not live in a script with no history anyone can read.

Workflows in Neblex Integration Fabric are deterministic, multi-step processes with branching, retries, and compensation built in. They are triggered on a schedule, by a webhook, by a poll for changes or a live stream from a connected system, or by someone submitting a form.

Every run is recorded in event-sourced history, so you can see which step ran, what it did, and what it returned. If something breaks, you replay the flow from the exact step that failed instead of re-running the whole thing.

Workflows and AI agents run on the same platform and the same audit trail, so a process can start deterministic and hand off to an agent for the one step that genuinely needs judgment, without leaving the platform.

When a process needs a person in the path (an approval to grant, a task queue to work, an SLA to meet) that is business process management, and it runs on the same platform. Workflows are the deterministic parts around it: the branching, the writes, and the rollback.

Flows are built three ways, and you can move between them on the same flow:

• Natural language. Describe the flow to Matt, the Neblex AI Assistant built into the builder. Matt drafts the canvas, maps fields, and explains steps. It runs on the platform's builder model by default, or on a model you connect for the building experience only. That setting never supplies a model or credential to deployed agents, their tools, knowledge search, apps, or flows.
• Native builder. Assemble steps, branches, and connectors on the visual canvas.
• MCP. Create, change, publish, and run flows programmatically, so an external client or agent can build on Neblex directly, with consent scopes for operating, authoring, and publishing.

Agents, forms, apps, data tables, and connections have their own builders and the same MCP surface.

An AI agent is a step type inside a flow, the same as an API call, a branch, or an approval. You drop it in at the one point where the logic is a judgment call and keep every step around it deterministic.

The agent gets a scoped task, only the tools you grant it for that step, and a model you choose. It returns a structured result that the next step branches on, and its reasoning and every tool call it made land on the same run log as the rest of the flow. Any approval checkpoint set on the agent still applies before it acts.

For example, a refund flow validates the request deterministically, calls an agent to judge whether a borderline case looks legitimate, and routes anything the agent is unsure about to a person. The validation, the payout, and the write-back stay fixed logic; only the judgment is delegated.

• Branching, retries, and saga-style compensation to unwind partial writes cleanly on failure
• Scheduled, webhook, event, and form or app submission triggers
• Event-sourced history with step-level replay: fix the cause, resume from the failure
• Promotion approvals move changes from dev to prod, on a tamper-evident audit trail
• Call an AI agent as a step for the one judgment call, with its reasoning on the same run log
• The same platform and governance as AI Agents, so the rest of the flow stays deterministic

A real flow teams build on day one, with the actual step-level detail.

A closed deal fanned out to four systems, rolled back cleanly on any failure

When an opportunity is marked closed-won, the flow creates the customer and order in the ERP, provisions the product, opens a billing account, and updates the CRM, with no person in the path. If any write fails, the ones before it are undone.

1. 1Trigger: a CRM webhook fires on stage = Closed Won with the account and line items.
2. 2Idempotency: the trigger deduplicates on the opportunity ID, so a duplicate or replayed webhook is a no-op, and each write carries an idempotency key so a cooperating API sees one write.
3. 3Write ERP: create the customer and sales order in NetSuite and capture both internal IDs.
4. 4Provision: call the product API to activate entitlements for the order.
5. 5Billing: open a billing account and attach the subscription.
6. 6Write CRM: write the ERP order number and billing account ID back to the opportunity.
7. 7Compensate: if provisioning or billing fails, cancel the NetSuite sales order and deactivate the customer, then mark the run failed for replay.