Your workflows already do the work. Now your Agents can call them. FLO workflows run on schedules, webhooks, and manual triggers today. FLO to Sigma adds a fourth way to invoke them: a user simply asking for what they need, in conversation with a Sigma Agent. The workflow isn’t rebuilt and the logic isn’t duplicated. Sigma connects to the existing workflow and makes it available as a Tool an Agent can call when it’s relevant to the request.
Build the workflow once, in FLO. Make it callable, from Sigma.

​
What Changes

The workflow’s behavior is unchanged. What changes is how it can be reached.

​
Architecture

FLO exposes a project’s workflows through an MCP server. Sigma connects to that server, discovers the available workflows, and presents each one as an attachable Tool. An Agent with a workflow attached can invoke it mid-conversation and return the result as part of its response.
FLO remains the system of record for the workflow. Sigma provides the conversational interface to it.

​
Setting Up a Connection

1

Connect a FLO Project

Provide the project’s MCP server URL and an authentication token in Sigma’s FLO integration settings.
2

Review Discovered Workflows

Once connected, Sigma lists every workflow in the project individually, with its name and description. No manual re-entry is required. For example, a project might expose:Each discovered workflow can be enabled or disabled independently.
3

Enable the Workflows You Want Available

Not every workflow needs to be exposed to every Agent. Enable only the ones relevant to a given use case, and disable the rest.
4

Attach a Workflow to an Agent

Enabled workflows are attached to an Agent using the same mechanism as any other Action.
5

Invoke It in Conversation

Once attached, the Agent can recognize a matching request and call the workflow directly, returning the result inline.

​
Governance and Approval

A workflow attached to an Agent is treated as a Tool, and follows Sigma’s existing tool-governance model, including optional approval gating. With approval enabled:
Without approval (for low-risk, read-only workflows):
Approval requirements are configured per workflow, allowing sensitive actions to require explicit confirmation while low-risk lookups run without friction.
FLO-backed Tools follow the same approval and access rules as every other Tool in Sigma — there’s no separate safety model to learn. See Actions & MCP for more on approval controls.

​
Design Principles

  • No duplicated logic — the workflow’s business logic stays in FLO. Sigma exposes it; it doesn’t reimplement it.
  • No rebuild required — existing workflows become available to Agents without modification.
  • Workflows keep every existing trigger — schedules, webhooks, and manual runs continue to work exactly as before. Conversational invocation is additive.
  • Consistent governance — FLO-backed Tools follow the same approval and access controls as every other Tool type in Sigma, with no separate model to configure or learn.

​
Example Use Cases

Live status lookups

A workflow that checks a live data source becomes something a user can simply ask about, instead of navigating to check it manually.

Calculations and data processing

A workflow that transforms or computes a result can be triggered by a natural-language request, with the result returned in context.

System and account checks

A workflow that queries an internal system for status information becomes available as a direct question in chat.

Operational actions

A workflow that performs a downstream action can be gated behind approval, so the Agent prepares the action but a human confirms before it executes.

​
Getting Started

1

Open FLO Integration Settings

Open the FLO integration settings in Sigma.
2

Connect a FLO Project

Connect a FLO project using its server URL and token.
3

Review and Enable Workflows

Review and enable the workflows you want available.
4

Attach to an Agent

Attach enabled workflows to the relevant Agent.
5

Test It

Test by asking the Agent a question the workflow can answer.
FLO to Sigma connects your existing automation to the conversational layer, without requiring any change to how the underlying workflow is built or maintained.