This chapter will get you started by providing general information about this book and the Salesforce Certified Technical Architect (CTA) credential. This chapter will help you get some answers to questions such as what the typical profile of a CTA looks like, how the exam is related to the day-to-day activities of a Salesforce Architect, and why understanding the way CTAs think is important even for senior architects who are not necessarily targeting the CTA credential. This chapter also provides general details about the review board exam's structure and setup (whether that is physical or virtual) and the main artifacts needed to document an end-to-end solution.

In this chapter, we're going to cover the following main topics:

• Understanding the profile of a Salesforce Certified Technical Architect
• The CTA review board's structure and format
• From exam to real life – how to train to become a CTA
• The nature of the exam – a point collection exercise
• What kind of artifacts you need to generate and why
• Let's get started!

As the Salesforce economy continues to grow rapidly, there's never been a better time to build a Salesforce-based career. Architects and architect-related skills are in higher demand than ever.

The Salesforce Certified Technical Architect credential is ranked as one of the Top Enterprise Architect Certifications in the industry. Just run a quick search on the web for job postings and you'll have no doubt about the value of this prestigious certificate. The very limited number of CTAs around the world gives an even more satisfying feeling of joining the club to the newly certified CTAs.

With such rapid growth of the Salesforce ecosystem, the borders between traditional roles in some workplaces are blurring. And with that, the value of having people with that special talent to link between the different teams becomes vital. Technical architects are not afraid to dig deep into business challenges, asking tough questions to reveal the real business value behind a particular requirement. They like to get to the bottom of things, and roll up their sleeves when necessary to try things out in order to select the right solution approach that serves the current and future potential requirements. They do not hesitate to jump into conversations with the development teams to give guidance and best practices, and then work with the project management team to prepare that cutting-edge presentation for the stakeholders.

As a CTA, you are expected to rely on your broad knowledge across multiple technologies and your deep expertise of the Salesforce Platform to design secure, high-performance systems that maximize the potential of the Salesforce Platform. You must then combine this with an excellent set of soft skills to help you socialize and defend the proposed solution.

The candidate should be able to demonstrate deep knowledge and experience in the following areas:

• 5+ years of implementation experience, including development, across the full software development life cycle. Although having hands-on development skills is not mandatory, those who had the chance to code would normally develop a sense of what would normally work for a software solution, which can help with logically selecting and justifying a particular solution.
• 3+ years of experience in an architect role, which includes experience across the entire spectrum of architecture activities. This includes, but is not limited to, designing data models, integration interfaces, and end-to-end solutions; communicating and socializing a solution; and having deep hands-on experience with the platform's capabilities and potential solution trade-offs.
• 2+ years of experience on the Lightning Platform, with at least one of those in a lead architect role, implementing Salesforce applications and technologies.
• Has held a technical architect role on multiple complex deployments, or has gained equivalent knowledge through participation and exposure to these types of projects.
• Experience guiding a development team on the appropriate use of platform technology.
• The ability to identify and mitigate technical risks across the architecture, which normally comes with experience.
• Exposure to globalization considerations on a project. Projects with globalization requirements come with a particular set of challenges. Having a practical understanding of the platform's capabilities is key.
• Experience with object-oriented design patterns. Although a CTA is not necessarily expected to write code, understanding object-oriented design patterns and principles creates a more rounded architect who is more capable of explaining how a particular module would work.
• Awareness of platform-specific design patterns and limits. In order to pass the CTA review board, it is strongly recommended that they have hands-on experience with the different platform functionalities.
• Experience developing code on the Force.com platform, as well as an understanding of limitations and associated challenges, even if they're not necessarily doing hands-on coding.
• Ability to identify development-related risks, considerations, and limits for the platform.
• Experience with multiple development languages (for example, .NET, Java, or Ruby) and design frameworks. This would largely help when designing an integrated solution. Understanding what is possible and what is likely not is the key.
• Experience with common integration patterns; experience with integration on the Salesforce Platform. Any hands-on experience here is a massive plus.
• An understanding of and the ability to architect a solution to address security complexities, mechanisms, and capabilities on the Lightning Platform as part of a functional security model.
• An understanding of and the ability to design an identity and access management strategy as part of an end-to-end solution.
• An understanding of data migration considerations, design trade-offs, and common ETL tools.
• Awareness of large data volume (LDV) considerations, risks, and mitigation strategies.
• Awareness of general mobile solutions and architectures and an understanding of on-platform mobile solutions and considerations.
• Experience with project and development life cycle methodologies.

