11

Communicating and Socializing Your Solution

This chapter will continue exploring Salesforce-specific knowledge areas required to pass the CTA review board. This time, you will tackle the communication domain. This is the seventh and final knowledge domain a CTA must master. This chapter will give you the knowledge and teach you the soft skills required to pass this domain. Then, you will complete a hands-on exercise using a mini hypothetical scenario.

Communication skills are crucial for a CTA. These skills allow you to explain your vision in a clear and detailed way, ensuring that your audience fully understands how everything is going to work together. This skill incorporates several sub-skills, such as the ability to create a descriptive diagram that can help you explain your solution and how to handle unexpected changes in scope and adjust your solution accordingly.

You have already practiced creating presentation pitches in the last six chapters and used diagrams to describe the end-to-end solution. You learned that your presentation must be engaging and captivating; you should tell a story while walking your audience from one point to the next.

In this chapter, you are going to cover the following main topics:

• Understanding what you should do while communicating your solution
• Practicing communicating a mini hypothetical scenario
• Articulating your solution and managing objections

By the end of this chapter, you will have practiced handling objections and adjusting a solution on the fly and learned some best practices across the broad communication domain. You will start by understanding what is expected from a CTA to master this domain and then move on to the mini hypothetical scenario, where you will put that knowledge into action.

Understanding What You Should Do While Communicating Your Solution

Soft skills are essential for the modern-day architect as market expectations are higher than ever. The architect is expected to possess a solid technical background supported by an excellent ability to communicate a solution’s vision, target, and rationale. On top of that, the architect is expected to be able to walk the audience through the possible solution options, highlighting the pros and cons of each.

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/DGMnt

Next, you will have a closer look at each of these objectives.

Communicating Design Decisions and Considerations

While creating your solution, you will come across several use cases that can be fulfilled in one way or another. You saw this earlier, while developing solutions for the mini hypothetical scenarios in the previous six chapters.

During the review board, you have a limited amount of time and a lot of requirements to solve. When you present a proposed solution, you should focus on the considerations that would make a difference. These considerations should steer you away from one design decision to another.

In the end, you are not expected to list out the available options and take a step back but to come up with a crisp and precise solution for a given requirement. You are supposed to be the most senior Salesforce expert on a project. You should be the one confidently guiding other stakeholders to make decisions.

Note

Remember to provide a crisp, clear, and comprehensive solution. The three CTA judges will be seasoned, experienced architects. They will sense a lack of confidence. Do not bluff or rely on buzzwords. This is not an audience that will be impressed by buzzwords unless you can match them with solid, in-depth practical knowledge.

During the presentation, you have to present an end-to-end solution, just like a story would be told. You have to explain how your solution solves the problem. Take the following requirement as an example:

The sales manager needs to submit a new customer record for a credit check. The manager should be informed about the result as soon as the check is complete and receive an error if the check fails for any reason.

The following statement is an example of a dry, unattractive, and unengaging way of presenting a solution:

I will do the credit check via an APEX callout.

The judges are acting as CXOs representing the scenario’s client company. You are supposed to guide them and avoid dry answers to their questions. To help them, you need to continue with your presentation, point out or mention the requirement first, then explain your proposed solution. For example, you could start with something like the following:

On page three, paragraph two, we have the following requirement.

Then, you can briefly describe the requirement. Once you have done that, you proceed with the solution. Your response should explain the why and how with enough details. For example, the preceding statement could be rephrased like so:

To fulfill this requirement, I will implement a Lightning component with a button to submit the customer account for a credit check. The Lightning component will have an APEX controller. I propose using the remote process invocation request and reply integration pattern.The controller will use a callout to invoke a web service exposed by MuleSoft. I will use named credentials to authenticate to the web service. Authentication will occur using the OAuth 2.0 JWT token flow, and the integration channel will be protected using two-way TLS. Once the MuleSoft web service is invoked, MuleSoft will orchestrate the call to the credit check provider, get the result back, and return it to the Lightning component’s controller. The component will then display the result to the user.

If you are doing a virtual review board, it could be a good idea to arrange the requirements and proposed solution in an Excel sheet or a PowerPoint slide, whichever works best for you.

The key thing to keep in mind is that these are tools that you should use to help you propose your end-to-end solution. You should not simply go through your sheet and read the solution out; you should use diagrams to explain and visualize the solution, which is exactly what the next objective is all about.

