| | Separate Account per brand | Multiple Brands per Account |
| Pros | - Fully isolated data access per brand
- Ability to manage discrete Fluent configuration per brand
- Separate SSO setup per brand
- Specific plugins (business rules) can be isolated from one brand to another as they are deployed per account
- Fluent plugin(s) can also be shared by multiple brands. It’s only a matter of deploying them to the different brands accounts (CI/CD process) and allows you to roll out new releases following each brands own release cycle.
| - Can share resources across brands, e.g.:
- Locations - fulfilment/inventory, customer collection, customer return
- Products (Product Catalogue)
- Inventory (Inventory/Virtual Catalogue) for product availability and order fulfilment
- Customers
- User accounts
- Fluent plugins
- Reduced account setup/maintenance overhead
|
| Cons | - Additional account setup/maintenance overhead
- Brands can’t share fluent resources:
- Locations - fulfilment/inventory, customer collection, customer return
- Products (Product Catalogue)
- Inventory (Inventory/Virtual Catalogue) for product availability and order fulfilment
- Customers
- User accounts
- While you have the flexibility to deploy shared rules to different brand / account, it comes with more operational overhead as a change to a common rule will need to be deployed to the multiple brands/accounts using it.
| - Certain Fluent data objects can be viewed/accessed by all brands within an account:
- Settings, Products, Inventory Catalogue, Virtual Catalogue, Control Groups & Controls
- Fluent plugins are deployed at account level and are accessible to all retailers under an account
- A Fluent plugin can be shared by multiple brands by default. The downside is that all changes on one of the shared rules can impact all the retailers using it. Therefore a fix on a shared rule for given brand will need to be tested for all the brand using that rule. Which leads to some strict operational processes as all the brands will have the same release cycle for the shared plugins.
- Some Fluent configuration is applied at the account level which does not allow you to have a different strategy per brands (= retailers)
- See Account Settings
- Batch Pre Processing (BPP)
- UI manifests (can work around this by creating separate web apps per brand)
- Multiplication of the number of retailers especially on the development account as multiple retailers would need to be created for the devs and QA who work on multiple brands.
- Fluent SSO solution configuration is managed at the account level - e.g. a single Fluent SSO environment is provisioned per Fluent account
- In the case the PRODUCTION account is still account per brand based as it is the case for one of the proposal on the topic, while the sandboxes are using the retailer per brand solution, there could be a misalignment and confusion between the staging environments and the production environ.
|
