DRAGOPS
DRAGOPS
DocumentationTriggersPattern calls

Pattern calls

Build reusable patterns that other patterns invoke like functions with typed inputs and outputs.

The On Pattern Call trigger makes a pattern callable by other patterns. This turns the pattern into a reusable building block — like a function with a defined interface. The calling pattern provides input values, waits for the called pattern to complete, and receives the results through typed output pins.

Pattern composition is how you build complex automation from simple, focused pieces. Instead of duplicating logic across multiple patterns, you extract shared work into a callable pattern and invoke it wherever you need it.

How pattern calls work

A pattern call involves three nodes across two patterns:

  1. On Pattern Call (in the called pattern) -- defines the input and output interface
  2. Call Pattern (in the calling pattern) -- invokes the called pattern and passes inputs
  3. Respond With (in the called pattern) -- returns results to the caller

The flow looks like this:

Calling pattern                    Called pattern
┌──────────────┐                   ┌──────────────────┐
│              │                   │                  │
│ Call Pattern ├──── inputs ──────►│ On Pattern Call   │
│              │                   │        │         │
│   (blocks)   │                   │   ┌────▼────┐    │
│              │                   │   │  logic  │    │
│              │◄── outputs ───────│   └────┬────┘    │
│              │                   │   Respond With   │
└──────────────┘                   └──────────────────┘

The calling pattern blocks at the Call Pattern node until the called pattern completes and returns its results. This is synchronous execution — the caller does not continue until it receives the response.

Define a callable pattern

Set up the trigger

  1. Create a new pattern or open an existing one.
  2. Replace the trigger node with On Pattern Call (right-click on the canvas and search for "pattern call").
  3. The On Pattern Call node appears with an execution output pin and no input/output definitions yet.

Add inputs

Inputs define the data the caller must provide when invoking this pattern.

  1. Select the On Pattern Call node.
  2. In the Inspector Panel, add input parameters. Each input has a name and a type (String, Integer, Float, Boolean, Object, or Array).
  3. For each input you add, a corresponding output pin appears on the On Pattern Call node. Wire these pins to downstream nodes to use the input values.

Add outputs and return results

Outputs define the data this pattern sends back to the caller.

  1. In the Inspector Panel for the On Pattern Call node, add output parameters with names and types.
  2. Add a Respond With node to your pattern's execution flow.
  3. Wire the values you want to return into the Respond With node's input pins. Each output you defined on the trigger creates a matching input pin on Respond With.

The Respond With node must execute before the pattern ends. When it runs, the values on its input pins are sent back to the calling pattern.

Call a pattern

From the calling pattern:

  1. Right-click on the canvas and search for Call Pattern.
  2. Add the Call Pattern node to the canvas.
  3. Select the Call Pattern node. In the Inspector Panel, choose the target pattern from the dropdown. Only patterns with an On Pattern Call trigger appear in this list.
  4. The Call Pattern node updates to show input pins matching the target pattern's defined inputs and output pins matching its defined outputs.
  5. Wire your data into the input pins and connect the output pins to downstream nodes.

Example: validate an email address

Suppose you have a callable pattern named "Validate Email" with:

  • Input: email (String)
  • Outputs: is_valid (Boolean), reason (String)

In your calling pattern:

  1. Add a Call Pattern node and select "Validate Email" as the target.
  2. Wire the email value from an upstream node into the email input pin.
  3. Wire the is_valid output pin to a Branch node to handle valid and invalid cases.
  4. Wire the reason output pin to a Log node for debugging.

Type safety

Inputs and outputs on On Pattern Call are typed. When a calling pattern connects to a Call Pattern node, the type system enforces compatibility:

  • A String input pin only accepts String connections.
  • An Object output pin only connects to Object input pins.
  • Type mismatches appear as validation errors in the editor before you deploy.

This prevents a common class of runtime errors. If you change the interface of a callable pattern, any calling pattern that no longer matches shows type errors, alerting you to update the callers.

The Respond With node

Respond With is the mechanism for returning data from a called pattern. It serves a similar purpose to a return statement in a function.

Key behaviors:

  • Respond With must be reachable. If your pattern's execution flow ends without reaching a Respond With node, the caller receives empty results.
  • First Respond With wins. If your pattern has multiple Respond With nodes (for example, on different branches), the first one that executes sends the response. Subsequent Respond With nodes in the same execution are ignored.
  • Execution continues after Respond With. Nodes after Respond With still execute, but the caller has already received the results and resumed its own execution.

Use cases

Shared validation logic

Extract common validation (email format, URL structure, permission checks) into a callable pattern. Every pattern that needs validation calls the same shared logic, ensuring consistent behavior across your workspace.

Notification patterns

Build a "Send Team Notification" pattern that accepts a message and severity level, then routes to Slack, email, or PagerDuty based on the severity. Any pattern that needs to notify your team calls this one pattern instead of duplicating the routing logic.

Data enrichment

Create a pattern that takes a user ID and returns enriched data (profile details, recent activity, team membership) by calling multiple APIs. Calling patterns get a clean interface — pass in an ID, receive structured data — without knowing the details of the enrichment logic.

Multi-step workflows

Break a complex workflow into stages. A main orchestrator pattern calls sub-patterns for each stage: validate input, transform data, write to the destination, and send a confirmation. Each stage is independently testable and maintainable.

Error handling wrappers

Build a pattern that wraps an HTTP request with retry logic, circuit breaking, and error formatting. Callers get a reliable interface that handles transient failures internally, keeping the calling pattern's logic clean and focused.

Best practices

  • Keep interfaces small. Define only the inputs and outputs your pattern actually needs. A callable pattern with ten input parameters is harder to use and maintain than one with three focused inputs.
  • Name inputs and outputs clearly. Use descriptive names like user_email and is_valid rather than input1 and output1. Callers see these names on the Call Pattern node's pins.
  • Document the purpose. Add a description to your callable pattern explaining what it does, what inputs it expects, and what outputs it returns. Callers see this description when selecting a target pattern.
  • Handle errors inside the called pattern. If the called pattern fails, the error propagates to the caller. Use Try/Catch nodes inside the called pattern to handle expected errors and return meaningful results instead of letting failures cascade.
  • Test callable patterns independently. You can run a callable pattern directly from the editor by providing sample input values in the test dialog. Verify the pattern works correctly before calling it from other patterns.
  • Avoid deep call chains. A pattern that calls a pattern that calls a pattern creates a chain that is difficult to debug. Keep call depth shallow — one or two levels is usually sufficient. If you need deeper composition, consider restructuring into a flat orchestrator that calls multiple sub-patterns sequentially.
  • Version your interfaces carefully. Changing the inputs or outputs of a callable pattern affects every pattern that calls it. When you need to change an interface, check for existing callers first and update them alongside the called pattern.

On this page