6

Formulating a Secure Architecture in Salesforce

Your Unique Sign-Up Code

Your unique sign-up code to unlock the online content is c147tx. The sign-up link is https://packt.link/ctasignup.

Open the link, enter the code, and complete the sign-up process by following the instructions detailed in the Instructions for Unlocking the Online Content section of the Preface.

This chapter will continue exploring Salesforce-specific knowledge areas required to pass the CTA review board. This time, you will tackle the security domain.

Designing a secure system has never been more important than today, with the continuous move toward customer-centric solutions and the rise of connected devices. Salesforce has reshaped the common understanding of CRM. Several enterprises are adopting Salesforce as their central engagement platform, with dozens of inbound and outbound integrations to different other systems.

As a Salesforce security architect, you are expected to utilize the rich set of Salesforce functionalities to design a solid security architecture. You are also expected to define the security measures needed to protect the data while it’s being transferred from and to other systems. You must master the different ways license types and object relationships impact your data visibility—particularly while dealing with Salesforce communities or complex sharing and visibility requirements.

Security is one of the widest domains in Salesforce. It covers many different and diverse functionalities and is also impacted by other domains. You will come across topics related to security architecture in later chapters, considering the tight relationship it has with other domains, such as data architecture. In this chapter, you are going to cover the following main topics:

• Understanding what you should be able to do as a security architect
• Introducing the security architecture domain (mini hypothetical scenario)—Packt Innovative Retailers (PIR)
• Utilizing the appropriate security mechanisms and building your solution and presentation

Note

You are advised to utilize the section on cryptography in Chapter 3, Core Architectural Concepts: Integration and Cryptography, and the authentication flows listed in Chapter 4, Core Architectural Concepts: Identity and Access Management, as references to help you get the most out of this chapter.

Now, explore and get started!

Understanding What You Should Be Able to Do as a Security Architect

Security architects are crucial as they help assess the enterprise system for weaknesses, conduct penetration testing, and create security standards for their organizations. As a Certified Technical Architect, you need to be able to work with security architects and ensure that your proposed solutions are at the highest level of security compliance.

Note

According to Salesforce’s online documentation, you should be able to meet a specific set of objectives that can be found at the following link: https://packt.link/g6RGI.

By the end of this chapter, you should be able to do the following:

• Utilize the appropriate platform security mechanisms
• Design a secure portal architecture
• Control record-level security using declarative and/or programmatic features
• Use the platform security features to control object and field access permissions
• Design an end-to-end identity management solution

Now, it’s time to have a closer look at each of these objectives.

Utilizing the Appropriate Platform Security Mechanisms

Salesforce comes with a rich set of functionalities and tools that you can use to manage access to data. These functionalities can be considered stacked on multiple levels. You need to have a good understanding of each of these capabilities, how they work, and what their limitations are. You also need to practice configuring these features to get a solid understanding of their behaviors. Using these tools, you can configure security on multiple levels:

• Org
• Object
• Record
• Field levels

The following diagram illustrates these different levels:

Figure 6.1 – Data access control level

The object and field levels are sometimes considered one combined level, and it allows you to configure which objects and fields the user can have access to and what exactly they will be able to carry out with these objects and fields. On the other hand, record-level access determines which records, out of the objects a user has access to, are visible to that user and whether they can only view or also edit them.

The record owner always has full access to a record. When you think of the data sharing and visibility architecture, it is always about determining what records the current users do not own but still require access to.

Org-level access is about ensuring the data in your org cannot be accessed by users in other orgs, in addition to different security mechanisms to ensure users can access your org securely.

The tools and functionalities that can help you design and configure the data sharing and visibility architecture are listed in the following diagram:

Figure 6.2 – Salesforce data access control tools and functionalities

At the bottom of the chart, you can see the org-level security mechanisms. They ensure that the data of one org is not mixed with data from other orgs. Salesforce is based on a multitenant architecture, so data belonging to multiple tenants could be hosted on the same platform. The org ID ensures that users of one org can access the data that belongs only to that org. The other org-level security functionalities are meant to protect the org itself from unauthorized access.

There are object-level security mechanisms that control which objects are accessible for a particular user license. For example, the license granted for a particular user does not allow access to the opportunity object. In that case, all the higher-level security mechanisms will adhere to this restriction, which means that you would not be able to grant a user access to the opportunity via profiles or permission sets.

If you continue moving up the chart, you will come across the record-level security mechanisms, which control access to the records of a specific object—assuming that the user has access to the object from the lower object-level layer. This starts with the org-wide defaults (OWD), which set the default access levels for object records. For example, the OWD of the accounts could be private, public read-only, or public read-write. This defines the users’ access level for account records they do not own, assuming they have access to the account object.

Role hierarchies, sharing rules, and other sharing mechanisms can be used to grant users access to more records or higher privilege levels. For example, you can use criteria-based sharing rules to grant users in specific roles access to account records that meet certain criteria.

