Add manual trigger type and sharing search for automations

[timmilazzo]

Summary

Adds a third manual trigger type to automations (alongside schedule and event), tightens automation frontmatter serialization so trigger-irrelevant fields aren't leaked, and registers new automation-related actions (including account search for sharing) in the action-types plugin.

Problem

Automations previously supported only schedule and event trigger types. There was no way to define an automation that runs strictly on-demand via run-now, and the trigger dispatcher/routes still treated non-schedule triggers loosely, risking stale event/schedule/condition metadata bleeding into manual or mismatched trigger configurations. Additionally, supporting a "share with specific users" sharing option required a way to search for candidate accounts, which didn't exist yet.

Solution

Introduced manual as a first-class, persisted trigger type that never fires from the scheduler or event bus and only runs via explicit run-now. Updated the trigger dispatcher and routes to correctly gate subscription and field serialization based on triggerType, and added a new search-automation-accounts action to support per-automation sharing with specific users. Documentation for the automations skill was updated to reflect the three trigger types and clarify tool usage.

Key Changes

• packages/core/src/triggers/types.ts: Extended TriggerFrontmatter documentation for the new manual trigger type.
• packages/core/src/triggers/dispatcher.ts (spec updated): Ensures the dispatcher never subscribes to an event for manual automations, even if stale event metadata is present in frontmatter.
• packages/core/src/triggers/routes.ts:
  • nextRunForMeta now only computes a next run for schedule-type triggers.
  • resourceToAutomationItem conditionally includes event, schedule, scheduleDescription, timezone, condition, and nextRun fields only when relevant to the automation's triggerType, preventing stale/irrelevant fields from being surfaced.
  • setAutomationEnabledForOwner updated to only recompute next-run scheduling for schedule type triggers.
• New action: search-automation-accounts: Looks up candidate accounts (with organization membership context) for sharing automations with specific users.
• packages/core/src/vite/action-types-plugin.ts: Registered new automation actions (list-recurring-jobs, manage-recurring-job, run-automation-now, list-automation-runs, list-automations, list-automation-events, manage-automation, search-automation-accounts) in the core action registry, with accompanying spec updates.
• .agents/skills/automations/SKILL.md: Rewrote documentation to describe the three persisted trigger types (schedule, event, manual), clarify that "Email received" in the UI is a specialized event trigger (not a fourth type), and update guidance on manage-automations actions including run-now semantics for manual automations.
• Added tests covering manual automation listing (no automatic trigger fields exposed) and dispatcher behavior with stale event metadata on manual automations.

---

  

---

To clone this PR locally use the Github CLI with command gh pr checkout 2646

You can tag me at @BuilderIO for anything you want me to fix or change

[timmilazzo]

New, more opinionated UI for setting up Automations, with explicit trigger definitions and easier cron job selection.

[tgaribal]

@builderio-bot look at latest PR feedback and fix anything you agree with. Be skeptical. Reply to every comment if you fixed it or not and why.

[builder-io-integration]

There was a problem with your request, please try again later. Error id: f96ebd9706bf40439d33e393d9ac9331

[builder-io-integration]

Builder reviewed your changes and found 2 potential issues 🔴

Review Details

Incremental Code Review Summary

The latest commit correctly addresses all five previously reported issues: non-D1 optimistic concurrency guards are now enforced, resource IDs are carried through automation mutations, sharing state is wired into the editor, and stale event conditions are cleared during trigger transitions. Those stale review threads were resolved before this review.

Two new regressions were found in the follow-up implementation:

• 🔴 HIGH — Specific-user sharing is still summarized as private; opening and saving an already shared automation can reconstruct Personal sharing and revoke all collaborators.
• 🔴 HIGH — The editor always sends condition: null for schedule saves, but the service now rejects any defined condition for non-event triggers, so saving scheduled automations fails.

The manual trigger and stable-ID API changes otherwise follow the intended architecture, with useful coverage around access and transaction behavior.

🧪 Browser testing: Will run after this review (PR touches UI code)

[builder-io-integration]

🔴 Specific-user sharing is reported as private

explicitSharingSummary returns visibility: "private" for non-organization overlays even when grant rows contain specific collaborators. The owner-facing list therefore reconstructs an existing shared automation as Personal in automationSharingStateFromSummary; saving an unrelated definition change then replaces the grants and silently revokes every collaborator. Return visibility: "shared" when grants are present and preserve the grant details.

Additional Info

New issue found by 1 of 3 incremental reviewers; confirmed against the access summary and editor reconstruction path.

[builder-io-integration]

🔴 Schedule edits always send a rejected condition field

The schedule branch always includes condition: null in the update payload. updateAutomation now rejects any defined condition when the resulting trigger is not event, so saving an existing scheduled automation—even when only changing its instructions or timezone—fails with the unsupported-condition error. Omit condition from schedule updates; the service already clears stale event conditions during a trigger change.

Additional Info

New issue found by 1 of 3 incremental reviewers; this is distinct from the resolved stale-condition persistence issue.