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:

• Meta Flow - Allows workflows to start based on user interactions within Meta platforms such as WhatsApp flows.
• Webhook - Allows workflows to be initiated through real-time API calls from external systems.
• Virtual No - 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 - Create the Workflow using a mixpanel cohort as the trigger.
• Moengage - Enables workflows to start based on events and user activity tracked in MoEngage.
• Notification Event - 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:
  

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

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:

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.

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.

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.