A trigger is what starts a run. Every workflow needs at least one, and a workflow can have several: a Manual Trigger for testing plus a Schedule plus a Webhook can all be active at once. Triggers cost 0 credits; you only pay for the action nodes a run executes.
#The six trigger types
| Trigger | Fires when | Config |
|---|---|---|
| Manual | You click Run in the builder. | None |
| Schedule | A cron schedule comes due, in your chosen timezone. | Cron + timezone |
| Integration Event | A connected integration emits an event (new Gmail message, Stripe charge). | Integration + event |
| Webhook | An external system POSTs to a unique URL. | Method + auth |
| Data Change | A row is added to a workspace table, or a bound form is submitted. | Table + change type |
| Inbound Email | An email arrives at the workflow’s assigned address. | None (address is auto-assigned) |
#Manual
The simplest trigger. Add a Manual Trigger and run the workflow yourself from the builder. Useful while you’re building, for on-demand jobs, and for workflows a person kicks off by hand. No configuration.
Manual runs from the builder always use your current draft; see test runs .
#Schedule
Runs the workflow on a cron schedule. Configure:
- Cron expression, standard five-field cron (e.g.
0 9 * * 1for 9am every Monday). - Timezone, defaults to UTC. The schedule fires relative to this zone, so daylight-saving shifts are handled for you.
A schedule can be enabled or disabled independently of the workflow. Disabling a schedule stops it firing without touching the workflow’s other triggers; your Manual and Webhook triggers keep working.
If scheduled runs keep failing, Rills counts the consecutive failures and automatically disables the schedule after five in a row, then notifies the workspace. Re-enable it once you’ve fixed the underlying problem. A single failure doesn’t stop the schedule; only a sustained streak does.
#Integration Event
Starts a run when a service you’ve connected emits an event: a message lands in Gmail, a charge succeeds in Stripe, a pull request opens in GitHub. Configure:
- Integration, one of your connected integrations.
- Event, the specific event to listen for, chosen from that integration’s event list.
- Connection, which credential to use when more than one is connected.
The event’s payload becomes the run’s trigger data. Reference it downstream with {{trigger.field}}. See Integrations for connecting services.
#Webhook
Runs the workflow when an external system POSTs to a unique URL. Use it for services not in the integration catalog or for ad-hoc HTTP integrations. Webhook triggers support method selection and three authentication modes (none, API key, HMAC signature).
The full setup, authentication options, payload handling, and status codes live on the Webhooks page.
#Data Change
Runs the workflow when data in a workspace table changes. Configure:
- Table, the workspace table to watch.
- Change type, either Row added (default) or Form submitted.
- Form (optional), when the change type is Form submitted, scope to a single bound form; leave it off to fire for any form bound to the table.
Only published workflows fire on data changes. The changed row (or submitted form data) becomes the run’s trigger data. See Tables and Data nodes for working with workspace data.
#Inbound Email
Runs the workflow when an email arrives at an address Rills assigns to it. Use it to turn inbound mail into work, parse a reply, file an attachment, route a request to an approver.
#The assigned address
When you publish a workflow with an Inbound Email trigger, Rills provisions a unique address for that trigger:
yourworkspace-a1b2c3@in.rills.io
The address is stable: republishing keeps the same one, and it’s shown in the trigger’s configuration after publish. You don’t pick it, and it isn’t part of your config. Share it with whoever (or whatever) should mail the workflow, or use it as a reply-to on outbound mail so responses come back into the workflow.
#What the workflow receives
Each inbound message becomes trigger data with these fields:
| Field | Contents |
|---|---|
from | The sender’s address |
subject | The subject line |
textBody | The plain-text body |
htmlBody | The HTML body |
messageId | The message’s unique ID (used to de-duplicate retries) |
authenticated | Whether the sender passed authentication (see below) |
Reference them downstream like any trigger data: {{trigger.from}}, {{trigger.subject}}, {{trigger.textBody}}.
#Sender authentication
Email From headers are trivially forged, so Rills does more than a basic pass/fail check. It confirms author-domain alignment: the domain that actually authenticated the message must match (or be a parent/subdomain of) the domain in the From address. Only then is authenticated set to true. A message that authenticates for evil.com but claims From: someone@acme.com comes through as not authenticated.
Treat the authenticated flag as your trust signal:
- Authenticated mail is safe to act on and safe to reply to. When a run was started by an authenticated inbound email, a Send Email node may reply to that sender even on your default
@rills.aiaddress, without a verified sender domain, because Rills trusts the reply target. - Unauthenticated mail still starts the run (so you never silently drop legitimate mail that lacks strong auth headers), but you should branch on it. Add a Condition on
{{trigger.authenticated}}and route unverified senders to a Human Review step, or drop them, before taking any consequential action.
Rills de-duplicates retried deliveries by messageId, so a workflow won’t run twice for the same email.
#See also
- Workflows : the full node reference
- Webhooks : webhook setup, auth, and payloads
- Email : the Send Email node and sender domains
- Runs & Versions : how runs progress and how versioning works