Financial Data Platform | Modernbanc

Workflow Basics

Workflows consist of steps and triggers. Steps determine what this workflow will do when its ran and triggers determine when it's ran.

Steps

  • workspace_operation: Do an operation on objects in your workspace, e.g., create, update or delete a transaction or account.
  • connection_query: Makes an HTTP request.
  • condition: Evaluates a condition and returns true or false. They can have children's steps that will execute conditionally only if the result is true or only if the result is false.
  • pause: Stops the execution of the workflow until it is later resumed. It can have triggers associated with determining when the execution will resume.
  • function: Executes custom JavaScript code.
    • Supported Libraries: lodash, date_fns, BigNumber, uuid, crypto_js and axios.
  • search: Search your workspace for various objects.
  • pause: Stops the execution of the workflow until it is later resumed. It can have triggers associated with determining when the execution will resume.
  • for_each: Provide an array and performs all children's steps once for every element in the array.
  • action: Provide an array and performs all children's steps once for every element in the array.
  • format: Format any data throughout workflow execution.
  • return: Finish workflow execution and return with a status code and an error message or body.
  • reply: Reply to the initiating trigger. This does not stop the workflow. Currently can only reply to pre-event workspace triggers. The body of these replies is the same as the values passed in by these triggers.
  • parse_file: Convert various file types to JSON data.
  • container: Run a custom docker container.
  • In the Type dropdown, select the type of operation you want to perform. The options are Create, Update, Archive, and Delete.
  • In the Model dropdown, select the model you want to interact with. The options are Transaction, Account, Balance, Entity, Route, and Secret token.
  • In the Data/Parameters field, enter the data you want to use for the operation depending on the "type" and "model" you selected. The options are For Create and Update Secret Dto's, please refer to the Secrets page.

General execution logic

  • Execution statuses and codes:
    • execution.status reflects current state of the workflow. (e.g in-progress, completed, failed) etc.
    • execution.code reflects what http response code will API caller will receive.
    • If code is specified by whoever built the workflow (e.g via return or reply steps) it will decide the status of the workflow:
      • code < 400status: completed
      • code >= 400status: failed
    • If code is not specified then it'll be auto-decided by execution status. Completed executions will have 200 code while failed ones will have 420 code.

Accessing workflow data in steps

In workflows and steps, it is possible to access information about data passed to the trigger, variables stored in the workflow, or data resulting from steps that have already been executed. You can put any JavaScript code inside of {{ }}, including accessing variables.

The syntax to access them is as follows:

1. Trigger Data

  • Webhook Trigger Request Data: Access the request data passed to the webhook triggers using {{_trigger_version._input.<option>}}. Example:

    {{_trigger_version._input.body}}        // Request body

    Options: body, files, headers, query, cookies, params, user, auth_method, api_key_id, ip, ips

2. Workflow Steps

  • Single step: Access the result of a specific step in the workflow with the steps array. The first step is at index 0.
    {{steps[INDEX].result.data}}
  • Nested Steps:
    • Condition Step: When accessing nested steps within a condition step, you must specify whether you are referring to the true or false branch of the condition step.
      • True branch:
      {{steps[CONDITION_STEP_INDEX].steps.true[NESTED_STEP_INDEX].result.data}}
      • False branch:
      {{steps[CONDITION_STEP_INDEX].steps.false[NESTED_STEP_INDEX].result.data}}
      • CONDITION_STEP_INDEX: Represents the specific condition step you are referring to.
      • NESTED_STEP_INDEX: Represents a particular step within either the True or False branch of the condition step.
      • Make sure to replace CONDITION_STEP_INDEX and NESTED_STEP_INDEX with the appropriate numbers to refer to the specific steps you need.
    • For Each Step: For each steps have a nested steps array that contains the steps that will be run for each element in the array. You can access these nested steps with the following syntax:
    {{steps[FOR_EACH_STEP_INDEX].steps[NESTED_STEP_INDEX].result.data}}
    • FOR_EACH_STEP_INDEX: Represents the specific for each step you are referring to.
    • NESTED_STEP_INDEX: Represents a particular step within the for each step.
    • Make sure to replace FOR_EACH_STEP_INDEX and NESTED_STEP_INDEX with the appropriate numbers to refer to the specific steps you need.
    • You can also access the current index and array element of the for each step being iterated over with the _step object
      {{_step._index}}
      {{_step._array_element}}
  • Step error: Access the error object of a specific step in the workflow with the steps array. Steps are accessed the same way as above.
    {{steps[INDEX].error.message}}
    • Error object structure is as follows:
    {
      "code": "Error code",
      "message": "Error message",
      "exception": { "message": "Exception message" }[],
    }

Workflow Variables

  • Accessing Variables: You can access any variable stored in the workflow with the _variables object.
    {{_variables.my_variable}}

Notes

  • Replace INDEX with the appropriate index number for the step you're referring to.
  • The {{result.data}} example assumes that the step result has a data field. Adjust it to match your step's actual result structure.

Working with files

File Sources

  • Files can be passed in via webhook triggers. Simply attach the file(s) to your request and they will be available in your workflow. The files can be found at _trigger_version._input.files.
    • Each file reference will have a name, mime_type, and size (in bytes).
  • Files can be created in container steps. Any file saved to the folder /data by the container will be available for the rest of the workflow.

File Uses

  • Whenever a file is needed in a step, it will have a file or files field in the parameters.
  • You can pass a direct reference to a file (e.g. file: {{_trigger_verison._input.files[0]}}) or simply name the file (e.g. file: my-passed-in-file.csv).
  • Currently, two step types accept file input: parse_file and container

Usage

Create workflow

  • Navigating to the Workflows tab in the settings dropdown or by pressing G and then W.
  • Click the Create button in the upper right corner.
  • Give your workflow a Name, and click Create.
  • Select the workflow you want to amend, and click the Edit button in the top nav bar.
  • Add a new step by clicking the + button on the left of the step list.
  • Add a trigger by clicking the + button on the right.
  • Click the Save button in the top nav bar.
  • Click the Publish button in the top nav bar.
  • Your workflow is now published and actively running, listening for triggers, workspace operations, or any conditions you've set.

List Workflows

  • Navigate to the Workflows page, or press G and then W.
  • The display will show a list of all workflows. To narrow the results, you can add Filters or Sorts.

Update Workflows

  • Navigating to the Workflows tab in the settings dropdown or by pressing G and then W.
  • Clicking the Edit button in the top nav bar.
  • To save your workflow, click the Save button in the top nav bar.
    • Note: once a workflow is publised, you must create a new version to make additional changes.

Workflow Versions

Workflows are versioned objects. This means when you are working with a workflow you are working with a version, since it contains most of the data. Versions can have either draft or published status. You can't edit published versions but you can use them.