Core Triggers - Automation Anywhere EKB Docs

Core triggers cover the most common workflow entry points: manual invocation, scheduled runs, incoming HTTP requests, and file uploads.

Manual Input

Starts a workflow when a user or external system explicitly invokes it. You can configure it with custom input fields that must be filled in before the workflow runs — making it ideal for on-demand tasks that require user-provided context, such as submitting a request, kicking off a report, or initiating a process from within the Odin chat interface. When to use it

You want to run a workflow on demand from the Odin UI or via the API.
The workflow needs user-provided inputs before it can execute.
You are testing or debugging a workflow with specific values.

Configuration

Field	Type	Description
Input fields	Any	User-defined parameters configured in the trigger settings. Each field has a name, type, and optional description shown to the user at runtime.

Output variables

Variable	Description
`trigger.user_input`	The raw text submitted by the user.
`trigger.inputs.<field>`	The value of each named input field. Replace `<field>` with the configured field name (e.g., `trigger.inputs.customer_name`).
`trigger.chat_id`	The ID of the chat session that initiated the run.
`trigger.message_id`	The ID of the message that triggered the workflow.

Example: referencing an input field

Hello {{ trigger.inputs.customer_name }}, your request has been received.

Notes

Input fields are presented to the user as a form before the workflow starts. Keep field names short and descriptive.
trigger.user_input is available even if no custom input fields are configured.
To invoke this trigger programmatically, call the Odin API with the workflow ID and the required input values.

Webhook

Exposes a unique HTTP endpoint for your workflow. External systems — such as third-party applications, automation platforms, or custom scripts — can send an HTTP request to that URL to start the workflow. The request body, headers, query parameters, and HTTP method are all passed to downstream nodes. When to use it

An external system needs to notify Odin when an event occurs (e.g., a form submission, a payment event, or an update from another platform).
You are integrating Odin with Automation Anywhere or another system that can call an HTTP endpoint.
You want to expose a workflow as an API endpoint that other developers or tools can call.

Configuration

Setting	Type	Description
`http_method`	String	The HTTP method the endpoint will accept: `GET`, `POST`, `PUT`, `PATCH`, or `DELETE`.
`auth_type`	String	How incoming requests are authenticated: `none`, `basic`, or `header`.
`response_mode`	String	`onReceived` returns an immediate HTTP 200 as soon as the request arrives. `lastNode` waits for the workflow to complete and returns the final output as the HTTP response.

Output variables

Variable	Description
`trigger.body`	The JSON body of the incoming request.
`trigger.headers`	The HTTP headers sent with the request.
`trigger.query`	URL query parameters from the request.
`trigger.method`	The HTTP method used by the caller.
`trigger.webhook_url`	The full URL of the webhook endpoint. Share this with the external system that will be calling the workflow.

Response modes

Mode	Behavior
`onReceived`	Returns HTTP `200 OK` immediately when the request arrives, before the workflow finishes. Use for fire-and-forget scenarios.
`lastNode`	Holds the HTTP connection open until the workflow completes, then returns the final node output as the response body. Use when the caller expects a synchronous payload.

Notes

When using header auth, configure the expected header name and value in the trigger settings.
trigger.webhook_url is useful for including the endpoint URL in setup documentation sent to integration partners.
If you are calling this webhook from Automation Anywhere, use the HTTP Task action in your bot to POST to the webhook URL.

Schedule

Fires a workflow automatically on a recurring schedule defined by a cron expression. Use it to automate time-based tasks such as daily reports, periodic data syncs, or recurring notifications — without any manual intervention. When to use it

You need a workflow to run at a fixed time every day, week, or month.
You are automating a recurring business process (e.g., pulling data every morning, sending a weekly summary).
You want to poll an external system at regular intervals.

Configuration

Setting	Type	Description
`schedule`	String	A cron expression defining when the workflow runs.
`timezone`	String	The timezone in which the cron expression is evaluated. Accepts standard timezone names such as `UTC` or `America/New_York`.

Always set the timezone field explicitly. If left unset, the schedule runs in UTC, which may cause unexpected timing for region-specific workflows.

Cron expression reference A cron expression has five fields: minute · hour · day of month · month · day of week.

┌───── minute (0–59)
│ ┌───── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌───── day of week (0–6, Sunday = 0)
│ │ │ │ │
* * * * *

Expression	Schedule
`0 9 * * *`	Every day at 9:00 AM
`0 9 * * 1`	Every Monday at 9:00 AM
`0 /6 * *`	Every 6 hours
`0 8 1 * *`	First day of every month at 8:00 AM
`/15 * * *`	Every 15 minutes

Output variables

Variable	Description
`trigger.trigger_time`	The ISO 8601 timestamp of when the schedule fired.
`trigger.schedule_expression`	The cron expression used for this run.
`trigger.trigger_type`	Always `"schedule"`.

Notes

The Schedule trigger does not pass user input. If your workflow needs dynamic data, fetch it inside the workflow using an API node or toolkit tool.
Use trigger.trigger_time in downstream nodes to stamp records or log when the scheduled run occurred.

File Upload

Starts a workflow when one or more files are uploaded. It provides each file’s content, name, size, and MIME type to downstream nodes — making it ideal for document processing workflows such as parsing an uploaded report, extracting data from a spreadsheet, or routing a file to an AI model for analysis. When to use it

You want users to submit files for the workflow to process (e.g., invoices, contracts, CSV exports).
You need to extract content from uploaded documents and pass it to an LLM or data processing node.
You are building a multi-file ingestion pipeline.

Configuration This trigger has no required configuration fields. It activates automatically when a file is uploaded to the workflow’s associated chat or interface. Output variables

Single file
Multiple files

Variable	Description
`trigger.file.content`	The full extracted text content of the uploaded file.
`trigger.file.name`	The original filename.
`trigger.file.size`	The file size in bytes.
`trigger.file.type`	The MIME type (e.g., `application/pdf`, `text/csv`).
`trigger.file_count`	Total number of files uploaded. Returns `1` for a single file.

Variable	Description
`trigger.files`	An array of all uploaded files. Each item contains `content`, `name`, `size`, and `type`.
`trigger.file_count`	Total number of files uploaded.

Use a Loop node to iterate over trigger.files when processing multiple uploads in a single run.

File content is extracted as plain text. Binary formats such as PDFs and Word documents are parsed automatically — the extracted text is what appears in trigger.file.content.

Notes

trigger.file always refers to the first (or only) uploaded file. For multi-file workflows, use trigger.files with a Loop node.
Use trigger.file.type in a Conditional node to route different file types to different processing branches.

Documentation Index

​Manual Input

​Webhook

​Schedule

​File Upload

Manual Input

Webhook

Schedule

File Upload