A trigger defines how an AOP starts. All triggers are configured and managed from the Workbench. There are three types:

• Scheduled — run an AOP at a set time, once or on a recurring cadence (time-based).
• Inbound Webhook — let any external system start an AOP by sending it JSON (event-based).
• On App Event — start an AOP when a matching event happens in a connected app (event-based). In v1, this supports Gmail and Slack.

This page walks through setting up each type. For editing, pausing, and monitoring existing triggers, see Manage schedules & triggers.

1. Scheduled triggers

A schedule runs an AOP automatically at a time you choose — either once, or on a recurring cadence. Schedules are ideal for routine, time-bound processes such as daily reports, attendance reviews, or monthly compliance audits.

Accessing schedule creation

1. Navigate to Workbench — click Workbench in the left navigation menu. You'll see the List of schedules with any existing schedules.
2. Initiate schedule creation — click Create schedule in the top-right corner. The schedule creation form opens.

Step 1: Basic details

Name of schedule

• Give the schedule a descriptive name that clearly indicates its purpose.
• Examples: Check application access, Daily attendance review, Monthly compliance audit.
• Best practice: use consistent naming conventions across your organization.

AI Colleague selection

• Choose which AI Colleague will execute this schedule.
• The dropdown lists all AI Colleagues available in your system.

AOP selection

• Select the specific AOP to execute.
• Only AOPs associated with the selected AI Colleague appear in the list.
• The AOP must permit scheduled execution. If it's restricted to other start methods, it won't be selectable here.

Step 2: Schedule type configuration

Choose one of two schedule types.

Non-recurring (one-time execution)

Use for a one-off process or a specific date requirement.

• Time zone — select the time zone the execution time should be interpreted in.
• Date and time — choose the exact date and time to run.

Recurring (repeated execution)

Use for ongoing processes that need to run on a regular cadence.

• Frequency — how often the schedule repeats:
  • Minutes — 15, 30, or 45 minutes (15 minutes is the minimum interval)
  • Hours
  • Days
  • Weeks
  • Months
• Repeat interval — the interval within the chosen frequency (for hours/days/weeks/months, any value from 1 to 99 — e.g., every 2 weeks, every 3 months).
• Time zone — select the appropriate time zone (e.g., (UTC +05:30) Asia/Kolkata). Defaults to your local time zone.
• Execution time — the time of day the schedule runs, in 24-hour format.
• Start date — when the recurring schedule begins.

End condition — decide when a recurring schedule should stop:

• End on a date — the schedule stops after this date.
• After a number of occurrences — the schedule stops once it has run the specified number of times.
• If neither is set, the schedule continues until you deactivate it.

Month-end handling: for monthly schedules set to a day that doesn't exist in a shorter month (e.g., the 31st), the run is adjusted to the last valid day of that month.

Previewing and saving

• Before saving, review the configured cadence to confirm it matches your intent.
• After you save, the schedule appears in the List of schedules with an Active status, and its upcoming runs become visible in the Workbench.

Good to know

• The minimum frequency is 15 minutes for sub-hourly schedules.
• Time zones are honored per schedule, so schedules in different zones run at the correct local time.

2. Inbound Webhook triggers

An Inbound Webhook lets any external system start an AOP by sending it a JSON payload. When something happens in the source system (a new hire is created, a ticket is updated, a job finishes), that system sends an HTTP request to a secure URL, and the AOP runs immediately with the request data available as context.

Use a webhook trigger when the source system can send outbound HTTP requests and you want the AOP to react in real time.

Before you start

• The AOP you want to trigger must exist.
• You need an auth config set up in your platform's auth setup to secure the webhook. If the one you need doesn't exist yet, create it there first — it will then appear in the Auth type dropdown. (Creating and managing auth configs happens in the platform auth setup, not on the trigger page.)

Step 1 — Add a webhook trigger

1. Open the AOP and go to the Triggers area.
2. Choose Inbound Webhook as the trigger type.

The setup page shows the following fields.

The Production URL and Listen URL are clearly differentiated on the page — copy the right one for the right purpose. Use the Listen URL for testing and the Production URL for the live integration.

Step 2 — Choose an auth config

Select an auth config from the Auth type dropdown. This secures both the Production and Listen URLs.

• The credential itself (e.g., a header token, or a userID + password for Basic Auth) lives in the platform auth setup — it is not shown, copied, or regenerated on the trigger page.
• To rotate a credential, do it in the platform auth setup. Every trigger that references that config picks up the change automatically.
• Changing the auth config after the webhook is live will require the source system to be reconfigured with the new credential. You'll see a confirmation prompt before the change is applied.

Step 3 — Enter a sample request body

In the Sample request body field, enter a representative JSON payload that mirrors what your source system will actually send. For example:

{
  "employee_id": "EMP-4821",
  "employee_name": "Priya Sharma",
  "department": "Engineering",
  "start_date": "2026-04-15",
  "manager": "Rahul Mehta",
  "location": "Bangalore"
}

This body serves two purposes: it tells whoever configures the source system what payload to send, and it is used as the request body when you test with Copy as cURL.

• The body must be valid JSON. Errors are flagged inline as you type, and an invalid body blocks saving the trigger.
• Don't include a _trigger_meta object — that envelope is added automatically by the platform at run time (see What your AOP receives below).

Step 4 — Save the trigger

Save the trigger. Saving enables the Listen and Copy as cURL actions used for testing.

Step 5 — Test with the Listen URL

Before going live, verify your setup against the Listen URL (which never starts a run):

