Where to start: For Explorers
Topic
Author:
Fluent Commerce
Changed on:
9 July 2024
Docs
Author:
Fluent Commerce
Changed on:
9 July 2024
Copyright © 2024-2026 Fluent Retail Pty Ltd (trading as Fluent Commerce). Unless otherwise expressly stated in a current written agreement with Fluent Commerce or any of its affiliates or on any single page of the docs.fluentcommerce.com site, use of the materials on this site is strictly limited to viewing by individuals over 18 years old for legitimate commercially appropriate reasons; and any downloading, copying or other actions or uses of any kind or by any means of the materials on this site, including by artificial intelligence tools, is strictly prohibited. All other rights reserved.
Author:
Fluent Commerce
Changed on:
9 July 2024
The OMX UX Framework consists of the following parts:
Author:
Fluent Commerce
Changed on:
29 Aug 2025
Author:
Fluent Commerce
Changed on:
1 July 2024
Author:
Fluent Commerce
Changed on:
8 July 2024
| new cards to display information from Fluent APIs or external sources | new form field types that work with rules to extend user action capability | entirely new customised pages |
 |  |  |
Author:
Fluent Commerce
Changed on:
15 May 2024
The Workflow Engine is made of the following key components:
`Order`. An `Order` also has sub-entities that have specific meaning or information relevant to the `Order` at various stages within its lifecycle. For example, an `Order` typically contains one or more `OrderItem`s to define what items the `Customer` purchased. During the lifecycle of that `Order`, `Consignment`s are typically created to facilitate the fulfilment of that `Order`.A lifecycle typically involves a number of stages in which the entity moves. The stages that an entity moves through a workflow are represented through `State`s.The transition of an entity through its different states within the lifecycle is driven by business logic contained within Rules. `Rules` are grouped together in `RuleSets` which are executed in sequence when triggered by an `Event`.A retailer can have multiple workflows associated with a top-level entity. However, the entry trigger for each of the workflows should be unique. This allows for multiple workflows to exist with different entry triggers for the same Entity so that the system can identify one and only one workflow to execute.Workflows can contain multiple Rulesets, and Rulesets can contain multiple Rules.Workflows for an entity can interact with the workflows of other Entities. These interactions occur through Events.1 An entity is an object of importance in the system that we want to model and store information about. View Fluent Commerce's entity-relationship model which represents the business data schema in graphical form.2 A domain is an area of capability, such as Order Management, Global Inventory, Store Fulfillment, etc.Author:
Fluent Commerce
Changed on:
20 Sept 2024
A valid Module can contain any combination of Artifacts, however, they must also contain Metadata. Together, the Artifacts in a Module should provide a single package of domain capability or a reference to create or extend domain capability. Modules work together and extend each other.There are two categories of Module, Reference Modules and Extensions.| Artifact Name | Mandatory |
| Metadata | Yes |
| Rules | No |
| Workflows | No |
| Settings | No |
| Web App Manifests | No |
| Translations | No |
| UI Components | No |
| Structural data | No |
Author:
Fluent Commerce
Changed on:
5 Feb 2025
Authors:
Randy Chan, Esma Tuzovic, Cille Schliebitz, Holger Lierse, Shariff Dinah, Ben Harrison
Changed on:
9 Oct 2025
Roles are assigned within a Context, and higher levels of Context will automatically allocate to lower levels. For example, if a User has a Role which grants the ORDER_UPDATE Permission in the Account context, they will also have that Permission for all Retailers and Agents (Location level context) below that Account. `Type` field on a user represents the nature of the user. For example, a user with type API would indicate that this user is being used by an external system to integrate with the Fluent Commerce platform. Ultimately the roles assigned to the user define what access that user has, regardless of the user type. For more information on user types check Users Configuration Overview.`ROLE` names are fixed values such as GRAPHQL, ADMIN, and STORE_ASSISTANT. However, you can also personalize the Role naming, E.g. FINANCE_USER. There is a set of roles that come with every account, this is how you retrieve them: 1{
2 roles(first:1000){
3 edges{
4 node{
5 name
6 permissions{
7 name
8 }
9 }
10 }
11 }
12}1mutation createRole {
2 createRole (
3 input: {
4 name: "${role}",
5 permissions: [
6 {name:"${name}"}
7 ...
8 ]
9 }
10 ) {
11 id
12 name
13 }
14}`{{activeRetailer.id}}`, `{{activeLocation.ref}}` (Check the Page Route section in the OMX UX Framework Configuration Guide)
`fulfilments` only)`<account id>-<retailer id>-rubix` - This is a platform generated user which is created when a RETAILER is created. It is used for internal calls by our workflow engine to run Rules within the Workflows. This user SHOULD NOT be touched. The Password should not be changed. Modifying this user in any way may lead to your workflow not executing properly.`<retailer name>_admin` - This specific user is the default admin user created by the platform when a RETAILER is created. The username is generated based on `{{retailer name}}_admin`. This is your user and you can modify it if you wish. There is no backend platform activity that is outside of your control that relies on this user.`<account id>_event` - This is a system-generated user account that is automatically created during client account provisioning. It manages the creation and updating of event records in the client’s audit event storage system. Do not modify this account.