App triggers

Add an App trigger (trigger_app) and Elizon watches a connected account for you — a Drive folder, a calendar, a sheet — and starts the workflow once for every new item it finds. Pick the app, pick the account you connected under Connections, pick what to watch.

Three ship today:

They poll rather than subscribe: Elizon asks the provider on a schedule you choose. Push notifications (Google watch channels) are a later addition and will not change how a trigger you configure today behaves.

Configuration

The triggers each app offers and their inputs are on the app's own page: Google Drive, Google Calendar and Google Sheets.

How often, and the first run

Check every is 1–60 minutes, 5 by default. A shorter interval is not free — every check is a call against your Google account's own quota.

On the first enable the trigger records "everything up to now is history" and starts no runs. A trigger switched on over a folder of 500 files does not start 500 runs. If you do want the existing items processed, turn on process existing and set a maximum (1–200, 10 by default).

What "new" means is different for each one, and the difference matters

This is the one thing worth reading before you rely on a trigger, because it is not a limitation Elizon chose — it is what each provider is able to tell us.

Calendar remembers for us. Google hands back a sync token and the next poll gets exactly what changed since, nothing more and nothing less. This is the only one of the three that is exact. Cancellations arrive as changes, which is why a cancelled event fires. If Google retires the token (it can), Elizon re-baselines rather than replaying your calendar.

Drive will sort but will not remember. Elizon asks for the folder newest-created-first and keeps the creation time of the newest file it has fired for. That is honest and it has a limit worth knowing: a file whose creation time is older than the newest one already seen is never fired for. Uploading something with a back-dated creation time, or a file that arrives late from another system, can be missed. The trigger watches for files that appear, so a file edited in place is not a new file and does not fire again.

A sheet has no notion of time at all. A range is a list, and "new" means "further down than I had read". Elizon keeps the row count. So: inserting a row in the middle does not fire, and deleting rows can make later additions look like they were already read. Append to the bottom. Give the trigger your whole table (Sheet1, or Sheet1!A:D) including the header row, so new rows fall inside the range it is watching.

Exactly once, even across a crash

Each item starts exactly one run. The run's identity is derived from the item itself, and the workflow engine refuses to start the same one twice — so a crash between starting a run and recording progress does not double-fire.

For Calendar the identity is the item and its version, which is what makes "updated" work: an edited event has the id it always had, so identity by id alone would make the update look like a duplicate of the fire it already had, and the edit would be silently dropped.

A tick starts at most 50 runs. The rest are not lost — the next check picks up where this one stopped. Runs are subject to your plan's concurrency ceiling like every other run.

When it cannot reach the account

A trigger shows its last error, when it happened, and how many checks in a row have failed — the same surface the Email trigger uses. Checks back off as failures accumulate and return to the normal interval on the first success. A connection that needs reconnecting says so: reconnect it on the Connections page and the trigger resumes from the cursor it had, without replaying what it already fired for.

Output

The run's payload is flat: the item the provider returned, under the keys each app's page lists — for example {{ trigger.item.name }} for a new Drive file. {{ run.trigger.type }} is app and {{ run.trigger.id }} is this node's id.

Example

name: New Drive file
description: Summarises every file dropped into the shared folder.
graph:
  nodes:
    - id: new-file
      type: trigger_app
      position: { x: 0, y: 0 }
      data:
        app: google-drive
        trigger: file-added
        connection: drive-account
        inputs: {}
        pollMinutes: 5
        processExisting: false
        processExistingMax: 10
    - id: summarise
      type: ai_agent
      position: { x: 280, y: 0 }
      data:
        mode: existing
        agent: agents.summariser
        agentName: Summariser
        inputMappings: []
  edges:
    - { id: file-to-summarise, source: new-file, target: summarise }

In a real workflow inputs names the folder to watch — see Google Drive.

In a Package

A Package can declare an app trigger. Your interval, process-existing choice and the trigger's own inputs travel with it; the account does not. The installer binds their own Google account through a credential Slot, exactly as they would for an App node — a packaged trigger pointed at the author's calendar would be both useless and a leak.

The cursor never travels. An installed trigger starts from "everything up to now is history" in the account it was just bound to, which is the only baseline that can mean anything there.

slots:
  - id: drive-account
    type: credential
    scheme: oauth2
    app: google
triggers:
  - id: new-file
    type: app
    connectionSlot: drive-account

On the node:

• Travels: app, trigger, inputs, pollMinutes, processExisting, processExistingMax
• Converted: connectionId → connection (the credential Slot the installer binds an account to)
• Never carried: none