And a trigger is the "when" clause of the contract you give it: tell InTouch AI what to do, when to do it, what to do when it works, what to do when it doesn't, and who to notify.
Triggers in InTouch AI are first-class objects — not polling loops bolted onto an older 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 workflow or a single tool directly, with access control, alerts, and a full audit trail attached — because the AI is the architecture and the governance sits behind it, not the other way around.
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 workflow property, and inherit the same access control + 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 workflows when a condition matches. No event plumbing. No polling code. One IML file.
Config-era platforms treat triggers as an afterthought — a webhook node or a brittle file-check on a schedule. InTouch AI does everything a specialized trigger tool does. 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 workflow: triggerFile, triggerEvent, the changed timestamp.
Watch a directory. The trigger fires on any change in the folder — new files, deleted files, modified files. The workflow 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 workflow: 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 workflow runs, skill runs, or another workflow-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 IML: check + when arms (optional else). Find one and run it — install a ready-made Monitor from the InTouch Hub, point it at your setup, and go. Or generate one from a plain-English description, or write it yourself. Start from something that works, not a blank page. Link to one or more schedules and/or trigger files — same many-to-many wiring workflows use.
Action verbs in when[].do: notify, run_tool, run_skill, run_jobfile, nothing (five). The workflow-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, Workflow-Local ScopeThis is the contract's "what to do when it doesn't work" clause, now intelligent. The fixed rule — retry N, email a log — can't tell you why. An ai: arm reads the failure, knows why, and acts: smart-retry, refresh an expired token, or surface the one sentence that matters. "It broke. Here's why. I fixed it." No older tool can say that. Monitors give you condition-driven automation across schedule fires; the new if task gives you the same expressive power inside a single workflow. 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 workflow 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 workflow. Forward-only by sequence — server rejects backward jumps so the workflow 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": true, "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 workflows and monitors via the same many-to-many link wiring schedules use. The workflow 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 workflow it runs. Useful when you want "the file arrived" to notify a different team than "the workflow 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.
Workflow 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) | ✓ | — | — | — |
| access control on trigger objects | ✓ (Dept/Enterprise) | — | Enterprise plan | — |
| Tailored alerts per trigger | ✓ across 8 channels | Via DAG failure hooks | Build a workflow | — |
| Run workflow 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 access control over watched paths. External schedulers have no file awareness at all. And none of them have an AI core to grow into — you can bolt AI onto an older engine, but you can't bolt on a center.
An SFTP drop lands a CSV. The folder trigger fires, publishes newFiles, the workflow 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 workflow 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 14 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.
The config era's polling loops are dead. Download the free Personal edition and give the AI its first contract — a file trigger that fires the moment your data lands — in about ten minutes. No license key.