Best Practices to Model Prospects, Customers, Suppliers, Partners in an Oracle Fusion Cloud Implementation

October 26, 2018 | 10 minute read
Bala Mahalingam
Consulting Solution Architect A-Team
Text Size 100%:


Three major entities of every business/enterprise in most industries, are Customers, Suppliers and Products. In reality, customer, supplier and product data is required to be stored in all applications and each application might have different data model and data structure requirements. If customer data and product data are not consistently stored in all applications across enterprise, this will result in supply chain inefficiencies, misguided campaigns, and potential impact on reporting and business growth.

As a business, an organization can sell products and services to other organizations directly and/or indirectly using partners, and at the same time can procure products & services from the same organization as well. Managing the core profile data about an organization is critical for all business activities and to enable the single version of truth.

For example, if a company “ABC Corporation” is both your customer and supplier, most CRM and ERP applications would store two separate representations of “ABC Corporation.” with no link between them. When “ABC Inc.” changes their address, profile information, hierarchy or getting acquired, you will need to make sure that you update both records appropriately. It could be two different teams who manages these records as well. It is also difficult find these two records are representing the same business entity.

Oracle Cloud handles this situation elegantly, and will be the focus of this blog.

Oracle Engagement Cloud, Supply Chain Management Cloud, Financials Cloud, Procurement Cloud, and all other Fusion application cloud services uses a standard underlying data model to store party information. In this blog, I will discuss and provide the best practices around modeling your prospects, customer, supplier objects within Oracle Application Cloud. With the common underlying data model across modules, Oracle Fusion application has the foundation that can be leveraged to effectively model your customers, prospects and suppliers.

The best practices provided here are guidelines that can be leveraged to help guide your data modeling and core setup decisions. While these guidelines offered are for a cross pillar application implementations (example: Sales / Service / Engagement Cloud and ERP Cloud) together, these are also applicable for independent application implementation.

Each module within Oracle Fusion application cloud may use different terminologies for describing customers; but the underlying data model is same. Modeling of data need to be carefully thought through to avoid duplicates and to maintain clean, consistent, and complete version of data.

Before we dive deep, the table below provides high level description of entities and the functional areas.

Entity / Object Definition / Description Functional Area
B2B (Business to Business) Customer is a business / Organization General Terminology
B2C (Business to Consumer) Customer is an individual consumer General Terminology
Party Real Thing: Organization or Person Customer Data Management
Organization Business Entity / Company Customer Data Management
Person Individual / Contact Customer Data Management
Group Group of Organizations Customer Data Management
Household Group of individuals Customer Data Management
Account Organization that salesperson sells to. Can be a prospect or customer. Engagement (Sales & Service)
Customer Someone with whom you have selling relationship. Financial, Order Management
Customer Account Attributes of selling relationship with a party Financial
Supplier Organization from where you procure products / services Procurement
Partner Partner Organization Partner Relationship


Consider “ABC Corporation” in four different locations – Headquartered in California, and having branches in Texas, New York, and North Carolina. “ABC Corporation” is a real business entity, and can play multiple roles/usages in your business such as Prospect/Customer/Supplier/Partner etc. But the name, address, DUNS Number, and other key profile attributes are going to be exactly same irrespective of the usage. Additional information based on the rule such as billing preferences, supplier profile, bill-to/ship-to locations could vary depends on the functional needs.

Oracle Fusion application model stores the core organization/person party data once across all modules to avoid data duplication and provide efficiency in data management. Every module such as sales, order management, financials, partner management, and procurement stores additional information for the party as needed based on the transaction requirements.

Two Different Models

In general, two different approaches exist.

1) Traditional Model: One Business Entity Record and Four Address records

    a.   This model provides a back-end and transaction view; Most of the major Enterprise Resource Planning (ERP) applications uses this way of modeling.

b.   Provides a flat hierarchical view based on the business and address relationship.

c.   If visibility requirements exists, for example different regions / territory based and/or team based, then this model has limitations.

d.   If you need to store Dun & Bradstreet (D&B) number representation (or other similar), then you can store it only at the header record (Business entity) only.

2) Flexible Model: Four Business Entity Record and Four Address records

a.   This model provides a front-end view of data; Most of the major Customer Relationship Management (CRM) applications uses this way of modeling.

b.   There is no hierarchy defined yet, as they are four independent representations. This provides flexibility in creating dynamic relationships and hierarchies.