There are other factors that impact these tools and functionalities, such as the structure of the data model and the relationship types between the objects.

At the very top of the diagram, you can see the restriction rules, which is a functionality that has been recently introduced by Salesforce. You define restriction rules by specifying the record and user criteria that must be met to activate the rule. Once the criteria are met, the records that the user would have access to via the other mechanisms (such as OWD, sharing rules, manual sharing, and others) are filtered. This functionality provides a means to restrict access to specific records for some users. It is particularly useful with objects such as tasks, events, and contracts.

Restriction rules are available for the standard task, event, contract, timesheets, and timesheet entries objects, in addition to custom objects and External Objects.

Note

You can learn more about restriction rules at the following link: https://packt.link/bnsbu.

The existence of this functionality should not be misunderstood or misused as an excuse to introduce a less efficient data control mechanism. This functionality is not meant to replace any of the other functionalities but to extend them to cover use cases that were difficult to control in the past. CTAs are expected to understand the full breadth of the sharing mechanisms available on the platform and make the best use of them.

Scoping rules are another functionality that you should be aware of. This is not included in Figure 6.2 because it does not extend or restrict the user’s accessibility to records but simplifies it. Scoping rules control the records that the users see by default. However, the user is not restricted from accessing other records. Scoping rules are to help the users focus on a default set of records while still enabling them to look up other records if needed.

Imagine a scenario where you have users supporting a specific set of customers every day. You can configure scoping rules so that the users would see a different set of customers every day by default. They can still access the other customer records if needed (after all, they are expected to do that on the day they are assigned to support these customers), but the scoping rules would make their daily work simpler and more focused.

Note

You can learn more about this functionality at the following link: https://packt.link/w47wD.

Prior to learning about this functionality, you could still achieve the desired result but with much more effort, time, and overhead to the system. Now it is a built-in out-of-the-box feature.

Design a Secure Portal Architecture

The Salesforce Community functionality (now part of Salesforce Experience Cloud) allows you to design and expose secure customer and partner portals. The external app license can also help you develop custom applications for your internal employees.

Data can be shared with the partner license and the external app license users using standard sharing mechanisms, such as sharing rules. Users with the Customer Community Plus license can also benefit from this. While you can use sharing sets to share data with Customer Community users, Salesforce has recently made that functionality available for Customer Community Plus and Partner Community users as well. Records owned by users with licenses that do not have an assigned role (such as the Customer Community license) can be shared with users with role-based licenses (such as the Partner Community users) via criteria-based sharing rules. This is a feature that has been introduced in the Spring’22 release.

Note

You can learn more about the different types of Community licenses at the following link: https://packt.link/seMbm.

The CTA review board scenarios are likely to contain one or more customer requirements that can be solved using Salesforce communities. You are strongly encouraged to try out the different types of communities and configure them by hand.

Moreover, you need to familiarize yourself with the social sign-on capability, which is becoming more popular nowadays. With the rise of social media, most enterprises allow their customers to log in to secure portals using their social media credentials. Social media networks normally support OpenID Connect and/or OAuth 2.0 standards. Considering that Salesforce is a secure platform that can safely store a consumer secret, the flow that is used for social sign-on is the web server flow, which is covered in Chapter 4, Core Architectural Concepts: Identity and Access Management.

Salesforce has built-in support for some social networks, such as Facebook, LinkedIn, and Twitter.

Control Record-level Security Using Declarative and/or Programmatic Features

You need to be familiar with all the declarative record-level security features illustrated in Figure 6.2. Also, you need to understand how Salesforce sharing works. This will help you determine when it is appropriate to select a declarative or a programmatic sharing mechanism.

Process of Creating and Calculating Record Access Data

Every time a user attempts to access a Salesforce record by any means (such as opening a record page, viewing it in list views, running a report, accessing it via an API, or even searching for it using global search), Salesforce checks the security configurations for that record to determine the access level allowed for this user. This process could be expensive and resource-consuming. This is especially the case while working in a complex environment with millions of records, complex hierarchies, dozens of sharing rules, and several portals. Doing such complex calculations to determine whether the user can or cannot access these records could take a significantly longer time. That is why Salesforce calculates record access data only when there is a need to do so, which is normally when the configurations are modified.

Salesforce calculates the record access data and persists it so that it can be quickly accessed and evaluated whenever needed. This ensures optimal system performance. It also signifies that you need to consider the impact of changing your data security and sharing mechanisms before making any modifications.

You can share records programmatically, and if your Apex class has been developed to use the with sharing keyword, then your class will respect the sharing and visibility rules in your org. Classes with the without sharing keyword will ignore sharing settings and retrieve all records from a certain object, even if the currently executing user does not have access to some or all these records. This is a powerful tool that you should use wisely as it might cause a data leak. It is strongly recommended that you design your Apex classes so that they always use the with sharing keyword.

Different Types of Access Grants

Salesforce uses four different types of access grants to determine how much access a user or group has to a particular object with a private or public read-only OWD setting. These four grants are as follows:

