Flow Design Canvas

The flow design canvas defines the executable logic of an integration flow: it arranges nodes, connects processing paths, and configures data sources, field mappings, branch rules, target execution, and notifications, then saves or publishes the configuration as a flow version.

Enter Integration Flow Config from the selected OpenLink entry, select a flow, and click Open flow design canvas.

The canvas has four parts:

Part	Location	Responsibility
Top actions	Canvas top bar	Back, copy, save, publish, save and publish, request example
Node palette	Left	Adds nodes to the canvas and shows how many of each node type exist
Canvas	Center	Arranges nodes, creates connections, and selects nodes or connections
Inspector	Right	Edits node names, node behavior, field mappings, branch conditions, messages, and connection names

1. Top Actions

Action	Description
Back	Returns to the flow list
Copy	Validates the current canvas and creates an independent draft flow from it
Save	Saves the current canvas as a new flow version
Publish	Publishes the saved version when the current version is not published yet
Save and publish	Saves the current canvas and publishes the new version immediately
Request example	Shows a call example for the current webhook flow, including the authentication placeholders

The top bar also shows the flow type, current status, and current version. Copy, save, and publish run the validation described in section 4 first.

2. Node Palette And Connections

Node Types

Node	Purpose
Start	Defines the flow entry; a canvas keeps one start node
Source	Describes where input data comes from, such as a webhook body, poll script input, or local form data
Transform	Configures main and child table field mappings, and is usually the main data processing node
Branch	Splits paths by condition and routes matched and unmatched data separately
Target	Defines the execution result, such as writing to a local form or calling a Studio script
Message	Sends a notification inside the flow
Agent execution	Analyzes integration data with a published agent and runs the system commands that agent is allowed to use
Query	Reads local form records and the selected local child tables for query flows
End	Marks the end of the flow; a canvas keeps one end node

The palette shows the current count next to each node type. Start and end nodes cannot be added again once they exist.

Node Count Limits

Flow type	Limits
All	One start node and one end node
Inbound, outbound	One source node and at least one target node
Query data	One query node, no source node, and no target node
Message push	Only Start, Message, Agent execution, and End, with at least one Message

Connections

Drag from the output anchor of one node to the input anchor of another to create a connection. Select a connection to rename or delete it in the inspector. The canvas validates connections while editing, and invalid connections are not created.

Node	Connection requirements
Start	No incoming connection and exactly one outgoing connection
End	At least one incoming connection and no outgoing connection
Source, transform, target, agent execution, query	One incoming and one outgoing connection, with the outgoing anchor on a different side from the incoming anchor
Branch	One incoming connection plus the matched and unmatched outgoing connections
Message	One incoming connection; it may continue to later nodes or end the current path without an outgoing connection

Beyond the per-node rules, the canvas requires every node to be reachable from the start node, every path to reach the end node or finish at a Message, and the source node (the query node in query flows) to come before all branches.

When a flow has no saved canvas yet, Soln shows a starter canvas so design can begin from the default structure.

3. Node Configuration

Selecting a node opens the inspector on the right, which shows the current canvas state and the configurable options of the selection. Every node can be renamed, and connections can be renamed to express business meaning, such as “valid data”, “validation failed”, or “notify”.

Start Node

The start node describes how the flow is entered and shows the current form pairing and webhook information.

Setting	Description
Node name	Display name of the start node on the canvas
Trigger actions	For push flows, which local record events start the flow: create, update, or delete
Batch size	Poll flows always use paged batches; one submission is limited to 1–500 records and defaults to 100
Local form	The Soln form paired with the flow
External form	The external form paired with the flow
Webhook URL	Address that receives the external POST JSON request for webhook flows
Child table pairs	Shows the configured local and external child table pairs and provides Edit pairs

The start node does not replace the trigger mode chosen when the flow was created; it only adds entry details for that trigger mode.

Reconfigure Child Table Pairs

1. Select the start node and open the inspector
2. Under Child table pairs, click Edit pairs
3. Add, replace, or remove local and external child table pairs
4. Click Save pairs

Every pair needs one local child table and one external child table, and the same local or external child table cannot be used in more than one pair. External candidates include direct child objects of the external main form and objects that reference it through an enabled foreign key field.

When a removed or replaced pair is already used in Transform, the canvas asks for confirmation. Continuing deletes the child table mappings of that pair because the source and target relationship no longer exists, and keeps the mappings of unchanged pairs. The canvas is then marked as modified, and the change is stored only after saving or publishing.

Source Node

The source node describes the input side of the flow.

Flow context	Source behavior
Inbound webhook	Uses the webhook request body as source data
Inbound poll	Uses a Studio script to fetch or assemble source data
Outbound	Uses local form data as the source input

Inbound poll flows need a Studio script asset and script file, and the inspector shows a script input example. Paged polling passes a persistent checkpoint through input.cursor and a batch limit through input.pageSize; the script must request one page of external data and return { items, nextCursor } instead of iterating through every page internally.

For paged polling, Soln commits the page records and advances the schedule checkpoint in the same tenant database transaction. When a page fails, the page writes roll back, the cursor does not move, and the next execution continues from the last successful commit. Delivery is still at least once, so target nodes should use a local identifier field with create or update instead of relying on a non-idempotent create.

export default async function main(
  payload: StudioScriptRuntimeContextPayload,
  context: StudioScriptContext
) {
  const response = await context.http.requestJson({
    method: 'POST',
    url: 'https://api.example.com/integration/users/query',
    json: {
      cursor: payload.input.cursor,
      limit: payload.input.pageSize,
    },
    timeoutMs: 20_000,
  });

  return {
    items: response.data.items,
    nextCursor: response.data.nextCursor ?? null,
  };
}