1. Click Listen to start capturing against the Listen URL.
2. Send a test request to the Listen URL. The fastest way is Copy as cURL — it composes a ready-to-run cURL command using the Listen URL, the selected auth, the content type, and your sample body. Paste it into a terminal (or fire a request from Postman / the source system's sandbox).
3. The request appears in the Test request log on the setup page, showing the timestamp, validation outcome (accepted / rejected with reason), and the response returned to the caller.
4. Listening stops automatically as soon as the first request is received (pass or fail). Review the result, fix anything in the source system if needed, and click Listen again to test the next attempt.

The composed cURL includes your auth credentials — handle it with care.

Testing against the Listen URL never affects the Production URL, so live traffic keeps flowing during your test session.

Step 6 — Go live

1. Copy the Production URL and Method from the trigger page.
2. In the source system, configure an outbound webhook / integration that fires on the event you care about, and point it at the Production URL.
3. Set the auth header using the credential from your platform auth setup, and map the source event data into the JSON request body.

Once live, each valid request to the Production URL starts exactly one AOP run.

What your AOP receives

On each run, the AOP receives the request body plus a platform-added _trigger_meta envelope, so downstream steps can reference both the source data and how the run was triggered:

{
  "employee_id": "EMP-4821",
  "employee_name": "Priya Sharma",
  "department": "Engineering",
  "start_date": "2026-04-15",
  "manager": "Rahul Mehta",
  "location": "Bangalore",
  "_trigger_meta": {
    "trigger_type": "webhook",
    "received_at": "2026-04-15T09:42:11Z",
    "request_id": "req_a8f2c"
  }
}

The _trigger_meta envelope is also surfaced in the Trigger Context step on the AOP run details page.

Response and error codes

The webhook returns generic caller-facing responses (identical on both URLs):

Detailed rejection reasons appear in your logs — Production URL failures in Run History, Listen URL failures in the Test request log on the setup page.

Good to know

• POST + JSON only. There is no method or format selector.
• No batching or deduplication. Each valid request fires one run.
• Unique URLs. Every webhook trigger gets its own distinct Production and Listen URLs; no two triggers share a URL.

3. On App Event triggers (Gmail & Slack)

An On App Event trigger starts an AOP when a matching event is detected in a connected app. In v1, supported apps are Gmail and Slack — for example, when a new email arrives or a message is posted in a channel.

App-event triggers are polling-based in v1: the platform checks the app at a frequency you set and starts the AOP when new events match your filters.

Before you start

• The AOP you want to trigger must exist.
• You need a connected Gmail or Slack connection available to select. The setup page shows the connection status inline.

Setup flow

Configure the trigger on a single setup page, in order:

Step 1 — App connection

Select the app (Gmail or Slack), then select from the available connections for that app. The connection status (connected / disconnected) is shown inline.

If a connection breaks later (revoked token, permission error), polling pauses automatically, a failure state surfaces on this page, and the failure is recorded in Run History. Polling resumes only once the connection is restored.

Step 2 — Trigger event

Select the event to listen for from the dropdown. The available events depend on the app chosen in Step 1 (see the tables below).

Step 3 — Event configuration (filters)

Once you pick an event, a configuration form appears with the filter fields relevant to that event. Each field renders based on its type:

• Text fields (From, To, Subject, Channel, Author, File Name, etc.) — text input.
• Enum fields (Category, Is Unread, Message Subtype, Is Private, etc.) — dropdown.
• Multi-select fields (Label) — multi-select dropdown.
• Date fields — date picker.

Fields left empty match any value. Only events that match all configured filters will start the AOP.

Step 4 — Test event

Click Test event to fire a live call to the selected resource. The raw JSON response is shown inline below the button. This lets you:

• confirm the connection works, and
• see the actual response structure so you can check your filters line up with real data.

This first response is also stored as the baseline for detecting new events on subsequent polls.

Step 5 — Dispatch mode

Choose how matched events in a single poll are dispatched:

• Once per poll — trigger the AOP once, regardless of how many events matched that cycle.
• Per matching event — trigger a separate AOP run for each matching event.

Step 6 — Polling interval

Set how often the app is checked (e.g., every 15 minutes). The platform tracks which events it has already processed (a sliding window) so events aren't dispatched twice across polls. If the app response includes timestamps, those are used as cursors; if not, consecutive responses are compared to identify new events.

Supported events — Gmail

Supported events — Slack

Note: Filter fields may change to reflect the source app's response schema.

What your AOP receives

Each run started by an app-event trigger receives the matched event payload plus a platform-added _trigger_meta envelope:

• trigger_type — "app_event"
• source_app — "gmail" or "slack"
• triggered_at — timestamp when the poll matched and dispatched
• duration_ms — duration of the source API call
• match_count — number of events matched in the poll cycle
• match_index — position of this event (only when dispatch mode is Per matching event)

The _trigger_meta envelope is also surfaced in the Trigger Context step on the AOP run details page.

Good to know

• Polling, not real-time. In v1, events are detected on the polling interval you set, not pushed instantly.
• No duplicates across polls. The sliding window ensures each event is processed once.
• Connection health matters. If the connection breaks, polling pauses and surfaces a clear failure state until it's fixed.
• More apps coming. Additional app-event integrations (e.g., Workday, ServiceNow) are planned for a later release.

Monitoring triggered runs

All trigger runs — from every trigger type — are recorded in Run History. Open Run History and use the filters to narrow by Trigger Type (Scheduled, Webhook, App Event); filtered views are captured in the URL for bookmarking or sharing. Each triggered run includes a Trigger Context step showing how it started. For failed trigger evaluations, the Trigger Context step also shows the failure reason.

See Manage triggers for editing, pausing, and deleting triggers.