• Implicit grants: This is also known as built-in sharing. These are non-configurable special case grants that are built-in within the platform. For example, users who have access to child opportunities can also view their parent account records.
• Explicit grants: These grants are used when the records are explicitly shared with specific users or groups.

Note

The following use cases are examples of explicit grants:

Ÿ A user becomes the owner of a record

Ÿ A queue becomes the owner of a record

Ÿ A record is shared—via a sharing rule—with a user, a public group, a queue, a role, or a territory

Ÿ A record is shared with a user using an assignment rule

Ÿ A record is shared with a territory using a territory assignment rule

Ÿ A record is shared manually with another user, a public group, a queue, a role, or a territory

Ÿ A user is added to an account, opportunity, or case team

Ÿ A record is shared programmatical with a user, a public group, a queue, a role, or a territory

Behind the scenes, Salesforce creates a share record that defines the entities that can access this record and the permitted access level:

• Inherited grants: This is specific to hierarchies, particularly when a user, personal or public group, queue, role, or territory inherits access to a record via a role, territory, or group hierarchy.
• Group membership grants: This type of grant occurs when a group member (such as a user, public group, queue, role, or territory) gets access to a record because the group has been explicitly granted access to the record.

The relations between the different objects in your data model directly impact the record visibility and the overall sharing architecture.

Impact of Object Relations on the Sharing Architecture

The master/detail relationship between objects grants access to child records if the user has access to its parent/master record. You need to be particularly careful while designing your data model and ensure that you utilize the master/detail fields correctly. Hiding records using the UI layer should not be a preferred solution. You should aim to exhaust all your options, including programmatic sharing, as there is always a risk that the user can find a way to bypass the UI and get access to restricted records.

Use the Platform Security Features to Control Object and Field Access Permissions

You need to understand how you can use a combination of profiles, permissions sets, and field-level security to control object and field-level access. Be careful not to overlook the requirements that require object-level access control in the scenario. They are usually simple, and therefore many candidates tend to overlook them. This may result in missing the points associated with these requirements. Always keep in mind that the CTA review board is a point-collection exercise, and you should avoid missing easy points.

You also need to understand when you can propose using the view all and modify all object-level permissions. These are powerful permissions that allow your users to bypass the sharing mechanisms and access the records directly. Salesforce will not even create share records for users with view all or modify all object permissions as they simply do not need it. This makes the process of accessing a massive amount of data quicker compared to the regular case, where Salesforce needs to query and evaluate the share records first. Therefore, these powerful permissions are considered suitable for service users who need quick access to massive amounts of data, such as integration users.

The view all data and modify all data permissions are profile-level permissions that allow the user to have access to all the org’s data across all objects. They are even more powerful and riskier than the object-level view all and modify all. Be careful when suggesting a solution that grants a user such high privileges. Even an integration user should not be granted such a high privilege without a solid reason. Think of the damage that could be done if such a user account got compromised.

Also, make yourself familiar with the other security settings you can configure at the profile level, such as the session settings, password policies, and login policies. Try all these features yourself to become familiar with them.

Design an End-to-End Identity Management Solution

By now, you should already know the importance of solid IAM architecture in your solution. This is especially true in today’s modern world, where the customer’s experience is the main differentiator of online businesses.

In Chapter 4, Core Architectural Concepts: Identity and Access Management, you covered all these aspects and went through some of the key industry standards. You also learned about several authentication flows that are supported by Salesforce. Make sure you are very familiar with each of them. It is strongly advised to practice writing these authentication flows over and over to understand them thoroughly.

Most, if not all, of the CTA review board scenarios will have at least one IAM requirement and you are very likely going to be asked about an authentication flow. You should show a good amount of understanding and confidence while going through that.

There is one more authentication flow, called delegated authentication, that you should be aware of. It is Salesforce specific. Therefore, it was not included in Chapter 4, Core Architectural Concepts: Identity and Access Management (which focused on common and standard flows).

Salesforce-Delegated Authentication: Why and How to Use It

Platforms can provide bespoke mechanisms to provide SSO capabilities, in addition to supporting standards such as OAuth 2.0, OpenID Connect, and SAML 2.0. Delegated authentication provides SSO capabilities just like the other mentioned standards but using a different user experience. Here, the system relies on another system to authenticate the user. Sounds familiar, right? The difference here is that this authentication is done in a blocking fashion and does not rely on tokens. Moreover, if you have multiple systems relying on another system to authenticate their users, then the user would need to log in again every time they try to access one of these systems. Take a simple example to explain this better:

