Deploy and Run your Rules SDK project

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

How-to Guide

Author:

Lesley Dean

Changed on:

9 Feb 2026

Key Points

A step-by-step guide to deploy your custom Rules Plugin and run the project.
A fully setup and functioning Fluent Account is required.
An API User with the `DEVELOPER` role (Note: If using a Training Account, the Account Admin already has this role applied)

Prerequisites

Setup your Development Environment for Rules SDK

Create a new Rules SDK Plugin Project

Write your first custom Rule using the Fluent Rules SDK (Hello World)

Steps

Version and Package Your Custom Rules Plugin

Before deployment, you need to understand the plugin naming convention and version your plugin correctly.A plugin is uniquely identified by: `{accountId}.{pluginNamespace}::{version}`Component Breakdown:

Component	Description	Example	Rules
`{accountId}`	Your Fluent Account ID or wildcard (for more details see Create a new Rules SDK Plugin Project).	`ACME` or `_`	Must match deployment account or use `_` for any account
`{pluginNamespace}`	Unique namespace for your plugin	`customDomain`	no special characters except underscore
`{version}`	Semantic version number	`0.0.1`	Follow SemVer format (major.minor.patch)

Complete Examples:

`ACME.customOrders::0.0.1`
`ACME.inventoryExtensions::1.0.0`
`_.returnExtensions::2.1.3`

Reminder

Only a single version of a plugin for a specific namespace can be active at a time. In order to update an existing plugin, the `{version}` must be increased and the `{pluginNamespace}` must remain the same. This will ensure that upon activation of the plugin, the new version will become active and the previous version is deactivated.If the intention is to create a new plugin (e.g. for a new feature or capability), the `{pluginNamespace}` must be changed.When to increment VERSION (keep namespace the same):

Bug fixes: `1.0.0` → `1.0.1`
New features (backward compatible): `1.0.0` → `1.1.0`
Breaking changes: `1.0.0` → `2.0.0`
Effect: New version activates, old version automatically deactivates

When to change NAMESPACE (reset version to 0.0.1):

Completely new feature set
Different business capability
Want to run alongside existing plugin
Effect: Both plugins remain active simultaneously

Example Scenario:

Initial deployment: `ACME.ordermanagement::1.0.0`
Bug fix - increment version: `ACME.ordermanagement::1.0.1`
(version 1.0.0 deactivates automatically)
New feature - add to existing: `ACME.ordermanagement::1.1.0`
(version 1.0.1 deactivates automatically)
New capability - change namespace: `ACME.inventory_sync::0.0.1`
(ordermanagement 1.1.0 remains active)

Warnings

It is very important to follow the above naming convention for plugins. If the correct naming is not followed, there is a risk of many versions of the same plugin staying active. This in turn can cause unnecessary load on the platform and may lead to performance degradation.SNAPSHOT VersionsWhile SNAPSHOT versions are technically possible, they are NOT recommended:

The `-SNAPSHOT` suffix conflicts with the `::` separator
Platform cannot properly parse `ACME.plugin::1.0.0-SNAPSHOT`
Solution: Use simple SemVer like `0.0.1` for development versions

In your pom.xml file, update the project version to `0.0.1` and package your Plugin using `mvn clean package`.This will create a JAR file in the project's `target` directory.Plugins are deployed using the Plugin REST API, and include 3 simple steps:

Make sure you have authenticated a user with the DEVELOPER role to perform the above steps.

Tip

You can use the Postman Collection and Environment file packaged within the SDK to perform these steps.

Add your custom Rule to a Workflow

Using the Workflow Modeller, add your LogHelloWorld rule to the Order CC workflow CREATE Ruleset. No alt provided

For additional help with the above, see the building workflows documentation.

Fire an Event to execute your Rule

To execute your LogHelloWorld Rule, you will need to trigger the Order CC workflow CREATE Ruleset.Do this by creating a new CC Order for the Retailer using a GraphQL `createOrderWithCustomer` mutation.This should successfully create the new Order in your Account, and fire the CREATE Orchestration Event to trigger execution of your Rule.You can view the Orchestration Audit Events log to see the custom Log Action produced by your Rule using the OMS Events Search:

What's next?

You have now completed the Getting Started guide.You are now ready to learn more about implementing Rules with the following topics:

Related content

Lesley Dean

Reminder

Bug fixes: `1.0.0` → `1.0.1`
New features (backward compatible): `1.0.0` → `1.1.0`
Breaking changes: `1.0.0` → `2.0.0`
Effect: New version activates, old version automatically deactivates

When to change NAMESPACE (reset version to 0.0.1):

Completely new feature set
Different business capability
Want to run alongside existing plugin
Effect: Both plugins remain active simultaneously

Example Scenario:

Initial deployment: `ACME.ordermanagement::1.0.0`
Bug fix - increment version: `ACME.ordermanagement::1.0.1`
(version 1.0.0 deactivates automatically)
New feature - add to existing: `ACME.ordermanagement::1.1.0`
(version 1.0.1 deactivates automatically)
New capability - change namespace: `ACME.inventory_sync::0.0.1`
(ordermanagement 1.1.0 remains active)

Deploy and Run your Rules SDK project

Key Points

Prerequisites

Setup your Development Environment for Rules SDK

Create a new Rules SDK Plugin Project

Write your first custom Rule using the Fluent Rules SDK (Hello World)

Steps

Version and Package Your Custom Rules Plugin

Add your custom Rule to a Workflow

Fire an Event to execute your Rule

What's next?

Related content

Rule Structure

Rules SDK - Writing Rules - Overview

Rule Development Guidelines & Recommended Practices

Lesley Dean

Building Blocks

By Type

Helpful Resources

Quick Links