Salesforce, the World’s No. 1 CRM Solution, has seen impressive growth for years, attributable to its remarkable offering of Salesforce Products such as Salesforce Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, Analytics Cloud, and many more which have made Salesforce earn a sterling reputation.
The Salesforce Product and Price Data Model depicts the products available for purchase through opportunities, as well as how they can be organized into one or more price books. This, on the other hand, contains some of the objects associated with sales clouds, such as a Price Book, a Product, and Opportunity, an Order, a Quote, and so on.
This article talks about Salesforce Product and Price Data Models and the various components involved in a Data Model. It also gives an overview of What Salesforce is and describes its key features.
Migrating your data can become seamless with Hevo’s no-code intuitive platform. With Hevo, you can:
- Automate Data Extraction: Effortlessly pull data from 150+ connectors like Salesforce(and other 60+ free sources).
- Transform Data effortlessly: Use Hevo’s drag-and-drop feature to transform data with just a few clicks.
- Seamless Data Loading: Quickly load your transformed data into your desired destinations, such as BigQuery.
Try Hevo and join a growing community who rely on us for seamless and efficient migrations.
Get Started with Hevo for Free
What is Salesforce?
Salesforce is a San Francisco, California-based cloud-based software company. It offers sales, customer service, marketing automation, analytics, and application development CRM software and applications.
Salesforce is a well-known cloud-based CRM (Customer Relationship Management) platform. It has over 800 apps to help with things like generating new leads, acquiring new leads, increasing sales, and closing deals. Its purpose is to keep track of the company’s data of customers and sales. It has recently begun to connect the CRM platform to the IoT (Internet of Things).
Salesforce services enable businesses to better connect with partners, customers, and potential customers by utilizing cloud technology. Companies can use Salesforce CRM to track customer activity, market to customers, and perform a variety of other tasks.
A CRM platform allows you to dig deeper into all of your metrics and data; you can also create a dashboard that visually displays your data. Additionally, you can use automation to personalize your outreach. A CRM platform can also improve customer service’s ability to assist customers or a sales team’s outreach efforts, which is a significant benefit.
Key Features of Salesforce
- Contact Management: To see information about customers, such as contact information, activity history, customer communications, and internal account discussions, among other things. In a nutshell, it keeps track of all customer data.
- Opportunity Management: It contains information about the stage of a deal, the products involved in the deal, and the deal’s quotation, among other things. In a nutshell, it keeps track of all the information needed to identify, progress, and close a deal.
- Salesforce Engage: This feature focuses on making personalized contact with a customer for various marketing campaigns that the marketing team has created. It also sends real-time sales alerts based on a customer’s level of engagement.
- Sales Collaboration: This feature aids in the rapid identification of experts who can assist in the closing of a deal based on customer queries and feedback. In other words, it aids in bringing in a collaborative effort to involve an entire team in the deal and make it happen.
- Reports and Dashboards: Dashboards provide a snapshot of the business in real-time. Anyone can use this to create detailed reports that can be accessed from any location.
- Sales Forecasting: This feature enables a sales team’s forecast to be viewed in real-time. It supports multiple currencies and has an in-line editing mode to help you keep track of your sales forecast.
- Territory Management: This feature is used to create multiple territory models, preview them before rollout, and optimize and balance territories throughout the year.
Understanding Salesforce Product and Price Data Models
The above diagram shows a Salesforce Product and Price Data Model.
Product, Price Book, Quote, and other related Sales Cloud Objects are included in this Salesforce Product and Price data model, this diagram is also known as an Entity-Relationship Diagram (ERD). Each currency and price combination should have its PricebookEntry. Information Engineering (IE) notation is used in Salesforce ERDs in a modified form.
To understand the Salesforce Product and Price Data Model, you will need to understand the Data Model and its components.
Understanding Salesforce Product and Price Data Models: Data Models
A Data Model, also known as an ERD (Entity Relationship Diagram), is a graphical representation of an information system. It depicts the interconnections between people, objects, locations, concepts, and events in that system. It’s a logical representation of data’s functional structure. Entities in Salesforce ERDs usually correspond to a Salesforce database object. Salesforce Product and Price Data Model is one kind of Data Model or ERD.
The Salesforce Product and Price Data Model also use IE notation. Clive Finkelstein in Australia and CACI in the United Kingdom invented the Information Engineering notation, which James Martin later adapted. Although there is no single version of IE, it is supported by many Data Modeling tools and is one of the most popular database design notations.
Understanding Salesforce Product and Price Data Models: Entities
A thing or object of significance, real or imagined, about which information must be known or held, is referred to as an entity.
In the diagrams, entities are represented by boxes with rounded corners. In most cases, each entity box has two labels (where applicable):
- The entity’s logical name (in this case, “Salesforce Entity”). This may or may not correspond to the singular label of the represented Salesforce object.
- The object’s “physical” API Name or Developer Name in your Salesforce organization (in this case, “API Name”). Unless Salesforce or Industry cloud uses multiple managed packages, the API name listed in the diagram usually does not include the managed package namespace (“vlocity ins__,” for example). For managed package objects, the type of custom object used is indicated at the end of the API name: “__c” for regular custom objects and custom settings, “__mdt” for custom metadata, and “__x” for external objects.
One or more attributes that are representative of the entity’s attributes may also be listed in entity boxes. Either a “#” or a “-” character comes before an attribute.
- An attribute with a “#” in it is part of the entity’s logical unique key. The user primary key of the entity in the example diagram is “User Key Attribute.”
- A non-key attribute is denoted by a “•.”
Entity Formatting
Each entity-relationship diagram depicts the Salesforce data model from the standpoint of a particular cloud, such as Sales Cloud, Service Cloud, or Marketing Cloud. The Salesforce Product and Price Data Model also has a color scheme.
The diagram’s color scheme is based on the cloud in focus. This is very important to understand Salesforce Product and Price Data Model. The color scheme for all industry clouds, such as Financial Service Cloud, Health Cloud, and Media Cloud, is the same.
A given entity’s color on the diagram also has a specific meaning. The Salesforce branded color is used to indicate the focus cloud color, as shown in the examples below.
The following section will go over the various entity formatting options using the Sales Cloud example legend as a guide:
Cloud Entity
An object that comes with the cloud’s license is represented by an entity with the cloud’s colors.
Related Entity
A white entity with a black border represents an object that has a different license than the focus cloud and isn’t covered by the focus cloud license. Because Account and Contact entities are available with a platform license, they will appear white with a black border on a Sales or Service Cloud ERD, for example.
Extended Related Entity
The Focus Cloud extends an object with a light grey fill and black border that has a different license than the Focus Cloud. Commerce Cloud, for example, adds additional fields to the Product2 object. Fields, relationships, and record types can all be added as extensions.
External Entity
Virtual entities are those that have no physical boundaries. These boxes recognize the existence of an entity in the logical model for the domain when used in a diagram, but the entity is not implemented as a physical object in Salesforce. In the deployed solution, the data for this entity is expected to be accessed via external API calls or Salesforce Connect.
Record Type Entity
Entities with a dashed border in Salesforce are represented as record types. Because the map to record types delivered with the Communications Cloud-managed package, the subtypes Business Account, Billing Account, Consumer Account, and Service Account have a dashed border in this example.
Conceptual Entity
A dotted border is a virtual border. In the Salesforce solution, neither record types nor separate objects are used to distinguish these subtypes. These subtypes logically depict a domain concept that aids in demonstrating the data model’s functionality.
Supertype and Subtype Entities
The definition of a subtype of an entity is a subset of its occurrences. When a set of subtypes is added to a supertype entity, the supertype entity displays common attributes and relationships, while the subtype entities display subtype-specific attributes and relationships. Subtypes are mutually exclusive in the diagram notation, which means that each record must belong to a single subtype.
Subtypes can have nested subtypes that distinguish the occurrences even more. Subtypes in the diagrams are logical, but there are three ways to map them to a physical representation. The subtype entity border’s solidity determines how the subtype is represented in the Salesforce data model.
Subtype entities with a solid border have a real object that keeps track of the subtype’s occurrences. Because contacts who are registered as External Users are tracked with a record in the User object, the External User subtype of Contact has a solid border in this example.
Understanding Salesforce Product and Price Data Models: Relationships
A relationship is a formalized, meaningful link between two entities.
Relationships are important to understand the Salesforce Product and Price Data Models, it determines how entities are connected.
The cardinality, optionality, and meaning of the relationship are described by the markings and text on or around the lines.
Relationship Cardinality
The relative numbers of occurrences on each side of the relationship are indicated by cardinality. The Cardinality of the relationship on that end is indicated by the ends of a relationship line in the notation. A crow’s foot on one end indicates that many entity occurrences on that end can be related to each other. The absence of a crow’s foot on one end denotes that only one entity occurrence on that end can be linked to a given occurrence on the other end.
These explain how the entities are related to each other in Salesforce Product and Price Data Model.
Parent-Child Relationships
There are two types of relationship fields supported by Salesforce. Lookup fields and parent-child (aka master-detail) fields are linked in a new window. Parent-Child fields work similarly to required lookups, but they add an extra layer of coupling between related entities. When the parent record is deleted, records on the many sides of the relationship are deleted as well. The parent record’s visibility also controls the visibility of the detail records.
Salesforce ERDs use the diamond notation from UML to show the distinction between a child-parent relationship and a lookup relationship. When a diamond appears on a relationship’s singular side, it indicates that the entity on that side is the relationship’s master. The detail or child entity, which is contained within the parent entity, is the entity on the other side of such a relationship.
Relationship Optionality
Optionality refers to whether or not a relationship is required for an event to occur on both ends. Optionality is linked to cardinality as a concept, and the notation reflects this. Optionality is indicated on both ends of a relationship by a circle or bar across the line on the other side. On the same side of the line as the cardinality, include the optionality markup.
A circle is almost always present on the line on the many (that is, crow’s foot) side of the relationship. This implies that for each occurrence on the singular side of the relationship, there can be zero to many occurrences on the many sides.
An optional relationship for the entity on the crow’s foot side of the relationship is indicated by a circle and a bar on the singular side of the relationship. For each occurrence on the many sides of the relationship, the circle and bar indicate that there can be zero or one occurrence on the singular side of the relationship.
Double bars, on the other hand, indicate a required relationship for the entity on the many sides of the relationship on the singular side of the relationship. For each occurrence on the many sides of the relationship, the double bars indicate that there must be only one occurrence on the singular side.
These exist in Salesforce Product and Price Data Model and help in understanding the relationship between entities. Even if the underlying physical relationship in Salesforce is optional, a relationship’s optionality may be displayed as required. The AccountId field on a Contact, for example, is technically an optional relationship, but if you ignore Private Contacts, the direct relationship of a Contact to an Account is logically required. Only a small amount of the optionality indicator is used. The relationship’s underlying optionality is usually reflected in the ERD’s optionality.
Relationship Meaning
Aside from cardinality and optionality, each relationship between two entities has a distinct meaning that distinguishes it from other similar relationships. The nature of the relationship is defined by relationship end names like “part of” and “made up of” in the diagram above.
When the cardinality, optionality, and end names of a relationship are combined, a sentence that describes the relationship can be formed.
- From left to right: Each (may/must) be <end name 1> (one and only one / one or more)
- From right to left: Each (may/must) be <end name 2> (one and only one / one or more) .
As an example,
“Each Contact must be the primary contact for one and only one Account,” reads the list from left to right. “Each Account may be primarily represented by one or more Contacts,” reads the text from the right to the left.
Relationship Color Coding
The lines of relationships are color-coded. Color coding helps you understand the Salesforce Product and Price Data Model better. The cloud in the diagram’s focus adds relationships, which are color-coded. A relationship with a different license than the focus cloud is represented by a black line.
Recursive Relationships
Relationships can exist between two instances of the same thing. A recursive relationship is what this is called. Recursive relationships are represented by a curved relationship line.
Mutually Exclusive Relationships
Most business rules are typically ignored in Salesforce ERDs to focus on the data model’s structure, but a mutually exclusive relationship is one business rule that is informative to the structure, so it is noted.
A Mutually Exclusive Relationship means that for any given occurrence, only one of the several relationships included in the arc will be used. They are depicted in the Salesforce Product and Price Data Model and are easy to identify and helps understand the relationship between entities. It’s worth noting that a mutually exclusive relationship can include two, three, or even more relationships. “Each Entity may be an instance of one and only one First Other Entity or one and only one Second Other Entity,” as one example of a mutually exclusive relationship.
A broken relationship line that passes through the arc is not included in the mutually exclusive relationship in the Salesforce ERDs.
Understanding Salesforce Product and Price Data Models: Layout Conventions
To improve readability, official Salesforce product ERDs follow a standard layout. This standard layout is followed by the Salesforce Product and Price Data Models. The following are some of the layout standards:
- Always keep your relationship lines straight.
- Vertical or horizontal relationship lines should be drawn. Use a straight line on a diagonal in rare cases where this is not possible.
- Entity boxes can be resized (taller or wider) to provide a landing place for relationships between the two entities to keep relationship lines straight. The diagram is scaled up to emphasize the importance of the more important entities (those with the most relationships landing on them).
- The crow’s feet on relationships should be on the left side and/or top-side of the relationship line (upside-down layout) – or on the right side and/or bottom side of the relationship line (right-side and/or bottom-side layout) – throughout a single ERD (right-side-up layout). This convention aids comprehension by grouping similar entities in the same area of the diagram. Although using the upside-down layout causes diagrams to appear upside-down, with child entities falling above or to the left of parent entities, this ensures that the most specific entities in the diagram fall in the top-left corner, making the diagrams easily recognizable. The same common entities appear in the top left of every diagram when using the right-side-up layout convention, but child entities appear beneath or to the right of parent entities.
The layout conventions help to understand and analyze the Salesforce Product and Price Data Models.
Conclusion
This blog talks about the Salesforce Product and Price Data Models and the different components of the Data Models. In addition to that, it also gives a brief introduction to Salesforce and its Key Features.
Hevo Data, a No-code Data Pipeline helps you transfer data from various data sources like Salesforce into a Data Warehouse of your choice for free in a fully-automated and secure manner without having to write the code repeatedly.
Hevo with its strong integration with 150+ sources(Including 40+ Free Sources like Salesforce), allows you to not only export & load data but also transform & enrich your data & make it analysis-ready in a jiffy.
Want to take Hevo for a spin? Sign Up here for a 14-day free trial! Check out our unbeatable pricing to help you choose the right plan for your data needs.
FAQ Salesforce Products and Price Data Models
Which type of relationship do products and price books represent in Salesforce?
In Salesforce, the relationship between Products and Price Books is a many-to-many relationship. This relationship is managed through a junction object called Price Book Entry.
What is a product and pricebook in Salesforce?
In Salesforce, Products and Price Books are essential components of the product catalog and pricing strategy. They help businesses manage and organize the products they sell and the pricing structures they use for different customer segments or sales scenarios.
What data model is used in Salesforce?
Salesforce uses a multi-tenant, metadata-driven data model to manage and organize data. This model allows Salesforce to support the customization needs of various organizations while maintaining a scalable and efficient system architecture.
Harshitha is a dedicated data analysis fanatic with a strong passion for data, software architecture, and technical writing. Her commitment to advancing the field motivates her to produce comprehensive articles on a wide range of topics within the data industry.
