Novu Dashboard Workflows

Dashboard Workflows

Rules for authoring step content (subject, body, editorType, headers, body, conditions) on workflows that live in the Novu Dashboard — whether you're editing them by hand or via the Novu MCP.

Authoring in code with @novu/framework? Skip this skill — the Framework SDK encodes these constraints in its types and helpers.

Still need to decide what the workflow should look like (channels, severity, critical, digest, templates)? Start with design-workflow/, then come back here to fill in the step content.

When to use this skill

Use it whenever you write or edit the controls of a Dashboard / MCP step:

• "Set the email subject and body for this step"
• "Update the in-app notification copy"
• "Add headers to this HTTP Request step"
• "Change the digest window to 1 hour"
• "Skip this step when the subscriber is offline" (step condition)
• Any Novu MCP tool call that writes step content (create_workflow, update_workflow_step, etc.)

Step Content Guidelines

These rules apply to every step type.

• Use Liquid variables in control values for personalization. Variables must be wrapped in double curly braces {{ and }}. Example: {{ subscriber.firstName }}, {{ payload.* }}.
• EXCEPTION: In Block Editor (editorType: "block") node attributes, never use curly braces — use bare variable names like payload.actionUrl instead of {{ payload.actionUrl }}. See references/email-step.md for the full Block Editor rules.
• For steps after an HTTP Request step, use {{ steps.<http-step-id>.<property> }} to reference response data. Only properties defined in that HTTP step's responseBodySchema are available — never invent arbitrary response fields. Example: if HTTP step fetch-user defines responseBodySchema with name and email, use {{ steps.fetch-user.name }} and {{ steps.fetch-user.email }}.
• Never hardcode URLs, names, or product names — use variables instead.
• Keep content consistent with other workflow steps.
• Modify the content according to the user's intent.
• Preserve everything not explicitly asked to change.
• Keep the same editorType (block or html for email) and structure.

Step Types

Each step type has its own content rules. Open the matching reference before writing controls.

Common Pitfalls

1. Curly braces inside Block Editor attributes — Maily TipTap node attrs (url, text, src, id, each, href, externalLink) take bare variable names. "{{ payload.actionUrl }}" is wrong; "payload.actionUrl" is right. See references/email-step.md.
2. Referencing undeclared HTTP response fields — {{ steps.<http-step-id>.<property> }} only works for properties listed in that step's responseBodySchema. Add the property to the schema first.
3. Hardcoding array items instead of looping — when the payload contains an array (payload.items, payload.providers), iterate with a Block Editor repeat node or an HTML {% for %} loop. Don't list array items as separate nodes / elements.
4. Empty key/value entries in HTTP headers or body — use an empty array [] when not needed. Never [{ "key": "", "value": "" }].
5. Hardcoded URLs / product names — always pull from payload.* or subscriber.* so the workflow stays portable.
6. Changing editorType when editing email — keep block as block and html as html unless the user explicitly asks to switch.
7. Replacing a step condition when the user said "add" — "add" / "also" / "and" merges with { "and": [...] }; "change to" / "set to" replaces; "remove" / "clear" returns null. See references/step-conditions.md.

See Also

• design-workflow/ — choose channels, severity, critical, digest defaults, and pick a workflow template before authoring step content
• framework-integration/ — author the same workflows in code with @novu/framework instead
• trigger-notification/ — fire a workflow once it's authored