Demonstrating Your Visualization Skills to Articulate the Solution

The common language for architects is diagrams. Similar to human languages, certain diagrams represent a common language known and understood by peer architects.

In Chapter 1, Starting Your Journey as a CTA, you learned about the diagrams you need to depict an end-to-end solution and the level of detail required in each of these diagrams. There are several additional diagrams that an architect can use to explain a solution, including, but not limited to, the following:

• Flowcharts: This is a common way to represent an algorithm. It depicts the steps required to solve a particular task. A swimlane can be used to provide a better visual representation of a chart, especially complex processes.
• Data flow diagrams: These diagrams provide a representation of the flow of data through systems or processes. Do not mix these up with Entity Relationship Diagrams (ERDs) or object diagrams.
• Wireframes: This type of diagram represents a visual skeletal framework of the solution’s UI.

These additional diagrams could be valuable to explain some aspects of your solution. They are rarely used during the CTA review board but are helpful in real life.

What you particularly need to avoid are the top three mistakes in creating architectural diagrams. You will learn about those in the following subsections.

Mixed Diagrams

In some cases, the architect might decide to mix multiple diagrams into one. This could be due to one of the following reasons:

• Underestimating the value of standard diagrams: The standard diagrams took years to reach the maturity stage they are at. They are known by many architects and represent a common architectural language. Attempting to create a new language simply means you will be the only one to speak it. Moreover, a newly created type of diagram would likely lack the desired maturity level.
• Lack of knowledge: The architect might be unaware of a standard way to create a specific diagram. This could also be due to the confusion created by a lack of standardization.
• The wrong impression that standard diagrams are too complicated: Sometimes, the desire to create something simple could mean miscommunicating valuable information. Moreover, architectural diagrams are not only communication tools; they are frameworks to help the architect shape and refine thoughts. You learned about some of this in Chapter 1, Starting Your Journey as a CTA. In short, as an architect, you should use your diagrams to create, validate, and communicate your solution. You do not create the diagrams as an afterthought of an already-delivered job.

The following is an example of a mixed diagram. The architect mixed a flowchart diagram with a landscape architecture diagram:

Figure 11.1: An example of a mixed diagram

Such non-standard diagram mixing will cause confusion at multiple levels, especially with complex processes. It will distract and confuse the reader with unnecessary details. Moreover, it will create a redundant version of information that is likely to exist elsewhere. For example, you will need to maintain the list of integration interfaces across both the landscape architecture diagram and flowcharts. This could lead to outdated information in some diagrams.

Oversimplified Diagrams

The desire to oversimplify a diagram could lead to creating a mixed diagram. In addition, this is one of the most common reasons for information loss in diagrams. As an architect, you are responsible for generating top-quality architectural diagrams. This is not the duty of a junior resource or a job that you can offload to someone else. You are responsible for the overall solution architecture, which makes you accountable for creating, or closely supervising, the creation of all the elements that are required to communicate and document the technical solution.

This is precisely what you are expected to develop and communicate during the CTA review board: the end-to-end technical solution design.

The following diagram is an example of an oversimplified data model:

Figure 11.2: An example of an oversimplified data model

You can quickly tell that this diagram will not help you understand the proposed data sharing and visibility strategy. It will not help you detect LDV (Large data volumes) or sub-optimal relationships. It will also not even help you understand the nature of the relationships between the objects or their cardinality. The arrows might even communicate the wrong message. This could be an example of oversimplification and a lack of standardization (which is the third common mistake that will be covered).

Lack of Standardization

Next time you want to create a diagram, try to google and see whether there is a common standardized version of it. Look for templates and examples provided by purposely built diagramming tools such as Lucidchart, Visio, or Gliffy.

You will likely find a standard diagram that is suitable for your purpose. Do not try to search for something such as a solution architecture diagram because that is not just a single diagram. To describe an end-to-end solution architecture, you need multiple diagrams. You came across these diagrams and learned about their value in Chapter 1, Starting Your Journey as a CTA.

Note

Creating these diagrams should become part of your daily work, not something you do temporarily to pass the CTA review board. You need to continuously demonstrate your knowledge, values, and attitude as a CTA in live projects. Create these diagrams daily. This will help you develop architectural muscle memory and become quicker at creating these diagrams during the review board.

