diff --git a/content/docs/api-reference/contexts/context-schema.mdx b/content/docs/api-reference/contexts/context-schema.mdx
index f05a21927..db2adb489 100644
--- a/content/docs/api-reference/contexts/context-schema.mdx
+++ b/content/docs/api-reference/contexts/context-schema.mdx
@@ -8,5 +8,5 @@ title: Context schema
This makes them particularly useful for multi-tenant applications, dynamic branding, and scenarios where notifications need to reference common, reusable data.
-Read more about how to use contexts in workflows in the [contexts](/platform/workflow/contexts) section.
+Read more about how to use contexts in workflows in the [contexts](/platform/workflow/advanced-features/contexts) section.
diff --git a/content/docs/api-reference/contexts/context-schema.model.mdx b/content/docs/api-reference/contexts/context-schema.model.mdx
index f05a21927..db2adb489 100644
--- a/content/docs/api-reference/contexts/context-schema.model.mdx
+++ b/content/docs/api-reference/contexts/context-schema.model.mdx
@@ -8,5 +8,5 @@ title: Context schema
This makes them particularly useful for multi-tenant applications, dynamic branding, and scenarios where notifications need to reference common, reusable data.
-Read more about how to use contexts in workflows in the [contexts](/platform/workflow/contexts) section.
+Read more about how to use contexts in workflows in the [contexts](/platform/workflow/advanced-features/contexts) section.
diff --git a/content/docs/platform/inbox/advanced-concepts/multi-tenancy.mdx b/content/docs/platform/inbox/advanced-concepts/multi-tenancy.mdx
index fab95045f..2be2aebf6 100644
--- a/content/docs/platform/inbox/advanced-concepts/multi-tenancy.mdx
+++ b/content/docs/platform/inbox/advanced-concepts/multi-tenancy.mdx
@@ -4,9 +4,9 @@ description: 'Learn how to use context to implement multi-tenant notifications t
icon: 'Building2'
---
-Multi-tenancy in Novu lets you isolate notifications for different organizations, environments, or workspaces within the same Novu project. Instead of creating separate subscribers or workflows for each tenant, you can use [Contexts](/platform/workflow/contexts) to define and manage tenant boundaries.
+Multi-tenancy in Novu lets you isolate notifications for different organizations, environments, or workspaces within the same Novu project. Instead of creating separate subscribers or workflows for each tenant, you can use [Contexts](/platform/workflow/advanced-features/contexts) to define and manage tenant boundaries.
-This guide assumes you already understand what Contexts are. If not, start with the [Contexts](/platform/workflow/contexts) documentation.
+This guide assumes you already understand what Contexts are. If not, start with the [Contexts](/platform/workflow/advanced-features/contexts) documentation.
## How multi-tenancy works in Novu
@@ -48,7 +48,7 @@ context: {
You can also manage all tenant contexts centrally from the Novu dashboard or API.
-To learn more about creating, updating, and deleting contexts, see the [Manage Contexts](/platform/workflow/contexts) guide.
+To learn more about creating, updating, and deleting contexts, see the [Manage Contexts](/platform/workflow/advanced-features/contexts) guide.
### Applying tenant context in workflows
@@ -84,7 +84,7 @@ In this example:
- Notifications triggered with this tenant context will be isolated to that tenant’s workspace.
- The same tenant ID must be passed to the Inbox to display these notifications.
-Learn more about applying Context in workflows in [Contexts in Workflows](/platform/workflow/contexts/contexts-in-workflows) documentation.
+Learn more about applying Context in workflows in [Contexts in Workflows](/platform/workflow/advanced-features/contexts/contexts-in-workflows) documentation.
### Filter the Inbox by tenant
@@ -133,4 +133,4 @@ Once a tenant context is created, its data becomes accessible in all template ed
You can also use tenant context data to control conditional logic inside your workflows. For example, you may want to send certain updates only to enterprise tenants.
-To learn more about customizing notification content with context, refer to the [Contexts in Workflows](/platform/workflow/contexts/contexts-in-workflows) documentation.
\ No newline at end of file
+To learn more about customizing notification content with context, refer to the [Contexts in Workflows](/platform/workflow/advanced-features/contexts/contexts-in-workflows) documentation.
\ No newline at end of file
diff --git a/content/docs/platform/inbox/advanced-customization/customize-bell.mdx b/content/docs/platform/inbox/advanced-customization/customize-bell.mdx
index 776863d32..20640cab2 100644
--- a/content/docs/platform/inbox/advanced-customization/customize-bell.mdx
+++ b/content/docs/platform/inbox/advanced-customization/customize-bell.mdx
@@ -28,7 +28,7 @@ function BellComponent() {
export default BellComponent;
```
-See the [Custom Popover documentation](#) for how to use the Bell component with third party library like Radix UI to trigger a custom popover that contains the notification list.
+See the [Custom Popover documentation](/platform/inbox/advanced-customization/customize-popover) for how to use the Bell component with third party library like Radix UI to trigger a custom popover that contains the notification list.
## Replace the default Bell Icon
diff --git a/content/docs/platform/inbox/configuration/inbox-with-context.mdx b/content/docs/platform/inbox/configuration/inbox-with-context.mdx
index 542f9ab17..40ce5dca7 100644
--- a/content/docs/platform/inbox/configuration/inbox-with-context.mdx
+++ b/content/docs/platform/inbox/configuration/inbox-with-context.mdx
@@ -7,7 +7,7 @@ icon: 'Package'
_Contexts_ let you scope each `` instance to a specific environment, tenant, or app within your product. When combined with workflow-level contexts, they ensure that each `` displays only the notifications relevant to that specific context.
-If you’re new to contexts, start from the [Contexts](/platform/workflow/contexts) section to understand how contexts are created, managed in Novu and how they used in workflows.
+If you’re new to contexts, start from the [Contexts](/platform/workflow/advanced-features/contexts) section to understand how contexts are created, managed in Novu and how they used in workflows.
## How context works in ``
diff --git a/content/docs/platform/inbox/configuration/preferences.mdx b/content/docs/platform/inbox/configuration/preferences.mdx
index 2d7beb0ec..3c52564ba 100644
--- a/content/docs/platform/inbox/configuration/preferences.mdx
+++ b/content/docs/platform/inbox/configuration/preferences.mdx
@@ -60,7 +60,7 @@ The name given to a workflow in the Novu dashboard is the name your subscribers
For each workflow, the Inbox UI only displays the channels step used in a given workflow.
-Learn how to configure channel steps in a workflow in the [Building Workflows guide](/platform/workflow/build-a-workflow).
+Learn how to configure channel steps in a workflow in the [Create a Workflow guide](/platform/workflow/create-a-workflow).
### Filter preferences
diff --git a/content/docs/platform/inbox/headless-mode.mdx b/content/docs/platform/inbox/headless-mode.mdx
index 8cfff4318..f0816d322 100644
--- a/content/docs/platform/inbox/headless-mode.mdx
+++ b/content/docs/platform/inbox/headless-mode.mdx
@@ -24,7 +24,7 @@ npm i @novu/react
## Add the `NovuProvider`
-Wrap your application or the components that need access to notifications with the `NovuProvider`. This component initializes the Novu client and provides it to all child hooks via [context](/platform/workflow/contexts).
+Wrap your application or the components that need access to notifications with the `NovuProvider`. This component initializes the Novu client and provides it to all child hooks via [context](/platform/workflow/advanced-features/contexts).
```jsx
import { NovuProvider } from '@novu/react';
diff --git a/content/docs/platform/integrations/demo-integration.mdx b/content/docs/platform/integrations/demo-integration.mdx
index 3cec3fb4d..fe2da395c 100644
--- a/content/docs/platform/integrations/demo-integration.mdx
+++ b/content/docs/platform/integrations/demo-integration.mdx
@@ -27,7 +27,7 @@ The demo integrations are set as primary by default in new Novu environments.
1. Log in to the Novu dashboard.
2. Click **Workflows**.
-3. Click **Create workflow** and [create a new workflow](/platform/workflow/build-a-workflow).
+3. Click **Create workflow** and [create a new workflow](/platform/workflow/create-a-workflow).
4. Add two steps in the workflow: one for Email and one for SMS.
5. Click **Test Workflow**.
diff --git a/content/docs/platform/integrations/email/index.mdx b/content/docs/platform/integrations/email/index.mdx
index 10dd589f2..bcbed199e 100644
--- a/content/docs/platform/integrations/email/index.mdx
+++ b/content/docs/platform/integrations/email/index.mdx
@@ -56,7 +56,7 @@ Novu automatically sends the notification to the email address stored on the sub
-Learn how to [build email template](/platform/workflow/template-editor) using the block editor, custom HTML, and dynamic variables.
+Learn how to [build email template](/platform/workflow/add-notification-content/channels-template-editors#email-template-editor) using the block editor, custom HTML, and dynamic variables.
## Configuring email providers
diff --git a/content/docs/platform/integrations/push/(providers)/apns.mdx b/content/docs/platform/integrations/push/(providers)/apns.mdx
index f0313d183..a6b0c3448 100644
--- a/content/docs/platform/integrations/push/(providers)/apns.mdx
+++ b/content/docs/platform/integrations/push/(providers)/apns.mdx
@@ -99,7 +99,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Triggering workflows
-Once subscribers’ devices are registered, push notifications are delivered through [workflows that include a Push step](/platform/workflow/build-a-workflow). A workflow can be triggered using the Novu [SDK](/platform/sdks/overview) or [API](/api-reference/events/trigger-event).
+Once subscribers’ devices are registered, push notifications are delivered through [workflows that include a Push step](/platform/workflow/create-a-workflow). A workflow can be triggered using the Novu [SDK](/platform/sdks/overview) or [API](/api-reference/events/trigger-event).
```typescript
import { Novu } from '@novu/node';
diff --git a/content/docs/platform/integrations/push/(providers)/expo-push.mdx b/content/docs/platform/integrations/push/(providers)/expo-push.mdx
index b8037fc67..25ab0db28 100644
--- a/content/docs/platform/integrations/push/(providers)/expo-push.mdx
+++ b/content/docs/platform/integrations/push/(providers)/expo-push.mdx
@@ -92,7 +92,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Step 2: Send a notification
-Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/build-a-workflow) and trigger it. Novu sends the notification to all devices associated with the subscriber.
+Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/create-a-workflow) and trigger it. Novu sends the notification to all devices associated with the subscriber.
The example below demonstrates a simple trigger using Novu’s SDK.
diff --git a/content/docs/platform/integrations/push/(providers)/onesignal.mdx b/content/docs/platform/integrations/push/(providers)/onesignal.mdx
index bbb82fadf..b2d4f1a63 100644
--- a/content/docs/platform/integrations/push/(providers)/onesignal.mdx
+++ b/content/docs/platform/integrations/push/(providers)/onesignal.mdx
@@ -92,7 +92,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Step 2: Send a notification
-Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/build-a-workflow) and trigger it. Novu sends the notification to all devices (player IDs) associated with the subscriber.
+Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/create-a-workflow) and trigger it. Novu sends the notification to all devices (player IDs) associated with the subscriber.
The example below demonstrates, how to [trigger a workflow](/platform/sdks/server/typescript) using Novu’s SDK.
diff --git a/content/docs/platform/integrations/push/(providers)/push-webhook.mdx b/content/docs/platform/integrations/push/(providers)/push-webhook.mdx
index c00f52bbc..08e38b213 100644
--- a/content/docs/platform/integrations/push/(providers)/push-webhook.mdx
+++ b/content/docs/platform/integrations/push/(providers)/push-webhook.mdx
@@ -86,7 +86,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Step 2: Send a notification
-Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/build-a-workflow) and trigger it. Novu sends the notification payload to the webhook URL that you configured.
+Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/create-a-workflow) and trigger it. Novu sends the notification payload to the webhook URL that you configured.
The example below demonstrates a simple trigger using Novu’s SDK.
diff --git a/content/docs/platform/integrations/push/(providers)/pusher-beams.mdx b/content/docs/platform/integrations/push/(providers)/pusher-beams.mdx
index 6717e2a9c..001aca7af 100644
--- a/content/docs/platform/integrations/push/(providers)/pusher-beams.mdx
+++ b/content/docs/platform/integrations/push/(providers)/pusher-beams.mdx
@@ -89,7 +89,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Step 2: Send a notification
-Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/build-a-workflow) and trigger it. Novu sends the notification to the `userId`'s associated with the subscriber.
+Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/create-a-workflow) and trigger it. Novu sends the notification to the `userId`'s associated with the subscriber.
The example below demonstrates a simple trigger using Novu’s SDK.
diff --git a/content/docs/platform/integrations/push/(providers)/pushpad.mdx b/content/docs/platform/integrations/push/(providers)/pushpad.mdx
index 885a3e4aa..a882d2543 100644
--- a/content/docs/platform/integrations/push/(providers)/pushpad.mdx
+++ b/content/docs/platform/integrations/push/(providers)/pushpad.mdx
@@ -98,7 +98,7 @@ curl -L -X PUT 'https://api.novu.co/v1/subscribers//credentials'
### Step 2: Send a notification
-Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/build-a-workflow) and then trigger it. Novu sends the notification to the `uid`s associated with the subscriber.
+Now you're ready to send a push notification. [Create a workflow with a Push step](/platform/workflow/create-a-workflow) and then trigger it. Novu sends the notification to the `uid`s associated with the subscriber.
The example below demonstrates a simple trigger using Novu’s SDK.
diff --git a/content/docs/platform/integrations/sms/index.mdx b/content/docs/platform/integrations/sms/index.mdx
index 2e69a332f..d98ac7e6b 100644
--- a/content/docs/platform/integrations/sms/index.mdx
+++ b/content/docs/platform/integrations/sms/index.mdx
@@ -24,7 +24,7 @@ To learn [how to add an SMS provider](/platform/integrations/sms#supported-provi
### Add the email channel to your workflow
-Next, include an [SMS step in your workflow](/platform/workflow/build-a-workflow). This step defines when and how an SMS should be sent as part of your notification workflow.
+Next, include an [SMS step in your workflow](/platform/workflow/create-a-workflow). This step defines when and how an SMS should be sent as part of your notification workflow.
### Define the SMS content
diff --git a/content/docs/platform/meta.json b/content/docs/platform/meta.json
index 743a7762b..0871e644f 100644
--- a/content/docs/platform/meta.json
+++ b/content/docs/platform/meta.json
@@ -12,19 +12,15 @@
"...inbox",
"---Integrate ---",
"...subscription",
- "---Building Workflows---",
+ "---Build a Workflow---",
"workflow/overview",
- "workflow/build-a-workflow",
- "workflow/template-editor",
- "workflow/layouts",
- "workflow/channel-steps",
- "workflow/delay",
- "workflow/digest",
- "workflow/throttle-step",
- "workflow/step-conditions",
- "workflow/tags",
- "workflow/translations",
- "workflow/contexts",
+ "workflow/create-a-workflow",
+ "workflow/configure-workflow",
+ "workflow/add-and-configure-steps",
+ "workflow/add-notification-content",
+ "workflow/trigger-workflow",
+ "workflow/monitor-and-debug-workflow",
+ "workflow/advanced-features",
"---Integrate Channels Providers---",
"...integrations",
"---SDKs---",
diff --git a/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/delay.mdx b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/delay.mdx
new file mode 100644
index 000000000..44da6c911
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/delay.mdx
@@ -0,0 +1,115 @@
+---
+pageTitle: 'Configure Delay Step'
+title: 'Configure Delay Step'
+description: 'Learn how to use delay step to pause workflow execution.'
+icon: 'Timer'
+---
+
+import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
+
+After adding a Delay step to a workflow, it pauses workflow execution for a specified duration or until a scheduled time, then resumes execution with the next step. You can add a Delay step anywhere in a workflow, before or after any other step to control when subsequent steps run.
+
+This page focuses on how to configure the Delay step for your use case.
+
+To learn when to use Delay step in a workflow, refer to the [Delay step overview](/platform/workflow/add-and-configure-steps#delay).
+
+## Delivery behavior and scheduling
+
+Delay supports delivery-aware execution:
+- Notifications sent after a delay can respect a subscriber’s delivery schedule.
+- Notifications are delivered using the subscriber’s time zone if a `timezone` attribute is set.
+- If no time zone is available, UTC is used.
+
+
+ Changing the step content after triggering the workflow with delay step will affect the existing pending delayed notification content.
+
+
+## Adding a delay step
+
+You can add a delay step anywhere in a workflow, before or after any other step. When the workflow reaches the delay step, execution pauses for the configured duration and then resumes with the next step.
+
+## Delay types
+
+Delay types are used to define how long the workflow execution should be delayed before proceeding. These delay types are:
+
+### Fixed delay
+
+A fixed delay pauses workflow execution for a static duration. Use this when the delay length is known in advance and does not change.
+
+You can specify fixed delays in seconds, minutes, hours, days, weeks, or months.
+
+
+
+### Scheduled delay
+
+A scheduled delay pauses workflow execution until a specific date and time, based on the subscriber’s time zone.
+
+You can configure scheduled delays to resume execution:
+
+- **Minute**: Resume at a specific minute.
+- **Hour**: Resume at a specific hour and minute.
+- **Day**: Resume at a specific time of day.
+- **Week**: Resume on specific days of the week at a given time.
+- **Month**: Resume on specific days of the month at a given time.
+
+
+
+In the example above, the scheduled delay pauses workflow execution until the current day at either 10:00 AM or 11:00 AM, at 23, 24, or 25 minutes past the hour, based on the subscriber’s time zone.
+
+### Dynamic delay
+
+A dynamic delay, also called a variable-based delay, determines the delay duration using a variable from the event payload. This allows the delay to change per workflow execution.
+
+The variable can be defined in one of the following formats:
+
+- **ISO-8601 timestamp**: Example: `2027-01-01T12:00:00Z`. This value should be for future date and time.
+- **Duration object**: Example: `{ "amount": 30, "unit": "minutes" }`. This value should be for future date and time. Here *amount* is the number of units to delay and *unit* is the time unit. *unit* can be **seconds**, **minutes**, **hours**, **days**, **weeks**, or **months**.
+
+
+
+In this example, the `delayTill` variable is used to pause the workflow until the future date and time specified in the `delayTill` variable.
+
+
+
+
+ ```json
+ {
+ "delayTill": "2027-01-01T12:00:00Z"
+ }
+ ```
+
+
+
+ ```json
+ {
+ "delayTill": {
+ "amount": 30,
+ "unit": "minutes"
+ }
+ }
+ ```
+
+
+
+If a dynamic delay using an ISO date is added as the first step in a workflow, it effectively schedules the workflow execution to start at the specified time.
+
+## Extend to subscriber’s schedule
+
+When enabled, delayed execution respects the [subscriber’s delivery schedule](/platform/inbox/features/schedule).
+
+If the delay completes outside the subscriber’s available delivery window, execution resumes during the next available time slot. This option is disabled by default.
+
+## FAQs
+
+### If delay step fails, will the workflow continue to the next step?
+ No, workflow execution will stop immediately if the delay step fails due to an error. Common errors are:
+ - Invalid ISO date format.
+ - Invalid duration object format.
+ - Past datetime is specified.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/digest.mdx b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/digest.mdx
new file mode 100644
index 000000000..20e965463
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/digest.mdx
@@ -0,0 +1,99 @@
+---
+pageTitle: 'Configure Digest Step'
+title: 'Configure Digest Step'
+description: 'Batch multiple workflow trigger events into a single execution using configurable digest windows and grouping rules.'
+icon: 'Boxes'
+---
+import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
+
+After adding a Digest step to a workflow, Novu batches multiple trigger events and executes downstream steps only once per digest window, instead of once per event.
+
+This page focuses on how to configure the Digest step to fit your use case.
+
+To learn when to use the Digest step in a workflow, refer to the [Digest step overview](/platform/workflow/add-and-configure-steps#digest).
+
+
+
+## Group events by
+
+By default, Digest groups events by `subscriberId`, ensuring that each subscriber receives their own digest.
+
+You can optionally add one additional aggregation key to further group events within a subscriber’s digest. This gives you finer control over how events are batched.
+
+The aggregation key must come from the event payload defined in your [payload schema](/platform/workflow/configure-workflow#payload-schema). For example, if multiple users like different posts, you may want each subscriber to receive separate digests per post by grouping on `payload.postId`.
+
+## Digest window
+
+The Digest window defines how long events are collected before the workflow continues. You can configure the digest window as **Regular** or **Scheduled**.
+
+
+### Regular digest
+
+This allows you to set the amount of time to digest events for. Once the defined time has elapsed, the digested events are sent.
+
+
+#### Control digest duration
+
+You can configure the digest duration from the **Digest events for** field:
+- Seconds
+- Minutes
+- Hours
+- Days
+- Weeks
+- Months
+
+ Maximum digest duration varies based on your plan. For more information, refer to the [limits](/platform/developer/limits) documentation.
+
+#### Control when to start digest
+
+You can also control when digesting begins by selecting any of the following options from the **Start digest** field:
+
+- **Immediately**: Start collecting events as soon as the first event arrives.
+
+- **When events repeat**: Check whether a similar notification was sent recently.
+ - If yes, start a digest.
+ - If not, deliver the notification immediately and skip digesting.
+
+**Available presets:**
+- When events repeat within 5 minutes.
+- When events repeat within 30 minutes.
+- Custom.
+
+This behavior is useful when you want the first notification delivered instantly, while batching subsequent events that occur close together.
+
+### Scheduled digest
+
+A scheduled digest collects events and delivers them at fixed calendar intervals instead of relative durations.
+
+You can schedule delivery:
+- Every minute
+- Every hour
+- Daily
+- Weekly
+- Monthly
+
+
+
+
+Scheduled digests are delivered in the subscriber’s time zone.
+
+
+## Extend to subscriber’s schedule
+
+When enabled, digest delivery respects the subscriber’s delivery schedule.
+
+If the digest window ends outside the subscriber’s available hours, the notification is delayed until the next available time slot. This option is disabled by default.
+
+## FAQs
+
+
+
+ Yes, if scheduled digest is set for 9:00 AM daily then the digest will be sent at 9:00 AM every day without any event triggered.
+
+
+ Both digests are the same in this case.
+
+
+ No, workflow execution will stop immediately if the digest step fails due to an error.
+
+
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/meta.json b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/meta.json
new file mode 100644
index 000000000..aebb79e58
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/meta.json
@@ -0,0 +1,7 @@
+{
+ "title": "Configure Action Steps",
+ "description": "Configure Action Steps",
+ "icon": "Package",
+ "pages": ["delay", "digest", "throttle"],
+ "defaultOpen": false
+}
diff --git a/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/throttle.mdx b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/throttle.mdx
new file mode 100644
index 000000000..9cdba4394
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/configure-action-steps/throttle.mdx
@@ -0,0 +1,61 @@
+---
+pageTitle: 'Configure Throttle Step'
+title: 'Configure Throttle Step'
+description: 'Learn how to use the Throttle step in Novu workflows to control notification frequency.'
+icon: 'Gauge'
+---
+
+After adding a Throttle step to a workflow, it limits the number of times a workflow is allowed to continue within a specified time window b. Once the execution limit is reached, the workflow stops at the Throttle step and downstream steps are skipped.
+
+This page focuses on how to configure the Throttle step.
+
+To learn when to use the Throttle step in a workflow, refer to the [Throttle step overview](/platform/workflow/add-and-configure-steps#throttle).
+
+
+
+## Throttle window
+
+The Throttle window defines the time period in which executions are counted. Within this window, only the specified number of executions are allowed.
+
+In the Throttle step properties panel, you will find the options to set your Throttle Window. You can choose between the fixed or dynamic window.
+
+
+
+### Fixed window
+
+In fixed window, the time frame is predefined in the workflow editor from the **Throttle for** field. You can set a fixed duration of the time window. The time can be set in minutes, hours, or days. The minimum duration is one minute.
+
+You can use this mode when the time window for throttling is constant and known in advance.
+
+### Dynamic window
+
+In dynamic window, the time frame is determined by data sent in the trigger payload. In the **Dynamic window key** field you need to specify the key in the trigger payload that contains the dynamic window configuration. For example, `payload.throttleUntil` or `payload.customWindow`.
+
+The value for the dynamic window key can be provided in one of two formats:
+- **ISO-8601 Timestamp (string)**:
+This format throttles executions until a specific future date and time. Any new triggers before this timestamp will be evaluated against the throttle limit.
+
+ ```json
+ {
+ "throttleUntil": "2025-10-31T23:59:59Z"
+ }
+ ```
+- **Duration object**: This format throttles executions for a duration relative to the time of the first trigger. It follows the same structure as the fixed window configuration.
+
+ ```json
+ {
+ "customWindow": { "amount": 30, "unit": "minutes" }
+ }
+ ```
+
+ Use this mode when the throttle duration or end time needs to be flexible and defined at the time of the trigger. For example, throttle billing alerts until the end of the current billing cycle.
+
+## Execution threshold
+
+You can define the maximum number of workflow executions allowed within the specified time window in the **Execution threshold** field. This defaults to 1. This applies to both fixed and dynamic throttle window.
+
+## Group throttling
+
+By default, all throttling is grouped by the `subscriberId`. The **Group throttling by** field allows you to add a second aggregation key based on a variable from your trigger `payload`. This is useful for creating more throttling rules.
+
+For example, if you want to send a notification for each project a user belongs to, but no more than once a week per project. You can set **Throttle for** to 7 days and **Group throttling by** to `payload.projectId`. This ensures the user receives one alert for Project A and one for Project B within the same week, instead of just one alert total.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-and-configure-steps/index.mdx b/content/docs/platform/workflow/add-and-configure-steps/index.mdx
new file mode 100644
index 000000000..eb0bd5a30
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/index.mdx
@@ -0,0 +1,190 @@
+---
+pageTitle: 'Add and Configure Steps'
+title: 'Add and Configure Steps'
+description: 'Learn how workflow steps work in Novu, the different step types available, and how to add and execute steps in a notification workflow.'
+icon: 'CopyPlus'
+---
+
+import { Card, Cards } from 'fumadocs-ui/components/card';
+import { Bell, Mail, MessageSquare, MessagesSquare, Smartphone } from 'lucide-react';
+
+Steps are the building blocks of a workflow. Each step represents a distinct action or delivery mechanism that determines what happens, when it happens, and how a notification is delivered.
+
+A workflow is built as a sequence of steps, executed linearly from top to bottom. You define and arrange steps using the workflow editor in the Novu dashboard, where each node on the canvas represents a single step in the execution flow.
+
+Each step operates independently. If one step fails, other steps in the workflow can still succeed. Workflows support two types of steps from the Novu dashboard.
+
+
+
+You can create a custom step using Novu Framework. For more information, refer to the [Custom steps](/framework/custom).
+
+## Channel steps
+
+Channel steps deliver notifications to users through supported communication channels. Each channel step includes its own template editor for defining notification content and channel-specific behavior.
+
+Supported channel types include:
+
+
+ }
+ href="/platform/integrations/email"
+ description="Send notifications to your subscribers’ email. Supports layouts, visual block editing, custom HTML, and dynamic data."
+ />
+ }
+ href="/platform/inbox/overview"
+ description="Deliver notifications directly inside your application through the Novu ."
+ />
+ }
+ href="/platform/integrations/push"
+ description="Send notifications to user devices, either mobile, desktop, or web."
+ />
+ }
+ href="/platform/integrations/sms"
+ description="Send notification to your subscribers’ devices."
+ />
+ }
+ href="/platform/integrations/chat"
+ description="Send notifications to chat platforms such as Slack or Microsoft Teams."
+ />
+
+
+To send notifications through Email, Push, Chat, or SMS channels, you must configure the appropriate [channel provider integration](/platform/integrations/overview) for your environment. Without an active integration, messages sent through that channel won’t be delivered.
+
+Novu provides built-in [demo integrations](/platform/integrations/demo-integration) for the Email and SMS channels. These sandboxed providers let you test workflows before configuring a provider.
+
+## Action steps
+
+Action steps introduce logic and flow control into a workflow. They do not send notifications directly, but instead affect when and how downstream steps execute. Action steps are typically placed before or between channel steps to shape delivery behavior.
+
+### Delay
+
+The Delay step pauses workflow execution for a specified duration before continuing to the next step.
+
+Delay is used when timing matters, whether you need to wait a fixed amount of time, resume execution at a scheduled moment, or defer execution based on data from the trigger payload. This is useful for use cases such as:
+
+- Waiting for X amount of time before sending the message.
+- Waiting for a short period before sending a push message in case the user has seen the notification in the Inbox component.
+- Sending a reminder email 24 hours after a user abandons their shopping cart to encourage checkout completion.
+- Sending a follow-up message 3 days after user registration to check if they need onboarding assistance.
+
+**How does Delay work?**
+
+When a workflow reaches a Delay step:
+
+1. Execution pauses for the configured duration or until the scheduled time.
+2. Once the delay condition is satisfied, the workflow continues to the next step.
+3. All downstream steps execute normally unless blocked by conditions or other controls.
+
+Steps placed before the Delay step run immediately. Steps placed after the Delay step run only after the delay completes.
+
+Delay can be added anywhere in a workflow and can be conditionally skipped using step conditions.
+
+To learn how to configure delay types and scheduling behavior, refer to the [Configure Delay Step](/platform/workflow/add-and-configure-steps/action-steps/delay) documentation.
+
+### Digest
+
+The Digest step controls how often downstream steps execute by batching multiple workflow trigger events into a single execution.
+
+Instead of running the workflow once per event, Digest collects events over time, groups them per subscriber, and then allows the workflow to continue once per digest window. Use Digest to
+
+- Prevent over-notifying users during bursts of activity
+- Replace many similar notifications with a single summary
+- Batch repeated events that occur within a short period
+- Deliver notifications on a fixed cadence (for example, daily or weekly summaries)
+
+**How does Digest work?**
+
+When a Digest step is added:
+
+1. Workflow trigger events are collected instead of immediately flowing downstream.
+2. Events are grouped per subscriber (and optional grouping key).
+3. Once the digest window completes, the workflow continues once, with the aggregated events available as context.
+
+
+
+Steps placed before the Digest step execute in real time. Steps placed after the Digest step execute only when the digest duration is completed.
+
+
+
+ Learn how to configure Digest windows, group rules, and schedule behavior.
+
+
+ Learn how to use the result from a Digest step to personalize content in the channel step editor.
+
+
+
+### Throttle
+
+The Throttle step lets you limit the number of workflow executions within a specified time window. You can configure throttling directly in Novu workflow editor. By setting limits, you can prevent subscribers from receiving duplicate or excessive notifications when a trigger fires repeatedly.
+
+
+
+
+Some use cases for this include:
+- Limiting high-frequency alerts (such as CPU or billing usage checks) to one notification per hour, day, or week.
+- Preventing duplicate messages from automated cron jobs or recurring triggers.
+- Controlling notification frequency for subscribers who belong to multiple projects or contexts.
+
+**How does Throttle work?**
+
+At a high level, the throttle step counts the number of times a workflow is triggered for a specific subscriber.
+
+- If the count is within the defined execution threshold for the time window, then the workflow proceeds as normal.
+- If the count exceeds the threshold, then the workflow execution is halted at the throttle step. Any steps placed after the throttle step in your workflow will not be run. For example, if you have an email step following a throttle step, then that email will not be sent once the limit is reached.
+ 
+
+Throttling applies consistently across channels, whether the workflow sends email, in-app, SMS, chat, or push notifications.
+
+The throttle step applies to all workflows, including those marked as critical. If a critical workflow is triggered more frequently than the throttle limit allows, then it will be skipped just like any other workflow. This ensures that even high-priority alerts do not overwhelm a subscriber.
+
+To the subscriber, the experience is transparent. They are not aware that any throttling has occurred; they either receive a notification or they don’t. The subscriber is never exposed to information about the throttle itself.
+
+To learn how to configure throttle windows, thresholds, and grouping behavior, refer to the [Configure Throttle Step](/platform/workflow/add-and-configure-steps/action-steps/throttle) documentation.
+
+## Add a step to a workflow
+
+You add steps from the Workflow Editor when building or editing a workflow.
+
+The first step in every workflow is the Workflow Trigger, which represents the event that starts the workflow.
+
+To add steps:
+1. Open a workflow in the Workflow Editor.
+2. Click the **+** (Add step) icon at the desired position.
+3. Select a step type from the available options.
+4. Configure the step if required.
+
+
+
+You can add multiple steps and reorder them at any time to change the execution flow.
+
+## How steps execute
+
+When a workflow is triggered:
+
+- Steps execute sequentially, from top to bottom.
+- Each step receives the same workflow payload.
+- A step must complete before the next step begins.
+
+This execution model allows you to build complex notification sequences that adapt to timing, user behavior, and delivery requirements such as:
+
+1. Send an in-App message.
+2. Wait 24 hours (Delay).
+3. If the in-app message is unread, send an email.
+4. If the subscriber is a premium user, then follow up with an SMS message.
+
+This allows Novu workflows to adapt to user behavior and preferences while keeping the configuration visual and testable.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-and-configure-steps/meta.json b/content/docs/platform/workflow/add-and-configure-steps/meta.json
new file mode 100644
index 000000000..d1f7cc8d7
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/meta.json
@@ -0,0 +1,4 @@
+{
+ "pages": ["configure-action-steps", "step-conditions"],
+ "defaultOpen": false
+}
diff --git a/content/docs/platform/workflow/add-and-configure-steps/step-conditions.mdx b/content/docs/platform/workflow/add-and-configure-steps/step-conditions.mdx
new file mode 100644
index 000000000..00419fd58
--- /dev/null
+++ b/content/docs/platform/workflow/add-and-configure-steps/step-conditions.mdx
@@ -0,0 +1,148 @@
+---
+title: 'Step Conditions'
+description: 'Create dynamic notification workflows using rule-based conditions. Control message delivery based on subscriber, payload, and workflow data.'
+icon: 'ListFilter'
+---
+
+import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
+
+Step conditions let you control whether a workflow step runs or is skipped. They allow you to build adaptive notification flows that respond to subscriber attributes, payload schema data, and outcomes from previous steps.
+
+Conditions are configured per step and apply to both channel steps and action steps. This allows you to introduce branch logic into a workflow without duplicating steps or creating separate workflows.
+
+## Add step conditions
+
+You configure step conditions from the Workflow Editor.
+
+1. Select a step in the Workflow Editor.
+2. In the **Configure** step panel, click **Step Conditions**.
+ 
+3. Proceed to add your step conditions.
+
+
+
+If the condition evaluates to `true`, the step runs. If it evaluates to `false`, the step is skipped and the workflow continues.
+
+## How the condition builder works
+
+The step condition builder is rule-based and composed of three core elements:
+
+- **Logical operators**: Choose **AND** or **OR** to define how conditions are evaluated.
+- **Conditions**: Individual rules that compare a field, an operator, and a value.
+- **Condition groups**: Nested groups that allow more complex logic.
+
+In the UI, you’ll see:
+- **AND / OR** selector buttons
+- **+ Add condition** to add a rule
+- **Add group** to create nested condition groups
+
+This structure allows you to model both simple checks and complex branching logic.
+
+## Supported operators
+
+ The condition builder supports a wide range of comparison operators:
+
+
+ | Operator | Description | Example |
+ | --------------------- | --------------------------------------- | ----------------------------------------------- |
+ | `=` | Equal to | `subscriber.locale = "en-US"` |
+ | `!=` | Not equal to | `subscriber.isOnline != true` |
+ | `<` | Less than | `payload.totalAmount < 100` |
+ | `>` | Greater than | `payload.totalAmount > 100` |
+ | `<=` | Less than or equal to | `payload.totalAmount <= 200` |
+ | `>=` | Greater than or equal to | `payload.totalAmount >= 200` |
+ | `contains` | Contains a substring | `payload.orderId contains "123"` |
+ | `begins with` | Starts with | `subscriber.firstName begins with "J"` |
+ | `ends with` | Ends with | `subscriber.email ends with "@xyz.com"` |
+ | `does not contain` | Does not contain a substring | `payload.orderId does not contain "456"` |
+ | `does not begin with` | Does not start with | `subscriber.firstName does not begin with "M"` |
+ | `does not end with` | Does not end with | `subscriber.lastName does not end with "Smith"` |
+ | `is null` | Is null | `subscriber.phone is null` |
+ | `is not null` | Is not null | `subscriber.email is not null` |
+ | `in` | Matches one of several values | `subscriber.locale in ["en-US", "es-ES"]` |
+ | `not in` | Does not match any of the listed values | `subscriber.locale not in ["fr-FR", "de-DE"]` |
+ | `between` | Within a range | `payload.totalAmount between [50, 200]` |
+ | `not between` | Outside of a range | `payload.totalAmount not between [0, 50]` |
+
+
+## Data used for step conditions
+
+Step conditions can evaluate data from several sources. Choose the source that best represents the decision you’re trying to make.
+
+### Subscriber data
+
+Step conditions can use subscriber fields to tailor notifications based on user-specific data. For example, you can send an SMS only to users whose `subscriber.isOnline` is `false`.
+
+To learn more about Subscribers model, refer to the [Subscribers documentation](/platform/concepts/subscribers)
+
+### Payload data
+
+You can use data from the [payload schema](/platform/workflow/configure-workflow#payload-schema) or custom payload data passed during the workflow trigger call to the Novu API to configure step conditions. This allows you to define dynamic rules based on the data unique to each workflow execution.
+
+Example payload data:
+
+```json
+{
+ "orderId": "12345",
+ "totalAmount": 150,
+ "orderStatus": "completed"
+}
+```
+
+You can configure conditions such as:
+
+- `payload.orderStatus = "completed"`
+- `payload.totalAmount > 100`
+
+### Workflow variables
+
+You can base conditions on workflow variables. These variables provide metadata about the workflow being executed and allow you to add conditional logic.
+
+
+
+The following workflow variables are available:
+- `{{workflow.name}}`: The name of the workflow.
+- `{{workflow.description}}`: The description of the workflow.
+- `{{workflow.tags}}`: An array of tags associated with the workflow.
+- `{{workflow.severity}}`: The severity level (high, medium, low, none) of the workflow.
+- `{{workflow.workflowId}}`: The unique identifier of the workflow.
+
+### Previous step result
+
+For workflows involving sequential steps, conditions can also depend on the outcome of a previous step. For example, if the prior step was an in-app notification, then the condition could check:
+
+- `steps.in-app-step.seen`
+- `steps.in-app-step.read`
+- `steps.in-app-step.lastSeenDate`
+- `steps.in-app-step.lastReadDate`
+
+This can be used for follow-up notifications. For instance, send an email only if the in-app notification was not read within 24 hours.
+
+### Context
+
+You can use context variables in the **Step conditions** tab of a workflow step to add conditional logic to your notifications.
+
+To learn more about context, refer to the [Context documentation](/platform/workflow/advanced-features/contexts).
+
+### Dynamic data fields
+
+The **value** field in a condition can also be a dynamic data field. This allows you to compare two data points dynamically rather than using static values.
+
+For example:
+
+```json
+{
+ "operator": "AND",
+ "conditions": [
+ {
+ "field": "payload.foo",
+ "operator": "=",
+ "value": "{{payload.bar}}"
+ }
+ ]
+}
+```
+
+In this case, the step will execute only if `payload.foo` is equal to `payload.bar` at runtime. This enables flexible condition logic based on real-time data comparisons.
+
+For more complex scenarios where you need to perform advanced calculations based on your application state, you can use the [Novu Framework](/framework/typescript/steps).
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-notification-content/channels-template-editors.mdx b/content/docs/platform/workflow/add-notification-content/channels-template-editors.mdx
new file mode 100644
index 000000000..20c1f8e01
--- /dev/null
+++ b/content/docs/platform/workflow/add-notification-content/channels-template-editors.mdx
@@ -0,0 +1,278 @@
+---
+pageTitle: 'Channels Template Editors'
+title: 'Channels Template Editors'
+description: 'Learn how to design and configure notification content for email, in-app, push, and SMS.'
+icon: 'LayoutPanelTop'
+---
+
+import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
+
+The channel template editors are where you define the content of the notification that is delivered to your subscribers when a workflow runs.
+
+Each channel exposes an editor aligned with how messages are delivered on that channel:
+
+- **SMS and chat**: Body field only
+- **Push, email, and in-app**: Subject and body fields
+
+All editors (including the Subject field editors) support variables and dynamic data that can be used to [personalize notification content](/platform/workflow/add-notification-content/personalize-content). Notification preview is also supported on all editors.
+
+While some channel editors share common features, some channels expose additional channel-specific features that can be used to configure and customize the notification content for that channel.
+
+Variables autocomplete is supported in all channel template editors
+
+## In-app template editor
+
+The in-app template editor defines how notifications appear inside your application through the Novu {``}. In-app notifications are UI-driven, not just message-driven. This means that the template is responsible for both content and interaction.
+
+To learn how in-app notifications are rendered and displayed in your application, see the {``} documentation.
+
+The template editor lets you control what users see, how they act on it, and how it appears in your application and consists of the following configurable fields:
+
+
+
+### Disable content sanitization
+
+By default, Novu sanitizes both the subject and body fields to prevent unsafe HTML from being rendered. This includes sanitizing:
+
+- Suspicious HTML tags.
+- HTML entities such as `<`, `>`, and `&`.
+
+You should only disable content sanitization when:
+
+- You fully trust the trigger payload.
+- You control all dynamic data sources.
+
+ Disabling sanitization can expose your application to security risks such as XSS attacks. Only disable this option when using trusted data sources.
+
+### Avatar customization
+
+You can control how the notification avatar is displayed using one of the following methods:
+- Provide a custom avatar URL.
+- Select from the available built-in icons.
+
+
+
+### Action buttons
+
+In-app notifications support primary and secondary actions. For each action, you can configure:
+
+- Button text
+- Redirect URL
+- Navigation targets (`_self`, `_blank`, `_parent`, `_top`, and `_unfencedTop`)
+
+
+
+Actions allow users to respond directly from the Inbox without navigating elsewhere in the UI.
+
+### Redirect URL
+
+The redirect URL defines where the user is navigated when the notification itself is clicked.
+
+You can:
+
+- Define a static or dynamic URL.
+- Control navigation behavior using targets.
+- Omit the redirect URL and handle clicks using the `onNotificationClick` handler in the {``} component.
+
+This enables full control over client-side navigation behavior.
+
+### Data object
+
+The data object is a customizable key-value store available in the in-app step. You can use it to extend each Inbox component notification by embedding custom data.
+
+To learn more about how to use the data object to customize how messages appear in the {``}, refer to the [Data Object](/platform/inbox/configuration/data-object) documentation.
+
+## Email template editor
+
+The email template editor defines how email notifications are structured, rendered, and delivered. Novu dashboard provides multiple authoring modes:
+
+You can submit custom HTML email templates via the Novu API. This method supports workflows where you render templates externally and use Novu purely for delivery.
+
+### Block editor
+
+The block editor is a `WYSIWYG` editor that allows you to create and edit email templates. It has two fields: subject and body.
+
+A block can be added by clicking on the plus (+) icon in the top-left corner of body field or by adding a forward slash (`/`). In both cases, a menu appears with the list of supported blocks:
+
+
+
+
+
Blockquote
+
Bullet List
+
Button
+
Cards
+
Columns
+
Custom HTML code
+
Divider
+
Footers
+
Hard Break
+
Headers
+
Heading 1
+
Heading 2
+
Heading 3
+
Image
+
Inline Image
+
Numbered List
+
Repeat
+
Section
+
Spacer
+
Text
+
+
+
+
+You can duplicate or delete blocks using the block menu controls.
+
+Once you switch from block editor to code editor, you can’t go back to the block editor unless you reset the template.
+
+#### Custom HTML block
+
+The custom HTML block allows you to insert raw HTML inside a block editor layout.
+
+- Allows injecting variables using `{{ ... }}`
+- Supports LiquidJS control structures like `{% for %}` or `{% if %}`
+
+Use this block when you need inline markup control within a visual layout, but don't require full LiquidJS logic.
+
+#### Repeat block
+
+The repeat block lets you iterate over an array and render its child blocks for each item in that array. It works similarly to a JavaScript `for` loop and is used for displaying structured or repeated data such as order items, activity feeds, or grouped records.
+
+When the workflow runs, Novu evaluates the array you provide and repeats the block’s content for every element, allowing you to build dynamic lists.
+
+
+
+In the video above, the repeat block iterates over the following array:
+
+- `{{payload.order.items}}` is the array containing the items in an order.
+
+Within the repeat block, each item in the array becomes the current iteration context, which allows you to reference item-level properties directly. For example:
+
+- `{{payload.order.items.name}}`
+- `{{payload.order.items.price}}`
+
+This approach ensures each item in the array is rendered with its own data, making the Repeat block ideal for building dynamic, data-driven content.
+
+#### Show block conditionally
+
+The show block conditionally feature lets you control whether a content block is rendered based on runtime data. It allows you to show or hide specific parts of a template using conditions evaluated against subscriber properties or payload variables when the workflow runs.
+
+This is useful for keeping templates flexible and avoiding duplicated layouts, for example, showing a call-to-action only when it’s relevant to the recipient.
+
+The feature is supported by the following blocks:
+- Button block
+- Custom HTML block
+- Image block
+- Repeat block
+
+In the editor, conditional visibility is accessed using the **eye icon** on a supported block. When enabled, you define a condition that determines whether the block is rendered.
+
+For example, you can display a **Track your order** button only when a subscriber has a custom data field `showTracking` set to `true`. You can apply the same logic using payload variables passed when triggering the workflow, allowing content to adapt dynamically to each notification.
+
+
+
+#### Digest block
+
+The Digest block allows you to loop over the events collected by your digest step and displays them in your email content. It handles both layout and repetition automatically.
+
+The Digest block is only available in Email steps that come after a Digest step in the workflow.
+
+When you add a digest block to your email template editor:
+- Novu automatically inserts a Repeat block that iterates over the digested events.
+- You can define how many times the event is iterated.
+- Inside the loop, you can also use the special alias variable `current` to reference the item currently being processed, for example, `current.payload.name`.
+- The block also supports rendering a summary using the `steps.digest-step.eventCount` variable, typically with the pluralize LiquidJS filter.
+
+
+
+To learn more about using digested data and digest-related variables in templates, see the [Personalize Content](/platform/workflow/add-notification-content/personalize-content) documentation.
+
+### Code editor (Custom HTML)
+
+The code editor provides a built-in interface for writing raw HTML and embedding LiquidJS expressions directly inside the Novu dashboard. This gives you full control over layout, structure, and rendering beyond the capabilities of Novu's block editor.
+
+The editor supports advanced use cases such as:
+- Migrating existing HTML email templates
+- Implementing full design systems
+- Executing flow control logic directly inside email templates
+- Complete layout and styling freedom without editor constraints
+
+
+
+Switching from code editor to the block editor will reset your code.
+
+### Email layouts
+
+Layouts are reusable components used with email steps in the workflow, designed to bring consistency, maintainability, and efficiency to your email communications. With layouts, you can create a component using headers, footers and other branding elements and reuse that component across multiple email steps.
+
+Every layout must include the `{{content}}` variable. This variable dynamically injects the content of the email step.
+
+ On the Free plan, only one layout can be created per environment. Pro and higher plans support up to 100 layouts per environment. If you need more than 100 layouts, please [contact Support](mailto:support@novu.co).
+
+#### Layout features
+
+- Reusable across workflows.
+- Support both block and code editors.
+- Each environment maintains its own set of layouts.
+- Supports variables and translations.
+
+Payload variables are not supported in layouts because one layout can be used across multiple workflows and workflows can have strict payload schema validation.
+
+#### Apply an email layout to a workflow
+
+1. Navigate to [Workflows page](https://dashboard.novu.co/workflows) on Novu dashboard.
+2. Select a workflow from the list.
+3. Select an email step.
+4. Choose your layout from the Layout selector.
+
+
+
+The selected layout wraps around the content written in the email editor.
+
+#### Manage email layouts
+
+Email layouts are managed from the **Layouts** section of the Novu dashboard. From here, you can create, edit, delete, and reuse layouts across workflows.
+
+
+
+**Create an email layout**
+
+1. Navigate to the Layout page on Novu dashboard.
+2. Click on the **Create layout** button on the top right corner.
+3. Fill in:
+ - **Layout name**: Provide a human-readable name.
+ - **Identifier**: Provide a unique ID. Novu generates one automatically if you do not provide it. You cannot change the identifier after it is created.
+4. (Optional) Enable [translations](/platform/workflow/translations) for the layout.
+5. Click **Create layout**.
+
+A new layout is created and can be edited using either the block editor or the code editor.
+
+**Edit email layout**
+
+1. Navigate to Layout page on Novu dashboard.
+2. Select a layout from the list.
+3. To update the layout name or enable translations, click the **cog** icon in the editor.
+
+4. Modify the layout content using the block or code editor.
+5. Click **Save changes**.
+
+Changes apply immediately to all workflows using the layout.
+
+**Delete an email layout**
+
+Deleting a layout is permanent and cannot be undone.
+1. Navigate to Layout page on Novu dashboard.
+2. Select a layout from the list.
+3. Click the cog icon in the layout editor.
+4. Click **Delete layout** and confirm. If the layout is used by an email step, then you are notified on which step uses this layout.
+
\ No newline at end of file
diff --git a/content/docs/platform/workflow/add-notification-content/meta.json b/content/docs/platform/workflow/add-notification-content/meta.json
new file mode 100644
index 000000000..41c2acfa6
--- /dev/null
+++ b/content/docs/platform/workflow/add-notification-content/meta.json
@@ -0,0 +1,6 @@
+{
+ "title": "Add Notification Content",
+ "description": "Workflows",
+ "icon": "Package",
+ "pages": ["channels-template-editors", "personalize-content"]
+}
diff --git a/content/docs/platform/workflow/add-notification-content/personalize-content.mdx b/content/docs/platform/workflow/add-notification-content/personalize-content.mdx
new file mode 100644
index 000000000..37ba3da82
--- /dev/null
+++ b/content/docs/platform/workflow/add-notification-content/personalize-content.mdx
@@ -0,0 +1,236 @@
+---
+pageTitle: 'Personalize Content'
+title: 'Personalize Content'
+description: 'Learn how to personalize notification content in Novu using template variables, context data, and LiquidJS filters across all channel template editors.'
+icon: 'UserRoundCog'
+---
+
+import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
+
+Novu allows you to personalize notification content in all channel template editors using variables, conditional logic, and runtime data. This enables you to generate notifications that adapt to each subscriber and reflect the data available at the time a workflow is executed.
+
+## Template variables
+
+Template variables are placeholders that are resolved at workflow execution time and replaced with actual values when a notification is rendered. They allow templates to reference data from the workflow trigger payload, subscriber profile, workflow metadata, and outputs from previous steps.
+
+To insert a variable into a notification template, use double curly braces:
+
+```liquid
+{{variable_name}}
+```
+
+Variables also support nested objects and arrays. Use dot notation to access nested values:
+
+```liquid
+{{ variable_name.customer.name }}
+{{ variable_name.customer.email }}
+
+```
+
+Template variables can be used anywhere content is supported. They can be rendered directly, formatted using LiquidJS filters, or used within conditional logic and loops to control how content is displayed.
+
+You can [configure all template variables](/platform/workflow/add-notification-content/personalize-content#configure-variables) from the template editor to fit your use case.
+
+### Payload variables
+
+Payload variables represent the structured data available to a workflow through its payload schema. This payload data can originate from the event trigger or be defined and managed directly in the workflow’s payload schema.
+
+Payload variables are accessed using the `payload` namespace:
+```liquid
+{{ payload.propertyName }}
+```
+
+For example, if your payload schema defines the following fields:
+```json
+{
+ "orderId": "string",
+ "amount": "number",
+ "currency": "string"
+}
+```
+
+You can reference them in your notification templates as:
+```liquid
+Order {{ payload.orderId }} totaling {{ payload.amount }} {{ payload.currency }} has been confirmed.
+```
+
+Payload variables provide a stable, predictable interface for dynamic data in your templates. By defining them in the payload schema, you ensure that all templates, step conditions, and action configurations reference a consistent set of fields.
+
+ To learn how payload data is defined and validated, see the [Payload schema](/platform/workflow/configure-workflow#payload-schema) documentation.
+
+### Subscriber variables
+
+Subscriber variables expose data associated with the recipient of a notification. They allow you to personalize message content based on who the notification is for, making each delivery feel contextual and relevant.
+
+Subscriber variables are accessed using the `subscriber` namespace:
+```liquid
+{{ subscriber.propertyName }}
+```
+
+You can reference both standard subscriber fields and custom subscriber attributes stored on the subscriber profile.
+
+Standard fields include commonly used properties such as `subscriber.firstName`, `subscriber.lastName`, and `subscriber.email`. Custom attributes are stored under the `data` object and can be accessed using `subscriber.data.*`.
+
+```liquid
+Hi {{ subscriber.firstName }},
+
+You've been upgraded to the {{ subscriber.data.plan }} plan.
+
+Thanks,
+The Novu Team
+```
+
+ To learn more about subscriber metadata and profile structure, refer to the [Subscriber documentation](/platform/concepts/subscribers#subscriber-metadata-and-profile-structure).
+
+### Workflow variables
+
+Workflow variables provide access to metadata defined on the workflow that is being executed such as the workflow:
+- Severity level
+- Tags
+- Name
+- Description
+- Workflow identifier
+
+This workflow data can be used in the templates editor to personalize message content. Workflow variables are accessed using the `workflow` namespace:
+
+```html
+
This is a {{workflow.severity}} priority message regarding your account.
+```
+
+### Digest variables
+
+Digest variables expose the data produced by a Digest step and are available to all channel steps that run after that digest step. They allow you to summarize, list, or otherwise represent multiple events that were grouped during the digest window.
+
+Digest variables are accessed under the `steps` namespace and are scoped to the specific digest step.
+
+ Digest variables are only available in steps that follow a Digest step. They are not available before the digest runs.
+
+Digest support is split into two categories:
+
+- Digest step variables: Raw values produced by the digest step
+- Digest template helpers: Preformatted helpers built on top of those raw values
+
+The step variables expose data, while template helpers optimize for common notification use cases.
+
+#### Digest step variables
+
+Digest step variables expose the underlying data collected during the digest window. These variables hold values only.
+
+- **steps.digest-step.events**: The `steps.digest-step.events` variable is an array that contains all the events collected by the digest step. Each item in the array represents a digested event, including the payload with which the workflow was triggered.
+ ```liquid
+ {{steps.digest-step.events}}
+ ```
+
+ You can loop through it to build dynamic message lists, such as comment summaries or blog post digests, or use LiquidJS filters.
+
+- **steps.digest-step.eventCount**: The `steps.digest-step.eventCount` variable holds the total number of events collected during the digest step window.
+ ```liquid
+ {{steps.digest-step.eventCount}}
+ ```
+ It is an integer value and can be used directly in the template editor or passed into LiquidJS filters like pluralize to generate grammatically correct summaries.
+
+#### Digest template helpers
+
+Digest template helpers are preconfigured template variables designed to simplify common digest use cases. Internally, they are built by combining digest step variables with LiquidJS filters.
+
+They exist to reduce template complexity and eliminate repetitive logic.
+
+- **steps.digest-step.countSummary**: The `countSummary` variable returns a human-readable summary of the total number of digested events with correct pluralization applied.
+
+ This helper is built using `steps.digest-step.eventCount` and the LiquidJS `pluralize` filter. When used, it inserts logic equivalent to:
+
+ ```liquid
+ {{ steps.digest-step.eventCount | pluralize: 'notification' }}
+ ```
+
+ For example, if the digest collected five events, then the output would be:
+
+ ```text
+ 5 notifications
+ ```
+
+ You can use this helper when you want a concise count without manually managing plural rules.
+
+- **steps.digest-step.sentenceSummary**: The `sentenceSummary` variable returns a sentence-style string listing key items from the digested events array, such as a list of names, and gracefully handles formatting depending on the number of items present.
+
+ This helper is built using `steps.digest-step.events` and the LiquidJS `toSentence` filter. When the `sentenceSummary` variable is used in the template editor, it inserts logic equivalent to:
+ ```liquid
+ {{ steps.digest-step.events | toSentence: 'payload.name', 3, 'others' }}
+ ```
+ If the events contain names "Radek", "Dima", and five more users, then the result would be:
+
+ ```text
+ Radek, Dima, and 5 others
+ ```
+
+ You can configure the `toSentence` filter from the template editor by passing:
+ - A key path to extract from each item, for example, `payload.name`. This is a required argument.
+ - The number of items to display before collapsing.
+ - The suffix to use for remaining items, for example, "others".
+
+### Context variables
+
+Context variables come from context data. Once a context is created either through the Novu dashboard or API, its data becomes available in all channel template editors and can be referenced using the context namespace.
+
+
+```liquid
+{{ context.* }}
+```
+
+Context variables are typically used for tenant details, branding and configuration that should not live in the workflow payload or data shared amongst different entities in Novu.
+
+To learn how to create and manage context data, and how to use the context data in the template editor, refer to [Context](/platform/workflow/advanced-features/contexts).
+
+## Apply logic with LiquidJS
+
+All Novu template editors support LiquidJS. This allows you to add logic and control flow to your notification content, including conditional rendering, iteration, and value transformation directly inside channel template editors.
+
+Autocomplete suggestions are not available inside control statements like `{% if %}` or `{% for %}`.
+
+### Conditional rendering
+
+You can use the conditional statements in LiquidJS `if-else` statements to control whether content is shown based on a condition.
+
+```liquid
+{% if subscriber.data.plan == 'enterprise' %}
+ You have access to priority support.
+{% endif %}
+```
+
+When comparing string values in Liquid conditional statements, always use single quotes (`'value'`). Double quotes (`"value"`) are not supported.
+
+### Iteration and loops
+
+You can loop over arrays using `{% for %}` loop. This is useful when rendering lists of items, events, or grouped data.
+
+```liquid
+{% for item in payload.order.items %}
+ - {{ item.name }} ({{ item.price }})
+{% endfor %}
+```
+
+### Filters and transformations
+
+You can use filters to transform values before rendering them. Filters are applied using the pipe (`|`) symbol and can be chained.
+
+```liquid
+Your workspace {{ payload.workspaceName | upcase }} has been successfully created.
+```
+
+## Configure variables
+
+Novu provides a built-in variable configuration UI in the template editor that allows you to apply LiquidJS filters to variable output.
+
+
+
+When you insert a variable into the template editor, click the variable to open the configuration menu.
+
+
+
+From this menu, you can:
+- Apply Liquid filters
+- Reorder applied filters
+
+The filter input also provides filter suggestions, making it easier to discover and apply available filters. You can apply one or more filters to control how the variable value is rendered in your notification content.
+
+Filters are applied top to bottom, meaning the output of one filter becomes the input for the next. You can reorder filters using drag and drop to change the execution order.
diff --git a/content/docs/platform/workflow/contexts/contexts-in-workflows.mdx b/content/docs/platform/workflow/advanced-features/contexts/contexts-in-workflows.mdx
similarity index 97%
rename from content/docs/platform/workflow/contexts/contexts-in-workflows.mdx
rename to content/docs/platform/workflow/advanced-features/contexts/contexts-in-workflows.mdx
index b2dafd762..7092b5de1 100644
--- a/content/docs/platform/workflow/contexts/contexts-in-workflows.mdx
+++ b/content/docs/platform/workflow/advanced-features/contexts/contexts-in-workflows.mdx
@@ -53,7 +53,7 @@ Your account is on the {{context.tenant.data.plan}} plan.
You can use context variables in the **Step conditions** tab of a workflow step to add conditional logic to your notifications. For example, only send a "Feature X is now enabled" email if `context.tenant.data.plan` is `enterprise`.
-To learn how contexts are structured or how to define them, refer to the [Managing Contexts](/platform/workflow/contexts/manage-contexts) documentation.
+To learn how contexts are structured or how to define them, refer to the [Managing Contexts](/platform/workflow/advanced-features/contexts/manage-contexts) documentation.
## Viewing and debugging contexts
diff --git a/content/docs/platform/workflow/contexts/index.mdx b/content/docs/platform/workflow/advanced-features/contexts/index.mdx
similarity index 100%
rename from content/docs/platform/workflow/contexts/index.mdx
rename to content/docs/platform/workflow/advanced-features/contexts/index.mdx
diff --git a/content/docs/platform/workflow/contexts/manage-contexts.mdx b/content/docs/platform/workflow/advanced-features/contexts/manage-contexts.mdx
similarity index 100%
rename from content/docs/platform/workflow/contexts/manage-contexts.mdx
rename to content/docs/platform/workflow/advanced-features/contexts/manage-contexts.mdx
diff --git a/content/docs/platform/workflow/contexts/meta.json b/content/docs/platform/workflow/advanced-features/contexts/meta.json
similarity index 100%
rename from content/docs/platform/workflow/contexts/meta.json
rename to content/docs/platform/workflow/advanced-features/contexts/meta.json
diff --git a/content/docs/platform/workflow/advanced-features/meta.json b/content/docs/platform/workflow/advanced-features/meta.json
new file mode 100644
index 000000000..164d9d189
--- /dev/null
+++ b/content/docs/platform/workflow/advanced-features/meta.json
@@ -0,0 +1,6 @@
+{
+ "title": "Advanced Features",
+ "description": "Advanced Features",
+ "icon": "Sparkles",
+ "pages": ["translations", "contexts"]
+}
diff --git a/content/docs/platform/workflow/translations.mdx b/content/docs/platform/workflow/advanced-features/translations.mdx
similarity index 100%
rename from content/docs/platform/workflow/translations.mdx
rename to content/docs/platform/workflow/advanced-features/translations.mdx
diff --git a/content/docs/platform/workflow/build-a-workflow.mdx b/content/docs/platform/workflow/build-a-workflow.mdx
deleted file mode 100644
index fb5b054f9..000000000
--- a/content/docs/platform/workflow/build-a-workflow.mdx
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: 'Build a Workflow'
-description: 'Learn how to build a Novu Workflow'
-icon: 'Wrench'
----
-
-
-
- This is where you can find and manage your existing workflows.
-
-
- This will open the initial workflow creation screen.
- Here you define:
- - Name of the workflow
- - This is also referred to as the workflow `Identifier`
- - Tags (optional)
- - Description of the workflow (optional)
- - Enable [translations](/platform/workflow/translations) (optional)
-
- Once you've filled in the required fields, click **Create Workflow**.
-
-
-
- This is where you can start adding steps to your workflow. The first step will always be the **"Workflow Trigger"**.
-
- You can add the following steps by clicking on **+** which is the add step icon :
-
- **Channels**
- - Email
- - In-app
- - Push
- - Web push
- - Mobile push
- - Chat
- - Enterprise messaging platforms (e.g. Slack, Microsoft Teams, etc.)
- - Consumer messaging tools (e.g. WhatsApp, Telegram, Discord, etc.)
- - SMS
-
-
- If a channel step you've added is not configured in your Novu account, you'll see an Error.
-
-
- **Actions**
- - Digest
- - Delay
- - Custom (Coming soon, currently only available in the [Novu Framework](/framework/custom))
-
-
-
- Each step in the workflow requires a template that defines the notification or message content and payload. The editor enables you to preview the rendered output of your content.
-
- **Content creation and templates**
-
- - Each channel step has its own template configuration options, tailored to the limitations and requirements of the specific channel.
- - The editor provides a live preview to show how the final message will appear.
- - You can use system variables for personalization, including:
- - Subscriber variables: firstName, lastName, email, phone, avatar.
- - Actor variables: for details about the event initiator.
- - Step variables: for data specific to the workflow execution.
- - Brand variables: for aligning with your organization's visual identity.
- - Tenant variables: for organization-specific data.
-
-**Dynamic content**
-
- - Inject dynamic data into your templates using payload variables.
- - These variables can be utilized in message content, subjects, and sender names for enhanced personalization.
-
-**Important:** When using dynamic content with payload variables, ensure that the required payload is passed when triggering the workflow.
-
-
- Once you've finished configuring your template, don't forget to click the `Save step` button to apply your changes.
-
-
-
-
-
- There are three main ways to trigger a workflow:
-
-- **Via the Novu Dashboard**
- This method is ideal for conducting quick tests directly from the Dashboard. It's a simple and convenient way to verify basic functionality.
-- **Using the trigger code snippet**
- Copy the code snippet and execute it in your local environment or an online sandbox. This approach allows for more thorough testing, enabling you to integrate the trigger with your application logic and live data for a realistic evaluation.
-- **Integrating the trigger in your application**
- Once all tests are complete, you can implement the trigger method directly in your application. This allows you to test the workflow in a real-world scenario, ensuring it functions seamlessly with your app's actual environment and users.
-
-
-
-
-Novu operates in a multi environment setup, with the currently available environments:
-
-- **Development**: Acts as a staging and test environment, where your non-technical peers can view and modify controls.
-- **Production**: For triggering workflows to your customers.
-
-After you've tested your workflow in the **Development** environment, you can promote it to **Production**.
-
-[Learn more about promoting workflows to production](/framework/deployment/production)
-
-
-
-
-## Manage payload schema
-
-The Payload Schema in Novu allows you to define, manage, and validate the structure of incoming data for each workflow. By creating a schema, you ensure that dynamic payloads sent to workflows are predictable, type-safe, and consistent across environments.
-
-Novu’s payload schema is based on the [JSON Schema](https://json-schema.org/) standard.
-
-With a defined schema in place, you can:
-- Prevent unexpected runtime errors caused by invalid or missing data.
-- Build reliable conditional logic using type-aware operators.
-- Generate accurate previews powered by intelligent mock data.
-- Enable autocomplete suggestions when referencing payload variables.
-
-The schema acts as a contract between your systems and Novu, ensuring that every payload sent into your workflow conforms to expected rules. It provides your team with clear visibility into which variables exist, how they’re structured, and what validations are applied.
-
-Payload schemas are especially useful when building complex workflows that rely on dynamic content, reusable blocks, or strict validation requirements.
-
-### Define workflow schema
-
-You can define the expected payload schema in three ways: manually, by importing a JSON sample, or by creating inline variables. When adding or editing a schema property, you can mark it as required.
-
-
- If a property is marked as required, then it must be included in the payload when triggering the workflow using `novu.trigger()`.
-
-
-#### Add Schema properties manually
-
-You can manually define each property in your payload by specifying:
-- Property name (It must be a string)
-- Property type (string, integer, number, boolean, enum, array, object, null)
-
-Each property you define becomes part of the payload schema, and helps Novu suggest accurate variables when configuring channels steps or digest actions.
-
-#### Import from JSON
-
-If you already have a sample payload, then you can quickly define the schema by importing it as a JSON object. Novu infers property names, types, and structures for you.
-
-#### Create an inline variable
-
-When referencing a variable that doesn’t exist in the schema (for example, `payload.title`) while editing a workflow step, follow these steps:
-- Novu will prompt you to create the variable inline.
-- Click Insert to add the variable to your schema with a default type of string.
-- (Optional) After insertion, edit the variable in the manage schema tab. You can:
- - Changing its type.
- - Marking it as required.
- - Adding validation rules.
-
-### Enforce schema validation
-
-Schema validation is enabled on a per-workflow basis. When active, Novu validates incoming payloads against the schema when the workflow is triggered.
-
-This means:
-- Missing required properties will cause the request to fail.
-- Data types must match exactly. For example, a string cannot be passed where a number is expected.
-- Invalid values are rejected before the workflow executes.
-
-This validation is applied at the HTTP trigger level, and prevents invalid data from entering the workflow entirely.
-
-### Schema configuration options
-
-When defining a schema property, the available configuration fields vary depending on the selected type.
-
-#### General fields (for all types)
-
-- Property name
-- Property type
-- Required property checkbox
-- Default value – Optional fallback if no value is provided
-- Min length and max length
-
-#### Type-specific configuration
-
-Depending on the selected type, additional configuration options appear:
-
-- **String**:
- - **Format**: None, date-time, date, time, duration, email, hostname, ipv4, ipv6, uuid, uri-reference, uri-template, json-pointer, relative-json-pointer, regex
- - **Pattern**: Regex-based validation
-- **Enum**: Add choices, which are a list of predefined, allowed values. This restricts the field to only those values.
-- **Array**: Select the Array item type, which defines the data type of each array element.
-- **Object**: Add nested properties, each with their own type, required status, and validation options.
-
-## Notification severity
-
-Notification severity lets you classify worfklows based on their importance level. Each workflow can be assigned one of four severity levels:
-- **High**: Indicates a critical notification. Applies a red hue to the notification and the bell icon.
-- **Medium**: For important, but not critical, notifications. Applies an orange hue.
-- **Low**: For general or informational messages. By default, it has no color, but it can be styled.
-- **None**: The default level for all new and existing workflows.
-
-### Setting a severity level
-You can set the severity for any workflow directly from the Novu dashboard.
-
-1. From the **Workflows** page, open the workflow you want to configure, or create a new one.
-2. In the workflow editor, go to the **Configure workflow** section and then select **Configure channel preferences**.
- 
-3. Choose the desired severity level option from the **Notification severity** list.
- 
-
-This classification directly impacts how notifications are displayed in the Novu Inbox, helping your users quickly identify and prioritize messages.
-
-Severity affects visual cues like color-coding, icons, and the appearance of the notification bell. For more information, refer to the [Inbox component](/platform/inbox/overview).
diff --git a/content/docs/platform/workflow/channel-steps.mdx b/content/docs/platform/workflow/channel-steps.mdx
deleted file mode 100644
index d28a9a184..000000000
--- a/content/docs/platform/workflow/channel-steps.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: 'Channel Steps'
-icon: 'Waypoints'
----
-
-import { Card, Cards } from 'fumadocs-ui/components/card';
-import { Bell, Mail, MessageSquare, MessagesSquare, Smartphone } from 'lucide-react';
-
-A **channel step** within a workflow is the core building block for creating and delivering notifications to subscribers (End users). Each channel step is linked to a specific notification template and represents a notification to be sent through a single channel type (e.g., email, push, SMS, in-app, etc.).
-
-### Channel Step Execution
-
-When a channel step is executed, Novu performs the following actions:
-
-1. **Evaluates Step Conditions:** Novu checks any conditions defined for the step to determine if it should be executed. This allows for dynamic notification workflows.
-
-2. **Verifies Subscriber's Information:**
- Novu ensures the subscriber has the required information to receive notifications via this channel.
-
- For example:
-
- - For email, the recipient must have a valid email address.
- - For push notifications, the required channel data (device token) must be configured.
-
-3. **Checks Subscriber's Preferences:**
- Novu respects the recipient's notification preferences, verifying whether they've opted out of receiving notifications from this channel or workflow.
-
-### Rendering and Delivering Notifications
-
-If the step is valid and all conditions are met, Novu renders the associated template for the step and queues the message for delivery. The message is then sent to the selected provider using the credentials configured for the channel.
-
-### Available Channels
-
-
- }
- href="/platform/integrations/email"
- />
- }
- href="/platform/inbox/overview"
- />
- }
- href="/platform/integrations/push"
- />
- }
- href="/platform/integrations/sms"
- />
- }
- href="/platform/integrations/chat"
- />
-
diff --git a/content/docs/platform/workflow/configure-workflow.mdx b/content/docs/platform/workflow/configure-workflow.mdx
new file mode 100644
index 000000000..b829fa010
--- /dev/null
+++ b/content/docs/platform/workflow/configure-workflow.mdx
@@ -0,0 +1,167 @@
+---
+pageTitle: 'Configure Workflow'
+title: 'Configure Workflow'
+description: 'Configure workflow metadata, delivery preferences, and payload schema in the workflow editor.'
+icon: 'Cog'
+---
+
+After creating a workflow, you are redirected to the workflow editor, where you configure workflow-level settings. You can also open any existing workflow from the Workflows page to access the editor.
+
+In the **Configure workflow** section, you can update workflow metadata, control delivery behavior, and define the workflow payload schema.
+
+
+
+## Workflow status
+
+A workflow is active by default after creation. Disabling a workflow pauses execution and prevents triggers from running.
+
+Workflows can exist in one of three states:
+
+- **Active**: This means the workflow can be triggered.
+- **Inactive**: This means the workflow is paused. It cannot be triggered, but you can still edit its structure or steps.
+ 
+- **Action required**: This means the workflow contains one or more errors, such as missing required fields or unconnected channels. It can still be triggered.
+
+## Tags
+
+Tags are labels or categories that help you organize and manage workflows. By grouping workflows under specific tags, you better control how they're filtered, displayed, and managed.
+
+Tags help keep things tidy and manageable for both you and your team and you can add up to 16 tags per workflow.
+
+Tags can be used to:
+- Conditionally display notifications in the {``} or filter workflows in {``}.
+- Filter and search for workflows in the dashboard.
+- [Retrieve](/api-reference/workflows/retrieve-a-workflow) or [list workflows](/api-reference/workflows/list-all-workflows) via the Novu API.
+
+### Add a workflow tag
+1. In the workflow editor, find the Tags field.
+2. Type tag name, If tag already exists, it will be suggested.
+3. If tag does not exist, you can create it by pressing Enter.
+
+### Remove a workflow tag
+- Click the X icon next to the tag name to remove tag from the workflow.
+
+
+
+## Channel preferences
+
+Workflow channel preferences let you set default channel preferences for subscribers. For all new subscribers, the channel preferences will be set to the default preferences set for the workflow. Read more about [channel preferences](/platform/concepts/preferences).
+
+
+
+### Critical workflows
+
+Novu allows you to mark a workflow as critical, this means that the notification sent from that workflow must always be delivered to the subscribers regardless of their personal preferences and they cannot change their preferences for this workflow.
+
+This is useful for high-priority notifications that are related to security, financial, or access-related information, where missing a message could have some consequences.
+
+### Notification severity
+
+Notification severity lets you classify workflows by importance, helping subscribers quickly identify urgent notifications. Each workflow can be assigned one of four severity levels:
+
+- **High**: Critical notifications that require immediate attention
+- **Medium**: Important notifications that are not critical
+- **Low**: General or informational notifications
+- **None**: The default level for all new and existing workflows
+
+You can set the severity for a workflow in the Novu dashboard by selecting a value from the **Notification severity** list.
+
+
+
+Severity levels affect how notifications appear in the Novu {``}. By default, severity controls visual cues such as color, icons, and the bell indicator, helping users prioritize messages at a glance:
+
+- **High**: Red hue
+- **Medium**: Orange hue
+- **Low**: No color
+- **None**: Default styling
+
+These default styles are [customizable](/platform/inbox/configuration/styling#style-notifications-by-severity).
+
+## Payload schema
+
+The Payload schema defines, manages, and validates the structure of data sent to a workflow. By defining a schema, you ensure that payload object, while triggering the workflow, is predictable, type-safe, and consistent across environments.
+
+Novu’s payload schema is based on the [JSON Schema](https://json-schema.org/) standard.
+
+The schema acts as a contract between your systems and Novu, defining which variables exist, how they are structured, and what validation rules apply. This gives your team a shared, explicit source of truth for workflow data.
+
+You can reference payload schema fields in the template editor, action step configuration, and step conditions to insert dynamic content and build data-driven logic. Payload schemas are especially useful for complex workflows that rely on reusable components, dynamic payloads, or strict validation requirements
+
+**Benefits of defining a payload schema**
+
+With a defined schema in place, you can:
+- Prevent unexpected runtime errors caused by invalid or missing data.
+- Build reliable conditional logic using type-aware operators.
+- Generate accurate previews powered by intelligent mock data.
+- Enable autocomplete suggestions when referencing payload variables.
+
+### Schema properties
+
+Each schema property includes the following fields:
+
+- **Property name**: Must start with a letter or underscore, and contain only letters, numbers, underscores, or hyphens.
+- **Property type**: You can either select a string, integer, number, boolean, enum, array, object, or null.
+- **Required**: You can mark a property as required. Required properties must be included in the payload when triggering the workflow using `novu.trigger()` method.
+- **Schema configuration**: Additional validation and type-specific settings.
+- **Delete**: Remove the property from the schema.
+
+### Define workflow schema
+
+Each property you define becomes part of the payload schema, and helps Novu suggest accurate variables when configuring channel steps or digest actions.
+You can define the expected payload schema in three ways:
+
+#### Manually
+
+Manually define each property by specifying its name, type, and validation rules from the **Manage workflow schema** section.
+
+
+
+#### Import from JSON
+
+If you already have a sample payload, you can import it as a JSON object from the **Manage workflow schema** section. Novu automatically infers property names, types, and nested structures.
+
+
+
+#### Create an inline variable
+
+While adding notification content in the template editors, you can reference a variable that doesn’t exist in the schema (for example, `payload.title`). Novu will prompt you to create the variable inline and add it to your schema with a default type of `String`.
+
+After creating the variable, you can edit it from the **Manage payload schema** directly in the template editor.
+
+
+
+To learn more about how notification content are added to the template editors, refer to the [Add notification content](/platform/workflow/add-notification-content) documentation
+
+### Schema configuration
+
+When defining a schema property, the available configuration fields vary depending on the selected property type.
+
+#### General fields (for all types)
+
+- Property name
+- Property type
+- Required property checkbox
+- Default value (Fallback value if none is provided).
+- Min length and max length
+
+#### Type-specific configuration
+
+Additional options appear depending on the selected type:
+
+- **String**:
+ - **Format**: None, date-time, date, time, duration, email, hostname, ipv4, ipv6, uuid, uri-reference, uri-template, json-pointer, relative-json-pointer, regex
+ - **Pattern**: Regex-based validation
+- **Enum**: Add choices, which are a list of predefined, allowed values. This restricts the field to only those values.
+- **Array**: Select the Array item type, which defines the data type of each array element.
+- **Object**: Add nested properties, each with their own type, required status, and validation options.
+
+### Enforce schema validation
+
+Schema validation is enabled per workflow. When enabled, Novu validates incoming payloads against the schema when the workflow is triggered.
+
+This means:
+- Missing required properties will cause the request to fail.
+- Data types must match exactly. For example, a string cannot be passed where a number is expected.
+- Invalid values are rejected before the workflow executes.
+
+Validation occurs at the HTTP trigger level and prevents invalid data being used in the workflow execution.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/create-a-workflow.mdx b/content/docs/platform/workflow/create-a-workflow.mdx
new file mode 100644
index 000000000..10cf39832
--- /dev/null
+++ b/content/docs/platform/workflow/create-a-workflow.mdx
@@ -0,0 +1,90 @@
+---
+pageTitle: 'Create a Workflow'
+title: 'Create a Workflow'
+description: 'Create a workflow and define its identifier, metadata, and initial configuration.'
+icon: 'CirclePlus'
+---
+
+A workflow defines how Novu delivers notifications for a specific event. It contains the steps, templates, and rules that control how messages are sent across channels.
+
+You can create workflows in the Novu dashboard, using the [Novu API](/api-reference/workflows/create-a-workflow) or define them in code using the [Novu Framework](/framework/introduction#create-a-workflow). This guide focuses on creating workflows in the Novu dashboard.
+
+Workflows can only be created and managed in the development environment. Once created, workflows can be synced to other environments. To learn more, refer to [Environments](/platform/developer/environments#publishable-assets).
+
+## Create a workflow
+
+You can create a Novu workflow in the following ways:
+
+- **Create from scratch**: Build a custom workflow tailored to your exact needs.
+- **Create from template**: Start with pre-built workflows for common use cases.
+
+### Create a workflow from scratch
+
+1. Go to the Novu Dashboard.
+2. Navigate to **Workflows**.
+3. Click **Create workflow**.
+ 
+4. Fill in the [workflow details](#workflow-details):
+ - **Name** (Required): The display name shown in the dashboard. You can change this later in the workflow editor.
+ - **Identifier** (Required): The `workflowId` is immutable. It must be in a valid slug format (letters, numbers, hyphens, dots and underscores only) and must be unique within one environment.
+ The `workflowId` is required when triggering a workflow and when using [trigger overrides](/platform/integrations/trigger-overrides). It is also used to conditionally display notifications in the {``}.
+ - **Tags** (Optional): Organize and categorize workflows. Tags can be added later in the workflow editor.
+ To learn more about Tags, refer to [workflow tags](/platform/workflow/configure-workflow#tags).
+ - **Description** (Optional): Document the workflow’s purpose and behavior for your team. Description can be added later in the workflow editor.
+ 
+5. **Enable translations** (Optional): Support multiple locales for this workflow. This can be enabled after workflow creation in the workflow editor.
+ To learn more about translations, refer to [Translations](/platform/workflow/translations).
+6. Click **Create workflow**.
+
+After creating the workflow, you’re redirected to the Workflow Editor, where you can configure the workflow and add steps.
+
+### Create a workflow from a template
+
+Templates are pre-built workflows for common notification scenarios. They include pre-configured steps, sample content, and pre-filled workflow details that you can customize.
+
+To create a workflow from a template:
+1. Go to the Novu Dashboard.
+2. Navigate to **Workflows**.
+3. From the **Workflows** page, you can access templates in two ways:
+ - Click the icon on the **Create workflow** button and select **From template**.
+ 
+ - Click **Explore templates**.
+ 
+4. Select a template.
+5. Click **Create workflow**.
+
+## Manage workflows
+
+Once created, you can manage workflows from the Workflows page:
+
+### Update a workflow
+
+After creating a workflow, you can modify its configuration at any time from the workflow editor. This allows you to evolve notification logic without creating a new workflow.
+
+Click on any workflow to open the workflow editor, where you can:
+- Update name and description (identifier cannot be changed)
+- Add or remove the workflow tags.
+- Change [workflow status](/platform/workflow/configure-workflow#workflow-status).
+- Configure [channel preferences](/platform/workflow/configure-workflow#channel-preferences) and [payload schema](/platform/workflow/configure-workflow#payload-schema).
+- Add, remove, or reorder [steps](/platform/workflow/add-and-configure-steps#add-a-step-to-a-workflow).
+
+### Duplicate a workflow
+
+Duplicating a workflow lets you reuse an existing configuration as a starting point for a new workflow. This is useful when workflows share similar logic but differ in trigger identifiers, content, or steps.
+
+1. Find the workflow in **Workflows** page.
+2. Click the three-dot menu (•••).
+3. Select **Duplicate workflow**.
+4. Provide a new name and identifier.
+ 
+5. Click **Duplicate Workflow**.
+ 
+
+### Delete a workflow
+
+Deleting a workflow is permanent and cannot be undone. Any existing triggers referencing the deleted workflow will fail with a `workflow not found` error. Execution history is preserved in the [Novu Activity Feed](/platform/workflow/monitor-and-debug-workflow).
+
+1. Find the workflow in **Workflows** page.
+2. Click the three-dot menu (•••).
+3. Select **Delete**.
+4. Confirm deletion.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/delay.mdx b/content/docs/platform/workflow/delay.mdx
deleted file mode 100644
index 141ae959b..000000000
--- a/content/docs/platform/workflow/delay.mdx
+++ /dev/null
@@ -1,117 +0,0 @@
----
-pageTitle: 'Delay Steps in Workflows'
-title: 'Delay'
-description: 'Learn how to use delay step to add a delay in the workflow execution.'
-icon: 'Timer'
----
-
-The delay step allows you to pause the execution of your workflow for a specified duration. This is useful for implementing features like follow-up notifications, reminder sequences, or cooldown periods.
-
-## Common use cases
-
-- Waiting for X amount of time before sending the message
-- Wait for a short period of time before sending a push message in case the user seen the notification in the Inbox Component
-- Send a reminder email 24 hours after a user abandons their shopping cart to encourage checkout completion
-- Send a follow-up message 3 days after user registration to check if they need onboarding assistance
-
-## Adding a delay step
-
-Delay steps can be inserted at any stage of your workflow execution, they can happen after or before any action. The workflow execution will be halted for the given amount of time and then resumed to the next step in the flow.
-
-Notes:
-
-- Step conditions can be applied to delay step to skip the delay if certain conditions are met.
-- Delay step can be extended to subscriber's schedule. This option can be enabled in the delay step configuration. Channel notification after delay step will be sent on the next available slot in the subscriber's schedule.
-- Channel notification after delay step will be sent as per subscriber time zone if timezone attribute ofsubscriber is set. If timezone attribute is not set, then channel notification will be sent as per UTC timezone.
-
-
- Changing the step content after triggering the workflow with delay step will affect the existing pending delayed notification content.
-
-
-
-## Delay types
-
-- Fixed delay
-- Scheduled delay
-- Dynamic delay
-
-### Fixed delay
-
-Fixed delay is a delay that is fixed and does not change. For example, if you want to delay the workflow for 1 day, you can use the fixed delay. It can be specified in seconds, minutes, hours, days, weeks, or months.
-
-
-
-
-### Scheduled delay
-
-Scheduled delay is a delay that halts the workflow execution until the specified time is reached as per subscriber's time zone.
-
-
-Scheduled delay can be configured with these configurations:
-
-- util minute
-- until hour at specific minutes
-- until day at specific hour and minutes
-- until week and days of the week at specific hours and minutes
-- until month on specific days of the month and weekdays at hours and minutes
-
-
-Example:
-
-
-
-As per above example, schduled delay is configured to pause the workflow execution until current day till 10:00 AM or 11:00 AM and 23 or 24 or 25 minutes past the hour. This time is as per subscribers's time zone.
-
-### Dynamic delay
-
-Dynamic delay is also known as variable based delay. It allows to delay the workflow based on a variable in the payload. This variable can have two formats:
-
-- ISO-8601 timestamp: Example: `2025-01-01T12:00:00Z`. This value should be for future date and time.
-- Duration object: Example: `{ "amount": 30, "unit": "minutes" }`. This value should be for future date and time. Here *amount* is the number of units to delay and *unit* is the time unit. *unit* can be **seconds**, **minutes**, **hours**, **days**, **weeks**, or **months**.
-
-Example of a dynamic delay:
-
-
-
-In above example, delayTill variable is used to delay the workflow until the future date and time specified in the delayTill variable.
-
-
-
-
- ```json
- {
- "delayTill": "2026-01-01T12:00:00Z"
- }
- ```
-
-
-
- ```json
- {
- "delayTill": {
- "amount": 30,
- "unit": "minutes"
- }
- }
- ```
-
-
-
-If delay step is added as first step with dynamic delay ISO date configuration, it works as scheduling the workflow trigger as workflow executions will be delayed untill the time is reached specified in the ISO date.
-
-
-## Frequently asked questions
-
-### If delay step fails, will the workflow continue to the next step?
-No, workflow execution will stop immediately if the delay step fails due to an error. Common errors are:
-
-- Invalid ISO date format
-- Invalid duration object format
-- Past datetime is specified
\ No newline at end of file
diff --git a/content/docs/platform/workflow/digest.mdx b/content/docs/platform/workflow/digest.mdx
deleted file mode 100644
index b5bd1062f..000000000
--- a/content/docs/platform/workflow/digest.mdx
+++ /dev/null
@@ -1,220 +0,0 @@
----
-title: 'Digest Engine'
-description: 'Collect Multiple Events to a Single Message with the Digest Engine'
-icon: 'Boxes'
----
-
-import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
-
-The digest engine collects multiple trigger events, aggregates them into a single message, and delivers that new payload to the next workflow step.
-This becomes useful when a user would otherwise receive a large number of notifications, and you want to avoid over-notifying. When you use a Digest action step, Novu automatically batches the incoming trigger events based on the `subscriberId` and an **optional** `digestKey` that can be added to control the digest logic of the events.
-
-## Digest action step
-
-After adding a digest step to a workflow, each node that will be below the digest node will be only triggered once in the specified digest interval.
-You can decide to send messages before adding a digest node and they will be triggered in real-time.
-
-
-
-## Digest configuration
-
-### Digest key
-
-If specified, the digest engine will group the events based on the `digestKey` and `subscriberId`, otherwise the digest engine will group the events based only on the subscriberId.
-
-The digest key might come useful when you want a particular subscriber to get events grouped on a custom field. For example when an actor likes the user's post, you might want to digest based on the `post_id` key.
-
-### Time interval
-
-The time interval determines how long the digest engine will wait before sending the message once created. You can specify the amount and the unit that best suits your needs.
-
-In the image below, `5` is the interval amount, and `mins` is the interval unit. Interval units can be `sec(s)`, `min(s)`, `hour(s)`, or `day(s)`.
-
-
-## Digest strategy types
-
-The strategy which Novu should use to handle the digest step. More details on available strategies below.
-
-Novu allows you to define different digest strategies depending on the actual use-case you are trying to achieve. At this point we allow you to select from 2 strategies:
-
-- Regular
-- Look-back
-- Scheduled
-
-Let's explore them in detail:
-
-### Regular strategy
-
-In regular strategy, a digest will always be created for the specified window time. Which means that from the first event trigger, if no active digest exists for this subscriber, one will be created and the user will receive the message only when the digest window time is reached.
-
-### Look-back strategy
-
-In the Look-Back strategy, before creating a digest, Novu will check if a message was sent to the user in the Look-back period. If a message was sent, a digest will be created. Otherwise, a message will be sent directly to the user and the digest creation will be skipped.
-
-Look-back digest has two intervals, `digest interval` and `look-back window`. First, it checks if any event is triggered within the past look-back window, only then a digest is created for the digest interval. If not, the event is considered non-digest and workflow execution continues to the next step.
-
-#### Example
-
-Let's set the digest interval as 20 minutes and the look-back interval as 15 minutes.
-
-If we trigger the first event. Since it is the first event and there was no event triggered in the past 15 minutes (look-back interval), this event will send a message immediately (without digest).
-Now, if we trigger a second event within 15 minutes range, then a new digest will be created with this second event. From now on, for the next 20 minutes (digest interval), all triggers will be digested, and after 20 minutes, the workflow will carry forward to the next step with digested events as a payload.
-
-### Scheduled digest
-
-All digest times are in UTC time
-
-Digest incoming events for the specified time. Once that time threshold since the first event has passed, proceed to the next workflow step.
-
-Available timeframes:
-
-- Minutes
-- Hours
-- Daily
-- Weekly
-
-## Consuming digested events
-
-The digest step collects and groups multiple events over time. Once digested, the results can be used directly in your notification templates to create clear and concise summaries, such as daily digests or batch notifications.
-
-Novu provides built-in variables that expose the results of the digest step. These variables can be referenced in your templates to display totals, format summaries, or present grouped event data using LiquidJS filters.
-
-These variables are automatically exposed in all variable-supporting inputs following a digest step, as the digest payload determines their values.
-
-### Digest variables
-
-Digest variables can be used to reference the list of events and their count, making it possible to create dynamic content inside your templates based on the actual events processed during the digest window.
-
-#### steps.digest-step.events
-
-The `steps.digest-step.events` variable is an array that contains all the events collected by the digest step. Each item in the array represents a digested event, including the payload with which the workflow was triggered.
-
-You can loop through it to build dynamic message lists, such as comment summaries or blog post digests, and use it with LiquidJS filters.
-
-```
-New posts published: {{steps.digest-step.events | toSentence:'payload.title', 2, 'more'}}
-```
-
-If two events were collected, the rendered message would be:
-
-```
-New posts published: Scaling Node.js Apps, and Designing for Accessibility
-```
-
-If three or more events were collected, the rendered message would be:
-
-```
-New posts published: Scaling Node.js Apps, and Designing for Accessibility, and more.
-```
-
-#### steps.digest-step.eventCount
-
-The `steps.digest-step.eventCount` variable holds the total number of events collected during the digest step window. It is an integer value and can be used directly or passed into LiquidJS filters like pluralize to generate grammatically correct summaries.
-
-```
-You have {{steps.digest-step.eventCount | pluralize: "new comment"}}.
-```
-
-If one event was collected, then the rendered message would be:
-
-```
-You have 1 new comment.
-```
-
-If two events were collected, then the rendered message would be:
-
-```
-You have 2 new comments.
-```
-
-### Digest template variables
-
-Digest template variables are designed to simplify how you represent digested event data in user-facing messages. They wrap digest variables and LiquidJS filters to output preformatted summaries with minimal effort.
-
-#### steps.digest-step.countSummary
-
-The `countSummary` variable returns a sentence fragment summarizing the total number of digested events with correct pluralization.
-
-This variable is built on top of:
-- `steps.digest-step.eventCount`
-- The LiquidJS pluralize filter
-
-Internally, `countSummary` uses the event count to apply plural logic. To use `countSummary` in the editor, select it from the variables dropdown. This will automatically insert the variable like this:
-
-```
-You have {{steps.digest-step.eventCount | pluralize: 'notification'}}
-```
-
-For example, if the digest collected five events, then the output would be:
-
-```
-You have 5 notifications
-```
-
-If only one event was collected:
-
-```
-you have 1 notification
-```
-
-#### steps.digest-step.sentenceSummary
-
-The `sentenceSummary` variable returns a sentence-style string listing key items from the digested events array, such as a list of names, and gracefully handles formatting depending on the number of items present.
-
-This variable is built on top of:
-- `steps.digest-step.events`
-- The LiquidJS `toSentence` filter
-
-You can configure the `toSentence` filter by passing:
-- A key path to extract from each item (for example, `payload.name`). This is a required argument.
-- The number of items to display before collapsing (for example, 3)
-- The suffix to use for remaining items (for example, "others")
-
-Internally, `sentenceSummary` uses the events array to generate the sentence. To use `sentenceSummary` in the editor, select it from the variables dropdown. This automatically inserts the variable as shown:
-
-```
-{{steps.digest-step.events | toSentence:'payload.name', 3, 'others'}} replied to your post.
-```
-
-If the events contain names "Radek", "Dima", and five more users, then the result would be:
-
-```
-Radek, Dima, and 5 others replied to your post.
-```
-
-If there are only two events:
-
-```
-Radek and Dima replied to your post.
-```
-
-These variable allows for dynamic personalization without writing custom iteration logic in your template.
-
-## Email editor digest block
-
-The digest block is available in the email editor when working with workflows that include a digest step. It loops over the events collected by your digest step and displays them in your email content, handling both layout and repetition automatically.
-
-When you add a digest block to your email template:
-- It automatically inserts a repeat block that loops over `steps.digest-step.events`, with the maximum number of iterations defaulting to five.
-- Inside this loop, you define the structure once (for example, how each comment or notification looks), and it repeats for every event.
-- Inside the loop, you can also use the special alias variable `current` to reference the item currently being processed (for example, `current.payload.name`).
-- The block also supports rendering a summary using the `steps.digest-step.eventCount` variable, typically with the pluralize LiquidJS filter.
-
-You don’t need to write any code manually. The Email Editor handles the looping logic for you. Simply drag the digest block into your message and customize the layout visually using the available variables.
-
-
-The digest Block only appears if your workflow has a preceding digest step. This block will not be shown in the editor without a digest step.
-
-
-## Frequently Asked Questions
-
-### If scheduled digest is set for 9:00 AM daily then will the digest be sent at 9:00 AM every day without any event triggered?"
-If scheduled digest is sent for 9:00 daily, then novu will collect all events triggered between 9:00 AM today till 9:00 AM tomorrow and send the digest at 9:00 AM tomorrow. This process is repeated daily. If there is no any event triggered between 9:00 AM today and 9:00 AM tomorrow, then no digest will be sent.
-
-
-### What is the difference between Regular and Scheduled Digest set to 1 Hour?
-Both digests are same in this case.
-
-### If digest step fails, will the workflow continue to the next step?
-No, workflow execution will stop immediately if the digest step fails due to an error.
-
diff --git a/content/docs/platform/workflow/layouts.mdx b/content/docs/platform/workflow/layouts.mdx
deleted file mode 100644
index 99b33baf0..000000000
--- a/content/docs/platform/workflow/layouts.mdx
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: 'Email Layouts'
-description: 'Email layouts are reusable components used with email steps'
-icon: 'Container'
----
-
-## Overview
-
-Layouts are reusable components used with email steps in the workflow, designed to bring consistency, maintainability, and efficiency to your email communications. With layouts, teams can create a component using headers, footers and other branding elements and reuse that component across multiple email steps and workflows.
-
-Each environment includes one default layout, but you can create additional layouts based on your needs — such as transactional, marketing, or newsletter types.
-
-**Important**: Every layout must include the `{{content}}` variable. This variable dynamically injects the content of the email step.
-
-## Layout features
-
-- Reusable across workflows: one layout can be shared across many workflows and email steps.
-- Visual (Block) editor: block-based editor for building layout templates.
-- Code editor: use raw HTML for full control.
-- Environment-scoped: each environment maintains its own set of layouts.
-- Supports variables: use liquid variables like `{{subscriber.firstName}}` and `{{payload.orderId}}`.
-
-
- In free plan, only one layout can be created per environment. In pro and higher plans, upto 100 layouts can be created per environment. If you need more than 100 layouts, please contact us at support@novu.co.
-
-
-## Managing layouts
-
-You can find layouts in the sidebar on Novu dashboard.
-
-Here, you will see a list of existing layouts along with creation and editing options.
-
-
-
-### Creating a layout
-
-- Navigate to the [layouts page](https://dashboard.novu.co/layouts) on Novu dashboard.
-- Click on the **Create layout** button on the top right corner.
-- Fill in:
- - Layout Name - Human-readable name such as **Newsletter Layout**
- - Identifier - Unique ID used internally and in APIs such as **newsletter-layout**. This will be generated automatically if not provided.
-
-A new layout is created with the provided name and identifier.
-
-### Writing layout content
-Layout content can be written in two ways:
-
-- Block Editor: Visual interface for building layout components. Add elements like headers, footers, images, and buttons by pressing `/` key.
-- Code Editor: Write your layout using HTML.
-
-Both editors offer the same features and capabilities as the email step editor. Ensure your layout includes `{{content}}`, which acts as a placeholder for actual email content from the workflow.
-
-Example HTML content:
-
-```html
-
-
-
-
Welcome to Acme Inc.
-
-
- {{content}}
-
-
-
-
-```
-
-### Editing the layout
-
-- Navigate to [Layouts page](https://dashboard.novu.co/layouts) on Novu dashboard.
-- Click on a layout from the list.
-- Click the **cog** icon in the layout editor to rename the layout or change its identifier.
-- Edit the layout content in either the **Block** or **Code** editor.
-- Preview the layout in the preview pane, using mock subscriber data if needed.
-
-A layout can be deleted or duplicated by clicking on the three dots and selecting the action. If a layout is already in use, you will see a warning message while deleting the layout.
-
-## Using a layout in workflow email step
-
-- Navigate to [Workflows page](https://dashboard.novu.co/workflows) on Novu dashboard.
-- Select a workflow from the list.
-- Select any email step of the workflow.
-- Choose your layout from the Layout selector.
-
-The selected layout wraps around the content written in the email editor.
-
-
- Payload variables are not supported in layouts because one layout can be used across multiple workflows and workflows can have strict payload schema validation.
-
-
-### Previewing emails with layouts
-
-Use the Test Workflow feature to preview how the email renders with the layout and actual subscriber data. You can test different subscriber profiles and locales to validate the layout appearance.
-
-### Translation in layouts
-
-[Translations](/platform/workflow/translations) feature in layouts works the same as in email steps. You can use `{{t.key}}` to insert a translatable string. If the key already exists for the locale, it appears in the suggestions list. To use translations in layouts, you need to enable translations in the layout settings. Checkout the below example video on how to use translations in layouts.
-
-
-
-
-## Tips for using layouts
-
-- Use layouts for branding elements: logos, consistent colors, company details.
-- Use the **Block** editor for easier collaboration with non-technical teammates.
-- Use the **Code** editor when replicating an HTML design from Figma or another tool.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/meta.json b/content/docs/platform/workflow/meta.json
index a93cf1a43..4319e442c 100644
--- a/content/docs/platform/workflow/meta.json
+++ b/content/docs/platform/workflow/meta.json
@@ -1,6 +1,5 @@
{
"title": "Workflows",
"description": "Workflows",
- "icon": "Lightbulb",
- "defaultOpen": true
+ "icon": "Lightbulb"
}
diff --git a/content/docs/platform/workflow/monitor-and-debug-workflow.mdx b/content/docs/platform/workflow/monitor-and-debug-workflow.mdx
new file mode 100644
index 000000000..195526ece
--- /dev/null
+++ b/content/docs/platform/workflow/monitor-and-debug-workflow.mdx
@@ -0,0 +1,69 @@
+---
+pageTitle: 'Monitor and Debug Workflow'
+title: 'Monitor and Debug Workflow'
+description: "Learn how to monitor workflow executions and debug issues from the Novu Activity Feed."
+icon: 'Activity'
+---
+
+The Novu Activity Feed tracks the full execution lifecycle after a workflow is triggered. It provides real-time visibility into how workflows run, helping you understand what happened and why.
+
+From the Activity Feed, you can inspect each workflow run and API request to see how each subscriber notification was processed.
+
+
+
+Each environment has its own Activity Feed, ensuring execution data is isolated and easy to reason about.
+
+## Inspect workflow runs
+
+The Workflow Runs tab shows the details of every workflow triggered to each subscriber. Each run represents a single execution instance and reflects how the workflow behaved for that subscriber.
+
+You can filter workflow runs using parameters such as time period, workflow identifier, and channel. Selecting a workflow run opens the run details view, which gives you access to execution outcomes of each step in the workflow and investigate delivery issues.
+
+
+
+The workflow run details include:
+
+| Field | Description |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| **Workflow identifier** | The unique identifier of the workflow that was executed. |
+| **Transaction ID** | A unique ID associated with the trigger event. Use this to correlate workflow runs with trigger requests and logs. |
+| **Topic key** | The topic key used to trigger the workflow, if the workflow was triggered to a topic. |
+| **Subscriber ID** | The identifier of the subscriber for whom this workflow run was executed. |
+| **Triggered at** | The timestamp indicating when the workflow execution started. |
+| **Status** | The current state of the workflow run. Possible statuses include Completed, Pending, and Failed. |
+| **Severity** | The severity level associated with the workflow execution, if defined. |
+| **Critical** | Indicates whether the workflow was marked as critical. |
+| **Context data** | Context values passed when triggering the workflow. |
+| **Trigger payload** | The payload data sent with the trigger event and used to personalize notification content. |
+
+
+Each workflow run also includes execution details that show how Novu processed each step for a single subscriber. The timeline is ordered chronologically and reflects the internal state transitions of each step as the workflow runs.
+
+Execution details are step-specific and vary depending on:
+
+- The type of step
+- Whether the step succeeded, was skipped, or failed
+- Provider behavior and delivery outcomes
+
+## Inspect trigger requests
+
+The Requests tab in the Activity Feed shows detailed information about every request made to the Event API. Selecting a request opens a detailed view of how Novu processed it, the API response, and execution traces.
+
+
+
+You can filter requests using parameters such as time period, transaction ID, statuses or API endpoint. When you open a request, Novu displays details about the API call:
+
+| Field | Description |
+| ------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
+| **Endpoint** | The API endpoint that received the request, for example, `POST /v1/events/trigger` and a unique identifier for the API request. |
+| **Received at** | Timestamp indicating when Novu received the request. |
+| **Transaction ID** | The transaction associated with the trigger. Use this to correlate the request with workflow runs. |
+| **Source** | Indicates where the request originated, either the **Dashboard** or the **API**. |
+| **Request body** | The payload sent in the API call, including the workflow identifier, subscriber or topic targeting, and any additional data. |
+| **Response body** | Novu’s response to the request, confirming whether it was acknowledged and processed successfully. |
+
+Each request also includes API trace events that show how Novu handled the trigger internally.
+
+Common trace entries include:
+- Workflow execution started
+- Request subscriber processing completed
\ No newline at end of file
diff --git a/content/docs/platform/workflow/overview.mdx b/content/docs/platform/workflow/overview.mdx
index ef170253c..57774f6b1 100644
--- a/content/docs/platform/workflow/overview.mdx
+++ b/content/docs/platform/workflow/overview.mdx
@@ -1,51 +1,82 @@
---
-pageTitle: 'Workflow Editor Overview'
+pageTitle: 'Overview'
title: 'Overview'
-description: 'The workflow Editor combines no-code simplicity and code-based flexibility, enabling users to design and manage advanced notification workflows tailored to their needs.'
-icon: 'LayoutDashboard'
+description: 'Learn how to create, configure, and work with notification workflows in Novu.'
+icon: 'Workflow'
---
-import { Card, Cards } from 'fumadocs-ui/components/card';
-import { ArrowRightIcon } from 'lucide-react';
+Novu Workflows orchestrate how notifications move from application events to messages delivered across one or more channels. A workflow combines delivery logic, message content, and execution rules into a single notification pipeline.
-The workflow Editor is a robust visual tool that empowers both no-code users and developers to design advanced notification workflows. It seamlessly combines the intuitive simplicity of no-code building blocks with the adaptability and precision of code-based customization.
+Use workflows to control when notifications are sent, who receives them, what content is delivered, and how delivery behaves across channels.
-## What is a workflow?
+If you’re new to workflows, see the [Workflow core concept](/platform/concepts/workflows) for an in-depth overview of what workflows are and how they fit into Novu’s notification system.
-A workflow in Novu is a container for all notification/message logic and templates within your system.
+Novu Workflows help you:
-Each workflow:
+- Ship notifications faster without hardcoding logic in your application.
+- Centralize notification logic instead of scattering it across services and codebases.
+- Control delivery behavior with conditions, delays, batching, and throttling.
+- Personalize notifications at scale using event data, context, and templates.
+- Observe and debug notification execution with built-in monitoring and logs.
-- Has a unique identifier (key)
-- Executes for one subscriber at a time (e.g. end user, recipient, customer, etc.)
-- Contains complete notification/message logic and templates
-- Supports subscriber preference management
-- Can be triggered via API calls, events, or scheduled operations
+## Features
-## Different types of Novu Workflows
+- **Multi-channel**: Email, in-app, SMS, push, and chat channels.
+- **Action steps**: Delays, digests, and throttle notifications.
+- **Step conditions**: Define conditional logic for each workflow step.
+- **Template editors**: Channel-specific editors with variables and LiquidJS logic.
+- **Reusable layouts and components**: Email layouts and shared templates.
+- **Context and shared data**: Attach metadata and reusable objects across workflows.
+- **Translations**: Localize notification content across languages.
+- **Observability**: Activity feed and request logs for debugging and auditing.
-### Visual workflow editor (No-Code)
+## Workflow lifecycle
-**Best suited for:**
+A workflow typically follows this lifecycle:
-- Straightforward use cases without complex logic
-- Building emails using Novu's Email WYSIWYG Editor
-- Modifying existing workflows
-- Quick prototyping, testing, and iteration
-- Collaboration with non-technical stakeholders
+1. Create a workflow for an application event.
+2. Add and configure steps to define channels and execution logic.
+3. Author content for each channel.
+4. Trigger the workflow from your application using events and payloads.
+5. Monitor and iterate using activity logs and delivery metrics.
-### Framework SDK (Code-Based)
+This section walks through each stage in detail.
-**Best suited for:**
+## Getting started
-- Complex workflow logic implementation
-- External API integration
-- Custom data transformation
-- Advanced routing rules
-- Type safe workflow payloads
-- Specialized business logic
-- Complex conditional branches
-- Custom email templates (React Email, Vue Email, MJML etc.)
-- Workflow versioning
+Follow these guides to start building your first workflow:
-[Learn more about Novu Framework](/framework/overview)
+
+
+ Create a workflow and define its identifier and metadata.
+
+
+ Manage workflow metadata, channel preferences, payload schema, and activation state.
+
+
+ Add channel and action steps and define execution logic.
+
+
+ Trigger workflows from your application and send event data.
+
+
+
+## Use cases
+
+- **User lifecycle notifications**: Signup, onboarding, account changes, password resets.
+- **Transactional alerts**: Payments, security events, system updates.
+- **Product messaging**: Feature announcements, marketing notifications, in-app prompts.
+- **Operational workflows**: Internal alerts, DevOps notifications, system monitoring.
+- **Multi-tenant messaging**: Tenant-aware notifications using context and topics.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/step-conditions.mdx b/content/docs/platform/workflow/step-conditions.mdx
deleted file mode 100644
index 110222600..000000000
--- a/content/docs/platform/workflow/step-conditions.mdx
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: 'Step Conditions'
-description: 'Create dynamic notification workflows using rule-based conditions. Control message delivery based on subscriber data, payload information, and workflow outcomes.'
-icon: 'ListFilter'
----
-
-The Step Condition feature in Novu enables you to define conditional logic for each workflow step (node), ensuring a precise and tailored notification experience. This feature adds flexibility and control by allowing you to determine whether a step should execute based on subscriber data, payload data, or conditions stemming from previous workflow steps.
-
-## What are workflow step conditions?
-
-When adding a workflow step (node) in Novu, it can either be:
-
-1. **Channel Step**: In-App, Email, SMS, Push, or Chat.
-2. **Action Step**: Digest or Delay.
-
-Each step includes the ability to configure step conditions that define whether the step is executed. The conditions can combine multiple logical rules using AND and OR operators.
-
-## How to set step conditions
-
-1. In the workflow template editor, select the workflow step where you want to apply conditions.
-2. In the Configure step panel, click **Step Conditions**.
- 
-3. Proceed to add your step conditions
-
-## Areas for Configuring Step Conditions
-
-### Subscriber variables
-
-Conditions can leverage subscriber-related fields to tailor notifications based on user-specific data. Examples of subscriber variables include:
-
-- `subscriber.firstName`
-- `subscriber.lastName`
-- `subscriber.email`
-- `subscriber.phone`
-- `subscriber.avatar`
-- `subscriber.locale`
-- `subscriber.data`
-- `subscriber.subscriberId`
-- `subscriber.isOnline`
-- `subscriber.lastOnlineAt`
-
-
- For instance, you might want to send an SMS only to users whose `subscriber.isOnline` is `false`.
-
-
-### Payload data
-
-Conditions can also depend on custom payload data passed during the workflow trigger call to the Novu API. This allows you to define dynamic rules based on the data unique to each workflow execution.
-
-Example payload data:
-
-```json
-{
- "orderId": "12345",
- "totalAmount": 150,
- "orderStatus": "completed"
-}
-```
-
-You can configure conditions such as:
-
-- `payload.orderStatus = "completed"`
-- `payload.totalAmount > 100`
-
-This makes it possible to create dynamic notifications based on context-specific information.
-
-### Workflow variables
-
-You can also base conditions on workflow variables. These variables provide metadata about the workflow being executed and allow you to add conditional logic.
-
-
-
-The following workflow variables are available:
-- `{{workflow.name}}`: The name of the workflow.
-- `{{workflow.description}}`: The description of the workflow.
-- `{{workflow.tags}}`: An array of tags associated with the workflow.
-- `{{workflow.severity}}`: The severity level (high, medium, low, none) of the workflow.
-- `{{workflow.workflowId}}`: The unique identifier of the workflow.
-
-### Previous step conditions
-
-For workflows involving sequential steps, conditions can also depend on the outcome of a previous step. For example, if the prior step was an in-app notification, then the condition could check:
-
-- `steps.in-app-step.seen`
-- `steps.in-app-step.read`
-- `steps.in-app-step.lastSeenDate`
-- `steps.in-app-step.lastReadDate`
-
-This is especially useful for tailoring follow-up notifications. For instance, send an email only if the in-app notification was not read within 24 hours.
-
-### Advanced application state calculations
-
-For more complex scenarios where you need to perform advanced calculations based on your application state, you can use the [Novu Framework ](/framework/typescript/steps).
-
-This approach allows you to:
-
-- Access your application's database or external services
-- Perform complex business logic calculations
-- Make API calls to external services
-- Execute custom validation rules
-
-The skip step gives you full programmatic control over whether a notification step should be executed, going beyond the built-in condition builder capabilities.
-
-## Query Builder Options
-
-The query builder enables you to construct powerful logical expressions for your step conditions. Supported operators include:
-
-| Operator | Description | Example |
-| --------------------- | --------------------------------------- | ----------------------------------------------- |
-| `=` | Equal to | `subscriber.locale = "en-US"` |
-| `!=` | Not equal to | `subscriber.isOnline != true` |
-| `<` | Less than | `payload.totalAmount < 100` |
-| `>` | Greater than | `payload.totalAmount > 100` |
-| `<=` | Less than or equal to | `payload.totalAmount <= 200` |
-| `>=` | Greater than or equal to | `payload.totalAmount >= 200` |
-| `contains` | Contains a substring | `payload.orderId contains "123"` |
-| `begins with` | Starts with | `subscriber.firstName begins with "J"` |
-| `ends with` | Ends with | `subscriber.email ends with "@xyz.com"` |
-| `does not contain` | Does not contain a substring | `payload.orderId does not contain "456"` |
-| `does not begin with` | Does not start with | `subscriber.firstName does not begin with "M"` |
-| `does not end with` | Does not end with | `subscriber.lastName does not end with "Smith"` |
-| `is null` | Is null | `subscriber.phone is null` |
-| `is not null` | Is not null | `subscriber.email is not null` |
-| `in` | Matches one of several values | `subscriber.locale in ["en-US", "es-ES"]` |
-| `not in` | Does not match any of the listed values | `subscriber.locale not in ["fr-FR", "de-DE"]` |
-| `between` | Within a range | `payload.totalAmount between [50, 200]` |
-| `not between` | Outside of a range | `payload.totalAmount not between [0, 50]` |
-
-## Using dynamic data fields for comparison
-
-The **value** field in a condition can also be a dynamic data field. This allows you to compare two data points dynamically rather than using static values.
-
-For example:
-
-```json
-{
- "operator": "AND",
- "conditions": [
- {
- "field": "payload.foo",
- "operator": "=",
- "value": "{{payload.bar}}"
- }
- ]
-}
-```
-
-
-
-In this case, the step will execute only if `payload.foo` is equal to `payload.bar` at runtime.
-
-You can also use subscriber variables in the same way:
-
-```json
-{
- "operator": "AND",
- "conditions": [
- {
- "field": "subscriber.firstName",
- "operator": "=",
- "value": "{{payload.firstName}}"
- }
- ]
-}
-```
-
-
-
-This enables flexible condition logic based on real-time data comparisons.
-
-## Building condition groups
-
-Novu allows you to group multiple conditions using AND and OR operators to create complex logic. For example:
-
-- **AND Group**: All conditions in the group must be true for the step to execute.
-- **OR Group**: At least one condition in the group must be true.
-
-Condition groups can also be nested for advanced use cases.
-
-Novu's Step Condition feature empowers you to build intelligent and dynamic workflows tailored to your specific use cases. By leveraging subscriber data, payload information, and step outcomes, you can ensure that each notification reaches the right audience at the right time with the appropriate content.
diff --git a/content/docs/platform/workflow/tags.mdx b/content/docs/platform/workflow/tags.mdx
deleted file mode 100644
index 1b5a8bde2..000000000
--- a/content/docs/platform/workflow/tags.mdx
+++ /dev/null
@@ -1,36 +0,0 @@
----
-pageTitle: 'Tags: Organizing Your Notifications'
-title: 'Tags'
-description: "Learn how to organize and manage notification tags using Novu's visual workflow editor for better user experience and notification management."
-icon: 'Tags'
----
-
-**Tags** act like labels or categories that help you organize and manage notifications in your app. By grouping notifications under specific tags, you can better control how they're filtered, displayed, or managed by both your app and your users.
-
-For example, you might want to group all security-related notifications together, separate from updates about account activity or promotional offers.
-
-## Why Use Tags?
-
-- **Filtering Notifications**: Tags make it easy to filter and display notifications based on categories.
- For instance, you can create a UI that allows users to view only security or promotional notifications. Learn more about using tags to filter notifications in the [Inbox](/platform/inbox/react/multiple-tabs) section.
-
-Think of it as organizing emails into folders—tags help keep things tidy and manageable for both you and your users.
-
-## How to Add Tags to Notifications
-
-
- Navigate to the **"Workflows"** tab
- Create a new workflow or edit an existing workflow
-
- One of the fields in the workflow is the **Tags** field. You can add one or more (max. 16) tags
- to a notification
-
-
-
-## Best Practices for Using Tags
-
-- **Define Categories Early**: Identify key notification categories for your app, such as security, promotions, or updates.
-- **Consistent Naming**: Use clear and consistent tag names to avoid confusion (e.g., prefer security over sec_alert).
-- **Keep It Manageable**: Avoid overloading with too many tags. Focus on meaningful groupings that provide real value.
-
-Tags are a powerful way to streamline your notification system, helping users stay organized and informed while giving you greater control over your app's notification behavior.
diff --git a/content/docs/platform/workflow/template-editor.mdx b/content/docs/platform/workflow/template-editor.mdx
deleted file mode 100644
index b92185408..000000000
--- a/content/docs/platform/workflow/template-editor.mdx
+++ /dev/null
@@ -1,226 +0,0 @@
----
-title: 'Template Editor'
-description: 'Learn how to use the Novu notification template editor to design notifications'
-icon: 'NotebookPen'
----
-
-import { Card, Cards } from 'fumadocs-ui/components/card';
-import { FilterIcon } from 'lucide-react';
-
-Each channel step in a Novu workflow comes with its own notification template. This template defines how notifications appear for a specific channel.
-
-Quality templates are used to create personalized, visually appealing, and effective notifications.
-
-- Injecting variables from your trigger data into your notification template.
-- Using Liquid syntax for logic and control flow within templates.
-- Previewing and testing your notification templates.
-
-## Personalizing notifications using template variables
-
-To insert a variable into your Novu notification template, use double curly braces: `{{ variable_name }}`.
-
-Novu templates allow you to reference several types of variables:
-
-### Payload variables
-
-These variables originate from the data payload in your workflow trigger.
-For example, if you include `{ "order_id": "12345" }` in your payload, you can reference it in your template as `{{ payload.order_id }}`.
-
-### Subscriber variables
-
-You can access subscriber properties (like `firstName` or custom subscriber properties) using `{{ subscriber.* }}`. For instance:
-
-```liquid
-Hi {{ subscriber.firstName }},
-
-You've been upgraded to the {{ subscriber.data.plan }} plan.
-
-Thanks,
-The Novu Team
-```
-
-### Workflow variables
-
-You can access metadata about the workflow that is being executed, which you can use directly in your templates editor to personalize message content.
-
-For example, you can use the `{{workflow.severity}}` to display the severity level within the message itself.
-
-```html
-
This is a {{workflow.severity}} priority message regarding your account.
-```
-
-## Variable popover
-
-When clicking on a variable in the template editor, a popover will appear. This popover can be used to easily manipulate the variable formatting by applying default values or Liquid Filters.
-
-
-
-### Applying Liquid Filters
-
-The variable popover will display a list of suggested Liquid Filters based on the variable type, you can apply one or more filters to the variable and re-order using drag and drop.
-Re-ordering filters is useful as the filters are applied in the order they are listed, and the output of each filter is passed to the next one.
-
-### Previewing filters output
-
-With more advanced filter logic, you can preview the output of the filters by clicking on the **Preview** button and pass the variable value to see how the filters will be applied.
-
-### Raw Liquid.js syntax
-
-You can also apply raw Liquid.js syntax to the variable by clicking on the **Raw** button which will reveal the raw Liquid.js content that will be applied to the variable.
-
-## Adding logic with Liquid Filters
-
-Novu supports Liquid filters to add dynamic and conditional content to your notifications. Below are examples of how to use the top 10 Liquid filters in real-world notification templates.
-
-When comparing string values in Liquid conditional statements, for example `{% if context.tenant.data.branding.logoUrl != 'value' %}`, always use single quotes (`'value'`). Double quotes (`"value"`) are not supported currently.
-
-
- Learn more about the Liquid Templating Language.
-
-
-### `capitalize`
-
-Use `capitalize` to ensure proper formatting for user names.
-
-```liquid
-Hello {{ subscriber.firstName | capitalize }},
-Welcome to Novu! We're excited to have you on board.
-```
-
-**Output**:
-`Hello John,
-Welcome to Novu! We're excited to have you on board.`
-
-### `upcase`
-
-Use `upcase` for emphasizing specific information like workspace names.
-
-```liquid
-Your workspace {{ payload.workspaceName | upcase }} has been successfully created.
-```
-
-**Output**:
-`Your workspace TEAM ALPHA has been successfully created.`
-
-### `downcase`
-
-Use `downcase` for consistent email formatting or usernames.
-
-```liquid
-Hi {{ subscriber.email | downcase }},
-We've sent a confirmation to your inbox.
-```
-
-**Output**:
-`Hi john.doe@example.com,
-We've sent a confirmation to your inbox.`
-
-### `date`
-
-Use `date` to format subscription or event dates.
-
-```liquid
-Your subscription will renew on {{ payload.renewalDate | date: "%B %d, %Y" }}.
-```
-
-**Output**:
-`Your subscription will renew on December 31, 2024.`
-
-### `truncate`
-
-Use `truncate` to shorten long content like notification messages.
-
-```liquid
-New comment on your post: {{ payload.commentText | truncate: 20 }}
-Click here to read more.
-```
-
-**Output**:
-`New comment on your post: Great work on your...
-Click here to read more.`
-
-### `truncatewords`
-
-Use `truncatewords` to limit the number of words in a preview.
-
-```liquid
-{{ subscriber.firstName }}, here's a preview of the article:
-{{ payload.articleExcerpt | truncatewords: 5 }}
-```
-
-**Output**:
-`John, here's a preview of the article:
-Novu is a flexible and...`
-
-### `replace`
-
-Use `replace` to dynamically update template content.
-
-```liquid
-Hi {{ subscriber.firstName }},
-Your {{ payload.subscriptionType | replace: "basic", "premium" }} subscription is active.
-```
-
-**Output**:
-`Hi John,
-Your premium subscription is active.`
-
-### `split`
-
-Use `split` to parse tags or interests.
-
-```liquid
-You have new updates in {{ payload.tags | split: "," | join: ", " }}.
-```
-
-**Input**:
-`"announcements,updates,offers"`
-
-**Output**:
-`You have new updates in announcements, updates, offers.`
-
-### `join`
-
-Use `join` to list multiple items in a human-readable way.
-
-```liquid
-Hello {{ subscriber.firstName }},
-You have the following items pending: {{ payload.tasks | join: ", " }}.
-```
-
-**Input**:
-`["Upload documents", "Confirm email", "Schedule meeting"]`
-
-**Output**:
-`Hello John,
-You have the following items pending: Upload documents, Confirm email, Schedule meeting.`
-
-### `default`
-
-Use `default` to provide fallback values.
-
-```liquid
-Hi {{ subscriber.nickname | default: subscriber.firstName }},
-Your account settings are updated.
-```
-
-**Output (when nickname is null)**:
-`Hi John,
-Your account settings are updated.`
-
-
- }
- href="https://liquidjs.com/filters/overview.html?utm_source=Novu"
- description="Learn more about 40+ filters supported by LiquidJS"
- />
-
-
-
-## Previewing and testing notification templates
-
-When your notification template is ready, use the **Preview** mode to visualize how your notification will look. You can:
-
-- **Test dynamic payload data:** Provide sample data to see how your template renders with different values.
-- **Send test notifications:** Save your template, return to the workflow canvas, and run a test with real trigger data.
diff --git a/content/docs/platform/workflow/throttle-step.mdx b/content/docs/platform/workflow/throttle-step.mdx
deleted file mode 100644
index 56e95b54e..000000000
--- a/content/docs/platform/workflow/throttle-step.mdx
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: 'Throttle Step'
-description: 'Learn how to use the Throttle step in Novu workflows to control notification frequency.'
-icon: 'Gauge'
----
-
-The Throttle step lets you limit the number of workflow executions within a specified time window. You can configure throttling directly in Novu workflow editor. By setting limits, you can prevent subscribers from receiving duplicate or excessive notifications when a trigger fires repeatedly.
-
-
-
-Some use cases for this include:
-- Limiting high-frequency alerts (such as CPU or billing usage checks) to one notification per hour, day, or week.
-- Preventing duplicate messages from automated cron jobs or recurring triggers.
-- Controlling notification frequency for subscribers who belong to multiple projects or contexts.
-
-## How the Throttle step works
-
-At a high level, the throttle step counts the number of times a workflow is triggered for a specific subscriber.
-
-- If the count is within the defined execution threshold for the time window, then the workflow proceeds as normal.
-- If the count exceeds the threshold, then the workflow execution is halted at the throttle step. Any steps placed after the throttle step in your workflow will not be run. For example, if you have an email step following a throttle step, then that email will not be sent once the limit is reached.
- 
-
-Throttling applies consistently across channels, whether the workflow sends email, in-app, SMS, chat, or push notifications.
-
-The throttle step applies to all workflows, including those marked as critical. If a critical workflow is triggered more frequently than the throttle limit allows, then it will be skipped just like any other workflow. This ensures that even high-priority alerts do not overwhelm a subscriber.
-
-To the subscriber, the experience is transparent. They are not aware that any throttling has occurred; they either receive a notification or they don’t. The subscriber is never exposed to information about the throttle itself.
-
-## Throttle Step properties
-
-You can find and edit all the properties for the Throttle step directly within the workflow editor.
-
-- **Navigate to the Workflow Editor**: Go to the **Workflows** page in your Novu dashboard and either create a new workflow or select an existing one.
-- **Add the Throttle Step**: On the workflow canvas, click the `+` icon between steps to open the step library, then select Throttle from the list.
- 
-- **Access the properties panel**: Click on the newly added **Throttle** step on the canvas. This will open its configuration panel on the right-hand side of the screen.
- 
-
-This panel contains all properties for the step, including:
-
-- **Name**: A descriptive label for the step in the workflow editor.
-- **Identifier**: A unique key used to reference the step programmatically.
-- **Throttle Window**: The main configuration for setting the time period and execution limits.
-
-## Throttle window
-
-The Throttle window defines the time period in which executions are counted. Within this window, only the specified number of executions are allowed.
-
-In the Throttle step properties panel, you will find the options to set your Throttle Window. You can choose between two main modes:
-
-- Fixed: Select this option to configure a predefined time window using the Throttle for and Execution threshold fields.
-- Dynamic: Select this option to use a window defined in your trigger payload. You will then configure the Dynamic window key to specify which payload variable to use.
-
-### Fixed window
-
-In fixed window, the time frame is predefined in the workflow editor. Use this mode when the time window for throttling is constant and known in advance. For example, "allow only one login alert per hour."
-
-
-
-- **Throttle for**: Sets the fixed duration of the time window. The minimum duration is one minute. You can set this in minutes, hours, or days.
-- **Execution threshold**: Defines the maximum number of workflow executions allowed within the specified time window. This defaults to 1.
-- **Group throttling by**: By default, all throttling is grouped by the `subscriberId`. This field allows you to add a second aggregation key based on a variable from your trigger `payload`. This is useful for creating more throttling rules.
-
-Here is an example of how they work together:
-
-Imagine you want to send a notification for each project a user belongs to, but no more than once a week per project. You can set `Throttle for` to "7 days" and `Group throttling by` to `payload.projectId`. This ensures the user receives one alert for Project A and one for Project B within the same week, instead of just one alert total.
-
-### Dynamic window
-
-In dynamic window, the time frame is determined by data sent in the trigger payload. Use this mode when the throttle duration or end time needs to be flexible and defined at the time of the trigger. For example, "throttle billing alerts until the end of the current billing cycle."
-
-
-
-- **Dynamic window key**: Specify the key in your trigger payload that contains the dynamic window configuration. For example, `payload.throttleUntil` or `payload.customWindow`.
-
- The value for the dynamic window key can be provided in one of two formats:
- 1. **ISO-8601 Timestamp (string)**:
- This format throttles executions until a specific future date and time. Any new triggers before this timestamp will be evaluated against the throttle limit.
-
- ```json
- {
- "throttleUntil": "2025-10-31T23:59:59Z"
- }
- ```
- 2. **Duration object**: This format throttles executions for a duration relative to the time of the first trigger. It follows the same structure as the fixed window configuration.
-
- ```json
- {
- "customWindow": { "amount": 30, "unit": "minutes" }
- }
- ```
-
-- **Execution threshold**: Works the same as in the fixed window mode.
-
-- **Group throttling by**: This also functions identically to the fixed window mode.
\ No newline at end of file
diff --git a/content/docs/platform/workflow/trigger-workflow.mdx b/content/docs/platform/workflow/trigger-workflow.mdx
new file mode 100644
index 000000000..874de2897
--- /dev/null
+++ b/content/docs/platform/workflow/trigger-workflow.mdx
@@ -0,0 +1,232 @@
+---
+pageTitle: 'Trigger Workflow'
+title: 'Trigger Workflow'
+description: 'Learn how workflows are triggered in Novu using the Event API, including triggering workflows for individual subscribers, attaching context data, and broadcasting notifications to topics.'
+icon: 'Zap'
+---
+
+Triggering a workflow starts the execution of a notification pipeline in Novu. A workflow is triggered when an event is sent to Novu.
+
+When a workflow is triggered, Novu resolves the target subscribers, evaluates workflow logic, and executes each configured step to deliver notifications across the selected channels. Trigger requests can include payload data, context, or target a topic, allowing you to control both who receives the notification and what data is available during execution.
+
+You can test a workflow directly from the workflow editor in the Novu dashboard before triggering it from your application. This allows you to validate step configuration and notification content for a specific subscriber.
+
+## Trigger Event API
+
+Workflows in Novu are triggered by sending events to the Event API. An event represents an action in your system, for example, an order created or a comment added and is mapped to a workflow using the workflow’s trigger identifier.
+
+When you trigger an event, you specify:
+
+- The workflow to execute.
+- The subscriber (or subscribers) the notification is intended for.
+- The payload data used to personalize notification content.
+
+At a minimum, triggering a workflow requires the workflow trigger identifier and a subscriber identifier.
+
+
+
+```ts
+import { Novu } from "@novu/api";
+
+const novu = new Novu({ secretKey: "" });
+
+await novu.trigger({
+ workflowId: "workflow_identifier",
+ to: [{ subscriberId: "string" }],
+});
+```
+
+
+```bash
+curl -X POST 'https://api.novu.co/v1/events/trigger' /
+-H 'Content-Type: application/json' /
+-H 'Accept: application/json' /
+-H 'Authorization: ApiKey ' /
+-d '{
+ "name": "workflow_identifier",
+ "to": {
+ "subscriberId": "string"
+ }
+}'
+```
+
+
+
+For full request options and response details, see the [Trigger Event API](/api-reference/events/trigger-event) reference.
+
+Once the event is received, Novu executes the workflow, evaluates step conditions, resolves variables, and delivers notifications across the configured channels.
+
+From here, you can extend event triggering by attaching context data or targeting multiple subscribers using topics.
+
+## Trigger a workflow with context
+
+You can attach context data when triggering a workflow using the Event API. Context can be referenced from existing contexts created in the Novu dashboard by providing the context type and identifier or defined inline at trigger time. Any context passed with the event is available to all downstream steps and channel templates during workflow execution.
+
+Context data is passed using the `context` object in the trigger request.
+
+
+
+```ts
+import { Novu } from "@novu/api";
+
+const novu = new Novu({ secretKey: "" });
+
+await novu.trigger({
+ workflowId: "workflow_identifier",
+ to: [{ subscriberId: "string" }],
+ context: {
+ context_type: "context_identifier",
+ region: "us-east-1",
+ app: "dashboard"
+ }
+});
+```
+
+
+```bash
+curl -X POST "https://api.novu.co/v1/events/trigger" \
+ -H "Authorization: ApiKey " \
+ -H "Content-Type: application/json" \
+ -H 'Accept: application/json' /
+ -d '{
+ "name": "workflow_identifier",
+ "to": [{ "subscriberId": "string" }],
+ "context": {
+ "context_type": "context_identifier",
+ "region": "us-east-1",
+ "app": "dashboard"
+ }
+ }'
+```
+
+
+
+To learn how contexts work and how to manage them, see the [Context documentation](/platform/workflow/advanced-features/contexts/contexts-in-workflows.mdx).
+
+## Trigger a workflow to a topic
+
+Once you’ve created topics and added subscribers, you can trigger workflows to those subscribers in bulk. Triggering a workflow to a topic is Novu’s primary mechanism for broadcasting notifications to large audiences with a single API call.
+
+When you trigger a workflow using a topic key, Novu performs a fan-out: it resolves all subscribers in the topic and executes the workflow independently for each subscriber.
+
+To learn how to create and manage Topics, see the [Topics API reference](/api-reference/topics/topic-schema).
+
+### Trigger to a single topic
+
+The most common use case is sending a notification to all subscribers within a single topic. This is suitable for announcements, incident updates, or targeted broadcasts.
+
+To trigger a workflow to a topic, set the `to` field with `type: "Topic"` and provide the corresponding `topicKey`.
+
+
+
+```ts
+import { Novu } from "@novu/api"
+
+const novu = new Novu({ secretKey: "", });
+
+await novu.trigger({
+ workflowId: "workflow_identifier",
+ to: { type: "Topic", topicKey: "topic_key" },
+});
+```
+
+
+```bash
+curl -X POST 'https://api.novu.co/v1/events/trigger' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-H 'Authorization: ApiKey ' \
+-d '{
+ "name": "workflow_identifier",
+ "to": {
+ "type": "Topic",
+ "topicKey": "topic_key"
+ }
+}'
+```
+
+
+
+### Trigger to multiple topics
+
+You can broadcast a notification to multiple topics by passing an array to the `to` field. This is useful when your audience spans multiple groups, such as notifying both paying-customers and beta-testers.
+
+Novu automatically de-duplicates subscribers. If a subscriber belongs to more than one of the specified topics, they will receive the notification only once.
+
+
+
+```ts
+import { Novu } from "@novu/api"
+
+const novu = new Novu({ secretKey: "", });
+
+await novu.trigger({
+ workflowId: "workflow_identifier",
+ to: [
+ { type: "Topic", topicKey: "topic_key_1" },
+ { type: "Topic", topicKey: "topic_key_2" }
+ ]
+});
+```
+
+
+```bash
+curl -X POST 'https://api.novu.co/v1/events/trigger' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-H 'Authorization: ApiKey ' \
+-d '{
+ "name": "workflow_identifier",
+ "to": [
+ {
+ "type": "Topic",
+ "topicKey": "topic_key_1"
+ },
+ {
+ "type": "Topic",
+ "topicKey": "topic_key_2"
+ }
+ ]
+}'
+```
+
+
+
+### Exclude a subscriber from a topic trigger
+
+When a workflow is triggered to a topic, all subscribers in that topic are included by default. You can exclude specific subscribers from receiving the notification for that trigger by using the `exclude` field.
+
+This exclusion applies only to the current trigger request and does not modify the topic membership.
+
+
+
+```ts
+import { Novu } from "@novu/api"
+
+const novu = new Novu({ secretKey: "", });
+
+await novu.trigger({
+ workflowId: "workflow_identifier",
+ to: [{ type: "Topic", topicKey: "topic_key", exclude: ["subscriber-id"] }],
+});
+```
+
+
+```bash
+curl -X POST 'https://api.novu.co/v1/events/trigger' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-H 'Authorization: ApiKey ' \
+-d '{
+ "name": "workflow_identifier",
+ "to": [
+ {
+ "type": "Topic",
+ "topicKey": "topic_key",
+ "exclude": ["subscriber-id"]
+ }
+ ]
+}
+```
+
+
\ No newline at end of file
diff --git a/public/images/Add-filter.png b/public/images/Add-filter.png
deleted file mode 100644
index 1f17bdfd0..000000000
Binary files a/public/images/Add-filter.png and /dev/null differ
diff --git a/public/images/Create-new-orgnization.png b/public/images/Create-new-orgnization.png
deleted file mode 100644
index 2d52323a1..000000000
Binary files a/public/images/Create-new-orgnization.png and /dev/null differ
diff --git a/public/images/Dashboead-sidebar.png b/public/images/Dashboead-sidebar.png
deleted file mode 100644
index 2d67d0d60..000000000
Binary files a/public/images/Dashboead-sidebar.png and /dev/null differ
diff --git a/public/images/Deley-action-properties.png b/public/images/Deley-action-properties.png
deleted file mode 100644
index 214de2fd4..000000000
Binary files a/public/images/Deley-action-properties.png and /dev/null differ
diff --git a/public/images/Template Store.gif b/public/images/Template Store.gif
deleted file mode 100644
index 69c32ce3f..000000000
Binary files a/public/images/Template Store.gif and /dev/null differ
diff --git a/public/images/abandoned-cart-recovery-workflow.png b/public/images/abandoned-cart-recovery-workflow.png
deleted file mode 100644
index c1fd16aa3..000000000
Binary files a/public/images/abandoned-cart-recovery-workflow.png and /dev/null differ
diff --git a/public/images/activity-feed-usecase.png b/public/images/activity-feed-usecase.png
deleted file mode 100644
index ad43f9804..000000000
Binary files a/public/images/activity-feed-usecase.png and /dev/null differ
diff --git a/public/images/activity-feed.png b/public/images/activity-feed.png
deleted file mode 100644
index 1d5cdfcc9..000000000
Binary files a/public/images/activity-feed.png and /dev/null differ
diff --git a/public/images/add-fields-kotlin.png b/public/images/add-fields-kotlin.png
deleted file mode 100644
index 258875165..000000000
Binary files a/public/images/add-fields-kotlin.png and /dev/null differ
diff --git a/public/images/create&edit-layouts.png b/public/images/create&edit-layouts.png
deleted file mode 100644
index 320883c3a..000000000
Binary files a/public/images/create&edit-layouts.png and /dev/null differ
diff --git a/public/images/create-workflow-nextjs.png b/public/images/create-workflow-nextjs.png
deleted file mode 100644
index 2038483ce..000000000
Binary files a/public/images/create-workflow-nextjs.png and /dev/null differ
diff --git a/public/images/create-workflow.png b/public/images/create-workflow.png
deleted file mode 100644
index 2038483ce..000000000
Binary files a/public/images/create-workflow.png and /dev/null differ
diff --git a/public/images/custom-code-input.png b/public/images/custom-code-input.png
deleted file mode 100644
index 0d65eac89..000000000
Binary files a/public/images/custom-code-input.png and /dev/null differ
diff --git a/public/images/custom-code-output.png b/public/images/custom-code-output.png
deleted file mode 100644
index 5af040eb7..000000000
Binary files a/public/images/custom-code-output.png and /dev/null differ
diff --git a/public/images/default-sub-kotlin.png b/public/images/default-sub-kotlin.png
deleted file mode 100644
index 6a699b67b..000000000
Binary files a/public/images/default-sub-kotlin.png and /dev/null differ
diff --git a/public/images/default-ui.png b/public/images/default-ui.png
deleted file mode 100644
index aa240d8a6..000000000
Binary files a/public/images/default-ui.png and /dev/null differ
diff --git a/public/images/digest-email.png b/public/images/digest-email.png
deleted file mode 100644
index 511fac928..000000000
Binary files a/public/images/digest-email.png and /dev/null differ
diff --git a/public/images/digest-flow.png b/public/images/digest-flow.png
deleted file mode 100644
index 2945978dd..000000000
Binary files a/public/images/digest-flow.png and /dev/null differ
diff --git a/public/images/digest-info.png b/public/images/digest-info.png
deleted file mode 100644
index b7eff0600..000000000
Binary files a/public/images/digest-info.png and /dev/null differ
diff --git a/public/images/digest-node.png b/public/images/digest-node.png
deleted file mode 100644
index 5d1eb02a8..000000000
Binary files a/public/images/digest-node.png and /dev/null differ
diff --git a/public/images/digest-settings.png b/public/images/digest-settings.png
deleted file mode 100644
index a2eeac71c..000000000
Binary files a/public/images/digest-settings.png and /dev/null differ
diff --git a/public/images/digest.png b/public/images/digest.png
deleted file mode 100644
index a4a4d0f60..000000000
Binary files a/public/images/digest.png and /dev/null differ
diff --git a/public/images/edit-nextjs.png b/public/images/edit-nextjs.png
deleted file mode 100644
index 258875165..000000000
Binary files a/public/images/edit-nextjs.png and /dev/null differ
diff --git a/public/images/email-node.png b/public/images/email-node.png
deleted file mode 100644
index 4115076f4..000000000
Binary files a/public/images/email-node.png and /dev/null differ
diff --git a/public/images/email-nodejs.png b/public/images/email-nodejs.png
deleted file mode 100644
index 6a3aa4f26..000000000
Binary files a/public/images/email-nodejs.png and /dev/null differ
diff --git a/public/images/email2-nodejs.png b/public/images/email2-nodejs.png
deleted file mode 100644
index 26e89e844..000000000
Binary files a/public/images/email2-nodejs.png and /dev/null differ
diff --git a/public/images/email3-nodejs.png b/public/images/email3-nodejs.png
deleted file mode 100644
index 0108941f5..000000000
Binary files a/public/images/email3-nodejs.png and /dev/null differ
diff --git a/public/images/filtering-by-channel.png b/public/images/filtering-by-channel.png
deleted file mode 100644
index c85de1c06..000000000
Binary files a/public/images/filtering-by-channel.png and /dev/null differ
diff --git a/public/images/filtering-by-workflow.png b/public/images/filtering-by-workflow.png
deleted file mode 100644
index d68313ace..000000000
Binary files a/public/images/filtering-by-workflow.png and /dev/null differ
diff --git a/public/images/in-app-node.png b/public/images/in-app-node.png
deleted file mode 100644
index 74eb48fd8..000000000
Binary files a/public/images/in-app-node.png and /dev/null differ
diff --git a/public/images/in-app-react.png b/public/images/in-app-react.png
deleted file mode 100644
index d62965322..000000000
Binary files a/public/images/in-app-react.png and /dev/null differ
diff --git a/public/images/inapp-editor.png b/public/images/inapp-editor.png
deleted file mode 100644
index 93a58bdc4..000000000
Binary files a/public/images/inapp-editor.png and /dev/null differ
diff --git a/public/images/integrations-store.png b/public/images/integrations-store.png
deleted file mode 100644
index 1b13fb5f4..000000000
Binary files a/public/images/integrations-store.png and /dev/null differ
diff --git a/public/images/mailbox-nextjs.png b/public/images/mailbox-nextjs.png
deleted file mode 100644
index 70724b341..000000000
Binary files a/public/images/mailbox-nextjs.png and /dev/null differ
diff --git a/public/images/manage-layouts.png b/public/images/manage-layouts.png
deleted file mode 100644
index 11020a0cf..000000000
Binary files a/public/images/manage-layouts.png and /dev/null differ
diff --git a/public/images/navigating-novu-cloud.png b/public/images/navigating-novu-cloud.png
deleted file mode 100644
index f2d2c73b8..000000000
Binary files a/public/images/navigating-novu-cloud.png and /dev/null differ
diff --git a/public/images/set-variant.png b/public/images/set-variant.png
deleted file mode 100644
index e96852681..000000000
Binary files a/public/images/set-variant.png and /dev/null differ
diff --git a/public/images/sms-editor.png b/public/images/sms-editor.png
deleted file mode 100644
index 87c48e5ea..000000000
Binary files a/public/images/sms-editor.png and /dev/null differ
diff --git a/public/images/sub-activity.png b/public/images/sub-activity.png
deleted file mode 100644
index 4ffd65cd8..000000000
Binary files a/public/images/sub-activity.png and /dev/null differ
diff --git a/public/images/subscriber-online-filter.gif b/public/images/subscriber-online-filter.gif
deleted file mode 100644
index 5f316c14e..000000000
Binary files a/public/images/subscriber-online-filter.gif and /dev/null differ
diff --git a/public/images/switch-organization.png b/public/images/switch-organization.png
deleted file mode 100644
index a57697863..000000000
Binary files a/public/images/switch-organization.png and /dev/null differ
diff --git a/public/images/template-nodejs.png b/public/images/template-nodejs.png
deleted file mode 100644
index de7f4b67c..000000000
Binary files a/public/images/template-nodejs.png and /dev/null differ
diff --git a/public/images/test-successful-nextjs.jpg b/public/images/test-successful-nextjs.jpg
deleted file mode 100644
index 36ac34df2..000000000
Binary files a/public/images/test-successful-nextjs.jpg and /dev/null differ
diff --git a/public/images/trigger-code.png b/public/images/trigger-code.png
deleted file mode 100644
index 849c13813..000000000
Binary files a/public/images/trigger-code.png and /dev/null differ
diff --git a/public/images/troubleshoot.png b/public/images/troubleshoot.png
deleted file mode 100644
index 1f18566f7..000000000
Binary files a/public/images/troubleshoot.png and /dev/null differ
diff --git a/public/images/v1-v0-variant.png b/public/images/v1-v0-variant.png
deleted file mode 100644
index 0a5113b70..000000000
Binary files a/public/images/v1-v0-variant.png and /dev/null differ
diff --git a/public/images/values-in-app.png b/public/images/values-in-app.png
deleted file mode 100644
index 5866f1aa7..000000000
Binary files a/public/images/values-in-app.png and /dev/null differ
diff --git a/public/images/vars-and-test-email-nextjs.png b/public/images/vars-and-test-email-nextjs.png
deleted file mode 100644
index ba19dc3fc..000000000
Binary files a/public/images/vars-and-test-email-nextjs.png and /dev/null differ
diff --git a/public/images/vue-email-notification.png b/public/images/vue-email-notification.png
deleted file mode 100644
index 1ee159845..000000000
Binary files a/public/images/vue-email-notification.png and /dev/null differ
diff --git a/public/images/workflow-editor.png b/public/images/workflow-editor.png
deleted file mode 100644
index 8689d241e..000000000
Binary files a/public/images/workflow-editor.png and /dev/null differ
diff --git a/public/images/workflow-kotlin.png b/public/images/workflow-kotlin.png
deleted file mode 100644
index 2038483ce..000000000
Binary files a/public/images/workflow-kotlin.png and /dev/null differ
diff --git a/public/images/workflows/activity-feed/request-tab.png b/public/images/workflows/activity-feed/request-tab.png
new file mode 100644
index 000000000..6d2bec9fe
Binary files /dev/null and b/public/images/workflows/activity-feed/request-tab.png differ
diff --git a/public/images/workflows/activity-feed/workflow-run.png b/public/images/workflows/activity-feed/workflow-run.png
new file mode 100644
index 000000000..855c127b2
Binary files /dev/null and b/public/images/workflows/activity-feed/workflow-run.png differ
diff --git a/public/images/workflows/activity-feed/workflow-runs-list.png b/public/images/workflows/activity-feed/workflow-runs-list.png
new file mode 100644
index 000000000..711f3e427
Binary files /dev/null and b/public/images/workflows/activity-feed/workflow-runs-list.png differ
diff --git a/public/images/platform/workflow/delay/dynamic-delay.png b/public/images/workflows/add-and-configure-steps/action-steps/delay/dynamic-delay.png
similarity index 100%
rename from public/images/platform/workflow/delay/dynamic-delay.png
rename to public/images/workflows/add-and-configure-steps/action-steps/delay/dynamic-delay.png
diff --git a/public/images/platform/workflow/delay/fixed-delay.gif b/public/images/workflows/add-and-configure-steps/action-steps/delay/fixed-delay.gif
similarity index 100%
rename from public/images/platform/workflow/delay/fixed-delay.gif
rename to public/images/workflows/add-and-configure-steps/action-steps/delay/fixed-delay.gif
diff --git a/public/images/workflows/add-and-configure-steps/action-steps/digest/configure-digest.gif b/public/images/workflows/add-and-configure-steps/action-steps/digest/configure-digest.gif
new file mode 100644
index 000000000..4b5e712dd
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/action-steps/digest/configure-digest.gif differ
diff --git a/public/images/workflows/add-and-configure-steps/action-steps/digest/regular-digest.gif b/public/images/workflows/add-and-configure-steps/action-steps/digest/regular-digest.gif
new file mode 100644
index 000000000..e28edf951
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/action-steps/digest/regular-digest.gif differ
diff --git a/public/images/workflows/add-and-configure-steps/action-steps/digest/scheduled-digest.png b/public/images/workflows/add-and-configure-steps/action-steps/digest/scheduled-digest.png
new file mode 100644
index 000000000..a16947e2f
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/action-steps/digest/scheduled-digest.png differ
diff --git a/public/images/workflows/dynamic-window.png b/public/images/workflows/add-and-configure-steps/action-steps/throttle/dynamic-window.png
similarity index 100%
rename from public/images/workflows/dynamic-window.png
rename to public/images/workflows/add-and-configure-steps/action-steps/throttle/dynamic-window.png
diff --git a/public/images/workflows/fixed-window.png b/public/images/workflows/add-and-configure-steps/action-steps/throttle/fixed-window.png
similarity index 100%
rename from public/images/workflows/fixed-window.png
rename to public/images/workflows/add-and-configure-steps/action-steps/throttle/fixed-window.png
diff --git a/public/images/workflows/throttle-panel.png b/public/images/workflows/add-and-configure-steps/action-steps/throttle/throttle-panel.png
similarity index 100%
rename from public/images/workflows/throttle-panel.png
rename to public/images/workflows/add-and-configure-steps/action-steps/throttle/throttle-panel.png
diff --git a/public/images/workflows/add-and-configure-steps/action-steps/throttle/throttle-window.gif b/public/images/workflows/add-and-configure-steps/action-steps/throttle/throttle-window.gif
new file mode 100644
index 000000000..a6b2c6659
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/action-steps/throttle/throttle-window.gif differ
diff --git a/public/images/workflows/add-and-configure-steps/add-step.gif b/public/images/workflows/add-and-configure-steps/add-step.gif
new file mode 100644
index 000000000..3748567ca
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/add-step.gif differ
diff --git a/public/workflow/media-assets/digest-engine.png b/public/images/workflows/add-and-configure-steps/digest-engine.png
similarity index 100%
rename from public/workflow/media-assets/digest-engine.png
rename to public/images/workflows/add-and-configure-steps/digest-engine.png
diff --git a/public/images/workflows/add-and-configure-steps/step-conditions/step-conditions.gif b/public/images/workflows/add-and-configure-steps/step-conditions/step-conditions.gif
new file mode 100644
index 000000000..9ab787c83
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/step-conditions/step-conditions.gif differ
diff --git a/public/images/workflows/notification-workflows/step-conditions.png b/public/images/workflows/add-and-configure-steps/step-conditions/step-conditions.png
similarity index 100%
rename from public/images/workflows/notification-workflows/step-conditions.png
rename to public/images/workflows/add-and-configure-steps/step-conditions/step-conditions.png
diff --git a/public/images/workflows/notification-workflows/workflow-step-conditions.png b/public/images/workflows/add-and-configure-steps/step-conditions/workflow-step-conditions.png
similarity index 100%
rename from public/images/workflows/notification-workflows/workflow-step-conditions.png
rename to public/images/workflows/add-and-configure-steps/step-conditions/workflow-step-conditions.png
diff --git a/public/images/workflows/add-and-configure-steps/steps.png b/public/images/workflows/add-and-configure-steps/steps.png
new file mode 100644
index 000000000..d37e4616a
Binary files /dev/null and b/public/images/workflows/add-and-configure-steps/steps.png differ
diff --git a/public/images/workflows/throttle-step-activity-feed.png b/public/images/workflows/add-and-configure-steps/throttle-step-activity-feed.png
similarity index 100%
rename from public/images/workflows/throttle-step-activity-feed.png
rename to public/images/workflows/add-and-configure-steps/throttle-step-activity-feed.png
diff --git a/public/images/workflows/throttle.png b/public/images/workflows/add-and-configure-steps/throttle.png
similarity index 100%
rename from public/images/workflows/throttle.png
rename to public/images/workflows/add-and-configure-steps/throttle.png
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/action-button.gif b/public/images/workflows/add-notification-content/channels-template-editors/action-button.gif
new file mode 100644
index 000000000..8891682d8
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/action-button.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/code-editor.png b/public/images/workflows/add-notification-content/channels-template-editors/code-editor.png
new file mode 100644
index 000000000..76f786f4d
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/code-editor.png differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/customize-avatar.gif b/public/images/workflows/add-notification-content/channels-template-editors/customize-avatar.gif
new file mode 100644
index 000000000..d44ac6715
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/customize-avatar.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/delete-layout.gif b/public/images/workflows/add-notification-content/channels-template-editors/delete-layout.gif
new file mode 100644
index 000000000..24fde34e0
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/delete-layout.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/digest-block.gif b/public/images/workflows/add-notification-content/channels-template-editors/digest-block.gif
new file mode 100644
index 000000000..6faed783f
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/digest-block.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/edit-layout.gif b/public/images/workflows/add-notification-content/channels-template-editors/edit-layout.gif
new file mode 100644
index 000000000..05a590298
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/edit-layout.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/email-layout.gif b/public/images/workflows/add-notification-content/channels-template-editors/email-layout.gif
new file mode 100644
index 000000000..d6fd86a2b
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/email-layout.gif differ
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/layouts-page.gif b/public/images/workflows/add-notification-content/channels-template-editors/layouts-page.gif
new file mode 100644
index 000000000..89b83d28d
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/layouts-page.gif differ
diff --git a/public/images/channels-and-providers/email/writing-email-template/show-block.gif b/public/images/workflows/add-notification-content/channels-template-editors/show-block.gif
similarity index 100%
rename from public/images/channels-and-providers/email/writing-email-template/show-block.gif
rename to public/images/workflows/add-notification-content/channels-template-editors/show-block.gif
diff --git a/public/images/workflows/add-notification-content/channels-template-editors/template-fields.gif b/public/images/workflows/add-notification-content/channels-template-editors/template-fields.gif
new file mode 100644
index 000000000..353b52514
Binary files /dev/null and b/public/images/workflows/add-notification-content/channels-template-editors/template-fields.gif differ
diff --git a/public/images/workflows/add-notification-content/personalize-content/configure-variable.gif b/public/images/workflows/add-notification-content/personalize-content/configure-variable.gif
new file mode 100644
index 000000000..a09e3a79b
Binary files /dev/null and b/public/images/workflows/add-notification-content/personalize-content/configure-variable.gif differ
diff --git a/public/images/workflows/add-notification-content/personalize-content/configure-variable.png b/public/images/workflows/add-notification-content/personalize-content/configure-variable.png
new file mode 100644
index 000000000..59c325a33
Binary files /dev/null and b/public/images/workflows/add-notification-content/personalize-content/configure-variable.png differ
diff --git a/public/images/workflows/configure-workflow/active-workflow.gif b/public/images/workflows/configure-workflow/active-workflow.gif
new file mode 100644
index 000000000..44f26d7f3
Binary files /dev/null and b/public/images/workflows/configure-workflow/active-workflow.gif differ
diff --git a/public/images/workflows/configure-workflow/add-tags.gif b/public/images/workflows/configure-workflow/add-tags.gif
new file mode 100644
index 000000000..08a874060
Binary files /dev/null and b/public/images/workflows/configure-workflow/add-tags.gif differ
diff --git a/public/images/workflows/configure-workflow/channel-preferences.png b/public/images/workflows/configure-workflow/channel-preferences.png
new file mode 100644
index 000000000..04995a1b6
Binary files /dev/null and b/public/images/workflows/configure-workflow/channel-preferences.png differ
diff --git a/public/images/workflows/configure-workflow/configure-workflow.png b/public/images/workflows/configure-workflow/configure-workflow.png
new file mode 100644
index 000000000..f54c7b3b3
Binary files /dev/null and b/public/images/workflows/configure-workflow/configure-workflow.png differ
diff --git a/public/images/workflows/configure-workflow/import-payload.gif b/public/images/workflows/configure-workflow/import-payload.gif
new file mode 100644
index 000000000..b1c037ebf
Binary files /dev/null and b/public/images/workflows/configure-workflow/import-payload.gif differ
diff --git a/public/images/workflows/configure-workflow/inline-variable.gif b/public/images/workflows/configure-workflow/inline-variable.gif
new file mode 100644
index 000000000..edc1a6296
Binary files /dev/null and b/public/images/workflows/configure-workflow/inline-variable.gif differ
diff --git a/public/images/workflows/notification-workflows/notification-severity.png b/public/images/workflows/configure-workflow/notification-severity.png
similarity index 100%
rename from public/images/workflows/notification-workflows/notification-severity.png
rename to public/images/workflows/configure-workflow/notification-severity.png
diff --git a/public/images/workflows/configure-workflow/workflow-payload.gif b/public/images/workflows/configure-workflow/workflow-payload.gif
new file mode 100644
index 000000000..af1673c3d
Binary files /dev/null and b/public/images/workflows/configure-workflow/workflow-payload.gif differ
diff --git a/public/images/workflows/create-a-workflow/create-a-workflow.png b/public/images/workflows/create-a-workflow/create-a-workflow.png
new file mode 100644
index 000000000..e53d0e865
Binary files /dev/null and b/public/images/workflows/create-a-workflow/create-a-workflow.png differ
diff --git a/public/images/workflows/create-a-workflow/create-from-explore.png b/public/images/workflows/create-a-workflow/create-from-explore.png
new file mode 100644
index 000000000..d3cfeded2
Binary files /dev/null and b/public/images/workflows/create-a-workflow/create-from-explore.png differ
diff --git a/public/images/workflows/create-a-workflow/create-from-template.png b/public/images/workflows/create-a-workflow/create-from-template.png
new file mode 100644
index 000000000..507f55b25
Binary files /dev/null and b/public/images/workflows/create-a-workflow/create-from-template.png differ
diff --git a/public/images/workflows/create-a-workflow/create-workflow.png b/public/images/workflows/create-a-workflow/create-workflow.png
new file mode 100644
index 000000000..6ba60a373
Binary files /dev/null and b/public/images/workflows/create-a-workflow/create-workflow.png differ
diff --git a/public/images/workflows/create-a-workflow/duplicate-a-workflow.png b/public/images/workflows/create-a-workflow/duplicate-a-workflow.png
new file mode 100644
index 000000000..7daf2f87d
Binary files /dev/null and b/public/images/workflows/create-a-workflow/duplicate-a-workflow.png differ
diff --git a/public/images/workflows/create-a-workflow/duplicate-workflow.png b/public/images/workflows/create-a-workflow/duplicate-workflow.png
new file mode 100644
index 000000000..af842f606
Binary files /dev/null and b/public/images/workflows/create-a-workflow/duplicate-workflow.png differ
diff --git a/public/images/workflows/inbox-notification-severity.png b/public/images/workflows/inbox-notification-severity.png
deleted file mode 100644
index d0ee12579..000000000
Binary files a/public/images/workflows/inbox-notification-severity.png and /dev/null differ
diff --git a/public/images/workflows/throttle-step.png b/public/images/workflows/throttle-step.png
deleted file mode 100644
index cbb81b678..000000000
Binary files a/public/images/workflows/throttle-step.png and /dev/null differ
diff --git a/src/middleware.ts b/src/middleware.ts
index d8d2d996a..e207a3993 100644
--- a/src/middleware.ts
+++ b/src/middleware.ts
@@ -79,6 +79,22 @@ export default async function middleware(request: NextRequest, event: NextFetchE
'/platform/inbox/react/styling#appearance-prop': '/platform/inbox/configuration/styling',
'/platform/inbox/react/headless': '/platform/inbox/headless-mode',
'/platform/inbox/react/localization': '/platform/inbox/advanced-concepts/localization',
+
+ // Workflow section (old → new structure)
+ '/platform/workflow/layouts':
+ '/platform/workflow/add-notification-content/channels-template-editors#email-layouts',
+ '/platform/workflow/template-editor':
+ '/platform/workflow/add-notification-content/channels-template-editors',
+ '/platform/workflow/build-a-workflow': '/platform/workflow/create-a-workflow',
+ '/platform/workflow/build-a-workflow#manage-payload-schema':
+ '/platform/workflow/configure-workflow#payload-schema',
+ '/platform/workflow/delay': '/platform/workflow/add-and-configure-steps#delay',
+ '/platform/workflow/digest': '/platform/workflow/add-and-configure-steps#digest',
+ '/platform/workflow/throttle-step': '/platform/workflow/add-and-configure-steps#throttle',
+ '/platform/workflow/step-conditions':
+ '/platform/workflow/add-and-configure-steps/step-conditions',
+ '/platform/workflow/channel-steps': '/platform/workflow/add-and-configure-steps#channel-steps',
+ '/platform/workflow/tags': '/platform/workflow/configure-workflow#tags',
};
if (pathname in redirectMap) {
+
+#### Digest block
+
+The Digest block allows you to loop over the events collected by your digest step and displays them in your email content. It handles both layout and repetition automatically.
+
+The Digest block is only available in Email steps that come after a Digest step in the workflow.
+
+When you add a digest block to your email template editor:
+- Novu automatically inserts a Repeat block that iterates over the digested events.
+- You can define how many times the event is iterated.
+- Inside the loop, you can also use the special alias variable `current` to reference the item currently being processed, for example, `current.payload.name`.
+- The block also supports rendering a summary using the `steps.digest-step.eventCount` variable, typically with the pluralize LiquidJS filter.
+
+
+
+
-
-## Digest configuration
-
-### Digest key
-
-If specified, the digest engine will group the events based on the `digestKey` and `subscriberId`, otherwise the digest engine will group the events based only on the subscriberId.
-
-The digest key might come useful when you want a particular subscriber to get events grouped on a custom field. For example when an actor likes the user's post, you might want to digest based on the `post_id` key.
-
-### Time interval
-
-The time interval determines how long the digest engine will wait before sending the message once created. You can specify the amount and the unit that best suits your needs.
-
-In the image below, `5` is the interval amount, and `mins` is the interval unit. Interval units can be `sec(s)`, `min(s)`, `hour(s)`, or `day(s)`.
-
-
-## Digest strategy types
-
-The strategy which Novu should use to handle the digest step. More details on available strategies below.
-
-Novu allows you to define different digest strategies depending on the actual use-case you are trying to achieve. At this point we allow you to select from 2 strategies:
-
-- Regular
-- Look-back
-- Scheduled
-
-Let's explore them in detail:
-
-### Regular strategy
-
-In regular strategy, a digest will always be created for the specified window time. Which means that from the first event trigger, if no active digest exists for this subscriber, one will be created and the user will receive the message only when the digest window time is reached.
-
-### Look-back strategy
-
-In the Look-Back strategy, before creating a digest, Novu will check if a message was sent to the user in the Look-back period. If a message was sent, a digest will be created. Otherwise, a message will be sent directly to the user and the digest creation will be skipped.
-
-Look-back digest has two intervals, `digest interval` and `look-back window`. First, it checks if any event is triggered within the past look-back window, only then a digest is created for the digest interval. If not, the event is considered non-digest and workflow execution continues to the next step.
-
-#### Example
-
-Let's set the digest interval as 20 minutes and the look-back interval as 15 minutes.
-
-If we trigger the first event. Since it is the first event and there was no event triggered in the past 15 minutes (look-back interval), this event will send a message immediately (without digest).
-Now, if we trigger a second event within 15 minutes range, then a new digest will be created with this second event. From now on, for the next 20 minutes (digest interval), all triggers will be digested, and after 20 minutes, the workflow will carry forward to the next step with digested events as a payload.
-
-### Scheduled digest
-
-
-
-In this case, the step will execute only if `payload.foo` is equal to `payload.bar` at runtime.
-
-You can also use subscriber variables in the same way:
-
-```json
-{
- "operator": "AND",
- "conditions": [
- {
- "field": "subscriber.firstName",
- "operator": "=",
- "value": "{{payload.firstName}}"
- }
- ]
-}
-```
-
-
-
-This enables flexible condition logic based on real-time data comparisons.
-
-## Building condition groups
-
-Novu allows you to group multiple conditions using AND and OR operators to create complex logic. For example:
-
-- **AND Group**: All conditions in the group must be true for the step to execute.
-- **OR Group**: At least one condition in the group must be true.
-
-Condition groups can also be nested for advanced use cases.
-
-Novu's Step Condition feature empowers you to build intelligent and dynamic workflows tailored to your specific use cases. By leveraging subscriber data, payload information, and step outcomes, you can ensure that each notification reaches the right audience at the right time with the appropriate content.
diff --git a/content/docs/platform/workflow/tags.mdx b/content/docs/platform/workflow/tags.mdx
deleted file mode 100644
index 1b5a8bde2..000000000
--- a/content/docs/platform/workflow/tags.mdx
+++ /dev/null
@@ -1,36 +0,0 @@
----
-pageTitle: 'Tags: Organizing Your Notifications'
-title: 'Tags'
-description: "Learn how to organize and manage notification tags using Novu's visual workflow editor for better user experience and notification management."
-icon: 'Tags'
----
-
-**Tags** act like labels or categories that help you organize and manage notifications in your app. By grouping notifications under specific tags, you can better control how they're filtered, displayed, or managed by both your app and your users.
-
-For example, you might want to group all security-related notifications together, separate from updates about account activity or promotional offers.
-
-## Why Use Tags?
-
-- **Filtering Notifications**: Tags make it easy to filter and display notifications based on categories.
- For instance, you can create a UI that allows users to view only security or promotional notifications. Learn more about using tags to filter notifications in the [Inbox](/platform/inbox/react/multiple-tabs) section.
-
-Think of it as organizing emails into folders—tags help keep things tidy and manageable for both you and your users.
-
-## How to Add Tags to Notifications
-
-
-
-### Applying Liquid Filters
-
-The variable popover will display a list of suggested Liquid Filters based on the variable type, you can apply one or more filters to the variable and re-order using drag and drop.
-Re-ordering filters is useful as the filters are applied in the order they are listed, and the output of each filter is passed to the next one.
-
-### Previewing filters output
-
-With more advanced filter logic, you can preview the output of the filters by clicking on the **Preview** button and pass the variable value to see how the filters will be applied.
-
-### Raw Liquid.js syntax
-
-You can also apply raw Liquid.js syntax to the variable by clicking on the **Raw** button which will reveal the raw Liquid.js content that will be applied to the variable.
-
-## Adding logic with Liquid Filters
-
-Novu supports Liquid filters to add dynamic and conditional content to your notifications. Below are examples of how to use the top 10 Liquid filters in real-world notification templates.
-
-