Now that we know what the CTA profile is, let's get to know the review board.

This section is mainly meant for those who are targeting the CTA exam. In order to pass the exam, you would need to set a review board with three CTA judges. You will receive a hypothetical scenario and have a limited amount of time to solve it and craft an end-to-end presentation, explaining the different elements of your solution and how you would solve the identified requirements in your scenario. The judges will then ask questions about your solution and challenge it. You are expected to justify, defend, and – if needed – change your solution accordingly.

The following are some more details about the exam:

• Exam prerequisites: The Salesforce Certified Application Architect credential and Salesforce Certified System Architect credential.
• Format: The candidate will review and solve a hypothetical scenario and then present this to a panel of three CTA judges. The presentation is followed by a question and answer session with the judges.
• Time allotted to complete the exam:

  180 minutes for scenario review and solution preparation

  45 minutes for scenario presentation

  40 minutes for scenario Q&A session

An exam facilitator and proctor will be onsite during the exam (or will join virtually if the exam is being executed virtually).

The following materials are provided to the candidate at the review board (onsite). No other materials are allowed. If the exam is onsite, you will need the following:

• A computer with PowerPoint, Word, and Excel (or Keynote, Pages, and Numbers for Mac)
• Flipchart paper
• Blank paper – for candidate notes only
• Pens, highlighters, and markers
• A timer

If the exam is virtual, you will need the following: A computer with PowerPoint, Word, and Excel (or Keynote, Pages, and Numbers for Mac) that the candidate can access via remote desktop.

You can deliver your artifacts/diagrams using one or more of the following tools:

• PowerPoint presentations
• Flipcharts
• Whiteboard (This is not transportable. Remember that you will normally create the solution and artifact in one room and then present it in another.)
• A combination of these

There is no right tool. You need to build your own habits and plans and use whatever works best for you.

Now that you have learned the review board exam's structure, let's find out how it's related to the day-to-day life of a Salesforce Architect.

In addition to the significant career boost, there are several other reasons to learn how to design secure, high-performance technical solutions on the Salesforce Platform in the same way it's expected from a CTA. During the review board exam, you are expected to perform certain activities and think in a particular way. This should not be thought of as activities required to pass the exam but more of best practices that an architect is expected to follow in order to produce a solution that delivers value and has fewer implementation risks.

Regardless of whether you are targeting the CTA credential or not, as an architect, you will find that you can apply the knowledge in this book to your day-to-day activities. Actually, the best way to get hands-on experience with all the required domain knowledge is by following these simple steps:

1. Apply the methodology explained in this book – or your own variation of it – to your day-to-day activities. Put it in action, and you will notice that it becomes second nature after some time. This makes it easier to set and pass the review board exam. Let's put it this way: if you are practicing this day in and day out, you will be actually preparing for the review board exam during your normal working hours.
2. Set up playground environments to try things out by hand. As an architect, it is crucial to have practical experience with the different elements and technologies that form your solution. This is particularly true while working with the Salesforce Platform, considering all the flexibility it has and how it lets you easily sign up for a virtually unlimited number of developer environments. Nothing beats hands-on experience. So, the next time you are investigating how a particular Single Sign-On (SSO) flow works, don't just read about it: set up a playground environment and closely observe how the systems are interacting with each other. Make this one of your day-to-day activities while assessing different potential solutions for a given business challenge.
3. Make yourself familiar with the activity of documenting design decisions. While working on a Salesforce implementation project, you will come across endless cases where there is more than one potential solution. Make yourself familiar with the structured way of documenting the details of each option, as well as its pros and cons. This activity has several benefits in that it helps you organize your thoughts by putting them on paper and sharing them with others. This increases the potential of selecting the right solution/approach. Moreover, it helps you clearly communicate the different options that are available to the project's architecture board and stakeholders. And on top of that, it helps you document your solution – something that your project sponsor will love you for. This is another example of a daily activity that can significantly help you prepare for the review board. Although you might not document the different solutions and tradeoffs in the same thorough way you do in real life, the principle of identifying different approaches, trade-offs, compromises, risks, and rationally justifying a particular solution is exactly what you are expected to do during the review board.