A good architectural diagram can help you organize your thoughts and spot gaps in your solution, answer questions before they are asked, explain your solution much more thoroughly, and handle objections, which is exactly what the next objective is all about.

Handling Objections and Unexpected Roadblocks

Throughout this book, you have learned that there is no single correct answer. You can expect some challenges to your solution. Some of these challenges might drive some required solution changes. You need to rationally defend your solution but not be too stubborn about it. If you make a wrong decision, go ahead and admit it. Humans are prone to making mistakes; even the judges on the board and the architects in this business will have committed a fair share of errors in their careers.

The way you handle an objection is a skill that will be assessed. Defending your solution confidently is as important as showing maturity while receiving feedback and accepting it without losing control. A CTA will frequently come across such circumstances. If you make a mistake, admit it and demonstrate your skills by rectifying it on the fly.

The judges will also add or change some scenario requirements during the Q&A to test your ability to quickly and adequately react to the evolving requirements and solution on the fly. When that happens, make sure you understand the requirements first. Do not hesitate to ask for explanations (but do not waste too much time doing so either). Take a few seconds to think it through, then confidently present your solution.

You are now familiar with this domain’s expectations. Next, take a look at a practical example where you will use this knowledge to create an engaging presentation and handle objections.

Practicing Communicating a Mini Hypothetical Scenario

The following mini scenario describes a challenge with a particular client. This scenario is slightly different from others as it has been tuned to raise tricky challenges that could be subjected to questions from the judges during the Q&A stage. In this scenario, you will not only provide a proposed solution but also defend that solution appropriately during a hypothetical Q&A.

The judges will challenge some of your proposed design decisions. You should expect a different type of challenge from each judge as they might have different personalities, strengths, and weaknesses.

The judges will also attempt to change some requirements during the Q&A. They might even introduce some new requirements. This is not an indication of an error on your end. Usually, the judges use this technique to test the candidate’s ability to solution on the fly. To pass this domain, you need to prepare yourself to handle objections. This is one of the vital soft skills for a CTA.

Moreover, you need to be able to solution on the fly. Some people refer to this as solutioning on your feet. The client might simply throw out a new requirement, and you are expected to understand it, challenge it (if needed), and provide a detailed solution that could fulfill it.

Note

Do not lose your focus or confidence when/if the judges start to ask questions and dig deeper into the requirements. Your lack of confidence will be obvious to the judges and reduce your chances of passing. Do not assume that these questions are being asked because you are not answering correctly or are doing something wrong. The judges could merely be checking whether you have the right soft skills and can handle such difficult situations that you will face in real life.

You need to go through the scenario once to build an initial picture of the required solution. Then, go through the requirements thoroughly and try to solve them yourself, followed by comparing them with the suggested solution. Try to practice explaining the end-to-end solution, as well as answering the Q&A challenges.

Without further ado, proceed to the scenario.

Scenario

An innovative reseller sells a broad set of software services, including support services and maintenance. They operate across Europe and offer their products directly to their end customers via multiple channels. They have recently started a digital transformation involving Salesforce Marketing Cloud, Salesforce Service Cloud, and e-commerce. They are planning to use Service Cloud as the System of Record (SOR) for customer management.

Current Situation

The company has several requirements around customer matching, merging, and deduplication. This is considered key to the program’s success.

They have multiple back-office applications, including Oracle ERP, a custom-developed order management system, and several other home-grown apps. They are all hosted on-premises.

The company has recently acquired another digital services company that operates in the US only. The acquired company also uses Salesforce as its main CRM. It has been tuned for their specific business processes.

Requirements

The company shared the following list of requirements:

• All of its enterprise apps need to utilize customers’ golden records. They also need to be able to enrich some of the values periodically. The company is looking for your guidance to provide recommendations around the tools and strategies to implement this requirement best, as well as to ensure it scales up as more brands are brought into the system.
• The company would like to implement a new sales solution focused on retail execution. The solution should serve all regions using a standardized business process wherever possible, with room for minor localization. The solution should also be integrated with the rest of the enterprise apps, such as the order management system. It is looking for your help to determine the right org strategy for its plans.
• The company would like to enable their reps in Europe with mobile apps that support offline functionality. This should help the reps operate in all locations and regions. The data that is captured via the mobile application needs to be surfaced in Salesforce and seven other different applications. They are looking for your guidance to determine the right mobile strategy, as well as their integration strategy.
• The company currently maintains invoices in a custom object. They need to share this record with the user specified in a lookup field. This sharing should be maintained even if the record owner is changed and should share the record only with the current user specified in the lookup field.

