Fluent Commerce Docs

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Content in this track:

Workflow Framework and the Rules SDK

Overview of Workflow Framework

Workflow Scenario (Recommended Practice)

End Of Track

Content in this track: Composing Workflows

Essential knowledge

Authors:

Dominik Malzacher, Esma Tuzovic, Cille Schliebitz, Anita Gu

Changed on:

1 July 2025

Overview

In this section you will learn all about rules, including:

Typical functions of a rule
How to use them in workflow
Rule design best practices and recommendations

Key points

Rules are the building blocks of Rulesets. They should be small, isolated, single-purpose, reusable, and composable.
Rulesets are composed of multiple rules to perform specific tasks.
Each rule within a Ruleset is executed in sequence.
A rule consists of a condition and an outcome (action).
Meaningful, descriptive names for Rulesets enhance workflow understanding and ease of troubleshooting.
Rulesets can perform functions like logical gates, state management, and notifying other domains.

In this module, we return to the concept of Rules as the building blocks for the Rulesets. We’ll also cover some guidelines for designing Rules.You are shown two different Lego configurations below, an Angel (Left) and Poseidon (Right). Take a minute to inspect both configurations. When you're ready....scroll down to reveal how this relates to designing rules. No alt provided

In the left image, the little Lego wing piece has been composed together with other pieces to form an Angel. In the right image, the same Lego piece is composed together with many other Lego pieces to form a Poseidon.The visual analogy demonstrates how rules should be:

Small, isolated single-purpose building blocks
Reusable and composable with other rules to form more complex business logic
Are the smallest building block for a task (ruleset) in a process

It also demonstrates how rulesets:

Are composed of one to many building blocks
May reuse rules from other rulesets one or more times
Combine to perform a specific purpose or task within a process

Let’s dig a little deeper...

In the case of the Angel the piece portrays an angel wing, while in the case of the Poseidon the piece is composed with other instances and forms a mustache, beard, and eyebrows. This is what rules are in the workflow framework — they can be composed together with other rules in a ruleset to form a completely unique outcome. Example: One ruleset may perform a certain task, while another ruleset composed of the same rule along with other rules performs a completely different task.Below is an example of a Ruleset (Ruleset A) showing 4 Rules (rules 1 to 4) configured within it. It illustrates the key concepts of rules execution, specifically:

Every Rule in the Ruleset is executed in sequence.
A Rule may or may not produce an outcome - i.e. it is conditional.

Multiple instances of a Rule are a design intention. No alt provided

Each Ruleset executes in sequence for the given context or event. No alt provided

Recommended practice regarding the naming convention for RulesetsEach Ruleset should only have a single purpose, and a Ruleset that changes the state of an entity should be clearly named to reflect that purpose. This is done so that a Workflow is easy to read and thus becomes easier to support.The diagram on the right shows an example, as well as a non-example of this recommendation. No alt provided

Key Takeaways and Best PracticesA Rule consists of two components:

The Rule Condition
The Outcome (Action)

Rules are meant to be:

Designed for a single purpose — they should do only one thing and produce only one action (if the Rule Condition is met).
Simple, isolated and reusable — only use a few lines of code. The key is not to lock away logic into the code. This idea aligns with a core value proposition we're trying to promote of flexibility and readability.
Reused - try to reuse as many of the Rules as possible. It might just be that their parameters are configured slightly differently or they may be in a slightly different sequence — that's our intention.

Note: Rules do not have to always produce an Action.When naming and defining Rulesets:

Aim to provide meaningful, descriptive names so that the workflow becomes self-describing and intuitive.
Try to align the name according to the piece of logic or function the Ruleset is performing within the workflow. This makes it easier for other people to review a workflow and understand its intention.

Benefits of applying rule best practices:

If there's a change in business requirements, it's easier to go in and make one, quick change.
Having single-purpose, isolated Rules simplifies the troubleshooting process, making it easier and faster to navigate the workflow and pinpoint and resolve issues.

Rulesets should be of a single purpose, such as to:

Perform a single function (E.g, CancelOrder) OR
Perform a logical gate for directing execution flow by using If/Else logic OR
Perform a State Management (E.g, SetAwaitingPayment) OR
Perform another purpose, such as notifying other orchestration contexts or other domains. (E.g., If an order comes in, notify the Inventory Catalog to reserve the product at that particular location — You will learn more about logical gates & state Management in the next lesson.