1

Starting Your Journey as a CTA

This Book Comes with Free Online Content

With this book, you get unlimited access to web-based CTA exam prep tools like flashcards and exam tips.

Figure 1.1 – CTA online resources dashboard

To unlock the content, you’ll need to create an account using your unique sign-up code provided with this book. Refer to the Instructions for Unlocking the Online Content section in the Preface on how to do that.

Accessing the Online Content

If you’ve already created your account using those instructions, visit packt.link/ctabookwebsite or scan the following QR code to quickly open the website.

Figure 1.2 – QR Code to access CTA online resources

Once there, click the Login link in the top-right corner of the page to access the content using your credentials.

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 it is physical or virtual) and the main artifacts needed to document an end-to-end solution.

In this chapter, you will learn the following topics:

• Understanding the profile of a Salesforce CTA
• 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

Understanding the Profile of a Salesforce CTA

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

The Salesforce CTA 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 will have no doubt about the value of this prestigious certificate. The limited number of CTAs around the world gives an even more satisfying feeling of joining an exclusive club to the newly certified CTAs.

With such a rapid growth of the Salesforce ecosystem, the boundaries between traditional roles in some workplaces are blurring. Additionally, the value of having qualified people to serve as a link between different teams becomes vital. CTAs are not afraid to dig deep into business challenges and ask 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 cutting-edge presentations for the stakeholders.

As a CTA, you are expected to rely on your broad knowledge of multiple technologies and your deep expertise in 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:

• Should have more than five years of implementation experience, including development, across the full software development life cycle. Although having hands-on development skills is not mandatory, those who have had the chance to code would normally develop a sense of what would normally work for a software solution. This can help with logically selecting and justifying a particular solution.
• Should have more than three years of experience in an architect role, which includes experience across the entire spectrum of architecture activities. This includes 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.
• Should have more than two years of experience on the Lightning Platform, with at least one of those in a lead architect role, implementing Salesforce applications and technologies.
• Must have held a technical architect role on multiple complex deployments or have gained equivalent knowledge through participation and exposure to these types of projects.
• Should have experience of guiding a development team through the appropriate use of platform technology.
• Should be able to identify and mitigate technical risks across the architecture, which normally comes with experience.
• Should have exposure to globalization considerations on a project. Projects with globalization requirements come with a particular set of challenges. A person with a practical understanding of the platform’s capabilities is key.
• Should have 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.
• Must be aware of platform-specific design patterns and limits. To pass the CTA review board, it is strongly recommended that they have hands-on experience with the different platform functionalities.
• Should have experience of developing code on the https://packt.link/WKCGT platform, as well as an understanding of the limitations and associated challenges, even if they are not necessarily doing hands-on coding.
• Should have the ability to identify development-related risks, considerations, and limits of the platform.
• Should have experience with multiple development languages (for example, .NET, Java, or Ruby) and design frameworks. This would be of great help when designing an integrated solution. The key is to understand what is possible and what is likely not.
• Should have experience with common integration patterns, an understanding of common enterprise service bus (ESB) tools, and integration on the Salesforce Platform. This hands-on experience is a massive advantage.
• Should have an understanding of and ability to architect a solution to address security complexities, mechanisms, and capabilities on the Lightning Platform as part of a functional security model.
• Should have an understanding of and ability to design an identity and access management strategy as part of an end-to-end solution.
• Should have an understanding of data migration considerations, design trade-offs, and common extract, transform, and load (ETL) tools.
• Must be aware of large data volume considerations, risks, and mitigation strategies.
• Must be aware of general mobile solutions and architectures and understand on-platform mobile solutions and considerations.
• Should have experience with project and development life cycle methodologies.

Now that you know what the CTA profile is, let’s explore and get to know the review board.

The CTA Review Board’s Structure and Format

This section is mainly meant for those who are targeting the CTA exam. To pass the exam, you need to sit through 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 scenario requirements. The judges will then ask questions about your solution and challenge it. You are expected to justify, defend, and change your solution accordingly, if needed.

Here are some more details about the exam:

• 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.
• Exam prerequisites: You need to hold both the Salesforce Certified Application Architect credential and the Salesforce Certified System Architect credential. In addition, you need to pass an Architect Review Board Evaluation. This has a similar format to the CTA virtual review board where you need to solve a hypothetical scenario. The difference is that the scenario in this case is much shorter (a mini-scenario) and you are judged by a single CTA judge rather than three.
• Time allotted to complete the review board exam:
  • 180 minutes for scenario review and solution preparation
  • 45 minutes for scenario presentation
  • 40 minutes for scenario question-and-answer session
  • Additional time is given to non-native speakers (30 minutes for the solution design and 20 minutes for the question-and-answer session)
  • If you managed to finish the presentation earlier, any time left will be added to the question-and-answer 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 tools/materials are provided/allowed for the candidate during the review board:

Exam Type	Onsite	Virtual
Provided/allowed tools/materials	Computer with access to Google Workspace (Slides, Docs, and Sheets) Flipchart paper Blank paper for candidate notes only Pens, highlighters, and markers Timer	A remote computer with access to Google Workspace (Slides, Docs, and Sheets). The candidate is expected to access this computer from their own system using a remote desktop. The candidate is allowed to use blank paper to draw diagrams.
You can deliver your artifacts/diagrams using one or more of the following tools	Google Workspace (Slides, Docs, and Sheets) 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.) Combination of the above	Google Workspace (Slides, Docs, and Sheets) Lucidchart (https://packt.link/rEERi) using base templates. You will be using an account offered by Salesforce on the remote computer. Scanned hand-drawn diagrams. Photos are also accepted assuming they are readable and of high quality. You can also show your diagrams live using the webcam. This approach is personally not recommended considering the several potential technical challenges that could occur during the call (such as lags). Combination of the above
Restrictions	No hard-copy or online materials may be accessed or referenced during the exam. Smart devices (such as phones and watches) must be removed and stored away prior to starting the exam.

Table 1.1 – Tools/materials provided/allowed for the candidate

You are expected to use these tools/materials to generate artifacts that can help you explain the solution to the judges. You should choose the tools that best fit your skills and preferences. You need to build your own habits and plans based on your skills and familiarity with the tools (in Table 1.1), then use whatever works best for you.

You can practice using some of these tools, such as Lucidchart, using a free account.

Note

Salesforce has the right to change the allowed/restricted tools for this exam. This chapter and its elements should not be considered an official document as it is based only on the author’s knowledge and experience.

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

From Exam to Real Life—How to Train to Become a CTA

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 is expected from a CTA.

During the review board exam, you are expected to perform certain activities (such as creating a data model diagram, rationally selecting between multiple potential solutions, and presenting your solution as a story) and think in a particular way. This should not be thought of as activities required to pass the exam but more as best practices that an architect is expected to follow 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. 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 into action, and you will notice that it will become second nature after some time. This makes it easier to sit and pass the review board exam. You can put it this way: if you are practicing this day in and day out, you will be 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, do not 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 advantages and disadvantages.

This activity has several benefits, including helping you organize your thoughts by putting them on paper and sharing them with others. This increases the chance 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. On top of that, it helps you document your solution; something that your project sponsor will appreciate.

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, and risks and rationally justifying a particular solution is exactly what you are expected to do during the review board.

The above-mentioned practices and skills should not be thought of as things you learn and master just to pass the review board exam; these are valuable skills and practices that should be a part of your daily routine. When you do so, you will find out that you are getting 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.

The Nature of the Exam: A Point Collection Exercise

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. The following table will help you demystify certain elements of this exam:

Topic	Details
Present your solution as an engaging story.	You will be requested to create an end-to-end solution and communicate it 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. Instead, imagine yourself sitting in front of a group of executives 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 them. They have solid technical knowledge about the platform and want to understand how you are planning to use it to solve their problems.
Target all the requirements and avoid missing the easy points. The exam is a point collection exercise.	The exam itself is a point collection exercise. You get points for identifying any solution requirements in the scenario. Some requirements are easy to spot and solve. For example, you might come across a security requirement that can be solved using field-level security settings. Do not overlook this or drop it from the solution story that you are going to tell. You might simply lose an easy point. During the Q&A stage, the judges will try to question you about the requirements that you did not 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 them all. This would mean losing valuable points that could make a difference in the results.
Embrace the Q&A stage.	Many CTA candidates misunderstand the purpose of the Q&A stage and consider it the most challenging part of the exam. But you should consider this stage as an opportunity to close some left-out gaps. It is the stage that will help you demonstrate your knowledge, skills, and experience to some of the finest technical architects in the world. It is true that you will be challenged, and your knowledge will be put to the test, but this is exactly the moment when you can show the judges your skills. You must stay focused and be precise with your answers. Avoid repetition as much as possible. Remember to make the most out of the available time in the Q&A stage.
Prepare for and anticipate some changes in the scenario.	During the presentation, the judges may decide to change one of the requirements to check your ability to adjust quickly and get to the solution on the fly. Avoid getting nervous because of that, or assuming that you might have made a mistake. Remember to stay calm as it is a part of the test.
Handle the situation when you make mistakes; what matters most is how you handle the situation.	During the presentation (or the Q&A), you may figure out that a mistake has been made and decide to adjust. This is not a disaster. Do not lose your focus; the judges will appreciate how you handle such difficult situations professionally and recover to get back on track. If you make a mistake, admit it professionally, explain the reason behind your 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 passing the exam will be reduced.
Let the judges know what you are thinking about and how you are making your decisions.	The judges are there to ensure that you have what it takes to create secure, scalable solutions using 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. Most of the scenarios you will be presented with can be solved in multiple ways. 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, that is, the ability to think of a holistic solution, identify potential solutions, and rationally select a suitable one.
Aim for the best solution from a technical perspective.	Your proposed solution should be the best 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. For example, do not select a sub-optimal solution because you are worried about budgeting challenges that the client might have; do this only if it is mentioned in the scenario itself.
Hone your communication skills.	Always keep in mind that your given solutions must be presented based on the given requirements. 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. You will come across several examples of this during later chapters in this book.

Table 1.2 – Understanding the nature of the exam

Now that you understand the nature of the review board exam, let’s learn about and explore the artifacts you need to create to get solutions for the hypothetical scenario.

What Kind of Artifacts You Need to Generate and Why

A Salesforce Architect is always aiming at creating a secure and scalable solution that meets all required functionalities. In addition, the architect should also ensure the solution is documented in a way that allows it to be communicated effectively to the stakeholders. This is applicable both 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 experience, there are usually several discrepancies in the way architectural diagrams are created. They could be inconsistent, fragmented, or lacking some details. In several cases, these discrepancies can be traced back to the misuse of an architectural description language (for example, unified modeling language), 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.

To describe your Salesforce technical solution architecture, you need the following artifacts:

• Must-haves (mandatory artifacts):
  • Actors and licenses
  • Data model diagram
  • System landscape architecture diagram
  • Role hierarchy
  • Development life cycle diagram
• Good to have (optional but advantageous):
  • Process flows (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

Note

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

Ÿ PowerPoint presentations/Google Slides, Sheets, Docs (virtual)

Ÿ Flipcharts/hand-drawn scanned images (virtual)

Ÿ Whiteboard (this is not transportable)

Ÿ Combination of the above

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

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

• Ensure 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 needs to be sufficient. Keep this golden rule in your mind while creating your artifacts and diagrams: they must be worthy of being presented to a CXO. During the review board exam, make sure the diagrams are readable, understandable, communicate the right message, and reflect 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. Avoid feeling restricted and choose the tool that works best for you and that you feel most comfortable with.
• Horses for courses: Some tools work better for specific diagrams. For instance, some diagrams are explained in a better way if they are drawn in an interactive environment. For example, 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 is an SSO sequence diagram. However, other diagrams are better shown pre-drawn due to the amount of time needed to create them, like the data model diagram. 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, the whiteboard is more suitable for interactively drawn diagrams. Flipcharts and PowerPoint presentations are better suited for pre-drawn diagrams and artifacts.

Now, discover each of these artifacts in detail in the next section.

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 to your stakeholders based on concrete use cases expected from each set of users. This diagram will help you achieve the following:

1. Identify the key use cases for each actor. This will help you determine the right license to use.
2. 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 question, that is, what are these users expected to be doing? This tends to become more difficult to answer with time.

For this diagram, you need to consider the following:

1. Include all the actors mentioned in the scenario.
2. 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 type.
3. Go for the most justified technical solution (license-wise). Avoid any non-standard approaches to cut down the cost. Avoid any pattern that could breach Salesforce’s terms and conditions.
4. This does not have to be a diagram. It could simply be a table. But the standard actors and use cases diagram is a great fit for the purpose mentioned. Owing to the time restrictions, you might find it easier to draw this diagram on a flipchart or paper rather than create it using PowerPoint. Alternatively, you can create this artifact as a bullet point list of actors and licenses, along with a sub-list of activities or use cases.

Note

What if you made the wrong decision and select a license type that is not sufficient to cover the requirement? In such a case, accept the fact that you picked the wrong license, rectify it on the fly, and explain your rationale behind selecting the original license to the judges. It is how you handle the situation that matters the most.

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

Figure 1.3 – Actors and licenses diagram

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.

Data Model Diagram

The data model diagram is one of the most crucial diagrams that you need to create. You need this to explain your solution properly, during the exam and in real life. This diagram will help you with the following:

• Identify the custom and 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 they can access). Also, keep in mind that standard object access depends on the licenses used, so you should make sure the data model fits the selected licenses. This diagram will help you identify and communicate your data model and the planned use of every object.
• Identify large data volume (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 to grow more rapidly (for example, junction objects), which can help you craft a mitigation strategy.
• This diagram is also crucial for sharing and visibility requirements. The record ownership and the types of relationships between objects have a direct impact on the records’ visibility. This is something you cannot easily identify without a diagram that you can digest at a glance.
• 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 is required for a particular report should be coming from.
• You cannot 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).
• Ownership details (the actor who owns records of a specific object type).
• 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).
• Optionally, you can include record-type details of the relevant objects.
• Logical data model level should be fine for the review board exam (showing key fields for each object). In real life, you must create a physical-level data model (showing all fields).

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