The company is looking for your help and guidance with all its shared requirements.

Articulating Your Solution and Managing Objections

You might have noticed that this scenario is a little light on details. This is intentional to allow more focus on the presentation and Q&A activities.

Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Once you have done that, you can go through the scenario step by step and create the solution, similar to what you did in the previous scenarios covered in this book.

Understanding the Current Situation

The company is using Salesforce Service Cloud as the primary SOR for customer management. Moreover, they have acquired another company that also uses Salesforce as a CRM. However, it is a heavily customized org tailored to meet specific needs. It is having issues with data quality, particularly duplicate management. On top of that, they have several other applications that you need to integrate Salesforce with. The company landscape looks as follows for the time being:

Figure 11.3: Landscape architecture – first draft

Now that you understand the current situation, it’s time to go through the requirements.

Diving into the Shared Requirements

You are all set to start tackling the company’s requirements, craft a proposed solution for each, and update the diagrams accordingly to help with the presentation. Start with the first requirement:

All of its enterprise apps need to utilize customers’ golden records.

First, you might consider using Salesforce’s native deduplication capabilities using duplicate rules. This makes sense because the company specified that they are considering Salesforce Service Cloud as the SOR. This is the system that is the authoritative source of truth for specific data (customer records, in this case).

However, the company also shared requirements that indicate they have issues detecting and managing duplicates. This could be because their matching algorithm is complex and probably relies on complex fuzzy logic. They also reported that they have concerns with merging duplicates.

Advanced matching and data merging are not capabilities offered out-of-the-box in Salesforce. This is the territory of Master Data Management (MDM). You learned about various MDM concepts and the three different implementation styles of MDM tools in Chapter 2, Core Architectural Concepts: Data Life Cycle.

Note

As a reminder, the three implementation styles are registry, consolidation, and coexistence. The latter two support the concept of the golden record.

To deliver the required functionality, you need an MDM tool that supports one of the two MDM implementation styles with the golden record concept. As mentioned several times in this book already, you need to familiarize yourself with product names from the Salesforce ecosystem. In this case, you can propose Informatica MDM.

Your proposed solution could be as follows:

In order to fulfill this requirement, I propose using an MDM tool that supports advanced deduplication and merges processes such as Informatica MDM. Informatica will be linked with Salesforce Service Cloud, which will be the system that is allowed to create new customers. Informatica will use its advanced matching capabilities to detect a duplicate and, if needed, merge it. Then, it will update the data in Service Cloud to ensure that the latest version of the data is always held in Service Cloud. This fulfills the company’s requirement to use Service Cloud as a SOR.

The other applications can get access to the golden customer record directly from Informatica. This also allows them to update specific attributes in it. Informatica would then handle any validations required for these values and attempt to replicate the data to Service Cloud. And only upon successfully updating the data in Service Cloud will Informatica commit the changes to the golden record.

I thought of using Salesforce duplicate rules to handle this requirement, but I assumed that the mentioned need for advanced deduplication is beyond the out-of-the-box capability. Moreover, Salesforce duplicate rules do not handle record merging if needed.

This solution looks good and solid. However, the judges may still want to challenge your proposed solution, either to ensure that you really understand the topic (and you have not merely memorized it) or to test your communication skills and the ability to solution on the fly.

A judge might ask you the following:

How do you propose handling the existing duplicate data in the Salesforce Service Cloud org? And what would your strategy be considering the newly acquired Salesforce org?

These questions are normally clear and straightforward but do not expect to be spoon-fed. If you continuously fail to spot the question and answer it correctly, the judges might simply decide not to give you the points. Your answer should be crisp, clear, and to the point. You have limited time during the Q&A, and you should aim to make the most of it. Your answer could be as follows:

Regarding the existing data, I plan to load that into Informatica MDM once the tool is introduced. This will be part of the tool’s setup. The MDM will determine duplicates and update or merge the existing records in Service Cloud, including any re-parenting process.

The fact that we have an MDM tool gives us more flexibility with the other Salesforce org. I am going to explain my org strategy in a later requirement. But, in short, we can connect the MDM tool to the other environment as well and utilize it as another SOR.

Make sure your answers are crisp and sharp. Be confident and consider the Q&A stage as an opportunity to share your ideas and thoughts in a limited time slot.

