Integration Designer

​

Overview

​

Key features

​

Managing integration endpoints

​

Data Sources

​

Creating a new data source definition

​

Data sources types

​

RESTful System

• Select Data Source: RESTful System
• Name: The data source’s name.
• Code: A unique identifier for the external data source.
• Base URL: The base URL is the main address of a website or web application, typically consisting of the protocol (http or https), domain name, and a path.
• Description: A description of the data source and its purpose.
• Enable enumeration value mapping: If checked, this system will be listed under the mapped enumerations. See enumerations section for more details.

2. Set up authorization (Service Token, Bearer Token, or No Auth). In our example, we will set the auth type as a bearer and we will set it at system level:

​

Defining REST integration endpoints

1. Under the Endpoints section, add the necessary endpoints for system integration.

2. Configure an endpoint by filling in the following properties:
   • Method: GET, POST, PUT, PATCH, DELETE.
   • Path: Path for the endpoint.
   • Parameters: Path, query, and header parameters.
   • Content type (POST endpoints): JSON, Raw, Multipart/Form-Data, or Binary.
   • Response: JSON or Single binary file.
   • Response example: Body or headers.

​

REST endpoint caching

​

Configuring cache Time-To-Live (TTL)

P1D

Expire Time: 00:00
Recurrency: 1
Time Unit: Day

Expire Time: 18:00
Recurrency: 1
Time Unit: Week

​

Cache visibility and management

• Cache Status: Whether results came from cache (hit) or external API (miss)
• Cache Key: Unique identifier for the cached response
• TTL Information: When the cache will expire
  • Duration-based: “Expires after PT10M” (10 minutes)
  • Time-based: “Expires at 23:00 on 2025-11-04”

• Available in the endpoint testing modal
• Available from the endpoint definition page
• Only visible when caching is configured

​

How caching works

​

Error handling

• Cache service unavailable → Direct API call
• Cache corruption or invalid data → Direct API call
• Cache storage failure → Direct API call (with warning logged)

​

Use cases

​

SQL operation caching

​

Extended response caching

​

POST endpoint caching

​

Mongo read caching

​

File operation caching

​

Defining variables

For example:

• For our integration example, you can declare configuration parameters and use the variables to store your tableId and baseId and reference them the Variables tab.

• Use variables in the Base URL to switch between different environments, such as UAT or production.

​

Endpoint parameter types

​

Path parameters

• Used to specify variable parts of the endpoint URL.
• Defined with ${parameter} format.
• Mandatory in the request URL.

​

Query parameters

• Query parameters are appended to the URL after a ? symbol and are typically used for filtering or pagination (for example, ?search=value)
• Useful for filtering or pagination.
• Example URL with query parameters: https://api.example.com/users?search=johndoe&page=2.

URL encoding option

• Encode enabled: The system automatically URL-encodes the parameter value (special characters like spaces, &, = are converted to their encoded equivalents like %20, %26, %3D)
• Encode disabled (default): The value is sent as-is, allowing you to provide pre-encoded values

​

Header parameters

• Header parameters (HTTP headers) provide extra details about the request or its message body.
• They are not part of the URL. Default values can be set for testing and overridden in the workflow.
• Custom headers sent with the request (for example, Authorization: Bearer token).
• Define metadata or authorization details.

​

Body parameters

• These are the data fields included in the body of a request, usually in JSON format.
• Body parameters are used in POST, PUT, and PATCH requests to send data to the external system (for example, creating or updating a resource).

​

Response body parameters

• These parameters are part of the response returned by the external system after a request is processed. They contain the data that the system sends back.
• Typically returned in GET, POST, PUT, and PATCH requests. Response body parameters provide details about the result of the request (for example, confirmation of resource creation, or data retrieval)

​

Enum mapper

​

Configuring authorization

• Select the required Authorization Type from a predefined list.
• Enter the relevant details based on the selected type (for example, Realm and Client ID for Service Accounts).
• These details will be automatically included in the request headers when the integration is executed.

​

Authorization methods

​

Service account

• Identity Provider Url: The URL for the identity provider responsible for authenticating the service account.
• Client Id: The unique identifier for the client within the realm.
• Client secret: A secure secret used to authenticate the client alongside the Client ID.
• Scope: Specifies the access level or permissions for the service account.

