Workflows

Manual (click button)

This is the default option. It means that the workflow only triggers when you manually click on "execute" in the workflow UI.

Cron (AWS cron)

Cron allows you to time your workflow execution very precisely (to the minute). We use the AWS Cron format to ensure a reliable scheduling experience.

Webhook (URL + payload)

OrbitType generates a webhook URL, which serves as your entry point. If a third-party app or your bot from a different client sends a POST request with a JSON body to this endpoint, it will serve as the input JSON for the first node. This input will also be saved in your workspace as an example to simplify testing. You can load it with "Load Input" in the first node’s code editor.

Database (table events and OrbitType API triggers)

As OrbitType is an integrated environment, you can listen for triggers from database tables. We support listening to creation, updates, and deletion events. The SQL request triggering the workflow must be executed using the OrbitType API and include a defined return value. For testing, the input is saved so it can be retrieved later.
If a row is updated, you will receive an array containing two objects as input—one with the old row and one with the new row. You can then use JavaScript within the node to precisely evaluate whether the changes should trigger the flow or whether to return early.

Each workflow is version-controlled; with every save of a node, the complete workflow is saved. You can revert these versions using the Versions button, which then restores the version. It keeps 50 versions as backups.

Code Nodes

This is the default node. Inside this node, you can write code and set config values to use within the code.

Decorative Nodes

These are visual elements which help you document and visually organize the workflow plan. They can also provide useful context to Orbitype Intelligence.

Entry Node

Each workflow has one specific entry node. It is the first one placed on the node canvas by convention or the one you set manually in the node settings.

Hard Limit

Nodes can run for up to 60 minutes. As you can chain nodes together, this can result in very long-running tasks. To prevent nodes from running too long in situations where they clearly should not exceed a few minutes, you can set a hard limit to cut off the runtime. This is not a graceful process, meaning you will receive no output if the node times out.
This can be very useful when experimenting with AI agents and prompts that are not optimized, which may lead to long-running tasks and wasted credits if no hard limit is set.

Naming

Proper naming of nodes helps you, your coworkers, and Orbitpye Intelligence better understand the purpose of each node. It is important to clearly name each node based on its function.

Orbitype Nodes must use the following syntax, with only one function allowed. Inside this function, you can use normal Node.js. Please keep in mind that this is a serverless environment, so some OS-related functionality will not work.
In Orbitype functions, you never need to require or import anything. Instead, you can provide the allowed libraries and API products via dependency injection into the function and then use them.

async ({input}) => {
  return {output: input}
}

If you want to log information, it is recommended to create a debug array and push messages to it. At the end, you can return it alongside other things. This way, the next node can analyze errors or you can process them further.

Output einer Node

If you just return something in the function, this will be set as the output.
If you want to have more control and also use features like next, you need to return an object with the key output. Then you can put it in there, and it will become clean, not boxed input for the next node.

async () => {
  const output = Math.random() 
  return {output, 
next: output > 0.5 ? "idOfTheNextNode" : "idOfTheOtherNextNode"}
}

Next Attribute

The next attribute allows you to set the next node dynamically. This works only when two or more nodes are connected with the output handle of the node.

async () => {
  const output = Math.random() 
  return {output, next: output > 0.5 ? "idOfTheNextNode" : "idOfTheOtherNextNode"}
}

Linear

This is an easy workflow, moving from a -> b -> c. It's the easiest and most common way.

Branching

If you have a workflow path which, at some point, needs to decide how to proceed with path a.a or path a.b, you can set the next parameter to test this.

Multi Input

Every workflow has only one entry node, but you can also add another node and connect it to the second node if this helps with testing an input payload. Later in the flow, it can also happen that you have multiple inputs. Keep in mind that the payload can vary in the input, as two or more different nodes may fill it. If you don't work with the same format in the previous nodes, then it can lead to errors in the node with the multiple inputs.

Looping

This is great to have conditions within a workflow, but keep in mind, wrong conditions can lead to endless loops, which can again burn tokens. Use looping only in very controlled settings with clear exit rules.

Sub Workflow Architecture

If a workflow consists of clearly separable sub-workflows, it mostly makes sense to build them into their own workflows and trigger them via webhooks. This way, you get a far more modular workspace structure and can use and test sub-parts in isolation.