Figure 1.4 – 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

The system landscape diagram will help you illustrate the systems included within your solution and the relationships between these systems. This is extremely important because it is 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).

Note

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. Avoid creating a diagram if you are unsure about using 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, adding all key functionalities might take more time than you can allocate.
• Include the systems that you are planning to completely/partially 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 can add this information directly to the diagram, but this could make it look clumsy. Alternatively, you can use an interface reference/code on the diagram and create a supporting table with full details. Then, you can use them both during the review board to explain your integration strategy.
• Remember to include SSO interfaces. You can also include any mobile devices that are part of your landscape. Add the type of the mobile app (Salesforce mobile, native custom app, hybrid app, or HTML5-based) right next to that.

Now, look at an example. Figure 1.5 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 some integration middleware (MuleSoft):

Figure 1.5 – System landscape diagram example

Figure 1.6 describes the proposed integration interfaces:

Figure 1.6 – Proposed integration interfaces

Typically, you do not 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 your proposed migration strategy. 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 illustrates the Salesforce role hierarchy used in your solution, which is a common data-sharing mechanism across the platform. 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.

The role hierarchy diagram should include the following:

• During the review board, you must create a full role hierarchy for at least one branch. You do not 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 the 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.

• You must create roles for Partner Community and Customer Community Plus licenses as well.
• Keep an eye on any license type limitations. The actors and licenses diagram will be handy at this stage.