c.   If you have to store D&B number, you can store for every record, and this provides efficiency in managing legal hierarchy as well.

d.   Simplifies Territory management and visibility needs.

e.   Potential downside of this model, will be a higher number of unique records based on name & address (as per this example, additional fields can be added to create uniqueness) and when user searches with just name of a business entity, user could get more records and will need to add additional criteria to limit/narrow down the needed record.


1.   Both models are supported in Oracle Fusion applications cloud and you can choose one way or other or hybrid based on your business priorities. If you want to interact with or separate the activities or get reporting or to classify an entity at individual location level, they create a party record for that location. You may link parties to create organization hierarchy and relationships. If you are modeling a large, global company that has 2,000 business entities should you create one party, 2,000 parties, or some number in between? It depends on how you interact with that company. If you truly interact with the company as one global business entity, then you only need one party. On the other hand, if you want to uniquely identifying and interact with all 2,000 business entities, then you should create 2,000 parties. However, these extremes rarely reflect reality. Most likely you will not interact with the company as one single global entity but you will also not have specific business reasons for interacting with all 2,000 business entities. The answer is generally somewhere in between. To determine the number of parties needed, identify all the business entities that you want to interact with distinctly.

2.   Avoid modeling like Traditional model (many addresses to a same party) to represent the organizational hierarchy. Hierarchies are better managed using Flexible model.

3.   If you need to manage D&B data, Flexible model is the way to go since DUNS number attribute is available at the business entity level.

Guidelines on arriving at your optimized model

  1.   1)   Most of the organizations already have applications with prospects, customer and supplier data. It is strongly recommended to perform data analysis, and model analysis on your existing applications. The following steps are provided as a good starting point.

a.   Start from analyzing existing source systems for master data entities & attributes to help you define the baseline

b    Analyze and categorize the systems & attributes

c.   Map entities (Organization, Person, Address, Classification, etc.) & attributes to Fusion application

d.   Perform gap analysis against the standard Fusion application model

e.   Finalize entities & attributes

  1. 2)   Understand the standard attributes for Organization & Person objects

For example, the diagram below represents high level Party model that is the foundation in Fusion application for both Sales/Engagement Cloud and ERP Cloud.

  • 3)   Make sure that you identify all attributes that are required to identify your customer/prospects/supplier data uniquely. For example – Organization record can be identified uniquely using Name, Address, DUNS Number, etc.; Person record may be identified uniquely with First Name, Last Name, Middle Name, Email Address, Phone Number, Social Security Number, etc.)
  • 4)   Consider all line of business including risk & compliance
  • 5)   Understand the source systems / system of origin / source of truth for these attributes and this will help in defining your data load and integrations.
  • 6)   Do not miss out the attributes required for reporting and the attributes for sharing across applications.

Terminologies across modules within Oracle Fusion application cloud

In Oracle Sales/Engagement Cloud, the term “Account” refers to an Organization Party, and “Contact” refers to an Individual Party.

In Oracle ERP and SCM Cloud, the term “Customer Account” refers to the attributes related to a selling relationship of a party (Organization / Person). Many times, “Customer Account” is called as “Account” as well as from the ERP functionalities perspective. You need to be careful and specific while talking between the ERP and Engagement Cloud business teams.

The table below provides the different terminologies used in different modules within Oracle Fusion application Cloud.

Customer Data Management Sales / Engagement Cloud ERP / SCM Cloud
Organization Party Account Customer / Supplier
Person Party Contact Contact
Location Address Site
  Billing Account Customer Account


Guidelines for creating “Customer Account” when implementing Sales/Engagement Cloud and ERP Cloud:

Now that, you have decided on your party model, creating “Customer Account” is required for establishing selling relationship and functional related attributes.

What is “Customer Account”?

company and the party. Customer Account attributes does not represent a real party and “Customer Account” is required only when a selling relationship is established. Selling relationship is not with the address, but with the party using that address.  One party can have multiple “Customer Accounts”. You need multiple “Customer Accounts” for one party if you market, sell-to, and service that party as one entity, but have different selling relationships. Typical functionalities that requires a “Customer Account” are to place orders in Order Management, to create invoices in Receivables, to bill from Contracts, to create Service Contracts, etc.

Sales/Engagement Cloud and ERP Cloud (Financials / Order Management) together

a.   Create “Account” record in Sales/Engagement Cloud as a Prospect

