Launching & Triggers
Run a published workflow manually, on a schedule, from an email, or through the API.
Building a workflow is half the story. The other half is deciding when it runs. The Triggers page is where you wire a published workflow to the real world: a button click, a POST from your systems, an email landing in your team inbox, or a clock.
There are four ways to start a published workflow:
The page has two tabs: Workflows for your browser workflows and Agents for your agent automations. Both support the same four launch methods, so everything below applies to either.
Publish first
Email and schedule triggers only fire for published workflows. A draft is never launched by anything: not a schedule, not an email, not the API. When you publish, its triggers go live in the same click. See Browser Workflows for how drafts and publishing work.
Manual launch
The simplest start: click Launch on the Workflows page or at the top of the Triggers page, fill in the workflow's inputs, and go. The run opens live so you can watch it work, step in if it asks a question, and see the outputs the moment it finishes.
Manual launches are also how most teams test a workflow after editing it. Because every run records its inputs and its full session log, a quick manual run is the fastest way to confirm a change before you rely on a schedule or an email rule to do the launching for you. Every run, however it started, ends up on the Sessions page.
API launch
Every published workflow is also a REST endpoint. Send a single POST with the inputs as JSON and you get a run back: same workflow, same graph, started from your own code instead of a click. The Triggers page shows a launch counter per surface (you can see at a glance how many API, manual, event, and schedule starts a workflow has had) and the workflow's API docs include a ready-to-copy snippet.
The API reference covers authentication, payloads, run status polling, and how to retrieve outputs and files programmatically.
Email triggers
An email trigger turns your team inbox into a launch surface. You pick a phrase; when an email from one of your workspace's team members arrives with that phrase in the subject line, the workflow runs, with its inputs filled in from the email itself.
Setting one up
Step 1
Choose the subject phrase. Matching is case-insensitive and looks for the phrase as whole words, so "New JODL DS order" matches "Re: New JODL DS order #4412" but won't fire on loose partial hits. Pick something your team would naturally put in a subject line and that won't collide with unrelated mail.
Step 2
Write extraction instructions. The trigger form lists the inputs this
workflow needs (in the screenshot above, a required order_number) and
reminds you to reference those fields by name. Your instructions tell an
AI extractor how to fill them from each email. The extractor reads the
email body, and attachments where relevant, and maps what it finds onto
the workflow's inputs.
Step 3
Create the trigger. From then on, every matching email from a team member launches a run automatically. No one opens RamAIn.
A worked example
Take the workflow in the screenshot, "Create JODL DS Order in Zoho". It needs
one input, an order_number. The trigger is configured like this:
- Subject contains:
New JODL DS order - Extraction instructions: "Pull the order number from the email body. If the sender lists multiple orders, use the first one."
Now a teammate forwards a customer email to team-rajesh@inbox.ramain.ai
with the subject "Fwd: New JODL DS order from the Mumbai team". Here's what
happens:
- The subject matches the phrase, so the trigger fires.
- The extractor reads the email body, finds "order JD-88412 and JD-88413",
and (following the instructions) takes the first one:
order_numberbecomesJD-88412. - The inputs parse, so the run launches automatically and shows up on the Sessions page like any other run.
- The sender can get a reply on the same thread when the run launches, and another when it completes, with the outputs included.
If the extractor can't fill a required input from the email, the run doesn't launch on bad data; the trigger holds instead of guessing. Clear extraction instructions ("use the first one", "the number always starts with JD-") are what keep this path reliable.
Note
Email triggers only accept mail from members of your workspace, sent to your team inbox address. Mail from outside your team never launches anything. Email is one of several channels on the trigger form; see Integrations for the full messaging surface, including Slack and Telegram.
Schedule triggers
A schedule runs the workflow on a timetable, no email and no click required.
You configure four things:
- Frequency. Hourly, daily, weekly, or monthly. Weekly schedules pick a day of the week; monthly schedules pick a day of the month.
- Time of day and timezone. Runs fire at the local time you choose, in the timezone you choose, so "9:00 AM Pacific" means 9:00 AM Pacific all year, regardless of where your team or your servers sit.
- Saved inputs. A scheduled run can't stop to ask questions, so you save the input values with the schedule. Every scheduled run launches with those values. If the workflow needs different inputs on different days, that's a sign it wants an email or API trigger instead.
- Slack results (optional). Check "Post results to Slack" and paste a Slack Incoming Webhook URL, and the schedule posts a completion message to your channel after each run. It's a lightweight way to see results without opening the platform.
The footer of the form confirms the plan in plain English, for example "Runs every day at 09:00 AM (America/Los_Angeles)", before you save. Scheduled runs appear on the Sessions page like any other run, so a missed morning report is a ten-second diagnosis, not a mystery.
The Agents tab
Everything above applies to agent automations too. Switch to the Agents tab on the Triggers page and you get the same four surfaces (manual, API, email, schedule) for the automations you built on the Agents page.
These are the multi-step orchestrations that combine APIs, code, LLM steps, and your browser workflows. An agent automation can be launched by a schedule, fed by an email rule, or called from your systems exactly the way a browser workflow can. See Agents for what those automations are and how to build them.
Triggers on the canvas
You can also author triggers where you author everything else: on the workflow graph. Add a Trigger block to the canvas in the editor, describe the email match or schedule there, and it syncs to a real, live trigger when you Publish. Same result, different door. It's useful when the trigger is part of how you think about the workflow's design rather than an afterthought.
Where to next
Every run, however it started, lands here. Watch live, replay history, and handle runs that need input.
The email address behind your event triggers, and everything else it can do.
Messaging channels, data sources, credentials, and the API surface.
Launch published workflows from your own systems with a single POST.
Was this page helpful?