1. Assume that you have three Salesforce instances—instances A, B, and C (each with a different My domain name to uniquely distinguish it).
2. All these instances are configured to rely on a remote authentication web service to validate users attempting to log in.
3. When a user attempts to log in to instance A, they will be presented with the Salesforce login screen (note that the user would not be redirected to a different login page, unlike what happens with standards such as SAML or OAuth). The user types in the credentials known by the remote authentication web service and hits the login button.
4. Salesforce checks the user record, and because the user has the Is Single Sign-On user permission enabled, it does not validate the credentials themselves. Instead, it invokes the remote authentication web service, passes the credentials (plus the IP from where the login attempt has been initiated), and waits for the response.
5. If the response is positive, the user is authenticated to instance A, a session cookie is created for instance A’s domain, and the user is logged in.
6. Now, assume that the user is attempting to access instance B. The browser would not detect a valid session cookie for instance B’s domain, which is the ideal case. With standards such as SAML, the user would not need to type in their credentials again (review the SAML SP-Initiated Flow section of Chapter 4, Core Architectural Concepts: Identity and Access Management). However, with delegated authentication, there is no mechanism to log them in automatically (because they have previously authenticated themselves against the remote authentication web service). Instead, they will have to input their credentials again (the same credentials used before to log in to instance A) and get authenticated again by the remote web service before they are allowed into instance B.

The following diagram illustrates the sequence of events that occur while logging in to instance A:

Figure 6.3 – Delegated authentication while logging in to a Salesforce instance (instance A)

The following diagram illustrates the sequence of events while logging in to instance B after successfully logging in to instance A. You will notice that the same sequence of events is getting repeated:

Figure 6.4 – Delegated authentication while logging in to a second Salesforce instance (instance B)

You typically use delegated authentication when you want to provide SSO functionality by utilizing an identity provider that does not support any of the standards recognized by Salesforce. You can also use this if the enterprise is using a complex login mechanism (likely, to increase security) that cannot be fulfilled with any of the supported IAM standards.

Now it is time to put all this knowledge into action. In the next section, you will be introduced to a mini hypothetical scenario that focuses on the security architecture domain.

Introducing the Security Architecture Domain: Packt Innovative Retailers

The following mini scenario describes a challenge with a particular client. You will study the scenario and then create a solution, step by step. To make the most out of this scenario, it is recommended that you read each paragraph and try to solve the problems within yourself, then come back to this chapter, go through the suggested solution, and compare and take notes.

Remember that the solutions listed here are not necessarily the only possible solutions. Alternate solutions are acceptable as long as they are technically correct and logically justified.

Scenario

Packt Innovative Retailers (PIR) is a global digital retailer. They sell computers, computer accessories, and services through multiple channels to both B2B and B2C customers. They also sell via a network of partners/distributors.

Current Situation

The organization is structured into two main departments—sales and service. Each report to an executive vice president (EVP), who, in turn, reports to the CEO. PIR mainly operates in three regions: AMER (North, Central, and South America), EMEA (Europe, the Middle East, and Africa), and APAC (Asia and Pacific). They share a single Salesforce org and currently have a set of global sales and services processed and configured that utilize the account, contact, opportunity, opportunity line item, product, service contract, asset, case, and entitlement objects. The sales department team is currently organized in the following structure:

• An EVP for global sales, who require visibility across all sales deals.
• A senior VP (SVP) covering each of the major three regions: AMER, EMEA, and APAC. SVPs report to the EVP.
• A VP for each country within a region (for example, France and Germany) reporting to the regional SVP. In total, PIR operates in 100 countries.
• A state/district director of each main territory/state in a country. There can be up to 60 territories per country. The average is 10 territories per country. State directors report to their country’s VP.
• Sales representatives who typically operate in a particular region or city. They report to the state director. Sales reps normally own the sales opportunity and direct customer relationships.
• In addition, there are 5,000 channel representatives (who sell the company’s products via the partner/distributor channel). They report directly to the global sales EVP, and they own the direct relationship with the partners.
• In total, there are around 20,000 employees in the sales department.

The service department is organized into two main product lines—hardware and software. This is in addition to the call center agents, who operate across both product lines. They are organized in the following structure:

• EVPs for the global service, who require visibility across all reported customer issues, service agreements, and service deals.
• An SVP for each product line, who requires visibility across reported customer issues, service agreements, and service deals related to their product lines.
• Each product line has multiple teams of service specialists (which could be up to 25 different teams) who provide support to resolve the raised client tickets and reported issues. They are organized by the different product categories they support, such as software servers, software cloud, and hardware desktop. Specialists can work in more than one team. Teams usually contain around 30 specialists.
• 500 call center agents who answer calls from customers and raise support tickets. They need visibility on all customer records, service agreements, and cases across all product lines.
• In total, there are around 1,000 employees in the service department.

PIR has a concern with the current setup. Several users have reported that they can view and edit records that they should not even be able to see. PIR also want to offer their customers the ability to self-serve as they see this as a crucial part of their future customer-centric services.

Requirements

PIR shared the following requirements:

