​

Step Conditions

Dashboard semantics: condition evaluates to true ⇒ step runs. Framework semantics: skip returns true ⇒ step is skipped. They’re mirror images — invert the boolean when porting between surfaces.

​

Available Variables

Prefer reusing existing variables for consistency. Only introduce new payload.* variables when truly needed — duplication makes templates and conditions harder to maintain.

​

Variable Namespaces

​

Subscriber Properties

• subscriber.firstName
• subscriber.lastName
• subscriber.email
• subscriber.phone
• subscriber.avatar
• subscriber.locale
• subscriber.timezone
• subscriber.subscriberId
• subscriber.isOnline
• subscriber.lastOnlineAt
• subscriber.data (custom subscriber data; deeply addressable as subscriber.data.<key>)

​

Step Outputs

​

Canonical Conditions (Dashboard JSON-Logic)

​

Subscriber is offline

{ "==": [{ "var": "subscriber.isOnline" }, "false"] }

​

In-App was not read

{ "==": [{ "var": "steps.<stepId>.read" }, "false"] }

​

In-App was not seen

{ "==": [{ "var": "steps.<stepId>.seen" }, "false"] }

​

Workflow tags include any of

{ "in": ["tag1,tag2", { "var": "workflow.tags" }] }

​

HTTP response property equals a value

{ "==": [{ "var": "steps.<http-step-id>.status" }, "active"] }

The property must be declared in the HTTP step’s responseBodySchema. Undeclared properties are not addressable.

​

Framework Equivalents

​

Subscriber is offline (run only if offline)

const inApp = await step.inApp("inbox", async () => ({ /* ... */ }));

await step.push("offline-push", async () => ({ title: "...", body: "..." }), {
  skip: ({ subscriber }) => subscriber.isOnline === true,
});

​

In-App was not read (send email fallback)

const inApp = await step.inApp("inbox", async () => ({ /* ... */ }));

await step.delay("wait", async () => ({ unit: "hours", amount: 4 }));

await step.email("fallback", async () => ({ subject: "...", body: "..." }), {
  skip: () => inApp.read === true,
});

​

Branch on HTTP response

const plan = await step.http("fetch-plan", async () => ({
  method: "GET",
  url: `https://api.example.com/users/${payload.userId}/plan`,
  responseBodySchema: {
    type: "object",
    properties: { status: { type: "string" } },
    required: ["status"],
  } as const,
}));

await step.email("notify", async () => ({ /* ... */ }), {
  skip: () => plan.status !== "active",
});

​

Quick Reference

​

Common Pitfalls

1. Inverting the boolean wrong — Dashboard runs when condition is true; Framework skip skips when true. They’re opposites.
2. Referencing undeclared HTTP properties — only properties in responseBodySchema are addressable in steps.<http>.<prop>.
3. Using subscriber.isOnline == true as a string — isOnline is a boolean. Use "false" (string) only in JSON-Logic; in Framework use the JS boolean false.
4. Conditions on a delay step — delays support skip too, but if a delay is skipped the workflow proceeds immediately. Don’t treat skip as “shorten”.

​

See Also

• channel-selection.md — uses these conditions for offline gating
• workflow-templates.md — every template’s Step condition lines map to these snippets
• framework-integration/references/workflow-and-steps.md — full Framework skip reference
• dashboard-workflows/references/step-conditions.md — Dashboard / Novu MCP authoring flow, including the merge / replace / remove intent rules