Run a Breeze agent on record creation, property change or schedule (three trigger patterns)

Outcome. An agent runs on the records you choose, at the moment you choose, with a run counter, a status property and an error path, so you can tell later what it did and what it cost.

Workflow map Enrollment, branches and actions at a glance reporting-alerts-050

flowchart TD
    A[Trigger: created, property changed or schedule] --> B[Delay 15 minutes]
    B --> C[Custom code: rate limit gate, stamp status and counter]
    C --> D{Status = queued?}
    D -->|No, rate limited| E[Stop, record stays skipped]
    D -->|Yes| F[Run an agent, output to Agent run output]
    F --> G{Output written?}
    G -->|Yes| H[Set status = success, stamp last run at]
    G -->|No| I[Set status = error]
    I --> J[Internal email to operations owner]

When to use it, when not to

• UseUse it as the base pattern under any agent-driven automation. The agent does the thinking, this workflow decides which records reach it and how often.
• UseUse it when you need an audit trail of AI runs. Without a status property and a counter, an agent run leaves almost nothing behind and nobody can answer "why did this record get processed twice".
• SkipDo not point an agent at a whole database on a schedule to see what happens. Every enrolled record is one run against the portal credit balance, and a schedule that matches 10 000 contacts spends 10 000 runs each time it fires. (check in your portal: how a single Run an agent execution is metered against the portal credit balance, and whether a failed run still consumes credits)
• SkipDo not trigger on a property the agent itself writes. That is a loop, and with re-enrollment on it is an expensive one.