Over the last couple of years, I have been posting about different account and contact types as they can be implemented in Oracle Sales Cloud: account, partner and competitors, about households, partner contacts and consumers. From a business perspective, these were all very different but form a technical perspective, deep down in Sales Cloud, they are actually all the same. These are different implementations of the same concept: a party. And the management of all party related information is called the party model.
Just ignore all my previous posts, let me build the Sales Cloud party model for you from the ground up.
Parties
Let me start with the most important concept in this blog post:
A party is ANY entity of interest you need to interact with
ANY entity of interest
They all share a common set of characteristics: names, classifications, addresses, communication info (phone, email, …), relationships, hierarchies and as many other attributes as you want or need to have available in Sales Cloud. Nothing in the party definition itself describes what the party is or how that party can be used though, that is done by assigning party usages.
Party Usages
First and for all, parties come in different types:
- Persons
- Organizations
- Groups
Each of these types has been implemented in different ways:
- Persons can be implemented as contacts, resources, employees, partner contacts or consumers
- Organizations can be implemented as customer, prospects, suppliers, partners or competitors
- Groups can be implemented as households
Notice how in the screenshot below, you can clearly see how a single party can have multiple usages too. Here a previous post all about how a customer can also be a partner in some deals but also a competitor in others. Usages can also evolve over time. This implements a party life cycle e.g. a prospect can become a customer or an inactive partner an active partner.
In Sales Cloud, parties are our contacts, consumers, accounts, partners, competitor and households. But notice now Sales Cloud is not the only Oracle cloud application that is using the party model. Oracle ERP Cloud is using it as well to manage customer and suppliers. Oracle HCM Cloud is using it to manage employees and through this, Sales Cloud also to manage its resources.
It is the flexibility of the party model that allowed me to be creative and come up with the concept of an account network. Just another implementation of households in the party model.
Party Relationships
Parties do not just exist on their own, they can be bound into relationships. An example of each of the relationship types (relationship, hierarchy or influence map) is also highlighted in my account network post
Cross-Referencing
Not only can parties be related to each other in Sales Cloud, they can also be related to parties in other systems. Sales Cloud can manage these relationships by storing the unique identifiers for its parties in other systems in a cross-reference table. This cross-referencing capability is what allows Oracle Sales Cloud CDM to play a pivotal role in keeping party information across an application landscape clean and consolidated. More on this in a future post.
The party model is the heart of the Sales Cloud customer data management system. The ability to not only manage, clean, enrich and detail parties in Sales Cloud as much as you want, but also to share that information with other systems who can tremendously benefit from the data that Sales Cloud can provide to them: It all starts with the party model.
