Chapter 11: Communicating and Socializing Your Solution

In this chapter, we will continue with another Salesforce-specific knowledge area that is required to pass the CTA review board: communication. This is the seventh and final domain. We will go through the needed knowledge and preparations for this domain and then 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 of scope and adjust your solution accordingly.

We have already practiced creating presentation pitches in the past six chapters. Each time, we ensured we utilized our diagrams to describe the end-to-end solution. We learned that...

Understanding what you should be able to do while communicating your solution

According to Salesforce's online documentation, the CTA candidate should be able to meet a specific set of objectives, all of which can be found at the following link: https://trailhead.salesforce.com/en/help?article=Salesforce-Certified-Technical-Architect-Exam-Guide&search=release+exam+schedule.

Let's have a closer look at each of these objectives.

Communicating design decisions and considerations

Communication is one of the most critical soft skills needed in a CTA's arsenal. While creating your solution, you will come across several use cases that can be fulfilled in one way or the other. We saw this earlier while developing solutions for the mini-hypothetical scenarios in previous chapters.

During the review board, you have a very limited amount of time and a lot of land to cover. When you present a proposed solution, you should focus on the considerations that would make...

Practicing communicating a mini-hypothetical scenario – Packt Digital

The following mini-scenario describes a challenge with a particular client. This scenario is slightly different from the 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, we will not only provide a proposed solution, but we will 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. After all, we are human, and we all 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 doesn't mean that you did or are doing something wrong. This is all part of the test. To pass this particular domain, you need to be able to handle the...

Articulating your solution and managing objections

You might have noticed that this scenario is a little bit light on the details. This is because we want to focus more on the presentation and Q&A activities and handle them in the best way possible.

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

Understanding the current situation

PD is using Salesforce Service Cloud as the primary system of record 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. PD is having issues with data quality, particularly duplicate management. On top of that, they have several other applications that we need...

Summary

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

We then tackled a mini-hypothetical scenario, and we included a hypothetical Q&A stage to practice handling objections. We solved the scenario together, handled specific challenges, and asked questions. We also learned about some pitfalls to avoid and how to leave the right professional impression during the CTA review board, as well as in real life.

After that, we explored multiple potential ways to handle a particular requirement. We learned how one path can lead you to a completely different set of potential challenges and how to prepare for them. We also learned how to avoid difficult situations by merely...