novu-dashboard-workflows

Original：🇺🇸 English

Translated

Author step content for Novu workflows defined in the Dashboard or generated/edited via the Novu MCP. Use when filling in step controls (subject, body, editorType, headers, body, conditions) for email, in-app, sms, push, chat, delay, digest, throttle, or HTTP Request steps.

7installs

Sourcenovuhq/skills

Added on2026-05-25

NPX Install

npx skill4agent add novuhq/skills novu-dashboard-workflows

SKILL.md Content

View Translation Comparison →

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

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
```
.
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.
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.
Empty key/value entries in HTTP headers or body — use an empty array
```
[]
```
when not needed. Never
```
[{ "key": "", "value": "" }]
```
.
Hardcoded URLs / product names — always pull from
```
payload.*
```
or
```
subscriber.*
```
so the workflow stays portable.
Changing
editorType
when editing email — keep
```
block
```
as
```
block
```
and
```
html
```
as
```
html
```
unless the user explicitly asks to switch.
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
```
.