These are not skills that you should learn and master just for the sake of passing the review board; these are valuable skills and practices that you should make part of your daily routine. And when you do so, you will find out that you are getting closer and closer to becoming ready for the review board exam. The CTA certificate will simply become the cherry on top of the cake, an assertion that you possess all the required skills and that you know how to put them all into action.

Understanding the nature of the review board exam will help you prepare for it, and will prove to be particularly valuable during the presentation stage:

• You will be requested to create an end-to-end solution and communicate it back to the judges. To do so, you will need to create a set of artifacts that will help you tell the solution as an engaging story. Your presentation should be executed in a way that will catch your audience's attention. Once you start the presentation, try to forget that you are in an exam room in front of judges; imagine yourself setting in front of a group of execs and CXOs from the company mentioned in the scenario. Forget for a moment that these judges work for Salesforce; put yourself in the right mood and mindset to present your solution to these client execs, who have solid technical knowledge about the platform and want to understand how you are planning to use it in order to solve their problems.
• The exam itself is a point collection exercise. You get points for identifying any solution requirements in the scenario. Every point counts. Some requirements are easy to spot and solve. For example, you might come across a security requirement that you can simply solve using field-level security settings. Don't overlook that or drop it from the solution story that you are going to tell. You might simply lose an easy point. However, during the Q&A stage, the judges will try to question you about the requirements that you didn't cover during the presentation. This will give you a second chance to cover them. Keep in mind that you have a limited time during the Q&A, and if you have many unidentified or non-solutioned requirements, then you could run out of time before you can cover all of them. This means losing valuable points that could be the difference between passing and failing.
• I have met many CTA candidates who dreaded the Q&A stage and I've always tried to explain that this stage should be considered as their friend, their opportunity to close some gaps caused by leaving things out, and an opportunity to express their knowledge, skills, and experience to some of the finest technical architects in the world. It is a time that the candidate should be looking forward to rather than fearing. It is true that you will be challenged and your knowledge will be put to the test, but this is exactly the moment where you can show the judges that you belong to the club – that you have got what it takes to join the very exclusive club of CTAs. You have to stay focused and be precise with your answers, and avoid wasting unnecessary time in describing things over and over again. Remember that the Q&A stage is your friend; you should try to make the most out of the available time. It is surprisingly similar to real-life presentations; the presenter will feel relieved when the audience starts to ask questions and the conversation becomes two-way instead of one-way.
• During the presentation, the judges might decide to change one of the requirements to check your ability to adjust quickly and get to the solution on the fly. Don't get nervous because of that, or automatically assume that they are doing so because you made a mistake somewhere. It is a part of the test.
• During the presentation (or the Q&A), you may figure out that you have made a mistake and decide to adjust. This is not a disaster. Don't lose your focus; the judges will also appreciate how you handle such difficult situations professionally and how you recover and get back on track. If you make a mistake, admit it professionally, explain the reason behind your early decision, and correct it. Also, explain in short how you would have handled such a requirement in a real-life project. However, keep in mind that if you make multiple mistakes, the likelihood of you passing will reduce.
• The judges are there to ensure that you have what it takes to create secure, scalable solutions based on the Salesforce Platform. It is good to let them know what you are thinking about and how you are making your decisions. This will help them understand your logic and therefore better understand the reasons behind making a decision that creates a sub-optimal solution. If you have valid reasoning and sound logic, then this will normally be taken into consideration. Most, if not all, of the scenarios you will be presented with can be solved in multiple ways. There is no one solution. The key thing to keep in mind is that your solution must be based on the right considerations and logic. This is a major skill that a CTA must have: the ability to think of the holistic solution, identify potential solutions, and rationally select a suitable one.
• Your proposed solution should be the best one you can think of from a technical perspective. You should not assume there are challenges that have not been mentioned directly or indirectly in the scenario. As an example, don't select a sub-optimal solution because you are worried about budgeting challenges that the client might have - only do this if that was mentioned in the scenario itself.
• Finally, always keep in mind that your given solutions must be presented based on the given requirements. Don't simply give a dry solution as if you are answering an exam on paper. Remember that you are supposed to be presenting to the CXOs of the client company and tie your solution to a requirement. This will attract the audience and make the overall picture much clearer. We will come across several examples of this during later chapters in this book.

