Jeremy Davis
Sitecore, C# and web development
I've been looking at some information architecture stuff for OrderCloud recently, and came across a situation where "groups" were suggested as helpful for the business scenario I needed to model. There didn't seem to be a great deal of documentation about why you might want them for things like this, so I figured it might help others for me to write down what I was looking at. And why groups might be the right answer for you too...
url copied!
OrderCloud understands the ideas that product visibility and pricing can be set for particular sets of users. I've been looking at some B2B features for a shop where the broad model for shoppers looks like:
flowchart LR or["Organisations
(The overall company)"] br["Branches
(A section of the company)"] pro["Products"] pr["Prices"] us["Users"] or ---> br br ---> pro br ---> pr br ---> us
The pricing and product visibility for users is controlled by what Branch they are associated with, and an overall organisation that we're doing business with is made up of one or more of these branches.
url copied!
Initially when I looked at this I was thinking that (depending on the particular approach) either Organisations or Branches might be represented by the
Buyer
object in OrderCloud. It's the top level object which products and their prices can be assigned to. That might work as either:
A branch is a Buyer
If you don't need to explicitly model the "Organisation -> Branch" relationship in the OrderCloud data then maybe you use a Buyer to model each of your branches. Assign the products and prices directly to the branch. And the Buyer can be marked with an extended properties field to say what organisation this Branch is part of.
A branch is a Group
But if you do need to represent the relationship between an Organisation and its Branches then Groups might be useful. A group can sit between a Buyer and its price and assignment. So a Buyer can represent an Organisation and a Group can represent a Branch.
However when I talked about this with people from Sitecore, they suggested that neither of these are a good idea in practice. They argue that the solution should have as few
Buyer
entities as possible. Creating one per Branch or Organisation is not a good plan. Ideally there should be a single one which basically represents the shop itself, rather than the individual customers.
So they explained a third approach, which is preferred:
What I'd not really thought about before (though it makes perfect sense) is that an OrderCloud
User
can be a member of
multiple
Group
entities. So we can use them to model more than one thing in our scenario. The extended properties of the groups can be used to store data that defines the details of these different types of entity. So a "Branch" might store flags about "what payment options are valid" for these users, while an Organisation might be used to allow a "Company Admin" user access to modify the company-level invoice billing address.
And the data model becomes something more like:
flowchart LR by["The shop
(A single Buyer)"] or["Organisations
(Groups)"] br["Branches
(Groups)"] pro["Products"] pr["Prices"] us["Users"] or ---> us by ---> or by ---> br br ---> pro br ---> pr br ---> us
So a user can inherit their pricing and visibility from their Branch group, and they can also be related to an Organisation group for access to whatever custom data it stores.
So how might that work in practice? It's mostly down to...
url copied!
The data import process that pulls internal business data into OrderCloud can create a group for each Organisation and Branch. This can be driven by data in kept in the internal CRM/ERP or whatever bit of software us used to manage this stuff by the business. (And these could also be created by a registration process on the website as well if a self-serve approach is required) Each creation is a call to:
POST https://api.ordercloud.io/v1/buyers/{buyerID}/usergroups
{
"ID": "...",
"Name": "...",
"Description": "...",
"xp": { ... }
}
The extended properties (xp) field here is going to store whatever project-specific properties your solution needs to keep for these entities - and they'd likely be different between the two types of groups.
When the import process is assigning products, it can use the Branch groups to attach products to. Those API calls looks like:
POST https://api.ordercloud.io/v1/products/assignments
{
"SellerID": "...",
"ProductID": "...",
"BuyerID": "...",
"UserGroupID": "...",
"PriceScheduleID": "..."
}
The optional
UserGroupID
here allows the assignment of the product to be specific to one of our Branch groups, rather than global to the Buyer. It is worth noting that this does expand out the quantity of assignments that need making fairly significantly, however. Having looked at the idea that "not all of the Branches have special prices or visibility" in the data model for my project, we're also looking at some groups to represent the base "you just get the standard products and prices" that can be shared between multiple Organisations in order to reduce that import overhead.
Finally then, when registration attaches a new user to a Branch and Organisation it can call:
POST https://api.ordercloud.io/v1/buyers/{buyerID}/usergroups/assignments
{
"UserGroupID": "...",
"UserID": "..."
}
And that will attach the user to each group. With that a call to
https://api.ordercloud.io/v1/me/products
will return only the products and prices inherited from their Branch group.
And aside from the product/price scenarios this approach allows, it's also potentially useful for security decisions in the website's head. Groups can be used to make access decisions in custom code as well.
So have a think about the power of Groups when you're looking into constructing your data model in OrderCloud.
↑ Back to top