• Users in the sales department should have access to the accounts owned by them or their subordinates only. This includes both direct and channel sales.
• Reports for direct sales should roll up from the entire sales org to the global EVP of sales.
• Reports for channel sales should roll up to the global EVP of sales.
• The service department reports should roll up by product line, and then should eventually roll up to the EVP of the service.
• Call center agents can create cases on behalf of customers. These cases could be about specific complaints, inquiries, or requests to service a PIR product they have purchased. Cases are organized by type and subtype, where the type value is aligned with the product line (hardware or software) and the subtype is aligned with the product line category, such as software servers, software cloud, and hardware desktop.
• Specialist teams can work on one or more case subtypes.
• Only the team of specialists working on a case and anyone above them in the hierarchy should be able to view it.
• Once a case is created, it gets assigned to a member of a specialty team based on the case’s type and subtype.
• PIR wants to provide its customers with the ability to self-serve by raising different types of cases. They currently have 500,000 B2B customers with up to 10 contacts each and 1 million individual B2C customers.
• Customers should only have access to cases related to their accounts.
• PIR wants to allow B2C customers to self-register or log in via Facebook. B2B customers must provide their corporate ID and their corporate email address during registration. B2B customers are also expected to provide a second factor of authentication upon logging in for additional security.
• PIR partners should be onboarded by their channel representatives. PIR has 20,000 partners, with an average of 10 users each. Partners should be able to have access to designated customer accounts only, determined by their channel rep. They should also be able to view and collaborate on the different sales and service opportunities for a given customer. They should not be able to access the customer’s cases.
• PIR employees in APAC have their credentials and user details defined in APAC’s Active Directory. Other regions use a different LDAP provider. PIR wants all its employees to access Salesforce using a unified login mechanism, which also requires the employee to use a mobile application to provide second-factor authentication.
• Once a PIR employee joins the company, a user should be created for them in Salesforce. Once the employee leaves, their corresponding Salesforce user must be deactivated immediately.
• The call service agents would like to use modern technology to look up the customer account based on the caller’s number. PIR does not want to utilize its existing call center infrastructure and would like suggestions for a more scalable and easy-to-maintain solution.

Utilizing the Appropriate Security Mechanisms and Building Your Solution and Presentation

Give yourself some time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Once you have done that, go through it again, section by section, and incrementally build the solution.

Understanding the Current Situation

First, try to understand the current PIR situation and landscape. You will start with the paragraph that begins with the following line:

The organization is structured into two main departments—sales and service.

PIR uses a single org for both the sales and service departments across three regions, that is, AMER, EMEA, and APAC. You need to keep that in mind while reading through the scenario and take notes if you believe they should consider a multi-org strategy.

You also learned that PIR utilizes a specific set of standard objects. You must memorize the key standard objects here (such as the sales and service objects). Use the official Salesforce documentation to get full and up-to-date data model diagrams. They are useful to help you understand the relationships between the different objects in a nutshell.

Note

You can use the following link to learn more about the standard Salesforce data model: https://packt.link/dJINu.

Based on the standard data model, you can draw your own diagram, which will be useful for the next stages. Your data model diagram may look as follows:

Figure 6.5 – Data model (first draft)

By knowing the standard objects that are being used, you can build an early idea of the types of licenses users would require. Clearly, PIR users are utilizing both sales objects (such as opportunity and opportunity line item) and service objects (such as case and entitlement). Keep this in mind while going through the rest of the scenario. You can take these notes on scratch paper.

Next, you have a set of bullet points starting with An EVP for global sales.

These bullet points describe the organizational structure/org chart of PIR’s sales department. This section can help you get an idea of the potential role hierarchy. Keep in mind that you do not necessarily design the role hierarchy to match the org chart. This is a common mistake. The roles in the role hierarchy play a part in defining what data the user will have access to; in particular, the level of data. The user at the top of the role hierarchy gets access to all the records that are visible for their role, along with all the data that is visible to the roles underneath them.

Nevertheless, this part of the scenario gives a good understanding of the org chart, which can help you develop an early idea of the role hierarchy. The statement there are 5,000 channel representatives (who sell the company products via the partner/distributor channel) should be particularly concerning for you because it describes a channel sales model. This means that some of the opportunities could be sold via partners.

This is a good early indication that PIR might need a Partner Community. This statement also indicates that the channel reps would own the partners’ accounts. This is also important considering that the partner roles are set directly underneath the role of the user who owns the partner account.

Remember that you can have up to three levels of partner roles (executive, manager, and user) and that they are named after the name of the partner account (or the account ID value if you enabled shield encryption for the account’s name field). For example, if the name of the account record enabled as a partner account is test account, then the partner roles for that account would be Test account partner executive, Test account partner manager, and Test account partner user.

You still do not have a clear requirement about the Partner Community, but for now, add all these notes to your list. This will help you create the required artifacts eventually.

The channel representatives report directly to the global EVP of sales. Does that mean they should be granted a role directly underneath the EVPs? At this moment, there is no clear requirement to direct you. You can add that temporarily and review it later.

At this stage, your draft role hierarchy may look as follows:

Figure 6.6 – Role hierarchy (first draft)

Your landscape should still be simple and look like the following:

Figure 6.7 – Landscape architecture (first draft)