Now that you understand the nature of the review board exam, let's move on and explore the artifacts you need to create in order to get solutions for the hypothetical scenario.

A Salesforce Architect is always aiming to create a secure and scalable solution that meets all required functionalities, and document them in a way that allows them to communicate them effectively with the stakeholders. This is applicable during the review board and while tackling a real-life implementation project. An architecture diagram is a graphical representation of a set of concepts that are part of an architecture. They are heavily used in software architecture and, when used effectively, can become a common language for documenting and communicating your solution.

Based on my experience, there are normally several discrepancies with projects in the way architectural diagrams are created. I have seen a lot of inconsistencies, a lack of detail, a lack of discipline, and fragmentation. In several cases, this can be traced back to the misuse of an architectural description language (for example, UML), or in some cases, the lack of using any standard at all. Sometimes, this is due to misunderstanding the value of the diagrams and relying on improper or inconsistent guidelines – and in some cases, a lack of architectural education.

In order to describe your Salesforce Technical Solution Architecture, you need the following artifacts:

• Must-haves:

  Actors and licenses

  Data model diagram

  System landscape architecture diagram

  Role hierarchy

  Development life cycle diagram

• Good to have:

  Process flows (in real-life projects, this is considered a must-have)

  Environment diagram (in real-life projects, this is considered a must-have)

  Contextual SSO flow

• Other diagrams, such as a data flow diagram, mind maps, and so on

  Remember

  You can deliver your artifacts/diagrams using one or more of the following tools:

  PowerPoint presentations

  Flipcharts

  Whiteboard (this is not transportable)

  A combination of these

  There is no right tool. You need to build your own habits and plans and use whatever works best for you.

There are a few things to keep in mind regarding these diagrams:

• Quality: During the review board exam, you have a very limited amount of time to craft your solution and create your artifacts. The quality of your diagrams is not expected to be top-notch, but they can't be scribbled scratches. Keep this golden rule in your mind while creating your artifacts and diagrams: they have to be pretty and must be worthy of being presented to a CXO. In the real world, these diagrams must look perfect. During the review board exam, however, they can look less perfect, but they still have to be readable, understandable, communicate the right message, and show your professional attention to detail.
• Use the tool that best suits your skillset: Some architects are sharper when it comes to using PowerPoint, while others are better with hand-drawn diagrams. Don't feel restricted – choose the tool that works best for you and that you feel more comfortable working with.
• Horses for courses: Some tools work better for specific diagrams. Some diagrams are explained in a better way if they're drawn in an interactive environment – for instance, where the audience can see the diagram being created in front of them and relate it to a story that you are telling. A good example of this is an SSO sequence diagram. However, other diagrams are better shown pre-drawn due to the amount of time needed to create them. The data model diagram is a good example of this. Here, you need to choose the right tool for the right diagram (you must also consider the way you are planning to set your review board; in-person or virtual). For an in-person review board, I find the whiteboard more suitable for interactively drawn diagrams, while flipcharts and PowerPoints and better suited for pre-drawn diagrams and artifacts.

