Skip to main content
AI Builder Automations Interface
Automations are the core server-side processes that power your AI Builder applications. They define what to do and when to do it, allowing you to create sophisticated workflows, integrate with external systems, and build intelligent applications.

Understanding Automations

In simple words, automations describe what to do and when:
  • What to do: A sequence of instructions that process data and perform actions
  • When to do it: Triggers that activate the automation when specific conditions are met
Example:A HubspotDealsOnSlack automation might send a notification message on Slack every time a new Hubspot deal is created:
  • The what would be a fetch instruction calling Slack API to send a message
  • The when would be a URL (webhook) trigger that Hubspot calls whenever a new deal is opened

Triggers

Automations can be activated through different types of triggers, configured at the top of the automation graph:
When an automation activates its URL trigger, it becomes publicly available through a URL which you can copy from your Workspace graph or source code. You can then use this URL in external services that support webhooks.From inside the automation, 5 variables give access to input HTTP requests:
  • body: Request body
  • headers: Request headers
  • method: HTTP method (GET, POST, etc.)
  • query: URL query parameters
  • pathParams: Extracted path parameter values (when using path parameters like :id)
For multipart/form-data requests, uploaded files will be detailed within a body.<fileKey> object variable.
Example :
By default, these HTTP requests will receive the automation output as a response body. However, an $http variable available inside the automation gives full control over the response:
You can also use this variable to implement Server-Sent Events (SSE) for streaming responses:
  • $http is only available in the URL-triggered automation (not in children calls)
  • Headers cannot be set after the first chunk is sent
  • When using SSE events, the automation output will also be sent as the last event
  • SSE automatically sets appropriate headers (Content-Type, Cache-Control, Connection)
For long-running SSE endpoints, you can configure a keep-alive to avoid timeouts:
After this instruction, a data: {"keepAlive": true} chunk will be regularly emitted until the connection ends.

Path Parameters

Webhook endpoints support path parameters for building RESTful APIs. Path parameters allow you to define dynamic URL segments that extract values from incoming requests.Basic Usage:
get-user
When a request is made to /webhooks/{workspaceSlug}/v1/users/123, the automation receives:
  • pathParams.id = "123"
Multiple Parameters:
get-user-post
Request to /webhooks/{workspaceSlug}/v1/users/alice/posts/456 results in:
  • pathParams.userId = "alice"
  • pathParams.postId = "456"
Combined with Query and Body:
update-user
Path Parameter Behavior:
  • Parameters are defined using :paramName syntax (e.g., :id, :userId)
  • All defined parameters are required - requests missing parameters will not match
  • Parameter values are automatically URL-decoded
  • Exact match endpoints take priority over pattern endpoints
  • When multiple patterns could match, the first defined pattern wins
  • Patterns like message:stream (colon without preceding slash) are treated as exact matches, not patterns
Path parameters must be defined in the endpoint field, not in the automation slug.The automation slug (e.g., get-user) only supports letters, numbers, spaces, underscores, and hyphens. To use path parameters, you must explicitly set the endpoint field to your desired path pattern:
Using endpoint: true will expose the automation at the slug path, but the slug itself cannot contain : characters.
An automation can listen to a list of events. Whenever such events are received, the automation is executed and can access:
  • payload: Event payload data
  • source: Event source information (source IP, correlationId, userId, automation, etc.)
These events can be:
  • Native events: Generated automatically by the platform
  • Custom events: Emitted from automations in the same workspace
  • App events: Emitted from installed Apps
Example configuration:
Workspaces can only listen to a specific subset of native events. See the Supported Native Events section for details.
An automation can be regularly triggered based on cron expressions:
  • Automations can be scheduled at most every 15 minutes
  • Schedules use UTC timezone
  • When scheduled, the automation runs “on the hour” (e.g., a 20-minute schedule starting at 3:14 will run at 3:20, 3:40, etc.)
  • When successfully scheduled, a runtime.automations.scheduled event is emitted
A helpful tool for creating cron expressions is crontab.guru.

Memory Architecture

