fix(service-automation): bind previous as null on the create leg; fix showcase notify recipient (#3427)

Dogfooding the record-after-write showcase flow in a live app surfaced two bugs:

1. The engine bound `previous` into the flow condition scope only when truthy, so
   on a record insert `previous` was an unknown CEL variable — the documented
   `previous == null` create-discrimination threw "Unknown variable: previous" and
   failed the whole start condition, dropping the run. `previous` is now always
   bound (null when there is no prior row), making the create/update discrimination
   the record-after-write docs + Studio designer advertise actually work. Verified
   end-to-end (integration test + a live showcase boot: the flow fires on
   create-urgent and on escalation, and correctly skips a non-urgent create).

2. The showcase `UrgentTaskAlertFlow` notify node had no recipient, so every run
   failed "at least one recipient is required". Now notifies the assignee, falling
   back to the triggering user (`{$User.Id}`) so an unassigned urgent task still
   pings someone. Live-verified: a `task.urgent` notification is delivered.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018939yJ413zG3irLzcTtqaa

Author: claude

.changeset/previous-null-on-create-leg.md

@@ -0,0 +1,18 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(service-automation): bind `previous` (as null) on the create leg so start conditions can discriminate create vs update (#3427)
+
+The engine bound `previous` into the flow condition scope only when it was
+truthy, so on a record insert (`record-after-create`, and the create leg of
+`record-after-write`) `previous` was an **unknown** CEL variable. Any reference to
+it — including the documented `previous == null` create-discrimination — threw
+`condition failed to evaluate as CEL: Unknown variable: previous`, failing the
+whole start condition and dropping the run.
+
+`previous` is now always bound, to `null` when there is no prior row. So
+`previous == null` is the create leg and `previous != null` / `previous.<field>`
+the update leg — the pattern the `record-after-write` docs and the Studio flow
+designer advertise. Update-triggered flows are unaffected (`previous` was, and
+stays, the prior row there).

examples/app-showcase/src/automation/flows/index.ts

@@ -1572,6 +1572,11 @@ export const UrgentTaskAlertFlow = defineFlow({
       label: 'Notify Assignee',
       config: {
         topic: 'task.urgent',
+        // Notify the assignee; fall back to whoever raised the priority
+        // (`{$User.Id}` = the triggering user) so an as-yet-unassigned urgent task
+        // still pings someone. Empty recipients are dropped, so the fallback only
+        // applies when `assignee` is unset.
+        recipients: ['{record.assignee}', '{$User.Id}'],
         channels: ['inbox'],
         severity: 'warning',
         title: 'Urgent task: {record.title}',

packages/services/service-automation/src/engine.ts

@@ -1623,9 +1623,13 @@ export class AutomationEngine implements IAutomationService {
                 if (!variables.has(k)) variables.set(k, v);
             }
         }
-        if (context?.previous) {
-            variables.set('previous', context.previous);
-        }
+        // Always bind `previous` — to `null` on the create/insert leg (there is no
+        // prior row) — so a start condition can DISCRIMINATE create vs update on a
+        // `record-after-write` flow: `previous == null` is the create leg (#3427).
+        // Binding only-when-truthy left `previous` an unknown CEL variable on
+        // insert, so ANY reference to it (even `previous == null`) threw
+        // "Unknown variable: previous" and failed the whole condition.
+        variables.set('previous', context?.previous ?? null);
 
         const runId = this.nextRunId();
         // Expose the run id to executors (ADR-0019): a pausing node (e.g. Approval)