Source: https://fyno.docs.pageloop.ai/documentation/advanced-features/workflows

# Workflows

Workflows let you create an automated omnichannel notification experience for your users using a visual workflow builder.

This feature has the flexibility to connect to any third party tool like Mixpanel, Amplitude, MoEngage, Segment or to any web hooks and use conditional blocks to decide who should receive what notifications. You can also design a pre-defined chat workflow where you can send notifications based on user reply. All these can be achieved with ZERO code.

## What is a Workflow?

Workflows in Fyno is a notifications orchestration service that allows anyone to easily design intelligent notification flows without coding.

Workflow can be used to:

- Deliver notifications based on notification events created from and data sources like Segment, Mixpanel, Amplitude or any webhooks .
- Deliver notifications based on a user response to a SMS or WhatsApp notification.
- Design a transactional journey flow based on Notification event trigger
- Enables you to call any APIs and the response can be used to determine any conditional flow.
- Send Delivery reports back to your backend system or third party analytics tools like Mixpanel through callbacks.

**Workflow as a Transformation Layer**

Migrating to Fyno from your current service provider requires no modifications to your existing payload structure. Our workflow is designed to accept any payload format and provides flexible transformation capabilities to match your specific requirements. This migration can be completed without any technical development work on your end.

**Key benefits**:

- Maintain your current payload structure.
- Utilize built-in transformation tools.
- Complete migration without coding requirements.
- Preserve existing integrations and data formats.

## Core Concept

To effectively use workflows, it is important to understand the core building blocks that define how they function.

### Triggers

A trigger is the entry point of a workflow that starts execution and passes data into it. Every workflow must have exactly one trigger; without it, the workflow cannot run.

Triggers determine:

- When the workflow is activated.
- What data is passed into the workflow.
- How the workflow connects to internal or external systems.
- Different trigger types are designed for different use cases. Some are event-driven, some are based on user behavior, and others rely on external integrations. Choosing the right trigger ensures that workflows run at the appropriate time, receive the required data, and scale effectively.
- We support the following trigger types in workflows:

![](/images/all-workflow-widgets.png)

- [Meta Flow](/documentation/advanced-features/workflows/workflow-using-meta) - Allows workflows to start based on user interactions within Meta platforms such as WhatsApp flows.
- [Webhook](./workflow-webhook-trigger-setup) - Allows workflows to be initiated through real-time API calls from external systems.
- [Virtual No](./creating-a-workflow-with-incoming-message-trigger) - A virtual mobile number with the capability to receive incoming messages can be configured here. If you want to design a workflow based on user's response in WhatsApp or SMS, then this trigger should be used. Contact <support@fyno.io> for configuring a virtual number.
- [Mixpanel](/documentation/advanced-features/workflows/workflow-using-mixpanel-cohort) - Create the Workflow using a mixpanel cohort as the trigger.
- [Moengage](/documentation/advanced-features/workflows/workflow-using-moengage) - Enables workflows to start based on events and user activity tracked in MoEngage.
- [Notification Event](./workflow-notification-event-trigger) - Allows workflows to start based on the lifecycle of a notification.

**How to Choose the Right Trigger**

Selecting the correct trigger depends on your use case, data source, and desired behavior.

Use the following guidelines to decide:

- If your workflow needs to start based on backend or system events, use the Webhook trigger.
- If your workflow depends on user behavior tracked in analytics tools, use Mixpanel or MoEngage.
- If your workflow is part of a conversational or interactive flow, use Meta Flow or Virtual Number.
- If your workflow depends on notification delivery or engagement status, use Notification Events.

### Actions

Actions represent the actual operations performed within a workflow.

These are the steps where something happens as a result of the trigger and logic defined in the workflow.

**Examples of actions include**:

- Sending notifications (SMS, Email, Push, WhatsApp).
- Calling external APIs via webhooks.
- Updating user data or attributes.
- Triggering downstream systems.
- Actions are executed in sequence unless modified by conditions. They are responsible for delivering value to the end user or interacting with other systems.

### Conditions

Conditions allow you to introduce decision-making into your workflow.

They evaluate data and determine which path the workflow should take next. This enables you to create different experiences for different users based on their attributes or behavior.
Conditions typically follow an if/else structure.

Examples:

