Integration Flow Config
Integration flows define how data moves between Soln forms and external forms. A flow belongs to the selected OpenLink: open OpenLink, select the target OpenLink entry, and enter Integration Flow Config from the details actions.
The configuration has three layers, each with its own job:
| Layer | Where | Responsibility |
|---|---|---|
| Flow list | The Integration Flow Config page | Create flows, search, enable or disable, run once, delete |
| Flow details | The panel next to the list | Review basic info, description, child table pairs, and audit info |
| Design canvas | Open flow design canvas | Configure nodes, field mappings, and data transformation, then save and publish a version |
1. Flow Types
Creating a flow starts with the flow type, which decides what the flow does, which trigger modes it can use, and whether it binds forms.
| Flow type | Purpose | Form binding |
|---|---|---|
| Inbound | Sync external form data into a local Soln form | Required; an inbound Webhook flow may skip the binding |
| Outbound | Send local Soln records to the external form or system | Required |
| Query data | Let external callers read local form records, returning data without writing it | Local main form only, without an external form |
| Message push | A notification flow triggered by an external Webhook, without form binding or form writes | Not used |
The request contracts for query and message push flows are in Query Data and Message Push.
2. Trigger Modes
The trigger mode decides how a flow starts, and the flow type limits the available modes.
| Flow type | Available trigger modes |
|---|---|
| Inbound | Webhook, Poll, Service call |
| Outbound | Push, Schedule, Service call |
| Query data | Webhook |
| Message push | Webhook |
| Trigger mode | Description |
|---|---|
| Service call | Called by an approval or automation node with business context, not a manual entry point for users |
| Webhook | The external system sends a POST JSON request to the generated address; inbound flows use the inbound webhook URL, query flows use the query endpoint, and message push flows use the push endpoint |
| Poll | Soln runs the source Studio script on a Cron expression, pages through external data, and advances the cursor when a page succeeds |
| Schedule | The outbound form of Poll: starts the outbound flow on a Cron expression without polling the external system, reusing the same scheduling runtime |
| Push | Soln pushes data when local records are created, updated, or deleted |
Trigger Settings
| Setting | Applies to | Description |
|---|---|---|
| Cron expression | Poll, Schedule | Required when the flow is created, for example 0 */5 * * *; it can be changed later in the edit window |
| Webhook URL | Webhook | After the flow is created and enabled, the external system triggers it with a POST JSON request to this address, which the edit window shows |
| Push actions | Push | Select at least one of create, update, and delete |
| Push overlap policy | Push | Decides whether overlapping executions of the same source record queue or run in parallel |
Push Overlap Policy
The policy applies only to Outbound + Push flows, and its scope is the current tenant, the current flow, and one source record. It never serializes the whole flow: different source records always run in parallel.
| Policy | Behavior | Use it when |
|---|---|---|
| Queue per record | When the same source record triggers again before the previous execution finishes, the new execution waits in the queue; this is the default | Events of the same record must stay ordered, or the external target cannot accept concurrent writes for one record |
| Allow parallel | Every event starts as soon as runtime capacity allows, including overlapping events of the same record | The external operation is concurrency safe and event order does not affect the result |
For example, the first outbound call for purchase order PO-100 is still running when the record is updated again. With Queue per record, the second execution waits until the first one succeeds, fails, is cancelled, or exhausts its retries. With Allow parallel, both calls run at the same time. Either way, PO-101 can run in parallel with PO-100.
When one business change involves 10,000 different records, they are not placed in one global serial queue. The policy only decides what happens when the same record overlaps with itself; the actual concurrency of different records still depends on runtime capacity and task scheduling.
3. List, Details, And Status
List Areas
| Area | Description |
|---|---|
| Back | Returns to the OpenLink page |
| Search external integration flows | Filters the flow list by keyword |
| New external integration flow | Opens the creation window |
| Summary cards | Count inbound, outbound, query data, message push, enabled, and disabled flows |
| Flow list | Shows flow name, code, form binding, local and external forms, trigger mode, status, version state, and audit info |
| List actions | View flow details, open the design canvas, view execution logs, run once now, enable, disable, and delete the flow |
| Configure inbound protection | Sets the tenant inbound protection: requests per minute and maximum concurrent requests |
Status And Versions
| Status | Description |
|---|---|
| Draft | The initial state of a new flow; it can be edited but does not run |
| Published | A published version exists, so the flow can be enabled and run |
| Archived | The flow is archived and is no longer used as a regular flow |
The list also shows the version state: None when the flow has no usable version and Configured when a version exists. Enabling a flow publishes its latest usable version.
4. Create A Flow
- Enter Integration Flow Config from the selected OpenLink entry
- Click New external integration flow
- Enter the Flow name
- Choose the Flow type
- Choose the Trigger mode
- Fill in the Cron expression, or the push actions and push overlap policy
- Add a Description when needed
- Choose the Local main form; inbound webhook flows and message push flows may skip the form binding
- Choose the External main form
- Add child table pairs when detail records need mapping
- Click Create
| Field | Required | Description |
|---|---|---|
| Flow name | Yes | Name shown in the flow list and execution logs |
| Flow type | Yes | Inbound, outbound, query data, or message push |
| Trigger mode | Yes | Available options come from the flow type |
| Cron expression | Yes for Poll and Schedule | For example 0 */5 * * * |
| Push actions | Yes for Push | Create, update, and delete; select at least one |
| Push overlap policy | Yes for Push | Defaults to Queue per record |
| Description | No | Explains this sync path |
| Bind form | Optional for inbound webhook flows | Message push flows never bind a form |
| Local main form | Yes when the flow binds a form | Soln form paired with the external main form |
| External main form | Yes when the flow binds a form and is not a query flow | External form paired with the local main form |
| Child table pairs | No | Local and external child table pairs |
The flow code is generated from the flow name, so it is not entered separately. When the flow type, trigger mode, and main pair reuse an existing form binding, Soln reuses it; otherwise it creates a new binding for the flow.
New flows are created as drafts. Complete the mappings and node configuration in the design canvas before enabling the flow.
Main And Child Table Pairs
| Pair | Description |
|---|---|
| Local main form | The primary Soln form used by the flow |
| External main form | The primary external form used by the flow |
| Local child table | A child table or detail table under the local main form |
| External child table | An external child table related to the external main form |
External child candidates include direct child objects of the external main form and external objects that reference it through an enabled foreign key field. A local or external child table can only appear in one pair, and every row needs both sides selected before it can be saved.
After child table pairs exist, changing the main pair clears the current child table drafts.
After the flow is created, open the design canvas, select the start node, and use Edit pairs under Child table pairs to add, replace, or remove pairs. When a removed or replaced pair already has transformation mappings, Soln asks for confirmation; continuing deletes the mappings of the invalidated pair and keeps the mappings of unchanged pairs. Save or publish the canvas afterwards so the changes become a flow version.
5. Design Canvas And Versions
Click Open flow design canvas in the flow list to configure flow nodes, field mappings, data transformation, and target execution behavior.
The canvas top bar provides Back, Save, Publish, Save and publish, Copy, and Request example. At least one usable version must exist before the flow can be enabled.
Copy A Flow
- Open the design canvas of the source flow
- Click Copy
- Enter the new flow name and an optional description
- Click Copy to confirm
Soln validates the current canvas before copying. The new flow uses the canvas and mapping snapshot that passed validation, so it can also include source changes that were not saved but are valid. Soln generates a new flow code, creates an independent draft flow, and opens its canvas.
The copy does not inherit the enable or publish state, execution logs, or active schedules of the source flow. It also does not copy the schedule of a poll or schedule flow, so the Cron expression has to be set again before publishing. Some flow type and trigger mode combinations cannot be copied.
6. Running And Scheduling
Enable Or Disable A Flow
Use the list actions to enable or disable a flow.
| State | Effect |
|---|---|
| Enable flow | Publishes the latest usable version so the flow can run; poll and schedule flows also activate their schedule |
| Disable flow | Returns the flow to draft; poll and schedule flows also pause their schedule |
A flow needs a usable version before it can be enabled, and Soln asks for canvas configuration when no version exists.
Run Once Now
Enabled poll and schedule flows show Run once now in the list: Soln starts one execution through the existing schedule of the flow, and an inbound poll keeps the cursor of that schedule.
A paused schedule can still run once, and a single run does not resume the later scheduled runs. Webhook flows need a real request body and push flows need local record context, so the list has no argument-free run button for them. Open the execution logs afterwards to review the result.
Execution Logs
Use View execution logs to inspect runs. The logs show the trigger mode, status, duration, business data, transformation result, target result, callback state, and errors.
7. Edit And Delete
Edit A Flow
- Select a flow
- Open the edit action
- Update the flow name or description
- Update the Cron expression for poll and schedule flows
- Update the push actions and push overlap policy for push flows
- Click Save
The flow type, trigger mode, and main pair are fixed at creation. Field mappings and node behavior are configured in the design canvas, and the Webhook URL is available in the edit window.
Delete A Flow
- Select a flow
- Click Delete flow
- Confirm deletion
Deleting removes the flow definition permanently. Delete a flow only when the flow and its execution records are no longer needed for configuration tracking.
8. Recommended Order
- Prepare OpenLink
- Create the required external forms and external fields
- Enter Integration Flow Config and create a draft flow with its type, trigger mode, and form pairs
- Open the design canvas
- Configure mappings, transformation, source, target, and other flow nodes
- Save and publish a version
- Enable the flow from the flow list
- Test it with Run once now, a webhook call, the schedule, or a push event
- Review the execution logs and adjust the flow