Note

In the landscape architecture diagram, you can also use the term Force.com to describe the Salesforce Core Cloud. The term customer 360 platform incorporates more than just the Force.com platform. It is recommended to use the term Salesforce Core Cloud as there is a continuous increase in the different Salesforce clouds and cross-cloud solutions, and that term sounds more precise as a description.

Now, move on to the next paragraph, which starts with the following line:

The service department is organized into two main product lines.

This paragraph and the bullet points that follow describe the org chart for the service department. Update your role hierarchy accordingly. The statement Each product line has multiple teams of service specialists (which could be up to 25 different teams)...They are organized by the different product categories they support, such as software servers, software cloud, and hardware desktop. Specialists can work in more than one team. Teams usually contain around 30 specialists. This is particularly interesting as it describes a way of working that is not particularly supported by the role hierarchy. You have users who could belong to multiple teams.

A user can have only one role at a given time. Considering that you are talking about the service department here, it is fair to assume that these users would be mainly dealing with the case object. There is still no clear requirement at this stage, but the assumption is logical. Based on that assumption, you can think of two possible out-of-the-box functionalities that could be useful, that is, case teams and queues. There are other features you could use, such as public groups, but so far, you do not have enough details about the requirements.

You must exhaust the configurable potential functionalities before you move on to programmatic solutions. Take note of the features you believe are likely to be used. Both functionalities (case teams and queues) are not normally part of the artifacts you covered in Chapter 1, Starting Your Journey as a CTA. However, you still need to incorporate that into your presentation, even as a simple statement. Make sure you do not miss any requirements as they all count.

Again, update your notes and draft diagrams according to your latest design. The statements “500 call center agents who answer calls from customers and raise support tickets. They need visibility on all customer records, service agreements, and cases across all product lines” are also interesting because they clearly describe the visibility requirements for the call center agents. This is a good example of where the org chart does not match the role hierarchy. To see records across both product lines, the call center agents must belong to a role that sits right below the EVP of service and above the SVPs of the product lines. This is unlikely to match the org chart, but keep in mind that you are trying to sort out record visibility using Salesforce roles rather than replicate the org chart.

Update your notes and your draft diagrams. Your actors and licenses diagram should look similar to the following:

Figure 6.8 – Actors diagram (first draft)

Your role hierarchy should look like the following:

Figure 6.9 – Role hierarchy (second draft)

No changes have been made to the landscape architecture diagram.

Note

Note that although this mini scenario focuses on the security domain, in particular, you still need to generate the standard set of artifacts covered in Chapter 1, Starting Your Journey as a CTA, to describe your solution from end to end.

Now, move on to the next paragraph, which starts with the following line:

PIR has a concern with the current setup.

There are two concrete requirements. PIR expects you, as an architect, to come up with a sharing and visibility architecture that solves their reported issues. They are also planning to offer self-service to their customers, which is an early indication that you are likely to need a Customer Community.

Take note of that, update your landscape architecture diagram and your actors and licenses diagram, and then proceed to the long list of requirements shared by PIR.

Diving into the Shared Requirements

PIR shared a set of requirements. You will go through each of them, craft a proposed solution, and update your diagrams accordingly. Start with the first requirement:

Users in the sales department should have access to the accounts owned by them or their subordinates only.

To restrict the visibility of the account records, you need to utilize the OWDs. In this case, accounts should be set to private. This ensures the account records are only visible to the user that owns them and anyone above that user in the role hierarchy. Update your data model diagram to indicate that the OWD for the account object is now private.

Reports for direct sales should roll up from the entire sales org to the global EVP of sales. Reports for channel sales should roll up to the global EVP of sales.

This is met by the proposed role hierarchy. This means your initial idea for this part of the role hierarchy is correct. There’s nothing you need to change on the diagram.

The service department reports should roll up by product line.

This requirement is also met by the role hierarchy. This is a good example where a nicely crafted diagram can help you answer the questions you are asking during the presentation.

Note

When you are presenting your solution, use the artifacts you created to tell the story. Your presentation must be engaging and attractive. The artifacts are tools you should use to deliver your message and tell an engaging story of how you see the solution from end to end. Use your diagrams, point at them, and help the audience follow you and understand your vision.

For example, do not just say that this requirement is met by the proposed role hierarchy. Use the diagram while you are doing so and point right at the branch/path of the role hierarchy that fulfills that requirement.

Now, move on to the next requirement.

Call center agents can create cases on behalf of customers.

This requirement is fulfilled by granting the call center agents the right license to create cases. Earlier, it was assumed that they would be using the Service Cloud license, which fulfills the requirement and allows users to work with the entitlement object, which is listed as one of the objects used by PIR.

Specialist teams can work on one or more case subtypes.

To further understand this requirement, you need to go to the next one, which contains the following details:

Only the team of specialists working on a case and anyone above them in the hierarchy should be able to view it. Once a case is created, it gets assigned to a member of a specialty team based on the case’s type and subtype.

