The real value of a Salesforce architect comes from the artifacts they produce to keep the solution consistent and aligned with the business objectives. The quality of an artifact differentiates an architect from other Salesforce roles. A Salesforce architect’s purview and responsibility is much more comprehensive. It is a common misconception that architects are a luxury item for a Salesforce project, as they are expensive and not needed.
We often tell people, “If you think Salesforce architects are expensive, try paying for a project without one.”
The key reason for discussing the artifacts so early in this book is to equip you with a Salesforce architect’s mindset and allow you to organize the technical details from this book in relevant context. We often see knowledgeable architects struggling to put their thoughts on paper mainly due to a disconnect between their Salesforce knowledge and their approach in developing the artifacts. The intent of this chapter is to bridge that gap.
The architectural artifacts are the first step in your design process. It will equip you to start with a standard approach and strengthen the artifact with granular technical details. The ideal artifacts must include considerations from each of the seven architecture domains outlined in Chapter 1.
We recommend using this chapter as the basis for organizing and absorbing the contents of this book.
The creation of three key artifacts commonly used in every Salesforce solution design
Using FUSIAOLA analysis to create artifacts
An approach to design a system landscape
Using seven essential data modeling techniques to design a Salesforce solution
Art of Artifacts
The artifacts you create should articulate the design of each component of the solution in the most straightforward format with as few documents as possible. These artifacts become the blueprints of the solution and a reference point for development.
- 1.
FUSIAOLA analysis
- 2.
System landscape
- 3.
Data model
Role Hierarchy and Sharing Diagram
Environment and Release Management Diagram
Source Code Branching Diagram
System Authorization Flow diagrams
However, in this chapter, we will only focus on the three critical artifacts identified earlier, since they are key to every Salesforce architecture design.
In the next section, we will outline the thought process and an approach to creating each of the three key artifacts. You can create and present these artifacts in any format or style of your choosing, as long as you remain true to the approach outlined in this chapter.
FUSIAOLA Analysis
The first step in the architectural process is to analyze the business domain and clearly understand all business requirements that need to be accomplished. Each business requirement needs to be assessed against the seven architectural domains introduced previously.
Only a few of us architects are lucky to be engaged in a project from the start. Most of us are brought in only when something is broken or in the middle of the project when the requirements get complex. No matter when you are brought in as an architect, your first question to answer should always be “What the FUSIAOLA is going on here?”
F: Features
U: Users
S: Systems
I: Integrations
A: Authentication
O: Objects
L: Licenses
A: Assumptions
F: Features
- 1.
A user interacting with Salesforce
- 2.
A remote system interacting with Salesforce
- 3.
Salesforce interacting with a user or a remote system based on some criteria or an event within Salesforce
To identify the features needed by the users, we need to understand each user’s experience with the system in explicit details. Systems do not have commonsense reasoning as humans do, and hence every logic and system expectation must be explicitly expressed within business requirements.
Typically, a business analyst on the project captures these business requirements, so you as architect must start by reviewing the completeness and coverage of the business requirements for the intended solution. Typically, a single business requirement is captured in a single statement such as “The system shall…” or as a user story. A user story is a business requirement written from the point of view of a specific user or a user group, along with the user’s achieved objective for the requirement.
User Story A: “As a sales user, I would like to create a new opportunity for an existing customer account with the opportunity status of “New” so I can process and track the opportunity throughout the opportunity lifecycle.”
User Story B: “As a sales user, I would like to create a new opportunity for a new customer account that does not exist in the system with the opportunity status of “New” so I can process and track the opportunity throughout the opportunity lifecycle.”
A user story often considers the business context of the user’s needs. However, as an architect, you need to decompose the business requirement a step further to determine the technical context of the user’s need.
For instance, in reading these user story examples, you may assume that both user stories are similar, and hence designing for User Story A solves for User Story B. If so, you would be wrong and here is why.
User Story A requires that the sales user can create a new opportunity for an existing account record, and hence the user will be able to associate the new opportunity record with an existing customer account. But what happens when a customer account does not exist? Whom do you associate the new opportunity with? This is where User Story B plays differently. In User Story B, the sales user must create a new opportunity along with a new customer account. In this case, there will always be a new account record which the new opportunity can be associated with.
The difference in the user stories specified in the preceding text is an oversimplification of the nuances that you as an architect will need to spot when reviewing the business requirements or user stories.
As an architect, you must think deeper than the business context and determine the technical context that dominates the business requirement.
- 1.
Data context
- 2.
Business logic context
- 3.
Interaction context
Every business requirement exhibits one or all three technical contexts. It is very common for one technical context to be more dominant than the other two for a given business requirement. All Salesforce capabilities, declarative or programmatic, can be mapped to one of these three key technical contexts, and hence categorizing all business requirements into one or more of the three technical contexts will become highly crucial in choosing the right Salesforce feature to meet each business requirement.
Data Context
A business requirement with a data context typically includes a user creating data, updating data, reviewing data, deleting data, or sometimes associating one data with another.
Both user story examples mentioned earlier are examples of data context–dominant requirements because the underlying objective of both user stories is to create data and associate data with each other. Yes, there is also a user interaction context (more on interaction context in the next section), as the user needs to enter data via a screen. And although both contexts are relevant, the data context is the more dominant technical context. If you had to choose one over the other, you would probably choose the data context over the interaction context. Later in this chapter, you will learn why choosing a dominant technical context is important.
Business Logic Context
- 1.
As a sales user, I want the system to calculate and apply a sales discount in the range of 0–5%, based on the discount thresholds allowed by me so that we can only offer discounts that I am authorized to offer without requiring additional approvals.
- 2.
As a product manager, I want all product inquiries and service requests related to the product we manage to be routed to me based on my geographical territory so that I only address the inquiries and customer support needed for the product we manage in my geographical territory.
Interaction Context
A business requirement with a dominant interaction context typically refers to a user interaction via a screen or a remote system interacting with Salesforce via a systems integration.
- 1.
As a sales manager, I want to view my team’s opportunity pipeline and forecast details grouped quarterly on a single page so that I can track all opportunities managed by me and my team.
- 2.
As a sales user, I want a new order to be created in the SAP system associated with the customer account when an opportunity is set to closed/won within Salesforce, along with the order number of the newly created order in the SAP system being available within Salesforce, so that a new order is created in SAP automatically when an opportunity is closed/won.
Once you identify the dominant technical context for each business requirement , you will find it easy to map the business requirements with the ideal Salesforce feature. Not only that, you will also be able to justify when you need to use code instead of declarative options. We will cover an approach to choosing the right Salesforce solution based on the three technical contexts in Chapter 3.
Sometimes it is hard to pick a single dominant technical context; this often means that the business requirement is overloaded and needs to be decomposed further and split into multiple requirements. After splitting the requirement, if you are still unable to pick a single technical context, it is okay to pick up to two technical contexts for a single business requirement. But just know that picking more than one or all three technical contexts will blur your choices for the ideal solution.
Illustration of Dominant Characteristics, Identification, and Assignment
User Story | Dominant Contexts | Declarative Option | Programmatic Option | |
|---|---|---|---|---|
1 | 2 | |||
As a sales VP, I want to manage select fields on each account and opportunity than the sales team since I only need to review these particular fields for any account or opportunity. | ||||
Interface | Data | Page layout or reports and dashboards | Visualforce page or Lightning web components | |
As a sales user, I want a new order to be created in the SAP system associated with the customer account when an opportunity is set to closed/won within Salesforce, along with the order number of the newly created order in the SAP system being available within Salesforce so that a new order is created in SAP automatically when an opportunity is closed/won. | ||||
Business logic | Interface | Workflow rule and outbound message | Lightning web components Or Apex Trigger and Apex class and REST API | |
As a sales user, I want the system to automatically update the opportunity status as closed/won when the contract status is “Executed” and also send me an email notification after changing the opportunity status so that I can be notified of the closed/won opportunity upon contract execution. | ||||
Data | Business logic | Process Builder or Lightning Flow | Apex Trigger | |
As a division lead, I only want to see data and functions that are relevant to my sales division so that I only manage functions relevant to my division. | ||||
Interface | Business logic | Lightning app or record types and page layout | Visualforce page or Lightning web components | |
As a salesperson for division A, I want to manage opportunities only for division A as per division A’s opportunity management process which is different for each division so I can adhere to the business process unique to my division. | ||||
Interface | Data | Record types and page layout | Not required | |
U: User
Refers to the users intending to use the Salesforce solution. In the Salesforce ecosystem, a user or a group of users with common business operations and roles is also referred to as an “actor.” Going forward, we will refer to a user or user group unanimously as an “actor.”
Each actor can be differentiated from another based on the actor’s nature of use of the system.
- 1.
Information role
- 2.
Business function
- 3.
Internal vs. external
- 4.
Role hierarchy index
Information Role Attribute
- 1.
Information provider
- 2.
Information processor
- 3.
Information consumer
An actor can be the creator and provider of the information needed within Salesforce. Actors that are information providers are usually customers, external partners, internal client-facing sales staff, or call center intake staff.
Information processors are typically the back or middle office staff that process the provided information and run it through the workflow of their operations.
The information consumers are typically supervisors, executives, customers, and external partners who monitor and consume the results of the operations executed within the system.
However, there can also be scenarios where a given actor is the provider, processor, and also consumer of the information. This is common in smaller organizations with fewer employees who manage the data intake, process the data internally, and consume the data. In such cases where a user is provider, processor, and consumer, you can safely categorize the user’s role as the “information processor.” In most cases, the information processor will need to be given the most comprehensive security access and license type within the system anyways. In any case, it is still valuable to assess and differentiate the actors based on their information role attribute in order to assign the appropriate license type, user profiles, permission sets, sharing rules, teams, and public group assignment for the appropriate level of visibility and sharing. More on visibility and sharing will be covered in Chapter 5.
Another value of the information role attribute is to determine the ideal license type for the user. For instance, let’s say an actor, identified as primarily an information consumer, may only require read-only access to accounts and contacts within Salesforce; manage CRM content, ideas, and answers within Salesforce; need read-only access to reports and dashboards; view and approve workflows; use the calendar to create and track their activities; and share data only with a group of users. All of these can be accomplished by assigning just a “Chatter Only” license to the actor, instead of a more expensive Sales Cloud or Service Cloud license. The user profile for such a user will also be unique compared to a Sales Cloud– or Service Cloud–licensed user, which will need to be taken into account for visibility and sharing requirements . More on license types will be covered in Chapter 3.
Business Function Attribute
Another key attribute that distinguishes a type of user from another is the business function(s) of the company that the actor manages. In large organizations, a clear and formal segregation of duties is outlined for each actor. The business division to which an actor belongs could be sales, service, marketing, or IT. Within a service division, the actor may be part of the call center function or the field service function. It is critical to dive deeper into an actor’s business functions rather than just classify them to a department or division because Salesforce now offers more than just Sales and Service Cloud licenses. Salesforce licenses vary by industry specialization such as Financial Services Cloud or Health Cloud as well as by functionality such as Field Service Lightning and Einstein Analytics. A single user within Salesforce can only be assigned a single Salesforce license at any given time. Due to this reason, assigning the correct licenses to each actor is highly crucial and the fundamental starting point for what an actor can do within the system. For instance, in a scenario where an actor belongs to the service division and is also part of the field service function of the company, a Salesforce Field Service Lightning license will be more appropriate for the actor than just a Service Cloud user license because a Field Service Lightning license covers all major functions available via a Service Cloud license, in addition to the field service capabilities that are primarily intended.
In large companies, it is easier to drill down from an actor’s business division to the actor’s formal business functions. However, in smaller companies and start-ups, there may not be any formal segregation of duties or a clear job function defined for any actor. In this case, an actor within the organization may need the ability to do everything from sales and service to field service functions. In this instance, the “Salesforce Field Service Lightning Plus” license would be more appropriate for most actors, as it provides the capabilities of Sales Cloud, Service Cloud, and Field Service Lightning , all from a single license.
The “Salesforce Field Service Lightning Plus” license is more expensive than an individual Sales Cloud or Service Cloud or Field Service Dispatcher or Field Service Technician license; however, the premium paid for the “Salesforce Field Service Lightning Plus” license is justified by the flexibility and scalability of functions available to a single actor of the system. This is why the Salesforce product mix and license model can be completely different for companies within the same industry with identical business operations. More on license types will be covered in Chapter 3.
Internal vs. External Attribute
The last but not the least is to identify if the actor is internal to the enterprise (i.e., employed by the enterprise) or external to the enterprise such as a customer or partner with self-service capabilities. Additionally, for external users, it’s important to understand the type of relationship they maintain with the enterprise and the functions or features that they are involved in. This is for identifying the appropriate Salesforce community licenses that may be needed for the actor.
The only licenses that can be applied to external users are either Community Cloud licenses or “Chatter External” licenses.
Through Salesforce community licenses, external users are provided access to a subset of the information stored and processed within Salesforce via a personalized portal access. It is however important to note that Salesforce community licenses can also be provisioned to internal users, if needed. We will cover “Salesforce community” and other common Salesforce product types in Chapter 3.
Role Hierarchy Index Attribute
A key sharing setting offered by Salesforce is the role hierarchy. Access within Salesforce can either be shared laterally with peer associates or vertically with a user’s manager and their managers, all the way up to the CEO of the company. The role hierarchy sharing setting within Salesforce addresses the vertical information sharing access between users, the user’s manager, and their managers.
A role hierarchy within Salesforce can be assigned to any user at the user’s profile level, allowing the user of that profile to view, edit, and report on all data that’s owned by the user or shared with the users below them in their role hierarchy. The only exception to access granted via role hierarchy occurs when the specific object (i.e., containing the information being accessed) is a custom object with the object’s organization-wide default setting for “Grant Access Using Hierarchies” being “disable.” In all other cases, a role hierarchy set for a given user determines the user’s access to all data that was either created by them or any user listed in the role hierarchy under them. A role hierarchy allows vertical access for a given user only in the direction of top to bottom and not the other way. By this, we mean a user, let’s say user X, who is listed in the role hierarchy above another user, let’s say user Y, can view all data that user Y has access to within the system, in addition to their own data within the system. On the other hand, user Y can only access data created by them but has no access to the data created or owned by user X.
Many people assume that the role hierarchy of Salesforce should be set up to replicate the formal organization chart of the company, assuming that the formal organization chart captures the vertical access needed within the system. This is not always the case and not in any way mandatory. The role hierarchy of Salesforce determines who needs to see what from an inherited data ownership perspective, without setting up complicated sharing settings for supervisors and managers to be able to access the data owned by their direct reports.
That being said, in many cases, an administrative assistant user who is shared by multiple executives may need access to the data owned or created by each of the executives whom they support. It would be too complex to create a set of sharing settings to give them access to each executive’s data. In such a scenario, it may just be easier to place the administrative assistant user above the executives they support, within the role hierarchy, even though the executives do not report to the administrative assistant. By manipulating the setup of the role hierarchy this way, the administrative assistant automatically gets access to all data managed by the executives they support within the system.
Another reason why a company’s formal organization chart may differ from the role hierarchy in Salesforce is that the role hierarchy can also include external users such as partners and customers who access the system for collaboration and self-service. That’s right; external users need to be set up in the role hierarchy within Salesforce, if they need to access the system via Salesforce Community Cloud. A role hierarchy index is a number assigned to each user, with respect to their role and position in the company. The role hierarchy index of 1 signifies the highest level in the role hierarchy, which is typically assigned to the CEO of the company. All role hierarchy indexes following the index of 1 (i.e., greater than 1) apply to subordinate users in the role hierarchy. There can be multiple roles with the same role hierarchy index signifying peer roles. For example, it’s common to have the role hierarchy index of 2 assigned to VP of sales, as well as VP of service, as well as VP of IT operations.
Salesforce User Attribute Chart
Actor Name | Actor Description | Information Role | Business Function | Internal vs. External | Role Hierarchy Index | Ideal License |
|---|---|---|---|---|---|---|
CEO | The chief executive officer (CEO) is the highest-ranking executive of the company, responsible for making major corporate decisions, managing the overall operations and profitability of the company. All vice presidents report to the CEO and share the overall health of the company related to key functions of the company which include sales, service, finance, IT, and human resources. The CEO rarely uses the system, but when they do use the system, it’s mainly to view reports and dashboards related to sales and service. | |||||
Consumer | Executive oversight | Internal | 1 | Platform Plus license | ||
Admin assistant of the CEO | The administrative assistant of the CEO keeps track of the CEO’s calendar, serving as gatekeeper to all interactions between the CEO and other employees of the company. The administrative assistant of the CEO interacts also with the company’s partners and customers on behalf of the CEO relating to logistical correspondence or general follow-ups. The administrative assistant’s use of the system includes reviewing the reports and dashboards for format and detail correctness prior to the CEO’s review. The administrative assistant of the CEO has almost the same level of access to the system as the CEO and is able to access all the information entered by all users (except for some information entered by the CEO) within the system. | |||||
Consumer | Executive oversight | Internal | 2 | Platform Plus license | ||
VP of sales | The vice president (VP) of sales is committed to overseeing the achievement of sales targets across all regions for all products sold by the company, which include product A and product B. The VP of sales is also responsible for reviewing and approving all sales contracts over $1 million and any discounts offered to customers that exceed 25% of the original deal value. The RVP of sales only uses the system to generate monthly, quarterly, and annual sales reports and view daily dashboards. The VP of sales is also interested in big deal alerts and deals requiring their review and approval. Occasionally, the VP of sales needs access to account- and deal-level details to review and investigate the account and deal background. | |||||
Consumer | Sales | Internal | 3 | Sales Cloud | ||
RVP of sales of product B | The regional vice president (RVP) of sales is committed to overseeing the achievement of the sales target for their designated geographical region related to product B. The RVP is also responsible for reviewing and approving all sales contracts over $1 million and any discounts offered to customers that exceed 15% and are less than 25% of the original deal value. The RVP only uses the system to generate monthly, quarterly, and annual sales reports and view daily dashboards. The RVP of sales is also interested in big deal alerts and deals requiring their review and approval. Occasionally, the RVP needs access to account- and deal-level details to review and investigate the account and deal background. | |||||
Consumer | Sales | Internal | 4 | Sales Cloud | ||
VP of service | The vice president (VP) of service is committed to overseeing the achievement of service and support offered across all regions and for all products sold by the company. The VP of service ensures that the service-level agreements offered to the customers are met adequately and the customer satisfaction rating for the company is maintained at the highest level. The VP of service uses the system to monitor a daily dashboard consisting of service KPI metrics and review service quality standards monthly, quarterly, and annually. The VP of service has full access to the system to access all service issues as needed such that they can intervene and address any case that has been escalated multiple times with no resolution. | |||||
Processor | Service | Internal | 3 | Service Cloud | ||
Field sales | The field salesperson is responsible for all direct sales with customers for customer accounts assigned to them within their territory. The field salesperson sets their revenue targets in the beginning of the fiscal year and tracks their sales targets quarterly within the system. The field salesperson often physically visits the customer’s location and with their customers on a regular basis and uses the system to enter and track all sales activities using their mobile device. Due to this reason, the field salesperson depends heavily on offline capabilities of their mobile device since many times they are in areas with no Internet or cellular connectivity. The field salesperson needs access to accounts, contacts, opportunities, quotes, cases, and any other data related to their assigned customers that are stored within the system to maintain a complete 360-degree information about the customers. | |||||
Processor | Field service | Internal | 5 | Field Service Lightning | ||
Product manufacturer for product A | A product manufacturer for product A is an external partner that is responsible for the production and supply of product A, supporting all regions, and collaborates with all field salespeople who sell product A. The product manufacturer for product A has access to all leads and opportunities related to product A across the company. The product manufacturer does not interact directly with the customer but supports any questions or issues related to product A via interactions with the designated field salesperson for product A. | |||||
Processor | Sales and service | External | 4 | Partner Community | ||
B2B customer | B2B customers are customer organizations that purchase products A and B at large volumes for redistribution at their retail location. A typical B2B customer organization comprises anywhere between 20 and 50 employee firms that primarily interact with the company for placing wholesale orders via a personalized company portal allowing for self-service and allowing member access and member management of the customer organization employees. | |||||
Provider | Customer | External | 6 | Community Plus | ||
B2B customer representative | A B2B customer representative is an employee staff member at the B2B customer organization who is responsible for placing and tracking orders with the company. They conduct all interactions related to order management via the B2B customer portal personalized for that B2B customer organization. The B2B customer representative can manage their own profile within the portal and can see all transactions related to their company, including transactions being managed by the peers in their own organization. | |||||
Provider | Customer | External | 7 | Community Plus | ||
B2C customer | B2C customers are direct customers who are individuals purchasing the company’s products for self-consumption. The B2C customers need the ability to shop for products online, create a personalized account when placing orders, or conduct self-service activities such as tracking orders placed, reviewing previous purchases, and opening support tickets for their transactions. | |||||
Provider | Customer | External | 6 | Community | ||
IT operations associate | An IT operations associate is a member of the company’s IT organization responsible for the administration, management, and maintenance of the CRM system. The responsibilities of the IT operations associate include setting up new users, supporting existing users with access to the CRM system, developing reports and dashboards as per requests from disparate users of the system, and conducting basic enhancements to the system on an ongoing basis and as needed. | |||||
Provider | General | Internal | 5 | Service Cloud | ||
S: Systems
This refers to all systems in the company’s ecosystem that either exist currently or are identified as systems of interest in the future. Note that I am recommending making a list of currently existing systems even if it is planned to be retired or be replaced. We will discuss how we communicate the existing and new systems a bit later in this chapter when we discuss the artifact “system landscape.”
Is the existing system being listed on-premise, on-cloud, or a hybrid of on-premise and on-cloud?
Will the existing system remain or be replaced in the desired environment?
If the existing system remains, will it require a bidirectional or a one-way integration with Salesforce?
If the existing system remains and requires integration with Salesforce, then does it support the REST API protocol or SOAP API protocol or both?
If the listed system is to be replaced, will it be replaced partially or fully?
If the listed system is to be replaced, will there be a need for data migration or data archiving from the existing system?
For the systems planned to be retired or replaced, can Salesforce fill all the functional gaps in the desired future state?
For any functional gaps not fulfilled by any products of Salesforce, are there any third-party apps on Salesforce AppExchange that meet the unfulfilled requirements?
For any functional gaps still remaining after considering Salesforce products and Salesforce AppExchange, what cloud-based solutions are available that have prebuilt Salesforce adapters or SOAP API protocols compatible with Salesforce? (More on Salesforce SOAP API protocol compatibility covered in Chapter 6.)
Other than the purpose of replacing the existing system(s), what other desired state requirements does the Salesforce-based solution need to address, and which Salesforce product(s) among the large variety of Salesforce products that best meets the requirements? (More on the most common Salesforce products and their high-level descriptions in Chapter 3.)
- Are any of the following systems needed in the desired state?
Middleware or an Enterprise Service Bus (ESB) tool
Extract-Transform-Load (ETL) tool
Master data management (MDM) system
Identity and access management (IAM) system
Data warehouse (DW) system
Document management (DMS) system
Content Management (CMS) system
Answering these questions should allow you to capture a list of all systems that need to be included and considered for a desired state system landscape, which we will create in the next section of this chapter (“System Landscape Artifact”).
I: Integrations
This refers to the integrations needed between the systems previously identified and Salesforce. Salesforce takes an API-first approach to building all its features on the Salesforce platform. With this approach, every feature and the underlying data within Salesforce can be accessed directly by another system or application without the use of a Graphical User Interface (GUI). This approach allows us to connect all the non-Salesforce systems with Salesforce and vice versa, using one of the many APIs supported by Salesforce. For an in-depth understanding of the integration approaches, pattern choices, and when to use which integration, please refer to Chapter 6.
However, for the purpose of FUSIAOLA analysis, you may add a column or two to Table 2-1, identifying the systems (among the list of all systems identified earlier) to be integrated and, in a separate column, identifying at a high level what each system needs to accomplish with the other. You can repurpose the preceding table to provide justification of each of the integrations that you have identified in your analysis.
A: Authentication
This refers to the authentication and authorization needed by users and external systems to access Salesforce or access other systems via Salesforce. This specifically considers the identity and access management capabilities needed to secure access to and from the Salesforce solution.
If you are new to the concepts of identity and access management, including authentication vs. authorization, OAUTH, SAML Delegated Authentication, and single sign-on (SSO), then I would recommend reviewing Chapter 7 before conducting the analysis here on authentication methods.
- 1.
Users and Account Management: Which users need access to Salesforce, and are they internal or external?
- 2.
Provisioning: How will internal and external users be provisioned within Salesforce?
- 3.
Authentication: How will users be authenticated, and which system will store the identity of the user?
- 4.
Authorization: How will users (when Salesforce is not the identity provider for the user) or external systems using the API get access into Salesforce?
- 5.
Single Sign-On: Do users need to access multiple systems using a single authentication and authorization method?
- 6.
Access Rights: Once users or systems have access to Salesforce, what can they do in Salesforce?
- 7.
Session Management: How long should users be allowed to stay idle within the system before their session is timed out, or in the case of system access, when should the system’s access be revoked?
- 8.
Logout and Redirects: When a user logs out of Salesforce, where should the user be redirected to?
- 9.
Deprovisioning: How will inactive users be deprovisioned access to the system?
- 10.
Account Recovery: When user’s access is disabled or locked, how can they regain access to Salesforce?
I will cover the lifecycle of identity and access management in detail in Chapter 7.
O: Objects
This refers to existing and new data tables that need to be created within Salesforce to organize and store the data that is needed to support the functions and features supported by the system. One technique to identify objects easily from your requirements is to look for the “nouns” used in the sentences. Most often, the nouns used in the requirement are something you need to store as data within the system. For instance, in the following user story, I have underlined the nouns that can be considered as objects that need to be created in Salesforce to store data: As a sales user, I want a new order to be created and associated with the customer account when any opportunity is set to closed/won, so that I can track all orders resulting from closed/won opportunities.
- 1.
User Object: For sales user
- 2.
Order Object: For new order
- 3.
Account Object: For customer account
- 4.
Opportunity Object: For any opportunity
This is an oversimplified example of how to identify objects from a requirement.
For a deep dive into data modeling and a detailed understanding of the Salesforce object model, along with the data architecture of Salesforce, please refer to Chapter 4.
L: Licenses
Specifically , this is the optimal mix of Salesforce licenses types that will be needed to support a majority of the solution using out-of-the-box capabilities of Salesforce. The true potential of a SaaS-based solution like Salesforce is best realized only when the majority of capabilities needed are achieved out of the box. Since one size does not fit all in the SaaS world, Salesforce has distinguished its product offerings into several license types based on business functions, such as Sales Cloud or Service Cloud, and industry-specific license types, such as Health Cloud and Financial Services Cloud.
Choosing the right licenses for the solution is the best starting point and a vital step in architecting with Salesforce. As an architect, it is important to optimize the licenses required by each Salesforce actor such that the total licenses required by the organization are optimized for design and cost efficiencies. Salesforce allows its customers to mix and match multiple licenses for its users within a single Salesforce instance. However, each user within Salesforce can only be assigned a single license type at any given time.
For instance, a standard Salesforce Lightning Platform license is significantly cheaper than a Sales or Service Cloud license and may be enough to cover all the functions and features needed by a single actor within the company. On the other hand, an industry-specific license such as a Salesforce Health Cloud license or Field Service Lightning license is more expensive than a standard Sales or Service Cloud license but is completely worth it, given the additional capabilities and specialized features covering a diverse set of functionalities and features required by an actor of this company. In the earlier section where we discussed users and created a user table, I have illustrated the assignment of user licenses within the same table. The exercise of assigning the ideal licenses to each actor requires a strong understanding of the various licenses offered by Salesforce. Although it’s hard to cover every Salesforce product license, I have discussed the most commonly used and most popular licenses of Salesforce in Chapter 3.
A: Assumptions
Assumptions refer to the assumptions that you as an architect have made at the time of designing the desired solution based on the information available to you and your architectural inferences drawn from it. An architect’s assumptions form the validity of their understanding of the business needs and an informal permission to fill in the blanks for information that is missing.
Although there can be a variety of topics for an architect to make assumptions, including topics covered in the earlier sections of the FUSIAOLA analysis, here are some recommended topics to consider when looking for assumptions.
Who Sees What?
During the design stage of the solution, it is often not clear as to which user can see what, why, and how. As an architect, I often make assumptions in this topic by referencing the user attribute table created during the FUSIAOLA analysis related to users. That table allows me to identify internal vs. external users and their information role and business functions. Assumptions in this topic also allow an architect to validate the licenses assigned to each actor. It is also easier to confirm or correct the assumptions related to this topic since it can be effectively done by updating the user attribute table.
Organization-Wide Defaults and Data Visibility
Another topic area for assumptions is the organization-wide default (OWD) settings for object and data visibility across the organization. The organization-wide default settings are often set up with the principle of “least privilege,” which means that the org-wide default settings for each object within Salesforce should be set up keeping in mind the user with the lowest and least access within Salesforce.
Another way of saying that is if any single user within Salesforce cannot access a particular object, let’s say “Object A,” then the OWD setting for Object A should be set to “Private,” which is the most restrictive setting using OWD in Salesforce. As an architect, I often indicate in my assumptions which objects within Salesforce I have considered to be private vs. public due to the principle of least privilege. There are other areas of visibility which are derived from ownership of records, in which case I often indicate how users can access records that they are not owners of (i.e., sharing rules, sharing via teams, sharing via group membership, etc.).
Scope and Nature of Integrations
Given the out-of-the-box integration capabilities of Salesforce, project stakeholders often assume that there is not much development or setup required in the non-Salesforce system to work with Salesforce. They also assume that since Salesforce offers more than ten different types of APIs readily available for integration, the API will work automatically without a significant amount of configuration within Salesforce. This is a key reason for outlining the different methods being used to integrate the different systems with Salesforce during our FUSIAOLA analysis, the integration part, earlier. The integration options selected will allow an architect to justify the recommended investment in a middleware tool such as MuleSoft or the use of one of the Salesforce APIs over the others.
Assumptions can also be made about the type of protocols supported by the non-Salesforce system, because it is often the case, especially with SOAP API–based integrations, when the WSDL file of the non-Salesforce system is not supported by Salesforce. In such cases, when a WSDL file is not supported by Salesforce and a SOAP API–based integration is warranted, the only option is to use a middleware such as MuleSoft or Informatica, which orchestrates a protocol conversion to map the SOAP API schema of the non-Salesforce system with Salesforce SOAP API.
Identity Provider–Initiated vs. Service Provider–Initiated Authentication
When designing a solution with seamless experience for users, it is critical for an architect to clarify which system acts as the identity provider for which users and which system(s) acts as the service provider. It is often the case that users within a company need access to many systems within the company other than Salesforce, and hence most companies implement single sign-on strategies that assign one system such as Microsoft Active Directory (AD) or PingFederate or Okta as the central repository and true source of all user details. In such cases, it’s important to indicate the identity management system as the identity provider for Salesforce and Salesforce as the service provider to the identity management system. In other cases where a user accesses other systems from within Salesforce by using the Salesforce Canvas app, Salesforce becomes the identity provider for the external system being accessed, and the external system becomes a service provider for Salesforce. It is important to lay out which system acts as the identity provider vs. which system acts as the service provider, because, more often than not, project stakeholders assume all systems can act as identity providers simultaneously.
Format of the FUSIAOLA Analysis
High-Level FUSIAOLA Analysis Example
For a detailed FUSIAOLA analysis in the right format, we recommend creating this artifact in Microsoft Excel with multiple worksheet tabs for each analysis, respectively.
Now that we have conducted the FUSIAOLA analysis, the artifacts from here on can be created based on the information gathered during the FUSIAOLA analysis. The FUSIAOLA analysis will be the basis for the next two artifacts that we will be discussing. We will start next with the system landscape artifact.
System Landscape Artifact
A Salesforce system landscape is a blueprint of the interoperability between Salesforce and all other systems existing within the company’s technical environment.
Illustrative System Landscape
You would replace the generic names in the preceding diagram with the relevant external system names, such as “Microsoft ADFS” instead of the Active Directory Federation server or “SAP ERP” instead of third-party systems or “MuleSoft” instead of middleware/ESB tool.
At first look, the Salesforce system landscape may appear overwhelming to create, but you will find it fairly easy to draw if you have done the FUSIAOLA analysis correctly and gathered all the information prior to attempting to draw the system landscape.
There are seven things to consider and include from the FUSIAOLA analysis when drawing a Salesforce system landscape.
What Is the Salesforce Organization Strategy ?
A company can either maintain a single environment of Salesforce for use by the entire company or have multiple Salesforce environments, each environment with its own set of users, licenses, data, functionalities, and governor limits allocated and managed independently. We will discuss the approach to choosing an ideal org strategy in detail in Chapter 3.
What Are the Systems Existing or New That Need to Interact with Salesforce?
To keep or replace the system.
To integrate with the system or migrate data from the system.
The system is on-premise, on-cloud, or a hybrid of on-premise and on-cloud.
Data will be migrated to Salesforce or an external data warehouse or both.
For a visual aid, you can often add a tick mark 
against the systems that will remain and a cross 
against the systems that will be replaced.1 The arrows connecting the system to Salesforce or the middleware or another system should indicate if it is one-way sync or bidirectional sync.
What Are the Specialty Salesforce Licenses That You Will Be Using Beyond the Core Sales, Service, or Platform Licenses?
Salesforce offers a variety of Salesforce licenses related to specialty functions such as Marketing, Quotes Management, and Einstein Analytics, which can be combined with the core Sales Cloud, Service Cloud, or Platform licenses. Most of the specialty Salesforce products seamlessly integrate with the core Salesforce platform similar to a Salesforce AppExchange app which is installed as an add-on package in your Salesforce environment and inherits access to all required records within Salesforce through the add-on app connection.
In exceptional cases, such as in the case of Salesforce Marketing Cloud, integration is configured using a Salesforce-provided connector called the “Marketing Cloud Connect.” The “Marketing Cloud Connect” connector is included within the price of the Marketing Cloud licenses and can be configured as a connected app to set up bidirectional integration between Marketing Cloud and your Salesforce environment. We will discuss the most commonly used Salesforce products and a high-level introduction of each product in Chapter 3.
What Are the AppExchange Products That You Will Leverage to Avoid Custom Development?
In addition to its vast variety of products and thousands of declarative capabilities, Salesforce also has a marketplace for independent third-party vendors who offer prebuilt apps that can be easily downloaded to extend any feature not fully available via Salesforce’s license types. The Salesforce marketplace for third-party apps, known as “AppExchange,” is similar to the “App Store” for Apple devices and the “Google Play Store” for Android devices.
Although most apps available on AppExchange have subscription costs associated with them, there are several apps available on AppExchange that are completely free. Some of these free apps are developed by Salesforce themselves such as the “Salesforce Adoption Dashboards” which provides a Salesforce administrator and other relevant users with visibility into overall user login history, trending, adoption of key features such as opportunity pipeline, and marketing productivity.
Also, brand name vendors such as DocuSign and QuickBooks, which offer specialized capabilities such as electronic signatures and bookkeeping, respectively, have connectors and adapters available on AppExchange to allow companies with a subscription to their services, with the ability to use their services seamlessly within Salesforce.
Almost all apps on AppExchange are required to be updated regularly to be compatible with the latest version of Salesforce and all its new features. Often the regular updates and maintenance of the apps are offered by the app developers to the Salesforce subscribers at no extra cost.
Hence, as an architect, you need to consider AppExchange as the next best option after exhausting declarative configuration capabilities and before considering coding options in Salesforce to meet business needs.
For your reference, we have shared details about a variety of popular and commonly used apps available on AppExchange in Chapter 3.
How Many Different Types of Salesforce Community Licenses Are Needed for External (or Any Internal) Users?
Salesforce communities deserve some consideration on their own when designing a Salesforce solution which requires giving access to a high volume of external users or when collaboration with external partner organizations is required or when a significant group of internal users needs to access Salesforce infrequently and for a small set of functions within Salesforce. A Salesforce community is used to provide segregated access to and allow collaboration between external customers, partner companies, and internal employees. A Salesforce environment can support multiple communities and community types, with each serving a distinct purpose and set of users.
A user’s access into Salesforce and their respective access to specific information within Salesforce not only vary between access via a core Salesforce platform license and a Salesforce community license but also vary significantly between the various types of Salesforce communities such as Community, Community Plus, Partner Community, and Employee Community.
The assignment of the ideal Community Cloud license to the appropriate users impacts the design for the various user authentication methods needed, data security, visibility, and sharing capabilities.
We will talk a bit more about the Salesforce communities and the different types of communities in Chapter 3.
What Are the User Authentication/Authorization Tools for Both Internal and External Users to Authenticate into Salesforce?
Having completed the FUSIAOLA analysis, you may already have a list of actors and the different methods of authentication that are needed by each actor. Users can access Salesforce directly using a standard username/password on the Salesforce login page or via the Community Cloud login page or through SSO capabilities supported by an identity and access management system such as Active Directory Federation Services or by using the credentials of a social account such as the user’s Facebook account.
We will be discussing in detail the various types of authentication methods and when to use which authentication method in Chapter 7. However, for the purpose of the Salesforce system landscape, we recommend making a note indicating the type of authentication needed by each actor besides the respective actor.
What Is the Integration Strategy to Integrate Salesforce with Existing or New Systems?
- 1.
Extract-Transform-Load (ETL) large volumes of data.
- 2.
Connect two or more systems for data accessibility across the connected systems.
- 1.
ETL Tool : Supports the process of extracting, transforming, and loading large volumes of data from multiple data sources. They can be used with batch, scheduled, or ad hoc data operations. They can also be used to perform data migration and data archiving activities.
- 2.
Enterprise Service Bus (ESB) : A system that provides a homogeneous bus designed to distribute work between connected systems and applications. This middleware environment normally connects systems via an Application Programming Interface or API. Salesforce recently bought MuleSoft, an industry leading ESB provider.
- 1.
Orchestration: Composing of several existing detailed components into an aggregated service. Orchestration will manage the level of service and data. This can be done to achieve appropriate “extensibility” of the underlying components.
- 2.
Transformation: Data transformation is often required to move information from one system to another. The ESB creates a transformation template to move data in one format to another format needed by a consuming system.
- 3.
Transportation: Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC). Note: Mule treats databases like another “service” by making JDBC just another transport (or endpoint) where data can be accessed.
- 4.
Mediation: Providing multiple interfaces for the purpose of (a) supporting multiple versions of a service for backward compatibility or, alternatively, (b) allowing for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (flat file), and one standards-compliant (SOAP/XML) interface.
- 5.
Nonfunctional Consistency: For a typical ESB initiative, this can include consistency around the way security and monitoring policies are applied and implemented. Additionally, the goals of scalability and availability can be achieved by using multiple instances of an ESB to provide increased throughput (scalability) and eliminate single points of failure (SPOFs), which is the key objective for highly available systems .
More than two systems need to be integrated with Salesforce, with complex integration requirements.
Multiple data transmission protocols are used, such as FTP, HTTP, web service, and JMS.
Business criteria dictate the message routing to and from external systems based on message content and criteria-based parameters.
Salesforce in addition to its standard API capabilities also provides prebuilt integration features such as Files Connect, which allows seamless integration between Salesforce and external files and document management systems such as Quip, Google Drive, SharePoint, or Box.com. With Files Connect, Salesforce users can seamlessly access, share, store, and search for files stored externally within Quip, Google Drive, SharePoint, or Box.com.
In this section, we mainly discussed the use of an ESB tool as the integration strategy. However, in Chapter 6, we will discuss integration strategies with out-of-the-box Salesforce integration capabilities.
So far, we conducted a deep-dive analysis of business needs and discussed the system capabilities needed with the FUSIAOLA analysis. Next, with the system landscape artifact, we discussed how Salesforce fits into the company’s technology ecosystem of new and existing systems.
In the next artifact, we will be diving into the inner mechanics of your Salesforce org by discussing how data is stored, retrieved, accessed, and managed within Salesforce.
Data Model Artifact
Data is the core ingredient of every system, but how data is entered, stored, organized, and utilized within a system determines the performance and efficiency of the system.
In a multi-tenant architecture , such as Salesforce, an optimized data model is extremely significant, because data model inefficiencies in Salesforce can result in performance degradation, leakages or blockages in visibility and sharing, and even data breach when interacting with external users and systems.
Sample Data Model of an Opportunity and Order Management Application
- 1.
Objects needed to store and manage data in Salesforce
- 2.
Object types (i.e., whether they are standard, custom, or external objects)
- 3.
Record types within each object
- 4.
Object relationship to other objects
- 5.
The organization-wide default settings for object visibility
- 6.
Owners of the records within each object
- 7.
Estimated number of records per object that can exist at any given period of time
Objects Needed to Store and Manage Data in Salesforce
One of the best ways to identify the objects that will be used to store and manage data is to start by assessing the standard objects within Salesforce and the purpose served by each standard object within Salesforce. To review which standard objects are available within Sales Cloud or Service Cloud, visit this site: https://developer.Salesforce.com/docs/atlas.en-us.api.meta/api/data_model.htm (please note, in this Salesforce article, the Service Cloud objects are referred to as “support objects”). Salesforce has developed these standard objects and their relationship to each other based on years of industry best practices. It is important that you map your sales and service business process as closely to the out-of-the-box business processes supported by Salesforce, in order to reap the most benefits from standard objects and the out-of-the-box capabilities supported by all standard objects. For example, the Salesforce assignment rules only work with the standard lead object or case object and are not available to use with any custom objects.
The first and most important standard object to start with is the account object. You cannot ignore the account object in Salesforce because Salesforce is an account-based system and is managed as the ultimate parent of most standard objects and custom objects that exist within any Salesforce org. Many of the sharing rules within Salesforce are also determined based on a specific user’s access level or ownership of the records within the account object. An account object can relate to a company or an individual. In cases where the account is mapped to individuals such as individual customers, the record type of account is called a “person account.” A person account can be enabled for any Salesforce org by opening a case with Salesforce.
The next core object that can be easily mapped with almost any business process is the contact object, which houses the details of individuals such as customers who are related to one or more accounts (e.g., employees of customer companies).
Lead
Opportunity
Order
Contract
Case
Product
Asset
Quote
Pricebook
A key thing to note about Salesforce standard objects is that the standard objects and the standard fields within the standard objects cannot be modified or deleted. You can always add new custom fields and not use the standard fields within the standard object if they are not standard required fields of that standard object. Also, the relationships between two standards objects cannot be modified or deleted. You can always have additional lookup relationships between two standard objects. You cannot create a custom master-detail relationship between two standard objects because one of the limitations of the standard objects is that standard objects cannot be on the detail side (i.e., child object) of a master-detail relationship.
Salesforce does not penalize you with any data storage limits or any restrictions if you do not use any or all of the standard objects available to you. But if you do use any of the standard objects, your data needs to play by the rules of that standard object. For example, if you use the opportunity standard object, then certain fields on the opportunity object such as “Stage” (i.e., opportunity stage) are required fields when you create or update an opportunity. Also, for opportunities with products, the opportunity amount field is automatically set to the sum of all products associated with that opportunity, and the amount field cannot be directly edited by users unless the opportunity has no products associated with it.
Due to some of these conditions and limitations associated with using standard objects, an architect can justifiably consider creating custom objects, instead of using a set of standard objects. The other justifiable reason for considering custom objects is when the architect has exhausted all data management options with standard objects and the data exhibits characteristics that cannot be accommodated by any available standard object. We will discuss the different object types in the next section.
Object Types
In simple terms, objects created by Salesforce are called standard objects, objects created by you within Salesforce are called custom objects, and any objects you create that map to data stored outside your Salesforce org, in an external system, are called external objects.
We discussed standard objects in the previous section, so here we will discuss the considerations related to using custom objects and external objects.
Every custom object name should be unique among all standard or custom or external objects existing in your Salesforce org and is automatically assigned a suffix of “__C” to distinguish itself from all standard objects.
A sharing rule object is automatically created for each custom object that does not have a master-detail relationship with another object. The sharing rule object manages any sharing rules that are applied to the custom object, such as a criteria-based sharing (CBS) rule, allowing sharing the object records with another user when a certain user-defined sharing criterion is met by the record. All sharing objects inherit the same name as the custom object but are appended with the suffix “__Share” instead of “__C” that is appended as a suffix to custom object names.
External objects are similar to custom objects, except that the data lives in an external system outside your Salesforce org. External objects are a great way to extend the Salesforce data model beyond Salesforce by connecting with externally stored data without having to bring in the data or store the data into Salesforce. Each external object that you create relies on a data mapping configured by you that maps the Salesforce data with the data stored in a data table on the external system. Each of the external object’s fields maps to a table column on the external system.
Every external object name should be unique among all standard or custom or external objects existing in your Salesforce org and is automatically assigned a suffix of “__X” to distinguish itself from all standard objects.
External objects can only maintain lookup relationships with any standard and custom objects within Salesforce. The lookup relationships for external objects can be one of two types: external lookups and indirect lookups. (Both are discussed in a later section of this chapter.)
Formulas and roll-up summary fields in standard or custom objects cannot reference fields on external objects.
You cannot assign default values to custom fields created in external objects.
- You cannot create any of the following custom fields in external objects:
Auto-number (available only with the cross-org adapter for Salesforce Connect)
Currency (available only with the cross-org adapter for Salesforce Connect)
Formula
Location
Master-detail relationship
Picklist and multi-select picklist (available only with the cross-org adapter for Salesforce Connect)
Roll-up summary
Text (encrypted)
Text area (rich)
- You cannot use the following standard features of Salesforce with external objects:
Activities, events, and tasks
Approval processes
Attachments
Field history tracking
Merge fields
Notes
Record-level security (sharing)
Record types
Schema Builder
Validation rules
Workflow rules
When you deploy an external object that is connected via OAuth 2.0, from a sandbox org to a production org, you will need to update the authentication provider each time you deploy.
Record Types Within Each Object
Often during data modeling , you may identify multiple sources of data exhibiting similar characteristics that requires you to reuse an existing standard or custom object that you are already using. An example of this situation is when you want to store data about partner companies and B2B customer companies both in the account object.
This is a classic scenario for creating a record type of common object where two types of data need to be stored. Record types can be perceived as different flavors of the same object, partitioned from each other based on differences in business processes and user visibility needs. You can expose different fields to different users via different record types of the same object. All fields in the different record types of a single object are still stored together in the same object. However, the record types allow you to provide different user experience requirements due to differences in business processes. Another key use of record types is to present different values in a picklist field to different users without creating redundant or duplicate picklist fields on an object. Picklist values are often critical within an object since they are used to capture information such as record status, record stage, user preferences, and record choices. Duplicating these fields can cause significant data integrity and data reporting issues.
Records within one record type can also be switched to another record type (if warranted by the business needs). This level of flexibility makes record types a critical design element when designing the data model for Salesforce.
Business and person accounts require at least one active record type. Person accounts are account records to which a special kind of record type is assigned by Salesforce. Person account record types allow contact fields to be available on the account and allow the account to be used as if it were a contact. A default person account record type named “Person Account” is automatically created when person accounts are enabled for your org. You can create multiple person account record types after having the initial person account enabled by Salesforce in your Salesforce org. Users can change a “person account” record type to another “person account” record type or a business account record type to another business account record type through the UI. But a person account record type can only be changed to a business account record type and vice versa programmatically.
A user can be associated with several record types. For example, for a user who creates opportunities for both B2C and B2B sales, then both the B2C and B2B opportunity record types can be made available to the same user when creating new opportunities.
You need to update any sharing rules associated with some record types if you want to apply the same sharing rule to other record types of the same object. For example, let’s say you have a record type called “B2C Opportunity” and you created a criteria-based sharing rule that shares all opportunity record types with your sales team. Now if you also have another record type called “B2B Opportunity” that you would also like to share with the same sales team, then you will need to update the sharing rule to include the “B2B Opportunity” record type in the criteria; else, it will not be shared automatically with the sales team .
Deactivating a record type doesn’t remove it from any user profiles or permission sets. Deactivating a record type only means that no new records can be created with that record type. However, any records that were previously created for that record type are still associated with it, and so are any page layouts associated with that record type.
- When converting, cloning, or creating new records, these additional considerations apply to objects with multiple record types:
When converting a lead, the new account, contact, and opportunity records use the default record type for the owner of the new records. The user can choose a different record type during conversion.
When cloning a record, the new record has the record type of the cloned record. If the user’s profile doesn’t have access to the record type of the cloned record, the new record adopts the user’s default record type.
When a user creates a case or lead and applies assignment rules, the new record can keep the creator’s default record type or take the record type of the assignee, depending on the case and lead settings specified by the administrator .
Object Relationship to Other Objects
An object standard or custom can have the following types of relationships with other objects:
Associating one object with another in a hierarchical relationship such that one object is a master (also known as parent object) and the other is a detail object (also known as child object). The parent object in such an association dictates the behavior of the child object including accessibility to the child object.
Detail and subdetail records inherit security settings and permissions from the master record. You can’t set permissions on the detail record independently.
The owner of the master object record automatically inherits ownership of the detail object records associated with it; ownership cannot be changed.
The records in a detail object cannot have any sharing rules exclusively applicable to itself. All sharing rules for a detail record are inherited from its master record.
A master record must exist and is required to create and store any detail record.
Deleting a detail record moves it to the Recycle Bin and leaves the master record intact; deleting a master record also deletes related detail and subdetail records. Undeleting a detail record restores it, and undeleting a master record also undeletes related detail and subdetail records. However , if you delete a detail record and later, separately, delete its master record, you cannot undelete the detail record, as it no longer has a master record to relate to.
Links two objects together. Lookup relationships are similar to master-detail relationships, except they do not support sharing or roll-up summary fields.
Can be required, prevent deletion, and cascade delete if set up.
Created by creating a custom object with two master-detail or lookup relationships. Such a custom object that sits between two objects is called a “junction object.”
A special lookup relationship is available for only the user object. It lets users use a lookup field to associate one user with another that does not directly or indirectly refer to itself. For example, you can create a custom hierarchical relationship field to store each user’s direct manager.
The following types of relationships only apply to relationships between external objects and standard or custom objects:
An external lookup relationship links a child standard, custom, or external object to a parent external object.
The standard external ID field on the parent external object is matched against the values of the child’s external lookup relationship field. External object field values come from an external data source.
Links a child’s external object to a parent standard or custom object.
When you create an indirect lookup relationship field on an external object, you specify the parent object field and the child object field to match and associate records in the relationship. Specifically, you select a custom, unique external ID field on the parent object to match against the child’s indirect lookup relationship field, whose values come from an external data source.
The Organization-Wide Default Settings for Object Visibility
Private
When this setting is enabled for the object, only the record owner, and users higher in the role hierarchy, can view, edit, and report on those records.
Public Read-Only
When this setting is enabled for the object, all users within your Salesforce org (i.e., internal as well as external users with access) can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.
Public Read/Write
When this setting is enabled for the object, all users within your Salesforce org (i.e., internal as well as external users with access) can view, edit, and report on all records.
Controlled by Parent
(only applicable to child objects in a master-detail relationship)
When this setting is enabled for an object that is a child object in a master-detail relationship with another object, then the user accessing this child object is granted the same access as the user’s access to the parent object.
Public Read/Write/Transfer
(only applicable to the lead object and case object)
When this setting is enabled for the lead object or the case object, all users can view, edit, transfer, and report on all lead and case records.
Public Full Access
(only applicable to the campaign object)
When this setting is enabled for the campaign object, all users can view, edit, transfer, delete, and report on all campaign records.
We will be discussing more on the need for visibility and sharing using organization-wide default sharing settings in Chapter 5. However, this sharing setting needs to be identified in the data model artifact because it is the only security setting that determines the object-level visibility and security within Salesforce .
Owners of the Records Within Each Object
Ownership of records within each object is an important detail that needs to be identified within a Salesforce data model because, in Salesforce, record ownership determines the visibility and security of data at a record level. Record ownership determines which users can access which records and record types related to the object.
- 1.
An owner field is automatically created in every object, except for a child object in a master-detail relationship.
- 2.
A sharing rule object is created for each custom object and already exists for standard objects, which defines which users and groups can access records.
- 3.
A group membership object manages access to records via sharing rules granted to a group of users through private and public groups, queues, the role hierarchy, and the territory hierarchy.
We will be discussing more on visibility and sharing at a record level based on ownership-based sharing (OBS) in Chapter 5. An important skill is identifying the record owners for records within each object. During the design of the data model, identifying which user can see what data allows you to detect any large data volume concerns . This concern is called an “ownership data skew.” Data skew occurs when a single user owns more than 10,000 records of a single object. We will be discussing more on the concerns related to large data volumes in the next section and also in Chapter 4.
An Estimated Number of Records Per Object That Can Exist at Any Given Period
You need to identify the volumes of data stored in each Salesforce object. Storing and managing large data volumes in Salesforce requires additional care. A large data volume design requires special consideration regarding ownership, sharing, queries, and role hierarchies.
When large data volumes are stored or managed in Salesforce, it leads to significant performance degradation of your Salesforce org, including slower SOQL queries, more time-consuming searches, and slower rendering of list views.
There are more than 50 million records stored in the account object.
There are more than 20 million records stored in the contact object.
There are more than 100 million records stored in any single custom object.
The total number of internal users within a single Salesforce org exceeds 10,000 users.
A single user within Salesforce is the owner of more than 10,000 records within a single object.
100 GB of record data storage capacity is reached, not including files and attachments.
There are several approaches to mitigate large data volumes within Salesforce. Most approaches start by identifying the objects with a potential for accumulating large data volumes over time, which is key to prescribing the appropriate measures for curing system performance of Salesforce.
With the preceding considerations, you should be well equipped to draw Salesforce data models. However, as we discuss the core concepts of Salesforce in the following chapters of this book, you will be able to create more productive and more detailed artifacts, including the optional artifacts we mentioned at the beginning of this chapter.
Summary
The three key artifacts that you as a Salesforce architect must produce for every solution. These consist of the FUSIAOLA analysis, the system landscape, and the data model.
The FUSIAOLA analysis decomposes the business requirements into functions and features, users and user groups, other systems interacting with the solution, integration methods between the other systems and Salesforce, authentication and authorization methods for users and systems to gain access into the solution, objects within Salesforce that will store various data records created for the solution, the Salesforce licenses needed for users, and finally the assumptions made in designing the solution.
Business requirements must be decomposed to determine the functions and features by categorizing them into one of three technical contexts. The three technical contexts are data context, business logic context, and interface context.
Users and user groups can be grouped together based on four attributes, which are information role attribute, business function attribute, internal vs. external attribute, and role hierarchy index attribute.
Other systems interacting with the solution can be existing systems or new systems that need to be set up as part of the final solution.
Integrations between existing and new systems and Salesforce need to be designed for each system based on its interaction level with Salesforce.
Authentication and authorization needs to be designed for each user group and system requiring access into the Salesforce solution.
An object model design in Salesforce determines how data is stored, organized, and utilized in Salesforce for optimal use and efficiency of the solution.
Assumptions should be documented to justify your design considerations that cover missing or implicit details relevant to the solution.
A system landscape artifact should be developed based on seven enterprise-level considerations.
A data model artifact should be developed based on seven enterprise-level considerations.