Triggers in InTouch AI are first-class objects — not polling loops bolted onto a scheduler. Watch a file for changes. Watch a directory for adds, deletes, and modifications. Or set up a Monitor that runs a tool on a cadence and fires actions when a condition is met. Every trigger can run a full job or a single tool directly, with RBAC, alerts, and a full audit trail attached.
Triggers are usually an afterthought — a polling loop, a webhook node bolted on, a folder-watching shell script someone wrote on a Tuesday. Here's what changes when they become first-class objects with the same governance every other piece of automation gets.
Before: a script polls a folder every 60 seconds, sleeps through every fire window, races itself on file rotations.
After: file triggers fire on actual filesystem events with a configurable settle time, pass the file path forward as a job property, and inherit the same RBAC + audit as every other object.
Before: a folder-watching shell script on one server, a different one on another, a Lambda doing S3 events on a third. Different code, different failure modes, no central log.
After: one trigger object per watched location. Concurrent writes, rotation, symlinks, vanished files — all handled by the engine. One audit log for all of them.
Before: business signals (a price crossing a level, an error rate climbing, a queue backing up) had no clean trigger path. You poll an API and write conditional code.
After: Monitors run a tool on a cadence, evaluate explicit when: arms against the tool's output, and fire notifications or downstream jobs when a condition matches. No event plumbing. No polling code. One YAML file.
Most automation platforms treat triggers as an afterthought — a webhook node or a brittle file-check on a schedule. InTouch AI treats triggers the same way it treats schedules: as governed, auditable objects with owners, groups, rights, and alerts.
Point a trigger at an absolute file path. When the file's modification time changes, the trigger fires. Use it for arrival signals, export readiness flags, upstream system drops — any case where a known file is the source of truth.
Published to the job: triggerFile, triggerEvent, the changed timestamp.
Watch a directory. The trigger fires on any change in the folder — new files, deleted files, modified files. The job receives lists of what changed, so it can process only the new arrivals instead of scanning the whole directory on every run.
Published to the job: newFiles, deletedFiles, modifiedFiles, changedFiles, counts for each.
A Monitor runs a check: tool on a schedule and evaluates one or more when: arms against its output. The first matching arm fires its actions — notifications across the eight outbound channels, downstream job runs, skill runs, or another job-file dispatch. Great for thresholds, anomalies, and "alert me if X" patterns: a stock crossing a price, disk space crossing a line, a website returning an error, a ticket queue exceeding SLA.
Defined as YAML: check + when arms (optional else). Generate one from a plain-English description, install one from the InTouch AI hub, or write it yourself. Link to one or more schedules and/or trigger files — same many-to-many wiring jobs use.
Action verbs in when[].do: notify, run_tool, run_skill, run_jobfile, nothing (five). The job-local if task uses the same grammar and adds two more (skip_remaining, goto) for task-list flow control. Capture intermediate outputs with as: <name> and reference them downstream in the same arm via {{name.field}}.
if task — Same Arm Grammar, Job-Local ScopeMonitors give you condition-driven automation across schedule fires. The new if task gives you the same expressive power inside a single job. Use it to gate, branch, alert, jump, or short-circuit — without scripting.
The if task takes an ordered list of arms. The first matching arm fires its do: actions. Triggers can be a condition (native expression), an ai: question (LLM judgement), or else (catch-all). Actions are the same seven verbs Monitors use.
After fetching upstream data, branch on response code. >= 500 pages on-call; 4xx logs and continues; 2xx proceeds. All three with templatable subject/body, all in one task.
skip_remaining halts the job after the condition is met — useful when the work is done early or a precondition failed. No more "set runif on every downstream task." One task, one decision.
goto skips to a named later task in the same job. Forward-only by sequence — server rejects backward jumps so the job graph stays acyclic. The right primitive for "if the row already exists, skip to the notification step."
arms:
- condition: "{{task.fetchStatus.responseCode}} >= 500"
do:
- type: run_skill
name: triage-error
input: "Upstream returned 5xx — analyze {{task.fetchStatus.responseBody}}"
as: triage
- type: notify
alertNames: [pager]
subject: "Upstream down — {{triage.answer}}"
body: "{{triage.answer}} (model={{triage.model}})"
- type: skip_remaining
- ai: "Is the response body a meaningful incident report?"
do:
- type: goto
task: parseIncident
- else:
do: []Operators: == != < <= > >= contains, combined with && and ||. Interpolate {{task.<name>.<prop>}}, {{job.<prop>}}, {{args.<key>}}, {{env(NAME)}}, or {{date(pattern)}}. Both {{...}} and ${...} are accepted.
A file being written doesn't fire the trigger repeatedly. Configure settleTime — the trigger waits until the file's size and mtime have been stable for N seconds before firing. No double-runs, no partial-file reads. One of those details you only miss when it's absent.
A single file or folder change can drive any combination of jobs and monitors via the same many-to-many link wiring schedules use. The job processes the files; the monitor evaluates a condition and acts. Both fire in the same pass — no duplicate plumbing.
Link an alert to a trigger and it fires when the trigger fires — independent of the job it runs. Useful when you want "the file arrived" to notify a different team than "the job succeeded." Alerts go to any of the configured messaging channels.
Every trigger object has an owner, a group, and per-role rights. On Department and Enterprise editions, only users with update rights on the trigger group can change what path is being watched. The filesystem has permissions; your automation platform should too.
Job tools receive every detail of the triggering event — the changed file's full path, its new timestamp, lists of additions and deletions for folder triggers. Build logic that only processes what's new, or that branches on the event type.
The engine watches filesystem events itself — you don't maintain bespoke folder-watching shell scripts. You point at a path, set a settle time, and the engine handles every edge case (concurrent writes, rotation, symlinks, vanished files).
| Capability | InTouch AI | Apache Airflow | n8n | Shell scripts |
|---|---|---|---|---|
| Native file trigger | ✓ | Sensors + DAG hacks | Watcher node (limited) | You write it |
| Folder change events (add / del / mod) | ✓ | — | Partial | You write it |
| Settle delay for in-flight files | ✓ | — | — | You write it |
| Condition-driven Monitors (schedule + check + when) | ✓ | — | — | — |
| RBAC on trigger objects | ✓ (Dept/Enterprise) | — | Enterprise plan | — |
| Tailored alerts per trigger | ✓ across 8 channels | Via DAG failure hooks | Build a workflow | — |
| Run job OR single tool/skill | ✓ | DAG only | Workflow only | — |
Airflow has no native file trigger — you bolt on Sensors inside DAGs. n8n has a watcher but no enterprise RBAC over watched paths. external schedulers have no file awareness at all.
An SFTP drop lands a CSV. The folder trigger fires, publishes newFiles, the job picks up only the new ones, loads them into a staging table, archives, notifies finance. Settle delay ensures no partial reads.
An upstream system writes a readiness flag file when month-end close completes. The file trigger fires, the job runs reports, sends them out. No fixed schedule, no polling script.
A Monitor checks transaction volume every 15 minutes against a baseline tool. The first when: arm fires a high-priority page if volume is 3x the trailing 30-day average; a softer arm posts a Slack note for 1.5x. No fixed schedule alert, no manual triage of normal spikes.
Folder trigger watches /dropbox/partner-x/. Each new file: validate schema, POST to the partner API, move to /processed/ or /rejected/ based on response. Full audit of every received file, every response.
A trigger can fire any of the 60+ tools — SQL across 11 databases, FTP/SFTP, SSH, HTTP, Docker, AWS (full CLI), Google Workspace, Essbase, TM1, JDE, or any of the 9 AI providers. A trigger can also invoke a skill by name: @weekly-report, @data-quality-check, @customer-escalation.
Download the free Personal edition and build your first file trigger in about ten minutes. No license key.