- If a user is a premium customer, send a premium offer; otherwise, send a standard offer
- If payment fails due to insufficient balance, retry later; otherwise, notify the user immediately
- Conditions make workflows dynamic and personalized, ensuring that users receive relevant communication instead of generic messages.

## How Workflows Work

The best way to explain the full scope and capability of Workflows is with an example. So, let’s dive right in.

Company ABC handles payments on its website via an external payment gateway.

The requirement is:

- To send a notification to the customer whenever an online payment succeeds or fails.
- If a payment fails, the Workflow should handle the failure scenario differently depending on the type of customer.
- If the user is a Power User, then convert the payment type to COD and confirm the order by sending an Email and SMS.
- If the user is non-Power User, then send a SMS with a payment link to retry payment.

Fyno’s Workflow makes it simple to operate this end-to-end process.

While Fyno’s notification events will handle the delivery of notifications, the true power of Workflows can be harnessed by calling any APIs as part of the Workflow and creating actions based on the response.

For this example, let’s assume that company ABC has two API endpoints -

- `/customers` - a `GET` endpoint that returns the type of customer.

- `/orders/{{customer_id}}` - a `PUT` endpoint that can update the customer’s order details\
  Here is how the end-to-end process would work:\
  ![](/images/automations-example.png)

1. Company ABC creates the Workflow in Fyno.
2. ABC then adds the Workflow URL as a webhook for successful and failed payments on the payment gateway site
3. Customer 1 makes a successful purchase on ABC’s website. The Workflow fires, and the customer receives an SMS and email confirming the successful purchase.
4. Customers 2 and 3 cannot make a successful online payment due to an issue with the bank. The Workflow fires, and due to the failed payment, it knows to trigger the `/customers` endpoint to get details about customer type.
5. Customer 2 is found to be a Power User (best user cohort in terms of monetisation) based on the result of the API call to `/customers`.
6. As a result, Customer 2’s order is confirmed (despite the failed payment), and the Workflow converts the order type to COD by making an API call to `/orders/{{ customer_id }}`.
7. If this API call is successful, the Workflow sends an order confirmation to Customer 2 via Email and SMS.
8. But Customer 3 is found to be a non-Power User.
9. So for Customer 3, workflow will trigger a notification with Payment link to retry and make the payment.
10. &#x20;Once the Customer 3 successfully makes the payment, he/she will receive Order Confirmation communication.

What would have otherwise required more than a few lines of code to configure, is being addressed with Fyno's Workflow feature, allowing you to add triggers, provide conditions and decide outcomes, all with a visual understanding of how the entire flow will work.

## Workflow Options Menu

Each workflow in the workflow list includes a **More Options** menu (**⋮**), which provides access to the most common workflow management actions. These actions allow you to update workflow information, review configuration details, create copies, request deletion, or publish changes without leaving the workflow list.

### Available Options

| Option                        | Description                                                                           |
| ----------------------------- | ------------------------------------------------------------------------------------- |
| **Edit**                      | Update the workflow name or change its assigned group.                                |
| **View Details**              | View the workflow, dependencies, versions, and where it is used across the workspace. |
| **Duplicate**                 | Create a copy of the workflow.                                                        |
| **Copy to Another Workspace** | Copy the workflow to a different workspace.                                           |
| **Delete**                    | Delete the workflow.                                                                  |
| **Go Live**                   | Publish the current **Test** version of the workflow to the **Live** environment.     |

## Edit Workflow

The **Edit** action allows you to modify the workflow's basic information without affecting its configuration. This is typically used to rename a workflow or reorganize it into a different group.

## Delete Workflow

The **Delete** action removes the workflow.

> **Note**: If approval requests are enabled, the deletion is submitted as an approval request instead of being deleted immediately.

Before deleting the workflow, the system displays any resources that reference it, helping you understand the impact of the deletion.

## Go Live

The **Go Live** action publishes the current **Test** version of a workflow to the **Live** environment, making the latest approved configuration available for production use.

After publishing, it is recommended to open **View Details**, switch to the **Live** environment, and confirm that:

- The expected changes are present.
- The **Last Updated** timestamp reflects the recent publication.

Performing this verification helps ensure that the correct version has been deployed successfully.

## View Details

The **View Details** page displays the modules and dependencies used by a workflow. It lists the resources that the workflow depends on, such as **Notification Events** and **Allowlist URLs**, helping you understand which workspace components are associated with the workflow before making changes or publishing updates.