Automations can use and modify data across different memory scopes:
Available only during current execution
Access pattern: {{run.variable}} Run variables include execution context like:
  • run.date: Current timestamp
  • run.ip: Client IP address
  • run.automationSlug: Current automation identifier
  • run.correlationId: Unique ID for tracing related events
  • run.depth: Current automation depth in the stacktrace
  • run.trigger.type: Trigger type (event, endpoint, automation)
  • run.trigger.value: Trigger value (event name, endpoint path, etc.)
  • run.socketId: Current socket ID if connected by websocket
  • run.appSlug: Current app slug if running from an appInstance
  • run.appInstanceSlug: Current appInstance slug if applicable
  • run.parentAppSlug: Parent app slug if parent is also an appInstance
The run context is automatically removed 60 seconds after the last automation run.
Persistent for the authenticated user
Access pattern: {{user.variable}}User variables include:
  • user.id: Unique user identifier
  • user.email: User’s email address
  • user.authData: Authentication information
  • user.role: User’s role in the workspace
  • Custom user-specific data that persists across sessions
Available for the current user session
Access pattern: {{session.variable}}Session variables include:
  • session.id: Current session ID
  • Custom session data
Session variables store temporary user data:
  • Form inputs across multiple steps
  • Wizard progress state
  • Temporary preferences
For authenticated users, session expiration is defined by the Gateway API (default 1 month). For unauthenticated endpoint calls, sessions expire after 1 hour of inactivity.
Shared across all users and executions
Access pattern: {{global.variable}}Global variables include:
  • global.workspaceId: Current workspace ID
  • global.workspaceName: Current workspace name
  • global.apiUrl: Current API instance public URL
  • global.studioUrl: Current studio instance public URL
  • global.pagesUrl: Current workspace pages public URL
  • global.pagesHost: Current pages instance base domain
  • global.endpoints: Map of available endpoint slugs to URLs
  • global.workspacesRegistry: Map of public workspaces
  • Custom workspace-wide variables
Available for the current websocket connection
Access pattern: {{socket.variable}}Socket scope provides a temporary state local to a websocket connection, useful for separating state between multiple browser tabs. This context automatically expires after 6 hours without any updates.
Workspace and app configuration
Access pattern: {{config.variable}}Contains the workspace configuration defined in the workspace settings.
Read-only workspace information
Access pattern: {{$workspace.variable}}This read-only context holds the current workspace definition, allowing access to any of its sections (e.g., installed apps config via $workspace.imports.myApp.config).
Except for $workspace, all these contexts can be written to using the set instruction. Written data will be persisted and available in subsequent requests. However, when setting variables inside session/user contexts from an unauthenticated webhook, they will not be persisted.

Working with Variables

Inside your automation instructions, dynamic data can be injected by surrounding a variable name with double braces: {{some.variable.name}}. Variables can be created and modified using the set instruction and removed using the delete instruction. For objects or arrays, you can access specific properties:
If session.myObjectVariable equals {"mickey": "house"} and item.field equals mickey, the entire expression resolves to house.

Instructions

Once triggered, automations execute a sequence of instructions in order. Here are the available instructions:

Logic Instructions

Conditionally execute instructions based on variable values or expressions.
More details on condition syntax
Loop through items or execute instructions multiple times.
You can also process batches in parallel:
Stop execution of the current automation or loop.
When break is meant to be handled from a parent automation’s try/catch, scope must be set to all.If using the instruction like this : - break: {}, it will default to scope: automation.
Execute multiple operations in parallel.
Handle errors gracefully.
The $error variable is accessible both inside and outside the catch block.

Data Instructions

Create or update variables in different scopes.
Like everywhere else, you can also use expressions in the value parameter:
Remove variables when no longer needed.

Integration Instructions

Make HTTP requests to external APIs.
Trigger events for UI updates or other automations.
Pause execution until a specific event is received.
Control resource usage with rate limiting.

Other Instructions