Update your diagrams, then move on to the next requirement:

The company would like to implement a new sales solution focused on retail execution.

The new solution should be used in all regions, and introduce a high level of standardization along with some room for minor changes.

But what is the right org strategy for the company to start with? The acquired brand has another Salesforce instance, which is heavily customized to meet their needs. The sales solution could be an extension of what they already have. Of course, you can assume that it is a complete replacement for their existing solution, then build your proposal based on that. The scenarios have not specified any details. Different assumptions could lead to entirely different logical answers. In any case, your assumption should be reasonable and not too far from what you would see in reality.

Once you have decided on the proposed org strategy, you need to come up with a solution that allows standardization with room for modification.

Your proposed solution could be as follows:

The Salesforce org of the acquired company is heavily customized. I am assuming that the current functionalities in this org do not include anything for retail execution. Therefore, the new functionality would be extending the existing functionality rather than replacing it.

Based on that, I propose keeping these orgs separate. The US org has other functionalities that are tailor-made for the region. The new retail execution solution will be developed based on the standard process, and it will be delivered to both orgs as an unmanaged package. This will allow the solution to be centrally managed and updated.

Whenever new functionality is introduced or updated, a new version of the package will be made available. After deploying the unmanaged package, the target org can add or modify it based on their requirements. The features and code will contain hooks to allow an extension and a mechanism to turn some functionalities on or off using metadata configurations.

Both orgs will be connected to the rest of the enterprise applications using an ESB such as MuleSoft. This will enable the company to establish a scalable and reusable integration architecture. MuleSoft will handle all required orchestrations, error handling, queueing, and retry mechanisms. Moreover, it will allow us to integrate a cloud-based solution such as Salesforce with on-premises hosted solutions.

Your assumption might be sound, but the judges might decide to change or challenge your assumption, either because they find it unsatisfactory or because they want to test your skills further.

A judge might ask you the following:

What will change in your solution if you assume that the customized solution in the US org is all about retail execution?

In this case, the judge is changing the scenario to further check the logic behind your proposed org strategy. In addition, this is a test of your on-the-fly solutioning skills. Your answer could be as follows:

This will change the way I think about the org strategy. Previously, the two orgs were serving different regions with two completely different processes. The retail execution processes were something new for both orgs and I did not find a reason strong enough to propose an expensive org merge.

However, if the new solution is a replacement for the US org’s customized solution, this would be a good opportunity for an org merge. Eventually, both orgs will have an almost identical sales process. Merging both orgs will make it simpler to introduce and manage a unified process. These minor changes can still be accommodated without impacting the solution’s quality or stability.

In the org merge case, all the US users and data will be migrated to the unified org. I am also assuming that no regulations prevent this.

Remember to keep an eye on the stopwatch. The previous answer should not take more than 90 seconds of your Q&A time. Try to read it and rephrase it using your own words and measure the time it takes. You might need to repeat this several times until you feel confident about the results.

You could also be asked about the rationale behind selecting the specific middleware. In this case, they are most likely testing your knowledge of the integration domain. You need to explain the difference between an ETL and an ESB (which is covered in Chapter 3, Core Architectural Concepts: Integration and Cryptography).

They might even ask you how MuleSoft will be able to communicate with an on-premises hosted application. For MuleSoft, this would require setting up a Virtual Private Network (VPN) between MuleSoft CloudHub (assuming it is using CloudHub) and the client’s intranet. This is different from the secure agent mechanism that was covered in Chapter 9, Forging an Integrated Solution, which is used by other ETL tools.

Update your diagrams and move on to the next requirement, which starts with the following line:

The company would like to enable their reps in Europe with mobile apps that support offline functionality.

The critical requirement is to deliver a mobile app with offline capabilities to the agent. The requirement did not specify any additional information, so you will have to make some valid assumptions.

You can assume that the required offline capability is advanced and therefore requires a specific type of mobile application to fulfill it.

Looking back at Chapter 5, Developing a Scalable System Architecture, you learned about four different types of mobile applications that you can develop/use with Salesforce:

• Salesforce mobile app: This is the standard app that is developed and maintained by Salesforce. It provides a rich set of configurable functionalities and a modern UI. However, it has limited offline capabilities.

Note

You can find out more about the offline capabilities of the Salesforce mobile app at the following link: https://packt.link/r7xTe.

