Chapter 6: Formulating a Secure Architecture in Salesforce

In this chapter, we will continue with other Salesforce-specific knowledge areas required to pass the CTA review board. This time, we 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 our common understanding of CRM. We see more and more enterprises adopting Salesforce as their central engagement platform, with dozens of inbound and outbound integrations with different other systems.

As a Salesforce security architect, you are expected to utilize the rich set of Salesforce functionalities available to design a solid security architecture. You are also expected to define the security measures needed to protect the data while being transferred from and to other systems. You have to master the different ways that license types and object relationships impact...

Understanding what you should be able to do as a security architect

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://trailhead.salesforce.com/en/help?article=Salesforce-Certified-Technical-Architect-Exam-Guide&search=release+exam+schedule.

Let's 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 up 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 in order to get a solid understanding of their behaviors. Using these tools, you can configure security on multiple levels:

• Org
• Object
• Record
• Field levels
...

Introducing the security architecture domain – Packt Innovative Retailers

The following mini scenario describes a challenge with a particular client. We will go through 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 yourself, then come back to this book, 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.

Without further ado, let's proceed to the scenario.

The 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...

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've done that, we go through it again, section by section, and incrementally build the solution.

Understanding the current situation

First, let's try to understand the current PIR situation and landscape. We'll start with the paragraph in the preceding scenario that begins with the following line.

The organization is structured as two main departments – sales and service

We gained a lot of information from this paragraph. PIR uses a single org for both the sales and service departments across three regions: 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.

We also learned that PIR is utilizing a specific...

Summary

In this chapter, we dived into the details of the security architecture domain. We learned what a CTA is expected to cover and at what level of detail. We 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.

We then tackled a mini hypothetical scenario that focused on security, and we solutioned it together and created some catching presentation pitches. We developed a set of OWDs to restrict records from specific objects to their owners. We then built a complex role hierarchy and a set of sharing mechanisms to allow users to access the right records.

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