These requirements should be considered together before you come up with a solution. The questions you should try to answer now are as follows:

• Is there a declarative feature that can fulfill this requirement?
• Which OWD should be used to restrict the visibility of the cases? And how can you make it visible to the specialist team only?
• What will the Case Assignment Rule look like?

Consider the different possible declarative sharing mechanisms. You can use the case teams and add all the members of a particular specialty team to the case they are working on, but then you would need a mechanism to assign the case to one of the team members who would be owning and closing it.

Alternatively, you can create queues for each case subtype, add the specialists to these queues, and utilize the Case Assignment Rules to assign the case to one of these queues based on the case subtype (which is also dependent on the case type). Remember that there is likely more than one possible solution. You need to pick a solution that meets all the requirements and is most suitable technically based on valid logic. Your suggested solution here could be as follows:

To fulfill these requirements, I propose to set the case object OWD to private. I will create queues for each case subtype and add the specialists to one or more queues, depending on their skill set. I will use the Case Assignment Rules to assign the case to a particular queue based on the case subtype. Once the case has been assigned to a queue, it will be visible to all the specialists in that queue, while other users would not be able to view it due to the OWD settings. This will allow one of the queue members to pick the case and work on it. Any user with a role higher than the user owning the case will also be able to view the case via the proposed role hierarchy.

Remember to use your diagrams and point to the right sections while explaining this topic. Move on to the next requirement.

PIR wants to provide its customers with the ability to self-serve.

The questions you should ask yourself here are as follows:

• What type of community do you need?
• Do you need more than one community?
• Can you utilize the Partner Community?
• What are the declarative sharing capabilities that you can use to fulfill the desired visibility requirements?

Considering that the requirement is related to PIR’s customers, it makes sense to utilize one of the Customer Community Licenses (Customer Community or Customer Community Plus). For B2C customers, this requirement can clearly be met by the Customer Community License. Do you need to assign the Customer Community Plus license for B2B customers?

The advantage you would get from this is the ability to use sharing rules. The disadvantage is that you will consume some of the instance’s portal roles allowance, which is limited. Moreover, it is a more expensive license and should not be proposed for such use cases unless there is a valid technical reason to do so. There is no shared requirement for the given scenario that cannot be fulfilled using the cheaper and more scalable Customer Community license.

Note

You can find more details about the portal roles at the following link: https://packt.link/C5dyY.

By default, the Customer Community license users can only access the account related to their contact records. This automatically fulfills the next requirement as well:

Customers should only have access to cases related to their accounts.

Customer Community users do not get an assigned role. Therefore, you do not need to update your role hierarchy diagram. However, you do need to update your actors and licenses diagram.

Your proposed solution for this requirement could be as follows:

To fulfill this requirement, I propose using customer communities. Each customer, whether B2B or B2C, will be utilizing a Customer Community license to log in to the Customer Community. PIR can consider using either a per-login license or a named-user license. This will not have any impact on the technical aspect of the solution. I propose creating a new community for the customer as it is likely to have a completely different look and feel than the Partner Community. I am assuming that PIR will expose the same set of functionalities for both B2B and B2C customers and offer them the same community look and feel. Therefore, I do not find any reason to go with two different customer communities. The Customer Community license allows the user to access the account related to the user’s contact record by default. However, to allow the customers to access the cases related to that account, I will use a sharing set where User.Account equals Case.Account.

The next requirement starts as follows:

PIR wants to allow B2C customers to self-register or log in via Facebook.

Your solution could be as follows:

In order to fulfill this requirement, I propose to enable self-registration for the Customer Community. I will customize the registration screen to provide a different set of required fields based on the customer type.

When the visitor selects to register as a business user, the page will display a set of input fields, including a mandatory field to capture the corporate ID. When the form is submitted, the code will look up the B2B account using the corporate ID and use the website address value stored on the account to validate the email address. This would ensure that it belongs to the same domain name and that a contact with the same email address does not already exist in Salesforce. If both conditions are met, the code will create a contact and a community user using the provided data, and then link the newly created contact to the corporate account record.

Self-registration for B2C customers is straightforward. The code will check whether the provided email is unique within Salesforce. If that is met, a person account will be created, along with a community user.

To enable social login/social sign-on, I will create a new authentication provider in Salesforce and select Facebook from the list of pre-defined providers. We do not need the consumer ID or the consumer secret because PIR has not requested that we customize the Facebook authorization approval screen.

Therefore, there is no need to create a specific app within Facebook. I will then add a button to my community login page to allow users to log in via Facebook. The OpenID Connect web server flow will be used to facilitate social sign-on. I will create a registration handler class for this authentication provider and set the running user’s value to one of the admin users. I am assuming that PIR does not want to allow social sign-up. Therefore, the registration handler’s code will extract the email address from the data that is passed from Facebook and use it to locate a user with the same email address. If no such user is found, login will fail. The code will not auto-create a new user as PIR did not request this.

