novuhq/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.

| Step type | Reference | Use it for | | -------------- | --------------------------------------------------------------- | ----------------------------------------------------------- | | Email | references/email-step.md | Detailed content, formal communications, receipts | | In-App | references/in-app-step.md | Real-time updates, activity feeds, high engagement | | SMS | references/sms-step.md | Urgent alerts, verification codes, time-sensitive messages | | Push | references/push-step.md | Mobile engagement, re-engagement, time-sensitive updates | | Chat | references/chat-step.md | Slack / Discord / Teams team & developer alerts | | Delay | references/delay-step.md | Pause workflow execution before a channel step | | Digest | references/digest-step.md | Batch multiple notifications into one | | Throttle | references/throttle-step.md | Limit notification frequency, prevent fatigue | | HTTP Request | references/http-request-step.md | Call external APIs / webhooks; fetch data for later steps | | Step condition | references/step-conditions.md | JSON-Logic for "send only if…", merge / replace / remove |

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