It is worth mentioning that the Salesforce mobile app can be branded using the Salesforce Mobile Publisher functionality.

• Hybrid apps: These are custom-developed cross-platform mobile applications. They typically have limited offline capability.
• HTML5 apps: These are cross-platform mobile apps developed using HTML5. They have a very limited offline capability by nature.
• Native apps: These are custom-developed mobile apps, targeted at specific platforms, such as iOS and Android, using specific programming languages. You can develop native mobile applications with advanced offline capabilities. These include the ability to cache a considerable number of records, store them safely in encrypted storage, and sync them back to Salesforce whenever the connection to the internet is restored.

Based on your assumption, you can propose a native app. Alternatively, you could have assumed that the standard Salesforce mobile capabilities are enough for this use case. However, in my opinion, it is a safer option to go with the former approach as the limitations of the Salesforce mobile app could be easily challenged by complex businesses, such as the company in this scenario.

This will answer half of the requirement. The rest of the requirement indicates a need to surface the data captured via the mobile application into Salesforce and seven other systems. This is another example where you might have more than one potential solution. The approach you choose will determine the challenges you might face during the Q&A stage. The following two possible options explain this:

• The mobile application can communicate directly with an API layer exposed by MuleSoft. This, in turn, will communicate with Salesforce and the seven other systems. This could happen in a parallel or sequential manner, where the changes are pushed to the other seven systems only after being accepted and committed in Salesforce.

Proposing this approach could raise several questions, including How can you authenticate to MuleSoft APIs? Is there an alternative approach that avoids caching data in MuleSoft? Besides, the required customizations in MuleSoft to achieve this are substantial, which could raise a few more questions and challenges.

• The mobile application can communicate directly with Salesforce. Once the data has been committed to Salesforce, it can be replicated to the other applications in different ways, such as batch sync using MuleSoft, asynchronous platform events, or Change Data Capture (CDC).

Proposing this approach could raise a different set of questions. The judges might be curious to know why you picked this approach over an API-led approach utilizing MuleSoft, which promises a more reusable interface. They might also change the requirement to include the US instance, which will push you toward the first approach.

The following diagram illustrates both approaches:

Figure 11.4: An illustrative diagram showing two different approaches for the mobile application

It is always favorable to use simple architecture. The simpler the architecture is, the less likely things will go wrong unless the architecture is unable to deliver the desired functionality or produces a sub-optimal variation of it.

Note

The mobile application is going to deal with data coming from Salesforce only. The mobile app is not supposed to retrieve data from other applications or commit data to them directly, so assuming a need for an API that does complex orchestrations could be a overkill.

The requirement to surface the captured data in other systems could be simply interpreted as a need to replicate this data to other systems once it has been committed to Salesforce. Avoid unnecessarily complicating things for yourself in the solution.

Your proposed solution could be as follows:

I am assuming that the desired offline capabilities are beyond what the Salesforce mobile app can offer. Hybrid and HTML5 mobile app offline capabilities are also limited. Therefore, I propose developing a native mobile application with advanced offline capabilities. The mobile app will allow reps to create and update data offline and sync back to Salesforce once the connection to the internet is restored. The app will also manage conflicts and will notify the user if any were found.

Once the data passes all server-side validations and is committed to Salesforce, I will use a data replication mechanism to copy this data to the other seven applications via MuleSoft. The scenario did not specify any timing requirements, so I am assuming a delay of an hour is acceptable. I propose using a batch data synchronization pattern where a scheduled batch job is initiated in MuleSoft. The job pulls the new data from Salesforce and replicates it to the other applications.

The batch data synchronization approach is more straightforward than the near real-time fire and forget pattern. When offline users go back online, they will be synchronizing dozens of records. These records should be committed to Salesforce in the right order. However, committing a large number of records would fire several platform events from Salesforce.

Ideally, they should all go into the event queue in the correct order, be sent to MuleSoft (or other subscribers) using the same order, and be delivered with none missing. However, you can see that several things could go wrong with this approach. This will be an unnecessary complexity unless a near real-time data sync is essential.

The choice is yours, as long as you can justify it. Move on to the next requirement, which starts with the following:

The company currently maintains invoices in a custom object.

They have a requirement to share this record with the user specified in a lookup field. This sharing should be maintained even if the record owner is changed, and they should only share the record with the current user specified in the lookup field.