Studio scripts run with a 30 second limit by default, and OpenLink integration scripts use a bounded 60 second setting. Single HTTP requests inside a script should still use a shorter timeout that matches the external API.

Transform

Transform maps source fields to target fields and supports main table and child table mappings.

Area	Description
Main table field mappings	Maps fields between the local main form and the external main form
Child table field mappings	Maps fields between local and external child tables
Source field	Uses a source-side field as the mapping value
Fixed value	Writes a fixed value without selecting a source field
Target field	Selects the field that receives the mapped value
Match field	Lets search fields define how incoming values match existing records
Option mapping	Maps option values between single select, multi select, and boolean fields
Auto mapping	Generates mappings from field names, API names, option labels, or option values
Mapping preview	Shows the data structure passed to later target execution

When a target node depends on transformed data, finish the transform mappings first and configure the target node afterwards.

Branch

Branch routes data by condition and has two outgoing paths: matched and unmatched. Every branch needs at least one condition, and the single source node (the query node in query flows) must come before all branches.

Available condition fields follow the flow direction: inbound flows can evaluate external fields and, where applicable, OpenLink subject mapping; outbound flows can evaluate local Soln fields.

Setting	Description
Branch name	Display name of the branch path
Condition	Rule that decides whether data enters the matched path
Matched path	Connection used when the condition is satisfied
Unmatched path	Connection used when the condition is not satisfied

Branches suit validation, exception handling, selective notifications, and routing records to different targets.

Target Node

The target node defines what happens after mapping and routing.

In inbound flows the target node usually writes into a local Soln form:

Inbound setting	Description
Write action	Create, update, create or update, delete, or a workflow callback where supported; the workflow callback is only available in inbound webhook flows
Trigger approvals	For create and create or update, controls whether the local form submission triggers approvals
Match field	Field used to match existing local records for update, create or update, and delete

In outbound flows the target node usually calls a Studio script:

Script setting	Description
Studio script	Script asset and script file to execute
Script input example	Shows the payload passed to the script, including flow info, trigger info, form binding, mapping result, raw input, and runtime context

Message

Message sends a notification; it may continue to later nodes or end the current path.

Setting	Description
Channel	In-app, push, or email; the template list follows the selected channel
Message template	Template to use; the template defines which input variables must be mapped
Recipient source	Recipients come from the flow context, fixed recipients, or local form fields
Context recipients	Sends to the trigger actor, the form submitter, or the recipients of a previous step
Fixed recipients	Members, roles, platform operators, organizations, or departments
Field recipients	Member, organization, or department fields from the local form
Priority	Low, normal, high, or urgent
Click action	None, open a resource, or open an external link; the resource type can be a flow execution, a form record, or a custom resource
Action template	Resource ID template, URL template, and optional JSON action arguments
Input mapping	Maps context paths or fixed values to the input variables declared by the template

Available context paths include flow input, upstream execution results, agent analysis results, source flow and execution information, form information, and the runtime language and time zone.

Query Node

The query node reads local form records and the selected local child tables for query flows.

1. Add a Query node
2. Select the local root form
3. Select the returned fields, or use select all and clear
4. Configure related data when child tables should be returned

Rule	Description
Local root form	Required; the query reads records of this local form
Returned fields	At least one field must be selected
Node count	A query flow keeps one query node and no source node

Agent Execution Node

The agent execution node analyzes integration data with a published agent and runs the system commands that agent is allowed to use.

1. Add an Agent execution node
2. Select a published agent
3. Enter the task instruction
4. Choose the execution timing: on success, on failure, or always

Both the agent and the task instruction are required, and the node connects like a source node: one incoming and one outgoing connection on different sides.

4. Validation, Versions, And Publishing

Validation Checklist

Before copying, saving, or publishing, the canvas must pass topology and node configuration validation:

• Exactly one start node and one end node
• Inbound and outbound flows have exactly one source node and at least one target node
• Query flows have exactly one query node and no source node
• Message push flows use only Start, Message, Agent execution, and End, with at least one Message
• Every branch has complete matched and unmatched paths and at least one condition
• Transform mappings are complete
• Every agent execution node has an agent and a task instruction
• Every node is reachable from the start node, and every path reaches the end node or finishes at a Message

When validation fails, the canvas points at the node that needs attention, and the operation can be retried after fixing it.

Save And Publish

Action	Description
Save	Creates a new version from the current canvas
Save and publish	Creates a new version and publishes it immediately
Publish	Publishes the saved version when there are no unsaved changes

A flow has a runnable version only after publishing. Enabling and disabling the flow stays in Integration Flow Config.

Copy The Current Canvas

1. Click Copy in the top bar
2. Enter the new flow name and an optional description
3. Click Copy to confirm

Soln runs the same validation as saving before copying, so the copy can include unsaved canvas changes that already passed validation. The flow code is generated automatically.

The result is a draft flow with its own version and audit information. Its graph, field mappings, child table pairs, scripts, node settings, and push overlap policy are copied. Runtime state is not: the new flow is not enabled or published automatically and does not inherit execution logs or an active poll schedule, so review and publish it separately.

5. Recommended Order

1. Confirm the flow type, trigger mode, main pair, and child table pairs in Integration Flow Config
2. Open the flow design canvas
3. Review the starter canvas and keep one start node and one end node
4. Configure the start node entry details
5. Configure the source node, selecting a Studio script when the source needs one
6. Configure the main and child table transform mappings
7. Add a Branch when conditional routing is needed
8. Add and configure the query node for query flows
9. Add agent execution nodes when model analysis is needed
10. Configure target execution
11. Add a Message when notifications are needed
12. Verify that every node connects from the start node to an end path
13. Save and publish the canvas
14. Go back to Integration Flow Config, enable the flow, then test the trigger and review the execution logs