​

Basic authentication

• Requires the following credentials:
  • Username: The account’s username.
  • Password: The account’s password.
    • Suitable for systems that rely on simple username/password combinations for access.

​

Bearer

• Requires an Access Token to be included in the request headers.
• Commonly used for OAuth 2.0 implementations.
• Header Configuration: Use the format Authorization: Bearer {access_token} in headers of requests needing authentication.

• System-Level Example: You can store the Bearer token at the system level, as shown in the example below, ensuring it’s applied automatically to future API calls:

Store tokens in a configuration parameter so updates propagate across all requests when tokens are refreshed or changed.

​

Certificates

openssl pkcs12 -export -in client.crt -inkey client.key -out keystore.p12 -name client

base64 -i keystore.p12

• a Custom CA without a client certificate
• a PEM certificate
• a CA and a client certificate in different formats, or one Inline and the other Path

​

File handling

{
  "customId": "${processInstanceId}_${timestamp}",
  "documentType": "CONTRACT"
}

​

Core scenarios

1

Downloading Files

Can call an external API (GET or POST) and receives a response containing one or more files. Integration Designer saves these files to a specified location and returns their new paths to the workflow for further processing.

2

Uploading Files

Can send a file that is already stored in the Document Plugin or a custom S3 Bucket to an external API via a POST request. The workflow transmits the file path, enabling file transfer without manual handling.

​

Receiving XML and SOAP responses