This page is particularly useful for identifying workflow dependencies, reviewing version information, and comparing the **Test** and **Live** versions before deployment.

### Information Displayed

The page includes the following information:

| Field            | Description                                                                                                                                                                               |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**         | Displays the workflow name.                                                                                                                                                               |
| **Group Tag**    | Identifies the group to which the workflow belongs, such as _Customer Journey_ or _Internal Automation_.                                                                                  |
| **Environment**  | Indicates whether the displayed information relates to the **Test** or **Live** version of the workflow.                                                                                  |
| **Last Updated** | Shows when the selected environment was most recently modified, helping identify the latest published or draft version.                                                                   |
| **Depends On**   | Lists the resources referenced by the workflow, such as notification events, templates, components, Omni-Channel routes, API integrations, or external services used within the workflow. |
| **Used In**      | Lists the resources that reference the workflow, where applicable, allowing you to assess the impact of modifying or deleting it.                                                         |

### Environment Selection

The environment selector allows you to switch between the two available versions of a workflow without leaving the details page.

- **Test** displays the draft version used for development, testing, and validation before publication.
- **Live** displays the version currently available to end users.

## Copy to Another Workspace

The **Copy to Another Workspace** action lets you copy a workflow from the current workspace to another workspace. This is useful when you want to reuse an existing workflow across multiple workspaces without recreating it manually.

### Workflow Versioning During Copy

When a workflow is copied to another workspace, versioning is handled automatically.

- If the workflow does **not** exist in the destination workspace, the copied workflow is created as **Version 1 (Test)**.
- If the workflow **already exists** in the destination workspace, the copied workflow is created as a new standalone version (for example, **v2**). You can then review the new version and either save it as the current **Test** version or publish it as the new **Live** version.

This approach prevents existing versions in the destination workspace from being overwritten while giving you control over when to promote the copied version.

### Prerequisites

Before copying a workflow to another workspace, ensure that all dependent resources used by the workflow are already available in the destination workspace.

This includes:

- Notification Events referenced by the workflow.
- Allowlist URLs required by the workflow.
- Any other workflow dependencies or referenced resources that are specific to the source workspace.

> **Important**
>
> If the required dependencies are not present in the destination workspace, recreate or migrate them before copying the workflow to ensure it functions correctly after the transfer.

## Groups

Groups help you organize related workflows together. For instance, if you have multiple workflows for different stages of a customer journey (Welcome, Onboarding, Engagement, Retention, Re-engagement), you can create a Customer Journey group and assign all these workflows to it. This makes workflow filtering and management more efficient.

### How versioning works

Let's say we are copying a workflow from Workspace A to Workspace B. There are two versioning scenarios to keep in mind.
![](/images/workflow-versions.png)

1. If the workflow does not exist in Workspace B, then the version created by the copy process will always be `v1 (Test)`.
2. If the workflow already exists in Workspace B, then the copy process will create a new standalone version (neither test nor live). For example, if the version in Workspace B is `v1 (Test)`, then the process will create a new version called `v2`. You can select this version from the version dropdown beside the workflow name and click “Save” to change the version to `v2 (Test)`, or click the “Go Live” button to promote it to `v2 (Live)`. This ensures that changes to existing versions in the destination workspace are not overwritten and gives you control over when to save or promote the copied workflow.

## How to view change logs?

To view the history of all the modifications made to a template, you can utilize the change logs feature.

To do so, locate the history icon positioned at the top right corner of the template page, as shown in the image below, and click on it to view the change logs.

It shows the following details

- Who updated it
- Which version was updated
- At what date & time its updated.
  ![](/images/email_template_changelog.png)

## How versioning works

Let's say we are copying a notification event from Workspace A to Workspace B. There are two versioning scenarios to keep in mind.

1. If the notification event does not exist in Workspace B, then the version created by the copy process will always be `v1 (Test)`.
2. If the notification event already exists in Workspace B, then the copy process will create a new standalone version (neither test nor live). For example, if the version in Workspace B is `v1 (Test)`, then the process will create a new version called `v2`. You can select this version from the version dropdown beside the notification event name and click “Save” to change the version to `v2 (Test)`, or click the “Go Live” button to promote it to `v2 (Live)`. This ensures that changes to existing versions in the destination workspace are not overwritten and gives you control over when to save or promote the copied notification event.