Triggers
A trigger decides when an automation should start.
Instead of opening a job and clicking Run every time, you can tell Automation Hub to start the job when a time arrives, when another system sends a signal, when something changes, or when a user starts it manually.
The Basic Idea
Main Trigger Types
Connector-Driven Triggers
Some triggers watch a specific connected system for new or changed records. Each one can run in polling mode (Automation Hub checks the system on a timer) or webhook mode (the system notifies Automation Hub when something happens).
Manual Trigger
Use a manual trigger when someone should decide exactly when the job starts. This is the simplest way to run an automation.
How It Works
A manual trigger fires when:
- A user clicks Run in the Automation Hub UI
- An AI agent calls the MCP start tool
- Someone sends a request to
POST /api/v2/job/start
Synchronous vs Asynchronous
When starting a job manually, you can choose how to wait for results:
| Mode | What happens | Best for |
|---|---|---|
| Asynchronous (default) | You get an execution ID immediately and the job runs in the background | Long-running jobs, fire-and-forget |
| Synchronous | The request waits until the job finishes and returns the result | Quick jobs where you need the answer right away |
Input Variables
You can pass input variables when starting a manual run. These become available inside the job as dynamic values.
For example, you might pass a department or reportMonth variable so the same job can run for different teams or time periods.
Good Examples
- Testing a new automation before adding a schedule
- Running a one-time cleanup
- Starting a job after reviewing data
- Giving an operations user a "Run Now" option
- Letting an AI agent run automations on demand
Schedule Trigger
Use a schedule trigger when the job should run at a predictable time. Schedule triggers use Temporal's native schedule system with standard cron expressions.
How It Works
What You Configure
| Setting | Plain-English meaning |
|---|---|
| Cron expression | Standard cron format that defines when the job runs |
| Timezone | Which local time should be used (timezone-aware) |
| Start or end date | Whether the schedule should begin or stop on a specific date |
Cron Expression Examples
| Expression | Meaning |
|---|---|
0 2 * * * | Every day at 2:00 AM |
0 9 * * 1 | Every Monday at 9:00 AM |
0 0 1 * * | First day of each month at midnight |
*/15 * * * * | Every 15 minutes |
Example
Use schedules when consistency matters more than instant reaction.
Good Examples
- Run a backup every night
- Send a report every Monday morning
- Clean old records on the first day of each month
- Check system health every 15 minutes
Webhook Trigger
Use a webhook trigger when another system should start the job by sending an HTTP request. Automation Hub gives you a unique URL that external systems can call.
How It Works
Webhook URL
Each webhook trigger gets its own unique URL. Sharing or reusing a URL across different jobs is not supported — each job must have its own webhook trigger configured.
Each webhook trigger gets a dynamic URL in the format:
/webhook/{path}/**
The path is unique to your trigger. External systems send their requests to this URL.
Supported HTTP Methods
Webhooks accept multiple HTTP methods, so they work with a wide range of external systems:
Response Modes
When a webhook request arrives, you can choose how Automation Hub responds:
| Mode | Behavior | Best for |
|---|---|---|
| IMMEDIATE | Returns HTTP 200 right away, job runs in the background | Most integrations, high-volume webhooks |
| WAIT | Holds the connection for up to 10 seconds, returns the job result if it finishes in time | Quick jobs where the caller needs a response |
Use WAIT response mode when an external system expects a synchronous reply — for example, a form submission that should display a confirmation message based on the job result.
Rate Limiting and Payload Size
Webhooks are protected by default limits:
| Limit | Default value |
|---|---|
| Request rate | 120 requests per minute |
| Maximum payload size | 10 MB |
These limits help protect Automation Hub from accidental floods or oversized payloads.
Authentication
Webhook authentication is optional. When enabled, incoming requests must include a valid JWT token. This prevents unauthorized systems from starting your jobs.
If authentication is not enabled, any system that knows the webhook URL can trigger the job.
Accessing Webhook Data
The data sent by the external system becomes available inside your job through trigger expressions:
{{trigger.payload.fieldName}}
For example, if a form submission sends {"customerName": "Alice", "email": "alice@example.com"}, your job can use:
{{trigger.payload.customerName}}to get "Alice"{{trigger.payload.email}}to get "alice@example.com"
Enable and Disable
You can enable or disable a webhook without deleting it. When disabled, incoming requests will not start the job. When you are ready, enable it again and the same URL continues to work.
Good Examples
- A website form is submitted
- A customer signs up
- A payment is completed
- A file is uploaded
- A ticket is created in another tool
Chat Trigger
Use a chat trigger when a person should start the job by chatting on a shareable web page. Instead of opening Automation Hub, the user visits a link, types a message, and each message they send starts the job and returns the workflow's reply in the conversation.
How a User Reaches It
Every chat trigger publishes a standalone chat page at a unique link. There are two variants:
| Route | Access | When to use |
|---|---|---|
public/chat/:path | Open — the page loads immediately | Public assistants where anyone with the link can chat |
public/chat/auth/:path | Auth-gated — the user must sign in first | Chat pages that should be limited to known users |
The :path segment is unique to the chat trigger step in your job, so the link maps to exactly one job.
The Chat Page
The chat page is a full-screen conversation view:
| Element | Behavior |
|---|---|
| Message input | Placeholder text Ask me anything... — the user types here and presses send |
| Header | Shows the chat title supplied by the job |
| New session | Starts a fresh conversation. This clears the current session on the page so the next message begins a new thread |
| Typing indicator | Shows AHub is typing... while the job runs and prepares a reply |
When a user sends a message, Automation Hub starts the job, and the workflow's result is shown back as the assistant's reply. A session groups the messages of one conversation so the job can keep context across turns; New session begins a new one.
Password-Protected Chats
The public/chat/auth/:path variant gates access behind a sign-in screen before any chatting is allowed:
| Field / label | Value |
|---|---|
| Heading | Sign in to Chat |
| Prompt | Enter your credentials to continue |
| Inputs | Username and Password |
| Button | Sign In |
Invalid credentials show Invalid username or password. The open public/chat/:path variant skips this screen entirely.
Testing from the Canvas
A chat trigger is also surfaced as a floating Chat Trigger control on the Canvas, so you can chat with the job while building it without opening the public link. From the Canvas control you can Clear chat or start a New session. When a job has more than one chat trigger, the control shows a Select a Chat Trigger picker first.
Good Examples
- A support assistant that answers questions and files tickets from a shared link
- An internal helpdesk bot gated behind a sign-in screen
- A conversational front end that runs a workflow on each message
Form Trigger
Use a form trigger when a person should start the job by submitting a form. The form is a standalone public page that can also be embedded in another site with an iframe, so a submission on your own website can start an Automation Hub job.
How a User Reaches It
Every form trigger publishes a form page at a unique link. There are two variants:
| Route | Access |
|---|---|
form/:path | The standard form link |
form/noauth/:path | The variant intended for public, unauthenticated submissions |
The :path segment is unique to the form trigger step in your job.
Fields
The form's fields are defined on the trigger in the backend, so the same page can collect whatever data your job needs. Each field has a label, an optional placeholder, and can be marked required. The supported field types are:
| Field type | Renders as |
|---|---|
text | Single-line text input |
email | Email input with email validation |
number | Numeric input |
date | Date picker |
dateTime | Date-and-time picker |
password | Masked password input |
textarea | Multi-line text box |
dropdown | Single-select dropdown |
checkboxes | Multiple-choice checkboxes (stores a list of selected values) |
radioButtons | Single-choice radio group |
Required fields are marked with an asterisk, and the form blocks submission until they are filled. Email fields are also checked for a valid address.
Submit Behavior
You configure what the submit button says and what happens after a successful submission:
| Setting | What it controls | Default |
|---|---|---|
| Submit button label | The text on the button | Submit |
| Response mode | Whether to show a success message or redirect | Success message |
| Success message | The confirmation text shown after submitting | Response submitted! |
| Redirect URL | Where to send the user instead of showing a message | -- |
When the success message mode is used, the page shows the configured message (for example, Response submitted!) followed by Thank you. Your submission has been recorded. When redirect mode is configured with a URL, the user is sent to that URL after submitting.
Embedding the Form
Because the form is a standalone page, you can drop it into another website with an iframe. When a submission completes, the form notifies the surrounding page by posting a message to the parent frame:
{ "type": "FORM_TRIGGER_SUBMITTED", "response": { } }
The host page can listen for this FORM_TRIGGER_SUBMITTED message to react to the submission — for example, to close a modal or show its own confirmation.
Good Examples
- A public contact or intake form embedded on a marketing site
- A support request form that opens a ticket workflow
- An onboarding form that kicks off a provisioning job
Event Trigger
Use an event trigger when Automation Hub should react to something that changes in a connected system.
Example
Good Examples
- A database record changes
- A Salesforce opportunity is created or updated
- A ticket status changes in a connected tool
- A field changes to a specific value
Event triggers are helpful when the job should react to a meaningful change, not just a fixed time.
Polling Triggers
A polling trigger watches a connected system by checking it on a timer instead of waiting for the system to call in. ServiceNow, Jira, and Email triggers all support a polling mode built on the same behavior, so once you understand polling in one place it works the same everywhere.
How Polling Works
When you connect a polling trigger, Automation Hub starts checking the source system on a regular interval. Each time it finds a new or changed record, it starts the job and passes that record along as trigger data.
Where Polling Starts
You control what happens to records that already exist when the trigger connects:
pollStartMode | What it does |
|---|---|
NOW (default) | Only records that appear after you connect start the job. Anything already in the system is ignored. |
RESUME | Picks up where the trigger left off, so records created while the trigger was paused or the service was down are still processed. |
With the default NOW mode, pre-existing records are not replayed. If you need to process historical records, choose RESUME.
Polling Interval
| Setting | Default | Minimum |
|---|---|---|
pollingInterval | 30 seconds | 10 seconds |
A shorter interval reacts faster but checks the source system more often. The minimum of 10 seconds protects the connected system from excessive requests.
No Duplicates, Even After a Restart
Every item a polling trigger processes is recorded so it is never handled twice. This dedup record survives restarts, so if Automation Hub goes down mid-poll and comes back up, each record still starts the job exactly once — no misses and no repeats. Processed records are kept for a retention window and then cleaned up automatically.
ServiceNow Trigger
Use a ServiceNow trigger when a record is created or updated in a ServiceNow table — for example, a new incident — and you want an automation to run in response.
A ServiceNow trigger can run in two modes:
- Polling — Automation Hub queries a ServiceNow table on the polling interval and fires when it finds new or changed records.
- Webhook — a ServiceNow Business Rule or Flow sends a notification to Automation Hub the moment a record changes.
What You Configure
| Setting | Required | Default | Meaning |
|---|---|---|---|
connectionId | Yes (polling) | -- | The ServiceNow connection (instance URL, username, password) |
tableName | No | incident | The table to watch |
pollingEvent | No | created | Whether to watch for created or updated records |
encodedQuery | No | -- | A ServiceNow encoded query to prefilter which records qualify |
pollStartMode | No | NOW | NOW for only new records after connect, RESUME to catch up |
pollingInterval | No | 30 seconds (min 10) | How often to poll the table |
Testing the Connection
Use the Connect action to verify the trigger before you rely on it. Automation Hub runs a small test query against the configured table and returns a clear pass or fail verdict, so you can confirm the connection, credentials, and table name are correct.
Good Examples
- Start an approval workflow when a new incident is created
- Notify a team when an incident is updated to a specific state
- Sync high-priority incidents to another system
Jira Trigger
Use a Jira trigger when an issue is created or updated in Jira and you want an automation to run in response.
A Jira trigger supports three modes:
| Mode | How it works | Requirements |
|---|---|---|
| Polling | Automation Hub searches Jira on the polling interval and fires on new or changed issues | A Jira connection |
| Auto webhook | Automation Hub registers a webhook in Jira automatically and removes it when the trigger stops | Jira admin permissions |
| Manual webhook | You configure a Jira Automation rule to post to a generated notification URL that Automation Hub gives you | A Jira Automation rule you control |
Use the manual webhook mode when you do not have Jira admin rights. Automation Hub provides a generated notification URL, and you paste it into a Jira Automation rule so Jira posts to Automation Hub when your chosen events happen.
What You Configure
| Setting | Default | Meaning |
|---|---|---|
connectionId | -- | The Jira connection |
events | jira:issue_created | Which Jira events start the job |
jqlFilter | -- | A JQL query that narrows which issues qualify |
pollingEvent | created | For polling mode, whether to watch created or updated issues |
pollStartMode | NOW | NOW for only new issues after connect, RESUME to catch up |
pollingInterval | 30 seconds (min 10) | How often to poll in polling mode |
Testing the Connection
Use the Connect action to confirm the Jira trigger works. Automation Hub checks the connection against Jira and returns a pass or fail verdict.
Good Examples
- Start a triage job when a bug issue is created
- Kick off a release checklist when an issue moves to a Done status
- Alert a team when a high-priority issue is filed for a specific project
Email Trigger
Use an email trigger when a new email arriving in a mailbox should start an automation.
An email trigger supports two modes:
- IMAP polling — Automation Hub checks a mailbox folder on the polling interval for new messages.
- Microsoft Graph webhook — Microsoft notifies Automation Hub when a new message arrives in the mailbox.
What You Configure
| Setting | Default | Meaning |
|---|---|---|
connectionId | -- | The email connection (IMAP or Microsoft 365) |
folder | -- | The mailbox folder to watch |
markAsRead | -- | Whether processed messages are marked as read |
pollStartMode | NOW | NOW for only new mail after connect, RESUME to catch up |
pollingInterval | 30 seconds (min 10) | How often to poll in IMAP mode |
Microsoft Graph Subscriptions
In Microsoft Graph webhook mode, Automation Hub creates a subscription so Microsoft can notify it about new mail. These subscriptions renew automatically before they expire, so the trigger keeps working without manual intervention.
Attachments
When an email starts a job, any attachments on the message are saved to storage so your job can work with them.
Testing the Connection
Use the Connect action to verify the mailbox connection before relying on the trigger.
Good Examples
- Create a ticket when a support email arrives
- Process invoices attached to incoming email
- Route messages from a shared inbox to the right workflow
API Trigger
Use an API trigger when external code should start the job programmatically.
How It Works
External applications call the REST API directly:
POST /api/v2/job/start
The request includes:
| Field | Purpose |
|---|---|
jobId | Which job to start |
inputVariables | Data to pass into the job |
synchronousExecution | Whether to wait for the result or return immediately |
The trigger type is recorded as API in the execution history, making it easy to distinguish API-started runs from other trigger types.
Good Examples
- A CI/CD pipeline starts an automation after a successful deploy
- A custom dashboard lets users trigger jobs through your own interface
- A script runs automations as part of a larger process
Job Call Trigger
Use a job call trigger when one automation should start another.
How It Works
Good Examples
- A main job calls a shared "send notification" job used by many automations
- A data pipeline calls separate jobs for each processing stage
- A parent job calls different child jobs based on a condition
Multiple Triggers on One Job
One job can have more than one trigger. If any trigger fires, the job runs.
Example: Sync Customer Data
Use multiple triggers when the automation has one purpose, but there are different valid ways to start it.
What Trigger Data Means
Every trigger creates a TriggerContext that travels with the job execution. This context contains:
| Field | What it holds |
|---|---|
payload | The data that came with the trigger (form fields, webhook body, input variables, etc.) |
triggerId | A unique identifier for this specific trigger |
triggerType | The kind of trigger that started the job (Manual, Schedule, Webhook, API, etc.) |
triggeredBy | Who or what started the job (a username, a system name, or an API key) |
triggeredAt | The exact time the trigger fired |
Using Trigger Data in Your Job
You can access trigger data anywhere in your job using expressions:
{{trigger.payload.fieldName}}
| Trigger type | Example data you can access |
|---|---|
| Manual | {{trigger.payload.department}}, {{trigger.payload.reportMonth}} |
| Webhook | {{trigger.payload.customerName}}, {{trigger.payload.orderId}} |
| Event | {{trigger.payload.recordId}}, {{trigger.payload.changedField}} |
| Schedule | {{trigger.payload.scheduledTime}} |
| API | {{trigger.payload.environment}}, {{trigger.payload.version}} |
| ServiceNow | {{trigger.payload.source}}, {{trigger.payload.event}}, {{trigger.payload.tableName}}, {{trigger.payload.timestamp}}, {{trigger.payload.record}} |
| Jira | {{trigger.payload.issueKey}}, {{trigger.payload.fields.summary}}, {{trigger.payload.fields.status}} |
{{trigger.payload.subject}}, {{trigger.payload.from}}, {{trigger.payload.body}}, {{trigger.payload.attachments}} | |
| Chat | {{trigger.payload.message}} (the text the user sent) |
| Form | {{trigger.payload.email}}, {{trigger.payload.fullName}} — one entry per configured form field, keyed by field name |
The TriggerContext is stored in the JobExecution record, so you can always look back and see exactly what data triggered a run.
Pausing a Trigger
You can disable a trigger without deleting it.
| If you disable... | What happens |
|---|---|
| Schedule trigger | The Temporal cron schedule pauses and the job stops running on that schedule |
| Webhook trigger | Incoming HTTP requests no longer start the job, but the URL is preserved |
| Event trigger | The job stops watching for that event in the connected system |
| Polling trigger (ServiceNow, Jira, Email) | The polling stops checking the source system. The last processed position is preserved, so RESUME mode can pick up where it left off when you re-enable it |
This is useful when you are testing, troubleshooting, or temporarily pausing automation activity. When you are ready, enable the trigger again and it picks up where it left off.
Common Trigger Patterns
Nightly Data Sync
Real-Time Lead Processing
High-Value Deal Alert
CI/CD Automation
Parent-Child Job Chain
Which Trigger Should You Use?
| Situation | Best trigger |
|---|---|
| It should run at the same time every day, week, or month | Schedule |
| Another application should start it via HTTP | Webhook |
| It should react to a change in Salesforce, a database, or another connected system | Event |
| A record is created or updated in a ServiceNow table | ServiceNow |
| An issue is created or updated in Jira | Jira |
| A new email arrives in a mailbox | |
| A person should start it by chatting on a shareable page | Chat |
| A person should start it by submitting a public or embedded form | Form |
| A user or AI agent should decide when to run it | Manual |
| External code needs to start it programmatically | API |
| Another automation should start it as a sub-job | Job Call |
| You need regular automatic runs plus an emergency run option | Schedule + Manual |
| You need instant webhook runs plus a backup nightly run | Webhook + Schedule |
Troubleshooting Triggers
| Problem | What to check |
|---|---|
| Scheduled job did not run | Is the trigger enabled? Is the cron expression correct? Is the timezone right? |
| Job ran at the wrong time | Check timezone settings on the schedule step |
| Webhook did not start the job | Confirm the external system sent the request to the correct URL. Check if the webhook is enabled. |
| Webhook returns an error | Check if the payload exceeds 10 MB or the rate limit of 120 requests/minute was hit |
| Webhook started but data is missing | Verify the external system is sending the expected fields in the request body |
| Webhook authentication failed | Confirm the external system is sending a valid JWT token in the request |
| Event trigger did not fire | Confirm the source system is connected and the event type matches |
| Event trigger fires too often | Add or adjust filters to narrow the conditions |
| Polling trigger did not fire on existing records | With the default NOW mode, records that existed before you connected are ignored. Use RESUME to catch up on earlier records |
| Polling trigger is not starting jobs at all | Run the Connect action and check the verdict. Confirm the connection and credentials are valid and the polling interval is at least 10 seconds |
| ServiceNow trigger fails to connect | Check the table name (it must exist) and confirm the connection's instance URL, username, and password are correct |
| Jira auto webhook could not be created | Auto webhook mode needs Jira admin permissions. Use manual webhook mode with the generated notification URL instead |
| Email trigger (Graph) is not receiving notifications | Confirm the Microsoft Graph subscription is active and the mailbox connection is valid; subscriptions renew automatically but the connection must stay authorized |
| API trigger returns an error | Check that jobId is correct and the job is enabled |
| Job Call trigger did not start child job | Verify the Call node has the correct child job ID and input parameters |
| Manual run is unavailable | Check whether the job is enabled |
Tips for Better Triggers
Name triggers clearly
- Use names like
Nightly Backup Schedule,New Lead Webhook, orSalesforce Deal Event
Always check timezone for schedules
- Scheduled jobs depend on the timezone you choose. A cron expression for 2:00 AM in UTC is different from 2:00 AM in your local timezone.
Choose the right response mode for webhooks
- Use IMMEDIATE for most cases. Only use WAIT when the calling system needs a result and your job finishes in under 10 seconds.
Protect webhooks with authentication
- Enable JWT authentication for webhooks that receive sensitive data or should not be triggered by unknown callers.
Use filters for noisy events
- If an event happens often, trigger only when the important condition is met.
Keep manual run available for important jobs
- Even jobs with schedule or webhook triggers benefit from a manual run option for testing, recovery, and urgent one-off runs.
Review trigger history
- If a job starts unexpectedly, check the TriggerContext in the execution record. It shows the trigger type, who started it, and what data came with it.
Use API triggers for integration
- When building custom applications that need to start automations, use the API trigger with
synchronousExecution: trueif you need results inline, orfalsefor background processing.