The openness and flexibility of APIs and the platform model have opened vast new horizons of possibility for businesses looking to supplement or replace their existing eCommerce implementations. Platforms are beginning to allow businesses to take their complex ordering processes online for the first time without being prohibitively expensive and/or slow to implement. In my experience as a Business Analyst on projects, this openness and flexibility lead to some interesting questions that come up early on in any project around which way to best map businesses and their requirements to our data model. I wanted to take a moment to provide an overview of our various building blocks at the highest level to help get those conversations started in the right direction.

4 Building Blocks of the Data Model:

Each “Organization” within can be thought of as a single seller

Each “Organization” is self-contained and does not share data with any other “Organization.” Think of it as a unique partition of OrderCloud. Many different resources within OrderCloud live at the “Organization” level so they can be managed globally and exposed into different Buyers as appropriate via “Assignments.” This allows every “Organization” to contain many different Buyers with many different business rules and pricing structures all placing orders.

Each distinct business entity submitting orders should most likely be a “Buyer”

In the B2B world many different entities can potentially be transacting with the seller. White Labelled experiences, unique workflows and many individual apps might be required. Or perhaps a unified experience for all under a single application. The OrderCloud data model supports any of these scenarios. Starting with each legal entity as a “Buyer” helps to organize pricing and order data in the cleanest possible way. Multiple distinct business entities transacting in a single “Buyer” can create complexities downstream such as during reporting and reconciliation.

“User Groups” are perfect for subdividing users within a given “Buyer”

User Groups enable the enforcement of business rules within a “Buyer” by restricting access to nearly any object in our data model via assignments. Common use cases would be to limit access to a “Cost Center” by internal department, order “approval” workflows, addresses by physical location (e.g. different retail locations) or even “Spending Accounts” by managerial level. Utilizing “User Groups” makes managing assignments easier and keeps the data more organized. It’s far easier to assign 50 addresses to a group of users with a single call than 50 addresses to each individual user of a specific type.

A “User” should be a single human user

This one may sound like common sense and it is. But you might be surprised how often the idea of sharing user credentials comes up during solution design as a quick work around. For the purposes of security and to get the most out of OrderCloud every human should be an individual “User.” This ensures notifications go to the right place, orders have the appropriate from User on them and Administrators have the most granular control possible through assignments and Security Profiles who has access to what.

These building blocks just discussed at a high level, Organizations > Buyers > User Groups > Users, can be used to map to any type of business whether a Manufacturer selling to thousands of resellers or a B2B2C experience with anonymous shoppers and commercial accounts using the same storefront. Keep your eyes on our blogs in the coming weeks. We’ll be taking a deeper dive into this same subject with the imminent release of additional features that will allow for even more flexibility in mapping our data model to your business requirements.




Start Building With The API

Solve your complex B2B eCommerce challenges with our RESTful API.
Built for B2B. Cloud-hosted. Pure API-Driven.