Now, look at Figure 1.7, which illustrates a company hierarchy based in the USA:

Figure 1.7 – 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 as it adds value. However, it also takes considerable time to create.

Practice creating this type of diagram and decide if you will include them as part of your generated artifacts or not. Remember that these diagrams are created 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 are a must-have. It is also strongly recommended that it is in standard BPMN 2.0 format as this creates a common language between team members and avoids missing details and precision.

This diagram should include the following:

• The systems should be included in a particular process flow. This is usually represented as swim lanes.
• The starting action and actor of the process.
• 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 should be included.
• Data that has been exchanged between systems should be included.

Now, look at an example. The business process diagram in Figure 1.8 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 include much more detail:

Figure 1.8 – 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.

Development Life Cycle Diagram

Governance is another key knowledge area that you must 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 do not 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:

• The environment types that are being planned at each stage.
• Justification for sandbox-type selection and how this is associated with the test plan. However, this probably is not going to be something you document in the diagram itself but rather mention during your presentation.
• The activities you 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 concepts of continuous integration and continuous deployment (CI/CD). Hands-on experience is very important.
• Any third parties that you are planning to use (for example, automated build tools, source controls, and so on).

You will cover examples and more details related to this diagram in the chapters to come in this title.

It is common to combine this diagram with the optional source code branching diagram, if you decided to create one.

The Contextual SSO Flow Diagram

Most of the CTA exam scenarios 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. If you did not 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 recommend as it is more suitable to be drawn interactively (for instance, using a whiteboard).

For this diagram, take the following into consideration:

• You need to know how to fully draw the following flows at 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 flows.

• 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 into Salesforce) or mobile architecture (for example, a native app authenticating into Salesforce).
• Social sign-on comes with a few caveats that you need to keep an eye on and be able to explain.

You will come across detailed examples of this diagram in the other chapters of this book. It is recommended that you include information regarding the data that is exchanged at each step of the sequence diagram.

Summary

In this chapter, you got 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 to train for the CTA review board. You now have a better understanding of the nature of the exam and some of the key considerations to keep in mind. You also took a deep dive into some of the key tools and artifacts that can help to create a secure and scalable end-to-end solution and communicate it with your audience.

In the next chapter—Chapter 2, Core Architectural Concepts: Data Life Cycle—you will dive deeper into some key architectural skills and knowledge areas. These skills are common for enterprise and software architects, and you are going to understand how they are applicable to the Salesforce Platform.