Now, let's discover each of these artifacts in detail.

The actors and licenses diagram

The importance of this diagram is derived from the need to clearly communicate the required Salesforce, feature, and third-party licenses with your stakeholders based on concrete use cases expected from each set of users. This diagram will help you do the following:

• Identify the key use cases for each actor. These will help you determine the right license to use.
• Clearly communicate the role of each actor within your solution. In the real world, this should also help you calculate the number of required licenses, feature licenses, or third-party licenses. Moreover, documenting the scope of each role will help you answer the common What are these users expected to be doing? question, which tends to become more difficult to answer with time.

For this diagram, you need to consider the following:

• Include all the actors mentioned in the scenario.
• Include all the required licenses, including feature and third-party licenses. Pay extra attention to community licenses. You need to understand the capabilities and limitations of each Salesforce license.
• Go for the best justified technical solution (license-wise). Don't think of non-standard approaches to cut down the cost. Avoid any pattern that could breach Salesforce terms and conditions.
• This doesn't have to be a diagram, but the standard actors and use cases diagram is a great fit for the purpose mentioned here. I personally find it particularly useful when it's drawn on a flipchart or a paper, but a bit difficult to create using PowerPoint, given the time restrictions. In this case, a bullet point list for the actors and licenses, along with a sub-list for activities/use cases, should do the trick.

  What if I made the wrong decision and selected a license type that is not sufficient to cover the requirement?

  Don't panic – accept the fact that you picked the wrong license, rectify that on the fly, and explain your rationale behind selecting the original license to the judges. We all make mistakes; it is how we handle the situation that matters most.

Now, let's take a look at an example. The following simplified actors and licenses diagram illustrates the activities/use cases related to three different personas, and the license(s) required by each:

Figure 1.1 – Actors and licenses diagram example

If there was an unclear reason for picking one license over the other, add the additional rationale behind your decision to the diagram/documentation. This will help the judges – or in real life, the stakeholders – further understand your vision and the drivers behind your decision.

The data model diagram

The data model diagram is one of the most crucial diagrams that you need to create. Without it, you can't explain your solution properly, neither during the exam nor in real life. This diagram will help you with the following:

• Identify the custom objects versus standard objects used in your solution. Remember that standard objects come with pre-built functionalities and limitations, while custom objects have a different set of considerations (for example, some licenses have a limit on the number of custom objects that it can access). This diagram will help you identify and communicate your data model and the planned use of every object.
• Identify LDV objects. Although identifying LDVs requires more than the data model (it requires performing calculations based on the given scenario), having a well-documented data model can help you identify where things are likely to go wrong and where the data is likely going to grow more rapidly (for example, junction objects), which can help you craft a mitigation strategy.
• This diagram is also crucial for your sharing and visibility requirements. The type of relationships between objects has a direct impact on the records' visibility. This is something you cannot easily identify without a diagram that you can digest by taking a quick look at it.
• Your data model has a direct impact on your reporting strategy. By looking at this diagram, you should be able to tell where the data that's required for a particular report should be coming from.
• You can't create a solid integration strategy without understanding your underlying data model.

This diagram should include the following:

• Relation types (master-detail versus lookup).
• Cardinality (one to many, many to many, and so on).
• Object type (standard versus custom versus external objects).
• Org-Wide Defaults (OWD) for each object.
• Must highlight LDV objects, though you must do the math for this (it is a good practice to include these somewhere on this diagram).
• The logical data model level should be fine for the review board exam (showing the key fields for each object). In real life, you have to create a physical-level data model (showing all fields).

Now, let's take a look at an example. The following simplified data model shows the relationships between a set of standard and custom objects:

Figure 1.2 – Data model diagram example

Highlighting the owner of the records of each object type will help you illustrate part of your sharing and visibility strategy. A legend to explain your diagram would also be a nice professional touch.

The system landscape diagram

This system landscape diagram will help you illustrate the systems included within your solution and the relationships between them. This is extremely important because it's likely that you are going to end up creating an integrated solution that spans multiple systems. The diagram will also help you identify and document high-level information about your integration interfaces. This will be the main diagram for describing how the data will be moving across the systems (unless you decide to create a data flow diagram).

Remember

You are creating all these artifacts to help you explain the end-to-end solution to your audience. It is important to understand why you need each diagram and how to use it. There is no point in creating the diagram if you don't know how to use it.

For this diagram, you will need to do the following:

• Show all systems involved in the landscape architecture (including third parties, such as AppExchange products or external systems). In real life, you may also want to extend the landscape architecture so that it includes the key functionalities that are delivered by each system. During the review board, this might take more time than what you can allocate.
• Include the systems that you are planning to retire. Find a way to differentiate them from the other systems that you want to add or keep. Color coding is a good idea, but you can simply add a symbol next to the system to indicate its status. In real life, you are probably going to create multiple copies of this diagram, with each representing a snapshot in time.
• Show the proposed integration interfaces. You also need to include information such as the integration pattern, how you are planning to secure your channel, and the authentication standard used. You might find that adding all of that directly to the diagram makes it a bit too busy. Alternatively, you can use an interface reference/code on the diagram and create a supporting table with full details. Then, you can use both during the review board to explain your integration strategy.
• Remember to include SSO interfaces.
• Also, include any mobile devices that are part of your landscape. Add the type of the mobile app right next to that (Salesforce Mobile, Native Custom App, Hybrid App, or HTML5-based).

Now, let's take a look at an example. The following diagram shows the systems involved in a landscape where Salesforce is replacing a legacy CRM. You will also notice that it is integrated with external systems through an integration middleware (MuleSoft):

Figure 1.3 – System landscape diagram example

The following table describes the proposed integration interfaces:

Figure 1.4 – Proposed integration interfaces

Typically, you don't include data migration interfaces in a landscape architecture diagram. However, this could be beneficial, particularly during the review board, to explain what tools you are planning to use and what your proposed migration strategy is. Ensure you clearly differentiate that from the integration interfaces. Mixing data migration and data integration concepts is a common mistake.

The role hierarchy diagram

Data security and visibility is a key topic for a Salesforce architecture. The wrong data sharing and visibility architecture can significantly impact the performance of the solution and can create a major risk to compliance and security. There are several elements that form your overall data sharing and visibility architecture, including your data model, role hierarchy, territory structure, and the capabilities and limitations of some Salesforce licenses. The role hierarchy diagram is a common sharing mechanism, and that is why creating this diagram will help you explain your overall data sharing and visibility strategy. In real life, you might even want to include full documentation of your sharing rules.

This diagram should include the following:

• A review board, where you must create a full role hierarchy for at least one branch. You don't need to create all the branches if they are simply copied variations of the illustrated branch. For example, if you are going to create a role hierarchy that includes the head of sales for each state in USA, there is no need to create branches for all the states, as long as you can show one or two full branches for some states and indicate that a similar approach will be followed for other states. In real life, you will have enough time to create documentation for the full hierarchy.
• Roles for partner community and customer community licenses as well.
• Any license type limitations. The actors and licenses diagram will be handy at this stage.

Now, let's take a look at an example. The following diagram shows a company hierarchy based on the USA:

Figure 1.5 – Role hierarchy diagram example

Additionally, you can also include a list of sharing roles and other sharing mechanisms that you are planning to use, likely as an annexed table.

The business process flow diagram

