Triggers
Orvanta scripts and flows can be triggered in various ways.
On-demand triggers
Section titled “On-demand triggers”Auto-generated UIs
Section titled “Auto-generated UIs”Orvanta automatically generates user interfaces for scripts and flows based on their parameters. By analyzing the main function parameters, it creates an input specification in JSON Schema format, which is then used to render the UI. Users do not need to interact with the JSON Schema directly.
Customized UIs with the App editor
Section titled “Customized UIs with the App editor”Orvanta provides a WYSIWYG app editor allowing you to build custom UI with drag-and-drop components and connect data to scripts and flows in minutes. You can also automatically generate a dedicated app to execute your script.
Full-code apps
Section titled “Full-code apps”For full control over your UI, build full-code apps with React or Svelte. Your frontend calls backend runnables that execute on Orvanta workers, providing framework-level flexibility while maintaining execution, permissions and logging.
Trigger from flows
Section titled “Trigger from flows”Flows are sequences of scripts executing one after another or in parallel. Flows themselves can be triggered from other flows, known as inner flows.
Workflows as code
Section titled “Workflows as code”Write a program that defines jobs and their dependencies, then execute that program within a Python or TypeScript script. This approach is known as workflows as code.
Schedule
Section titled “Schedule”Orvanta allows you to schedule scripts using a user-friendly interface, similar to cron but with more features. Create schedules by specifying a script or flow, its arguments, and a CRON expression to control execution frequency.
CLI (command-line interface)
Section titled “CLI (command-line interface)”The orvanta CLI allows interaction with Orvanta instances directly from your terminal.
Trigger from API
Section titled “Trigger from API”Orvanta provides a RESTful API for programmatic interaction. The operation “run script by path” is designed to trigger a script by its path, passing required arguments.
Trigger from LLM clients with MCP
Section titled “Trigger from LLM clients with MCP”Orvanta supports the Model Context Protocol (MCP) to trigger scripts and flows from LLM clients. All you need is an MCP URL to connect your LLM client to Orvanta.
Triggers from external events
Section titled “Triggers from external events”Webhooks
Section titled “Webhooks”In Orvanta, webhooks are autogenerated for each script and flow, providing either asynchronous or synchronous execution modes. Webhooks accept incoming HTTP requests, allowing users to trigger their Orvanta scripts and flows from external services by sending a POST request to the appropriate authenticated webhook URL (requiring a token as Bearer or query argument).
Webhooks: trigger scripts from Slack
Section titled “Webhooks: trigger scripts from Slack”One use case of webhooks is building a Slackbot with Orvanta. Orvanta uses Slack to trigger scripts and flows by establishing Slackbots and creating specific commands. By connecting Slack with Orvanta, parsing incoming Slack commands, and leveraging Orvanta workflows, operational teams can trigger complex automations directly from Slack.
Emails
Section titled “Emails”Scripts and flows can be triggered by email messages sent to a specific email address, leveraging SMTP. Preprocessors can parse and transform email content before processing.
Custom HTTP routes
Section titled “Custom HTTP routes”Orvanta allows you to define custom HTTP routes for scripts and flows. You can use preprocessors to transform incoming HTTP requests, handling headers, query parameters, and path parameters.
WebSocket triggers
Section titled “WebSocket triggers”Orvanta can connect to WebSocket servers and trigger runnables (scripts, flows) when a message is received. Preprocessors can transform websocket message data before passing to your script or flow.
Postgres triggers
Section titled “Postgres triggers”Orvanta can connect to a Postgres database and trigger runnables in response to database transactions (INSERT, UPDATE, DELETE) on specified tables, schemas, or the entire database.
Kafka triggers
Section titled “Kafka triggers”Orvanta can connect to Kafka brokers and trigger scripts or flows when messages are received on specific topics, enabling real-time event processing from your Kafka ecosystem.
NATS triggers
Section titled “NATS triggers”Orvanta can connect to NATS servers and trigger scripts or flows when messages are received on specific subjects, enabling real-time event processing from your NATS ecosystem.
SQS triggers
Section titled “SQS triggers”Orvanta can connect to Amazon SQS queues and trigger scripts or flows when messages are received, enabling event-driven processing from your AWS ecosystem.
MQTT triggers
Section titled “MQTT triggers”Orvanta can connect to an MQTT broker, subscribe to specific topics, and trigger scripts or flows when messages are received, enabling event-driven processing.
GCP triggers
Section titled “GCP triggers”Orvanta can connect to Google Cloud Pub/Sub, subscribe to specific topics, and trigger scripts or flows when messages are published, enabling event-driven processing.
Azure Event Grid triggers
Section titled “Azure Event Grid triggers”Orvanta can subscribe to Azure Event Grid topics, system topics, domains and Event Grid Namespace topics and trigger scripts or flows when events are delivered. Supports classic push, CloudEvents 1.0 push, and CloudEvents pull with lock-token acknowledgment.
Native triggers
Section titled “Native triggers”Native triggers allow external services like Nextcloud, Google Drive, and Google Calendar to push events directly to Orvanta, triggering scripts or flows in real-time via webhooks or watch channels.
Scheduled polls (Scheduling + Trigger scripts)
Section titled “Scheduled polls (Scheduling + Trigger scripts)”Trigger scripts are used in flows and designed to pull data from an external source and return all new items since the last run, without resorting to external webhooks. A trigger script is intended to be used as a scheduled poll with schedules and states (rich objects in JSON, persistent from one run to another) to compare execution to the previous one and process each new item in a for loop. If there are no new items, the flow will be skipped.
For more complex objects or structured relational data instead of simple state tracking, consider using Data tables which provide a workspace-scoped SQL database for storing and querying data.
Test triggers
Section titled “Test triggers”You can test your triggers in test mode.
Suspended mode
Section titled “Suspended mode”When a trigger is in suspended mode, it continues to accept payloads and queue jobs, but those jobs won’t run automatically. This is useful for debugging your runnable or trigger logic without disabling the trigger entirely.
To enable suspended mode, toggle the Suspend job execution option in the trigger settings.
Managing suspended jobs
Section titled “Managing suspended jobs”You can review all suspended jobs by clicking the See suspended jobs button. This opens a table showing all queued jobs for the trigger. From this table, you can:
- Resume individual jobs to execute them
- Discard jobs that are no longer needed
- Resume all jobs at once
- Discard all jobs at once
Updating trigger configuration
Section titled “Updating trigger configuration”If you modify the trigger’s configuration (such as changing the runnable, retry settings, or error handler) and save, resumed jobs will run using the updated configuration.