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:
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!
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:
Now, it’s time to have a closer look at each of these objectives.
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:
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.
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.
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.
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.
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:
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:
The relations between the different objects in your data model directly impact the record visibility and the overall 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.
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.
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).
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:
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.
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.
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.
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:
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:
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.
PIR shared the following requirements:
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.
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.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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.
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.