i.   If you have Customer Data Management and Data Quality functionalities enabled, you will get a popup window with potential duplicates if the application already has similar “Account” records.

b.   When the Prospect is converted as a Customer

i.   This “Account” in Sales/Engagement Cloud record will be visible in ERP Cloud automatically.

ii.   Financial related data such as Tax Profile (Controls, Identifiers, Registrations, Exemptions, Classifications, Reporting Codes, Withholding) will need to be updated.

iii.   User (typically financial user) will need to create “Customer Account” for this customer manually or if required “Customer Account” may be created automatically through custom configuration/scripting.

c.   In this model, you will create Customer Account for parties who needs to be billed and have a selling relationship. You can create multiple “Customer Accounts” if required based on your business requirements.

Start with ERP Cloud (Financials / Order Management) Implementation and then implement Sales/Engagement Cloud

a.   Create “Customer” Record and “Customer Account” Record

b.   Sales User won’t be able to see this customer record since they won’t have visibility.

i.   When Sales Users tries to create the same record through the application user interface, they will be displayed with the duplicate window and they can choose the existing record (created by financial user) instead of creating a new one. This way party record is reused for sales instead of creating duplicates. Sales User now, can add Sales related information such as activities, opportunities, contacts, etc. and can manage sales related functionalities.

c.   “Customer” records will be available automatically as “Account” records in Sales/Engagement Cloud is when implemented. Additional information will need to be populated/updated based on the Sales/Engagement Cloud business requirements.

Start with Sales/Engagement Cloud and then implement ERP Cloud (Financials / Order Management)

a.   This is similar to implementing Sales/Engagement & ERP Cloud together.

b.   Create “Account” record in Sales/Engagement Cloud.

i.   If you have Customer Data Management and Data Quality functionalities enabled, you will get a popup window with potential duplicates if the application already has similar “Account” records.

c.   This Account (Created in Sales/Engagement Cloud) record will be visible in ERP Cloud automatically.

d.   Financial related data such as Tax Profile (Controls, Identifiers, Registrations, Exemptions, Classifications, Reporting Codes, Withholding) will need to be updated.

e.   User (typically financial user) will need to create “Customer Account” for this customer manually or if required “Customer Account” may be created automatically through custom configuration/scripting.

f.   In this model, you will create Customer Account for parties who needs to be billed and have a selling relationship. You can create multiple “Customer Accounts” if required based on your business requirements.

Guidelines for creating “Suppliers” when implementing Procurement Cloud and Engagement Cloud:

Procurement Cloud and Sales/Engagement Cloud together / phases:

a.   Create “Supplier” record in Procurement Cloud

b.   Create similar or same “Account” record in Sales/Engagement Cloud


a.   Create “Account” record in Sales/Engagement Cloud

b.   Create similar or same “Supplier” record in Procurement Cloud

Note: If data quality functionalities enabled in the above scenarios, user will get a popup window with potential duplicate.

Screenshot below shows the popup window while creating a “Supplier Record” in Procurement cloud matched against a “Customer” record that was created in Sales/Engagement Cloud.

Supplier relationship can be established to an existing “Account” record using “Create Supplier Relationship” button on the screen instead of creating a duplicate record. Additional Supplier Profile data can be added that are related to Procurement Cloud transactions.


The recommendations and options described on this blog are general guidelines that you can use to model your prospects, customers, suppliers, and partners based on your business requirements.

While, Oracle Fusion applications cloud supports both Traditional (Site focused) and Flexible models (Party focused), thoroughly analyzing your business needs, and how you want to operate and interact with your parties will help you to optimize the model for your business requirements.

Check out the best practices to model customer / supplier / partner / party hierarchies blog:


Using Customer Data Management

Using Sales

Implementing Receivables Credit to Cash

Implementing Order Management

Using Procurement

Bala Mahalingam

Consulting Solution Architect A-Team

Bala has over 27 years of techno-functional and hands-on product development, implementation, solution architecture  and consulting delivery experience with most of his career spent in architecture, design, development and deployment of applications and technology both on-premises and cloud. His expertise on data management, data integration, data quality and data governance has enabled him to help several customers globally in Hi-Tech, healthcare, financial, life-sciences, automotive and manufacturing industries.

Previous Post

Address Validation Integration in CPQ

Julio Camara | 4 min read

Next Post

Less Is More: Improving by Reducing REST Calls

Dolf Dijkstra | 3 min read