When a B2B user logs in, a login flow will be used to send the user a request to validate their identity using the Salesforce Authenticator mobile app. B2B users will need to install the mobile app from the Google Store or App Store and configure it before it can be used. The login flow will be based on the B2B user profile. The B2C users will have a different profile and, therefore, will not go through the same process.

This way, you are providing an end-to-end solution for the shared requirements. Keep an eye on the timer during the presentation; the preceding paragraphs should take no more than 180 seconds to present.

In your solution, you need to mention the proposed authentication flow. You do not necessarily need to describe the flow at this stage; you can just mention it. The judges will ask about it at the Q&A stage if they want to test your knowledge. If they do, be prepared to draw the authentication flow’s sequence diagram and explain it in full detail. The flow is explained in Chapter 4, Core Architectural Concepts: Identity and Access Management. You can draw the diagram interactively while explaining it or create it at an early stage and simply walk them through it.

This is very similar to the approach you would normally follow in real projects. Move on to the next requirement:

PIR partners should be onboarded by their channel representatives.

The solution here could be as follows:

The account object’s OWD is private. I propose introducing a criteria-based sharing rule to share all accounts with the channel sales rep role. This will ensure that the channel reps get access to all accounts and can share them manually with the partner agents. They can also share them via account teams, or we can introduce a flow to automate this based on specific criteria. I am assuming that manual sharing will be acceptable in this case.

To restrict access to the case object, I propose controlling this using the profile settings of the partner user and making the case object inaccessible altogether to them. There is no requirement that indicates a need to grant the partners access to the case object.

Update your diagrams and move on to the next requirement:

PIR employees in APAC have their credentials and user details defined in APAC’s Active Directory.

The solution here could be as follows:

I propose introducing an identity provider such as Ping Identity to provide a unified login mechanism. This allows Ping Identity to integrate with both Active Directory and LDAP. Ping can be configured to use either Active Directory or LDAP to authenticate the user based on different criteria, such as the IP range. It can also be configured to try a series of identity stores to verify the user’s identity in case of failure.

For example, it can try to authenticate the user against Active Directory first, and if the user does not exist there, it could try the same with LDAP. Ping can integrate with multiple two-factor authentication providers, and it has its own mobile application. I am assuming that PIR is fine with its employees using the standard Ping mobile application.

Ping can be centrally configured to request second-factor authentication via the mobile app from all internal users attempting to log in. To enable Salesforce to utilize Ping as an identity provider, PIR will also need to enable the My domain feature in their Salesforce instance. I propose using SAML 2.0 as an authentication standard. Users would be signing in to Salesforce using the SP-initiated SSO flow.

Again, be prepared to draw the required sequence diagram and explain the SAML 2.0 SP-initiated flow, which was covered in detail in Chapter 4, Core Architectural Concepts: Identity and Access Management.

The next requirement is as follows:

Once a PIR employee joins the company, a user should be created for them in Salesforce.

This can be fulfilled as follows:

The provisioning and deprovisioning of internal users can be controlled by Ping Identity. Ping can be configured to detect changes in Active Directory and LDAP, such as creating a new user or deactivating an existing user. Once that has been detected, Ping can connect to Salesforce and provision or deprovision the user in it using either the Salesforce APIs or the SCIM standard, which is supported by Salesforce.

Finally, it’s time to move on to the last requirement:

The call service agents would like to use modern technology to look up the customer account based on the caller’s number.

Here, your proposed solution could be as follows:

To fulfill this requirement, I propose to use Service Cloud Voice. It detects the caller number and looks up the contact record with that number in Salesforce. It can support a fully cloud-based call center, with no need to utilize the existing telephony infrastructure.

Now, update all the diagrams according to the proposed solutions. The landscape architecture diagram should look as follows:

Figure 6.10 – Landscape architecture (final)

The list of integration interfaces should be as follows:

Figure 6.11 – Integration interfaces (final)

The actors and licenses diagram should look as follows:

Figure 6.12 – Actors and licenses (final)

Finally, the data model diagram should look as follows:

Figure 6.13 – Data model (final)

Nothing has changed in the second draft of the role hierarchy. Therefore, it can be considered final.

Summary

In this chapter, you have dived into the details of the security architecture domain. You learned what is expected from a CTA to cover and the level of detail. You then discovered how the delegated authentication flow differs from other flows based on standards such as SAML, before digging into the details of some security and data visibility functionalities in Salesforce.

You then tackled a mini hypothetical scenario that focused on security, found the solution, and created some attention-grabbing presentation pitches. You developed a set of OWDs to restrict records from specific objects to their owners. You then built a complex role hierarchy and a set of sharing mechanisms to allow users to access the right records.

Finally, you worked with multiple types of communities and proposed a secure solution to allow social sign-on via Facebook. You added extra security using second-factor authentication. Then, you explained how to utilize a third-party identity management tool to provide a seamless SSO experience across multiple identity stores.

In the next chapter, you will look at the third domain you need to master, that is, data architecture.