fix(flows): make record_change/schedule flows actually fire (engine contract)#17
Merged
Merged
Conversation
…ontract)
Every template flow used a start-node + CRUD-node shape the automation engine
does not recognize, so record-change flows registered but never fired. Aligned
all 30 flows + 9 package configs with the real engine contract (verified
end-to-end on a running 7.7 stack — a corrected flow now fires and applies its
update_record):
- Enable the `triggers` capability (+ `job` for project's scheduled flows) in
every package's `requires` — without it RecordChangeTriggerPlugin/
ScheduleTriggerPlugin never load and flows can't bind.
- Start-node binding: `criteria` + `criteriaDialect` / `triggerOn` →
`triggerType: 'record-after-{create|update}'` + `condition` (bare CEL). Legacy
Salesforce-flavor predicates (`!= NULL`, `AND`, `TODAY()`, `ISNEW()`,
`ISCHANGED(x)`, `PRIOR()`, `IN (...)`) translated to valid CEL (the 7.6+
validator rejects them).
- update_record / create_record: data key `values` → `fields`; record selection
`recordId`/`recordIds` → `filter` (the executor reads `fields` + `filter`).
- Triggering-record id placeholders (`{ticketId}`, `{pieceId}`, `{reportId}`, …)
→ `{record.id}`.
9/9 packages build green, typecheck clean; both trigger plugins load; the
helpdesk escalate flow verified firing (ticket → escalated).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every template flow was authored against a start-node + CRUD-node shape the automation engine does not recognize, so
record_changeflows registered at startup but never fired on data writes (and the CRUD nodes silently no-op'd). Root cause traced + fixed upstream in theobjectstack-automationskill (framework PR #1565); this PR fixes the templates to match the real engine contract.Verified end-to-end on a running 7.7 stack: a corrected flow (helpdesk
escalate_angry_customer) fires on update and applies itsupdate_record(ticket → escalated); bothRecordChangeTriggerPluginandScheduleTriggerPluginload once the capability is enabled.Changes (30 flows + 9 package configs)
triggerscapability (+jobfor project's scheduled flows) in every package'srequires. Without it the trigger plugins never load → flows can't bind.criteria+criteriaDialect/triggerOn→triggerType: 'record-after-{create|update}'+condition(bare CEL). Legacy Salesforce-flavor predicates (!= NULL,AND,TODAY(),ISNEW(),ISCHANGED(x),PRIOR(),IN (...)) translated to valid CEL (the 7.6+ ADR-0032 validator rejects them).update_record/create_record: data keyvalues→fields; record selectionrecordId/recordIds→filter(the executor readsfields+filter).{ticketId},{pieceId},{reportId}, …) →{record.id}.Verification
tscclean, 0 residualcriteriaDialect/triggerOn/recordId/values:in flows.Notes / follow-ups
record_change; they now bind asrecord-after-update(fire on the next write). Converting them to scheduled flows is a possible future refinement.variables(e.g.{reportId}) were left declared (harmless) to keep the diff minimal.🤖 Generated with Claude Code