1. The Accept header wins (what the integration expects back).
2. If Accept is absent, the request Content-Type is used as a fallback.
3. If neither is set, the engine runs in automatic mode and infers the format from the upstream’s response Content-Type.
4. Wildcard Accept values (*/*, application/*, text/*) are treated as automatic — they don’t commit to a format.

​

Receiving files (endpoint response configuration)

​

Enabling and configuring file downloads

​

Handling JSON content-type

​

Handling Single Binary content-type

1

Configure Content-Type

In the Response tab of your endpoint configuration:

1. Enable the Save Files toggle
2. Select Single Binary from the Content-Type dropdown

With the Save Files toggle off, a binary response isn’t saved as a file: the body reaches the workflow as a raw string. Turn Save Files on to store the file.

2

Choose File Destination

Select your preferred file storage destination:

• S3 Protocol
• Document Plugin

For files stored in custom S3 buckets, ideal for files not tied to specific process instances.

For files managed by FlowX’s document system, linked to process instances with additional metadata.

3

Configure File Name Identification

Choose how the system should identify the filename from the response.

Content-Disposition: attachment; filename="document.pdf"

# Extract filename from "filename=document.pdf"
filename=(.+)

# Extract filename with extension from complex header
([a-zA-Z0-9_-]+\.[a-zA-Z]{2,4})

# Extract quoted filename: filename="my document.pdf"
filename="([^"]+)"

{
  "contentType": "Single Binary",
  "saveFiles": true,
  "autoIdentifyFile": true,
  "fileDestination": "S3 Protocol",
  "defaultFileName": "downloaded_file",
  "defaultFolder": "client_${clientId}"
}

{
  "contentType": "Single Binary", 
  "saveFiles": true,
  "autoIdentifyFile": false,
  "fileNameHeaderKey": "X-Document-Name",
  "fileNameHeaderAttribute": "filename",
  "applyCustomRegex": true,
  "customRegex": "filename=\"([^\"]+)\"",
  "fileDestination": "Document Plugin",
  "defaultFileName": "fallback_document",
  "defaultFolder": "documents",
  "defaultDocumentType": "Contract",
}

​

Sending files (endpoint POST body configuration)

​

Content Type: Multipart/Form-data

1

Configure File Source

Select where the file originates:

• Document Plugin
• S3 Protocol

2

Define Form Parts

Add rows to the resource table, defining each part of the form:

• Key Type: Choose File or Text
• Value:
  • For files: Provide the filePath (Minio path for S3 or Document Plugin reference)
  • For text: Provide the string value or variable reference

​

Content Type: Single binary

​

Content Type: JSON

{
  "documentName": "contract.pdf",
  "content": "@@base64File(${filePath})"
}

• The path can come from a workflow variable, such as ${filePath} from an earlier node. Variables are resolved before the marker is read.
• Only string values are replaced. A marker used as a JSON key is left as it is.
• The file content is added only to the request that is sent. The saved request body and the generated curl command keep the marker.
• Downloading the file from the Document Plugin is cancelled after 5 minutes by default. On self-hosted deployments, change the limit with FLOWX_DOCUMENTPLUGIN_DOWNLOADTIMEOUT (see the Integration Designer setup guide).

​

Runtime behavior & testing

​

Workflow node configuration

​

Response payload & logging

​

Error handling

​

Testing guidelines

​

Example: sending files to an external system after uploading a file to the Document Plugin

​

Workflows

​

Workflow, process, or UI Flow: which one do I use?

​

Creating a workflow

1. Navigate to Workflow Designer:
   • In FlowX.AI Designer to Projects -> Your application -> Integrations -> Workflows.
   • Create a New Workflow, provide a name and description, and save it.
2. Start to design your workflow by adding nodes to represent the steps of your workflow:

• Start Node: Defines where the workflow begins and also defines the input parameter for subsequent nodes.
• REST API Call nodes: Add REST API calls for fetching or sending data.
• FlowX Database nodes: Read and write data to FlowX Database collections.
• Custom Agent nodes: Enable AI agents to use MCP tools for intelligent task automation.
• Intent Classification Agent nodes: Classify user messages using AI and route the workflow to the matching intent branch.
• Context Retrieval nodes: Perform RAG searches against Knowledge Bases to retrieve relevant chunks without calling an LLM.
• Start Parallel and End Parallel nodes: Run several branches of the workflow at the same time and merge their results when all branches finish.
• Fork nodes (conditions): Add conditional logic for decision-making.
• Data mapping nodes (scripts): Write custom scripts in JavaScript or Python.
• Subworkflow nodes: Invoke other workflows as reusable components.
• Navigate in UI Flow nodes: Navigate users to specific UI Flow screens from chat-driven workflows, passing dynamic parameters.
• Web Page Extractor nodes: Crawl web pages, follow links up to a configurable depth, and extract content for use in workflows or Knowledge Bases.
• End Nodes: Capture output data as the completed workflow result, ensuring the process concludes with all required information.
• Update Knowledge Base: Update the Knowledge Base with the results of the workflow.

​

How do I auto-arrange the workflow canvas?

• Auto-arrange always arranges the whole workflow, not a selection.
• There is no undo after you apply a layout, so compare the two layouts first.
• If the workflow changes after the preview is built, Apply becomes Refresh preview.
• The button is unavailable when the workflow is read-only, for example when you don’t have edit rights or while a running instance is shown on the canvas.

​

Workflow nodes overview

​

Workflow data models

​

Key benefits

​

Quick start

​

Referencing workflow data in node configurations

// Script node placed before the consuming node
output.firstFile = input.uploadedFiles[0];

​

Start node

​

External triggers

var msg = input.webhookMessage;
var order = msg.payload;
output.orderSummary = order.client + " wants " + order.suma + " " + order.detalii.moneda;

​

How do I run a workflow on a schedule?

​

REST API Call node

• Params: Configure path, query, and header parameters.
• Input/Output: Input is auto-populated from the previous node; output displays the API response.

​

When does a REST API Call node take its failure exit?

• a non-2xx response;
• a timeout, stored as status 408 with data.timeout: true (set the limit with Timeout on the node’s Settings tab, default 10000 ms);
• a connection error;
• a response body declared as JSON or XML that can’t be parsed.

​

FlowX database node

​

Tabular Data Extraction node

• Use Test File — toggles where the file comes from. OFF: provide File Path, the download path of a file available at run time (for example, produced by a previous node or a file upload); supports ${} expressions. ON: select an uploaded test file — useful while building and testing the workflow
• Sheet (Excel only) — the sheet name to extract from; leave empty to use the first sheet
• Response Key — where the node writes its output; the extracted rows are stored under <responseKey>.data

{
  "rows": {
    "data": [
      { "id": "1", "name": "Alice", "role": "Engineer" },
      { "id": "2", "name": "Bob", "role": "Designer" }
    ]
  }
}

​

Data Parse: XML and JSON support

• Accepted files: CSV, XLS, XLSX, and XLSM spreadsheets, plus XML and JSON files. Test file uploads are still capped at 15 MB. Uploaded XML and JSON test files are listed with the Structured Data type.
• Sheet: applies to Excel files only (.xls, .xlsx, .xlsm) and is ignored for CSV, XML, and JSON.
• Output: always under <responseKey>.data. Spreadsheets return rows as described above. XML and JSON files return an object tree.
• Size and depth limits: XML and JSON files are parsed up to 5 MB. XML nested deeper than 64 levels is rejected.

• The root element is unwrapped: data holds its content, not an object keyed by the root name.
• An element with only text becomes a string. An empty element becomes an empty string.
• Attributes become keys. When an element has both attributes and text, the text is stored under value.
• Sibling elements with the same name become an array. A single occurrence stays an object, so plan for both shapes when the count can vary.
• Namespaces are dropped and only local names are kept. All values are strings.
• Document type definitions (DTDs) and external entities are not processed.

<customers>
  <customer id="1">
    <name>Alice</name>
    <role>Engineer</role>
  </customer>
  <customer id="2">
    <name>Bob</name>
    <role>Designer</role>
  </customer>
</customers>

{
  "customers": {
    "data": {
      "customer": [
        { "id": "1", "name": "Alice", "role": "Engineer" },
        { "id": "2", "name": "Bob", "role": "Designer" }
      ]
    }
  }
}

​

Generate Tabular File node

• File name: the name of the generated file, up to 255 characters; supports ${} expressions (for example, ${reportDate}). The extension is added from Format, so a typed .csv, .xlsx, or .xls extension is replaced. The characters \ / : * ? " < > | are replaced with _.
• Document Tag (optional): the tag stored on the generated document; supports ${} expressions. When left empty, the file name without its extension is used.
• Format: CSV (default) or XLSX.
• Row format: the shape of each row in Data.
  • Arrays (default): each row is a list of values, such as ["FP-1001", "Closed"]. The first row is the header row, and each following row is written in the same column order.
  • Objects: each row is an object, such as {"invoice": "FP-1001", "status": "Closed"}. The keys become the column headers, in the order they first appear. A missing key leaves the cell empty.
• Data: a single workflow variable that holds the rows, such as ${data} or ${dbResult.sheets}. The variable must resolve to an array; inline JSON is not accepted.
• Response Key: where the node writes the generated file’s metadata.

[
  { "id": 1, "name": "Alice" },
  { "id": 2, "name": "Bob", "role": "Designer" }
]

{
  "export": {
    "fileName": "team-export.csv",
    "documentType": "team-export",
    "format": "CSV",
    "rowFormat": "objects",
    "rowCount": 2,
    "fileSize": 40,
    "downloadPath": "internal/files/{fileEntryUuid}/download",
    "filePath": "...",
    "fileEntryUuid": "..."
  }
}

• CSV files are UTF-8 encoded with a byte order mark, so spreadsheet apps read non-ASCII characters correctly. XLSX files have a single sheet named Sheet1, and numbers and booleans keep their type.
• Text that starts with =, +, -, @, a tab, or a carriage return is written as text, never as a formula.
• In Arrays mode, a row shorter than the header row is padded with empty cells, and extra values become extra columns with an empty header.
• Rows with no values are left out. An empty array still produces a file, with rowCount set to 0.

​

Template Filling node

• Template — select a document template defined in your project’s Document templates; Open template jumps to the template definition
• Language — enabled once a template is selected, and defaults to the template’s first available language
• Template Variables — click Configure Variables to fill the template’s data-model variables with values from the workflow; changing the template resets the language and variables
• Input Mapping — new nodes map workflow data onto the template’s input parameters in the data mapper (Configure mapping on the Template Input card) instead of Template Variables. Nodes created before FlowX.AI 5.13 show an Enable data mapping toggle: on uses the data mapper, off keeps Template Variables
• Folder — optional folder for the generated file; supports ${} expressions (e.g., ${client.id})
• Document Tag — the tag under which the generated document is stored (e.g., ContractTemplate)
• Document format — PDF (default) or DOCX

​

Send Notification node

• Template — the notification template to send, from your project’s notification templates; Open notification template jumps to its definition. Language unlocks once a template is picked. Variables fills the template’s data-model variables from workflow data, the same mapping as the Template Filling node.
• Recipients — To (required), Cc and Bcc. Each takes a recipient address, a JSON array of addresses, or a ${} expression resolving to either.
• Email options — all optional: Subject override (leave empty to use the template subject), Sender name and Sender email, Attachments (one file path or ${} key per line), and Custom headers, which must be a JSON object or a ${} expression that resolves to one.

​

When does a Send Notification node take its failure exit?

• A configuration problem caught before sending, such as no template or language, an empty To after ${} expressions resolve, an attachment given as a URL instead of a file path, or custom headers that aren’t valid JSON
• The Notifications plugin rejecting the message
• An authorization error (401 or 403)
• The plugin being unreachable, timing out, or answering with a 5xx

​

Combine Files node

• Files — add two or more source files, each by path (or a test file). Set the order and choose which pages to include per file: All pages or a custom page range.
• Folder — optional folder for the combined file; supports ${} expressions.
• Document Tag — the tag under which the combined file is stored.

​

Split File node

• Source file — the PDF to split, by path (or a test file).
• Output files — define each output by its pages using a range grammar such as 1-3,5, or a ${} expression that resolves to one at runtime. Each output can set its own Folder and Document Tag.

​

Context Retrieval node

• Source — choose between Knowledge Base or Memory (Memory is available only in chat-driven workflows)
• Knowledge Base — select a Knowledge Base to search (when source is Knowledge Base)
• User Query — the search query, supports process variable expressions (e.g., ${userMessage})
• Search Type — Hybrid (default), Semantic, or Keywords
• Max Number of Chunks — how many chunks to return (1-10, default: 5)
• Min Relevance Score — minimum relevance threshold (0-100%, default: 70%)
• Metadata Filters — filter chunks by metadata properties using the query builder: typed operators per key type and AND/OR grouping
• Use advance metadata filters — toggle to enable expression-based filtering for complex logic
• Use Re-rank — toggle to re-rank retrieved chunks before returning

​

Custom Agent node

• Access external systems through MCP servers
• Execute complex, multi-step operations autonomously
• Make intelligent decisions based on available tools
• Return structured responses for downstream processing

• Customer support automation with CRM integration
• Data analysis across multiple systems
• Dynamic integration orchestration
• Autonomous problem-solving workflows

​

Intent Classification Agent node

• Define up to 10 intents as plain-text descriptions
• Automatic “If No Intent Matches” fallback branch
• Optional conversation memory for context-aware classification
• Optional rationale output explaining the classification decision

• Chatbot message routing
• Email triage and classification
• Customer support ticket categorization

​

Context Retrieval node

• Query Knowledge Bases using semantic, keyword, or hybrid search
• Configure relevance thresholds and result limits
• Apply property-based filters to narrow results
• Optional re-ranking for improved result quality
• Returns structured chunk data (content, metadata, relevance score, store)

• Feeding context into a downstream Custom Agent or Text Generation node
• Building multi-step RAG pipelines with custom processing between retrieval and generation
• Retrieving relevant documentation chunks for further analysis

​

AI Nodes

​

AI Text Operations

​

AI Document Operations

​

AI Image Operations

​

AI Data Operations

​

Personal Information Guard

​

Condition (Fork) node

• If/Else: Routes based on condition evaluation.
• One branch per run: The node follows the first branch whose condition passes, or the Else branch. To run branches at the same time, use the Start Parallel and End Parallel nodes.

​

Available bindings

​

Condition examples

// Route based on user identity
additionalData.securityDetails.username === 'admin@company.com'

// Route based on configuration parameter
additionalData.applicationConfiguration.featureEnabled === true

// Combine input data with config parameters
input.amount > additionalData.applicationConfiguration.approvalThreshold

// Check user and input together
input.priority === 'high' && additionalData.securityDetails.details.email.endsWith('@company.com')

# Route based on user identity
additionalData["securityDetails"]["username"] == "admin@company.com"

# Route based on configuration parameter
additionalData["applicationConfiguration"]["featureEnabled"] == True

# Combine input data with config parameters
input["amount"] > additionalData["applicationConfiguration"]["approvalThreshold"]

# Check user and input together
input["priority"] == "high" and additionalData["securityDetails"]["details"]["email"].endswith("@company.com")

​

Calling reusable functions in conditions

// Route on the result of a reusable function
functions.lending.isEligible(input.applicant) === true

# Route on the result of a reusable function
functions.lending.isEligible(input["applicant"]) == True

​

Start Parallel and End Parallel nodes

​

How do I run steps in parallel?

​

What data does each branch see?

​

How are the branches merged?

• Keys written by only one branch are kept.
• A key written by two branches ends up with the value from the branch that finished last.
• Nested objects are merged key by key, so only the conflicting leaf values are overwritten.
• Arrays and all other non-object values are replaced whole. There is no element-level merge, so two branches cannot each fill a different element of the same array.

​

What happens when a branch fails?

• A node that fails inside a branch follows the same rules as anywhere else in the workflow. If its failure exit is connected, the branch continues on that path and must still reach the End Parallel node. If the failure exit is not connected, the workflow instance fails.
• When the instance fails, the other branches stop at the next node they reach. Nothing they already executed is rolled back.
• If the branches of one Start Parallel node end on different End Parallel nodes, or one End Parallel node receives branches from two different Start Parallel nodes, the run fails with Missing end parallel gateway and the cause Parallel branches merge failed: missing or incompatible end parallel node.
• A Start Parallel node with no outgoing sequence fails the run with Workflow is missing outgoing sequences.

​

Runtime view

​

Use cases

​

Limitations

• Same End Parallel node for all branches: every branch of a Start Parallel node must end on the same End Parallel node, and that node allows one outgoing sequence.
• Last-write-wins merge: write to distinct keys per branch and combine them in a Script node afterwards.
• No element-level array merge: you cannot process the first element of an array in one branch and the second in another.
• No cross-branch reads: branches run on independent data copies and cannot see each other’s writes until the merge.
• Nesting is allowed: a branch can contain its own Start Parallel and End Parallel pair.

​

Script node

​

Calling reusable functions

functions.projectName.functionName(input.params)

​

Testing a script in isolation

​

Run instance IDs in the Logs tab

​

Subworkflow node

​

Data mapping

​

Parallel multi-instance

• A result whose correlation value matches an existing element of the output array updates that element.
• A result that matches no element is appended.
• With no correlation attribute set, every result is appended.

​

Execution logic and error handling

• Parent workflow waits for subworkflow completion before proceeding.
• If the subworkflow fails, the parent workflow halts at this node. Connecting the node’s failure exit routes the failure down its own branch instead. See Routing a subworkflow failure.
• Subworkflow output is available to downstream nodes via the response key.
• Logs include workflow name, instance ID, and node statuses for both parent and subworkflow.

​

Routing a subworkflow failure

​

Console logging, navigation, and read-only mode

• Console shows input/output, workflow name, and instance ID for each subworkflow run.
• Open subworkflow in a new tab for debugging from the console.
• Breadcrumbs enable navigation between parent and subworkflow details.
• In committed/upper environments, subworkflow configuration is read-only and node runs are disabled (preview/open only).

​

Use case: CRM Data Retrieval with subworkflows

{
  "crmData": "${responseKey}"
}

​

End node

• Receives input in JSON format from the previous node.
• Output represents the final data model of the workflow.
• Multiple End nodes are allowed for different execution paths.

​

Running and stopping workflows

• Run Workflow: Click Run Workflow in the workflow editor toolbar to start a new workflow instance. You can provide start data in JSON format before running.
• Stop Run: While a workflow instance is running, the button changes to Stop Run. Click it to cancel the instance. All in-progress and scheduled nodes are marked as cancelled.

​

Integration with external systems

​

Integration in FlowX.AI

1

Define a Data Source

Navigate to the Integration Designer and create a new data source:

• Name: Airtable Credit Data
• Base URL: https://api.airtable.com/v0/

2

Define Endpoints

In the Endpoints section, add the necessary API endpoints for system integration:

1. Get Records Endpoint:
   • Method: GET
   • Path: /${baseId}/${tableId}
   • Path Parameters: Add the values for the baseId and for the tableId so they will be available in the path.
   • Header Parameters: Authorization Bearer token

See the API docs.

2. Create Records Endpoint:
   • Method: POST
   • Path: /${baseId}/${tableId}
   • Path Parameters: Add the values for the baseId and for the tableId so they will be available in the path.
   • Header Parameters:
     • Content-Type: application/json
     • Authorization Bearer token
   • Body: JSON format containing the fields for the new record. Example:

   {
    "typecast": true,
    "records": [
        {
            "fields": {
                "First Name": "${firstName}",
                "Last Name": "${lastName}",
                "Age": ${age},
                "Gender": "${gender}",
                "Email": "${email}",
                "Phone": "${phone}",
                "Address": "${address}",
                "Occupation": "${occupation}",
                "Monthly Income ($)": ${income},
                "Credit Score": ${creditScore},
                "Credit Status": "${creditStatus}"
            }
        }
    ]
}

3

Design the Workflow

1. Open the Workflow Designer and create a new workflow.
   • Provide a name and description.
2. Configure Workflow Nodes:
   • Start Node: Initialize the workflow.

On the start node add the data that you want to extract from the process. This way when you will add the Start Workflow Integration node action it will be populated with this data.

{
"firstName": "${firstName}",
"lastName": "${lastName}",
"age": ${age},
"gender": "${gender}",
"email": "${email}",
"phone": "${phone}",
"address": "${address}",
"occupation": "${occupation}",
"income": ${income},
"creditScore": ${creditScore},
"creditStatus": "${creditStatus}"
}

Make sure these keys are also mapped in the data model of your process with their corresponding attributes.

• REST Node: Set up API calls:
  • GET Endpoint for fetching records from Airtable.
  • POST Endpoint for creating new records.
• Condition Node: Add logic to handle credit scores (e.g., triggering a warning if the credit score is below 300).

Condition example:

input.responseKey.data.records[0].fields["Credit Score"] < 300

• Script Node: Include custom scripts if needed for processing data (not used in this example).
• End Node: Define the end of the workflow with success or failure outcomes.

4

Link the Workflow to a Process

1. Integrate the workflow into a BPMN process:
   • Open the process diagram and include a User Task and a Receive Message Task.

In this example, we’ll use a User Task because we need to capture user data and send it to our workflow.

2. Map Data in the UI Designer:
   • Create the data model
   • Link data attributes from the data model to form fields, ensuring the user input aligns with the expected parameters.

3. Add a Start Integration Workflow node action:

• Make sure all the input will be captured.

5

Monitor Workflow and Capture Output

Receive Workflow Output:

• Use the Receive Message Task to capture workflow outputs like status or returned data.
• Set up a data stream in the node’s Integration Output section to ensure workflow output is mapped to a predefined key.

One key per hop. Data crosses three boundaries on its way back to the process, and each one uses its own name:

1. Inside the workflow, the REST node stores its result under its Response Key - the body is at ${responseKey.data}.
2. The End node maps that value into the workflow’s declared output parameter.
3. The Receive Message Task maps the returned output into a process attribute through its data stream output mapping.

Most “empty value” problems come from using a key from the wrong hop, or from a typo - a wrong key in a ${...} placeholder resolves silently to nothing rather than raising an error. If the result never reaches the process, check the error glossary for the two runtime errors that pinpoint which hop is broken.

6

Start the integration

• Start your process to initiate the workflow integration. It should add a new user with the details captured in the user task.

• Check if it worked by going to your base in Airtable. You can see, our user has been added.

​

Export and import

​

Exporting

1. Navigate to the Data Sources or Workflows list in Integration Designer
2. Open the context menu for the resource you want to export
3. Select Export
4. The resource is downloaded as a ZIP file containing the full configuration

• Data Sources - data source configuration, endpoints, NoSQL operations, MCP tools
• Workflows - workflow nodes and their configurations

​

Importing

1. Navigate to the Data Sources or Workflows list in Integration Designer
2. Open the context menu and select Import from ZIP
3. Select the ZIP file exported from another project or environment
4. If resources with the same identifiers already exist, a Review Resource Identifiers Conflicts modal appears
5. Choose a strategy for each conflicting resource (or use Apply to all):
   • Keep both - imports the resource as a new copy alongside the existing one
   • Replace - overwrites the existing resource with the imported version
   • Skip this one - keeps the existing resource unchanged
6. Click Continue to complete the import

​

FAQs

{
  "query": "mutation { updatePerson(input: { name: \"${input.name}\" }) { id status } }"
}

​

Academy courses