Generate authentication tokens for internal API calls. This token cannot be used outside of automations, and is specifically intented for fetch consumption (as an Authorization header).
When fetching a Prismeai automation endpoint with such workspace token, a {{run.authenticatedWorkspaceId}} variable (which cannot be manually set) will be made available to securely check calling workspace.
You can also forward source workspace authentication to a subsequent fetch :
Manage user subscription topics.User topics allow sending events to multiple users without knowing who they are in advance, automatically granting them read access to these events without requiring any API Key.
User topics allow sending events to multiple users without knowing who they are in advance.

Run instruction

Run is a generic instruction allowing you to call runtime modules.
These are lightweight NodeJS packages offering various methods for use cases needing raw Javascript for better performances than standard automations.
Example :
Parameters :
  • module : Module name
  • function : Function name
  • parameters : Function parameters object
  • onError : Exception handling behaviour
    • break will break current automation with given exception (default)
    • emit will emit an error event but continue current automation
    • continue will only return the error and continue current automation

Collections

Store, query, and manage structured data with MongoDB-style queries. This module is generally meant to be used through the Collection application.

Collections Module Reference

Functions: create, findMany, updateOne, deleteOne, aggregate, and more

Secrets

Securely store and retrieve sensitive values (API keys, tokens, credentials) at runtime, with automatic redaction from logs.

Secrets Module Reference

Functions: set, get, delete — scopes: workspace, user

Access Manager

Manage organization service account tokens at runtime with in-memory secret caching and event-driven invalidation.

Access Manager Module Reference

Functions: getServiceAccountToken, createServiceAccount, rotateServiceAccountSecret, deleteServiceAccount

Text

Pure-JS text processing utilities for splitting text into chunks with configurable separators and overlap.

Text Module Reference

Functions: splitText

Condition and Expression syntax

Conditions allow you to execute different instructions based on contextual information. You can use a powerful expression syntax in conditions and anywhere with {% ... %} delimiters.

Basic Operators

Logical Operators

Regular Expressions

MongoDB-like Conditional Matches

Example condition:

Deep merge objects

This functiun helps deep merge two objects.
It also accepts an option object which can slightly modify the merge behaviour.
Example options:

Date Functions

Parsing and Access

Note: Tested values are UTC based, and day starts on 0 for Sunday (so 3 is Wednesday).

Formatting

See all formatting options on Day.js documentation.

Math Functions

Operators

Functions

String Functions

URL parsing

Parse URL search params :
Or parse a complete URL as an object :
This returns :
Or directly access a specific field :

Arguments

When calling a native instruction or another automation, different arguments can be transmitted. These graphical inputs are not reserved to native instructions, but can also be configured for your own custom automations by specifying expected arguments and their types.
The someToken argument defined with secret: true is automatically redacted from native runtime events to avoid accidental leaks of sensitive information.

Arguments Validation

Automation arguments can be validated during execution by enabling validateArguments: true:
Arguments support various validation formats including date, url, time, password, etc. Validation errors immediately stop current and parent automations.

Advanced Automation Patterns

Implement secure webhook endpoints for third-party integrations:

Supported Native Events

Workspaces can listen to a specific subset of native events:

Best Practices

Create maintainable automation structures:
    Break complex flows into smaller automationsUse events for communication between modulesCreate reusable patterns for common tasksDocument automation purposes and interfaces
Build robust fault tolerance:
    Use try/catch blocks for risky operationsImplement appropriate retry strategiesProvide informative error messagesCreate fallback paths for critical operations
Handle data appropriately across scopes:
    Use appropriate memory scopes for different data needsClean up temporary variables when finishedInitialize variables before using themBe mindful of persistence requirements
Keep your automations secure:
    Store sensitive data in secretsValidate inputs from external sourcesImplement rate limiting for external APIsUse proper authentication for API calls
Ensure efficient execution:
    Use parallel processing for independent operationsImplement batching for large data setsCache results when appropriateMonitor execution times and optimize bottlenecks
Validate automation functionality:
    Test with representative data samplesVerify error handling pathsTest edge cases and unexpected inputsUse Activity view to review execution history

Next Steps

Learn about UI components that trigger automations
Discover how to create interfaces for your applications
Learn more about deployment strategies