The business process flow diagram will help you illustrate and communicate the targeted user experience for a given process. This is a good to have diagram during the review board in terms of the value it adds, but also in terms of the time it takes to create. Practice creating these types of diagrams and decide if you will include them as part of your generated artifacts or not. Again, remember that we create these diagrams to help us explain the end-to-end solution, not just for the sake of creating diagrams. In real life, diagrams that explain each business process is a must-have. It is also strongly recommended that it's in standard BPMN 2.0 format as this creates a common language between team members and avoids you losing the required details and precision.

This diagram should include the following:

• Systems included in a particular process flow. I personally prefer to use swim lanes.
• The starting action and actor.
• Activities included at each stage, and whether they are manual or automated.
• The logic that controls moving from one step to the other or from one system to the other.
• Data that's been exchanged between systems.

Now, let's take a look at an example. The following business process diagram describes a partner onboarding process. You can add as much detail as you wish for the given hypothetical scenario. In real life, this diagram is likely to be much more detailed:

Figure 1.6 – Business process flow diagram example

Subprocesses help create reusable elements. It is recommended that you use subprocesses whenever applicable. However, this is perhaps more suitable for real-life scenarios rather than the review board.

The environment diagram

Governance is another key knowledge area that you have to cover as part of your end-to-end solution. Part of it is your environment strategy; that is, what kind of environments you are planning to use and for what. If you don't create this diagram as part of your presentation, then you are likely going to be asked to draw it during the Q&A session. This diagram is a must-have in real life and can also drive some budget-related discussions.

This diagram should include the following:

• What environment types are being planned at each stage.
• Justification for sandbox-type selection and how this is associated with the test plan. However, this probably isn't going to be something you document on the diagram itself.
• The activities you've planned for each environment and the types of tests included.
• Details about who will be deployed to each branch and at what stage.
• Make sure you fully understand the Continuous Integration and Continuous Deployment (CI/CD) concepts. Hands-on experience is very important here.
• Any third parties that you are planning to use (for example, automated build tools, source controls, and so on).

We'll cover examples and more details related to this diagram in the chapters to come.

I recommend that you combine this with your source code branching diagram, assuming you have enough time to do so.

The contextual SSO flow diagram

Most scenarios you get will have SSO requirements. This diagram (you might need more than one, depending on the used SSO standards) will help you walk your audience through the details of the target user experience without missing any points. If you didn't create this diagram as part of your presentation, then you are likely going to be asked to draw it during the Q&A session. A standard sequence diagram is highly recommended. This is one of the diagrams I personally find more suitable to be drawn in an interactive way (for instance, using a whiteboard).

For this diagram, take the following into consideration:

• You need to know how to fully draw the following flows like the back of your hand, along with all the required details:

  SAML IDP initiated

  SAML SP initiated with deep linking

  OAuth 2.0/OpenID Connect web server/Auth code

  OAuth 2.0/OpenID Connect User-Agent

  OAuth 2.0/OpenID Connect refresh token

  OAuth 2.0/OpenID Connect JWT flow

  OAuth 2.0 Asset token flow

• You need to understand when to use each of these standards.
• Pay extra attention to the use cases when you need to include them as part of your integration architecture (for example, an external system authenticating with Salesforce) or mobile architecture (for example, a native app authenticating with Salesforce).
• Social sign-on comes with a few caveats that you need to keep an eye on and be able to explain.

We'll cover examples and more details related to this diagram in the chapters to come.

It is recommended that you include information regarding the data that's exchanged at each step of the sequence diagram.

In this chapter, you managed to get a better understanding of the typical CTA profile. You learned how this book is structured and how you can make the most of it, as well as how to utilize your day-to-day activities in order to train for the CTA review board. You now have a better understanding of the nature of the exam and some of its key considerations to keep in mind. We also took a deep dive into some of the key tools and artifacts that can help you create a secure and scalable end-to-end solution and communicate it to your audience.

In the next chapter, we will dive deeper into some key architectural skills and knowledge areas. These skills are common for enterprise and software architects, and we are going to understand how are they applicable to the Salesforce Platform.