Similar to what you have done several times already, you will start by considering configurable functionalities. You will only move on to a custom-developed solution when you have concluded that the standard functionalities are incapable of delivering the requirements.

This requirement cannot be met with configurable platform functionalities. However, you know that the record owner can share the record manually with the target user. You can also automate this process and create share records using APEX. In this case, the APEX class will create an invoice__share record automatically to share the record with the target user.

Your proposed solution could be as follows:

The desired functionality cannot be met using the configurable sharing mechanisms; therefore, I propose creating the invoice__share records automatically using APEX. When the record is created or updated, a trigger will delete all the invoice__share records associated with users other than the user specified on the lookup field. The trigger would then create an invoice__share record and associate it with the user specified in the lookup field if such a record does not already exist.

Good enough? The answer is no.

One of the common challenges observed while coaching over a dozen and a half CTA candidates is the accidental jump over requirements. The candidate is under pressure to deliver the solution on time. In such circumstances, the candidate might miss or jump over requirements and fail to identify them.

In some cases, it might be a simple requirement with low or no impact on the solution. In other cases, it may have a significant impact. This may lead to the domino effect, where one hesitant solution change will cause other elements to fall apart. This is one of the most critical risks a candidate could face in the review board.

The best way to avoid it is by making sure you do not miss any requirements. Such an incomplete solution would definitely draw some questions from the judges, such as the following:

The requirement indicated that sharing should be maintained even if the record owner is changed. How would you achieve this using your solution?

This is a requirement you failed to spot and can backfire. A hesitant answer could be as follows:

The trigger will fire even on the change of the record owner. In this case, the code will continue to run, as described earlier.

A hesitant answer is usually much longer than that and this means that you are losing some valuable Q&A time. However, this answer could make things worse. The judges might now get the impression that you are unaware of the standard behavior associated with the changing of the record owner.

When a record owner is modified, the manual sharing records are automatically deleted. You might know that already, but the provided answer does not reflect this knowledge. Moreover, relying on the trigger to unnecessarily create share records is a sub-optimal solution, especially when there is a standard way to meet the desired requirement.

Some candidates might lose more than five precious minutes due to incorrect or incomplete answers, not counting the side conversations that such answers might spark.

A good answer, which would likely grant you the points associated with the requirement, could be as follows:

I plan to define a custom sharing reason on the invoice object and then use this sharing reason in the APEX sharing. I am aware that manual sharing records will get automatically deleted upon changing a record owner. However, APEX managed sharing records with custom sharing reasons are maintained across record owner changes.

It would have been ideal if you included that statement in your original proposed solution. This would have saved the 30 seconds that were lost from your Q&A time.

Note

The Q&A stage is your friend. The judges will ask you questions to fill in any gaps and missed requirements. They will also ask questions that help them determine whether you have the skills and knowledge required to pass the exam. This time is very precious – make sure it is not wasted.

Some CTA candidates dread the Q&A as they consider it the most challenging stage of the review board. It is not. This is time given to you to close any gaps and prove that you have got what it takes to pass the exam.

That was the last shared requirement. Update all the diagrams and see how they look. The following is the landscape architecture diagram:

Figure 11.5: Landscape architecture – final

The following are integration interfaces:

Figure 11.6: Integration interfaces – final

That concludes the scenario and the solution too. You may have noticed that you only had a few diagrams for this scenario. This is because it is a mini scenario with a particular focus on communication. Things will look different in a full scenario.

Summary

In this chapter, you have dived into the details of the Salesforce communication domain. You learned what a CTA is expected to cover and the level of detail. You went through some practical examples of ways to present a particular solution and understood the importance of standard diagrams and the common types of diagrams you are likely to encounter.

Then you tackled a mini hypothetical scenario and had a hypothetical Q&A stage to practice handling objections. You also learned about some pitfalls to avoid and how to make the right professional impression during the CTA review board and in real life.

After that, you explored multiple potential ways to handle a particular requirement. You learned how one path can lead you to a completely different set of potential challenges and how to prepare for them. You also learned how to avoid difficult situations by merely striving for a simple solution where fewer things can go wrong.

This concludes the seven knowledge domains you need to master. In the next chapter, you will start your first full hypothetical scenario. You will be introduced to a full-sized scenario that you would need to solve using all the knowledge and techniques you have learned so far. Buckle up and get ready!