In the digital world, the term “solution architecture” refers to the process of analyzing client needs, understanding the core of their problems, and determining the appropriate solution to provide measurable benefits to the business.
The solution architect is likely the most business-aware architect on a project. To pass the CTA review board, you must possess both the technical skills and the ability to interpret business needs and craft an end-to-end solution architecture. Your solution must consider the capabilities and limitations of the platform.
The detailed principles of lean architecture are beyond the scope of this book. But in short, it is all about eliminating waste by achieving the following:
As a CTA, you are expected to have strong hands-on experience with the platform and use that knowledge while designing a solution. Salesforce is a platform that enables architects to easily try things out. This is a powerful capability that should be fully utilized.
You have already come across principles and activities related to solution architecture in the last three chapters. In this chapter, you will dive deeper into these principles and cover the following main topics:
A solution architect is usually the person that forms a bridge between business and technology. This architect will focus on creating the technical vision for solving a specific business problem. As a CTA, you are expected to lead and support both Salesforce and non-Salesforce solution architects during an implementation.
Note
According to the Salesforce online documentation, the CTA candidate should meet a specific set of objectives that can be found at the following link: https://packt.link/7kjFw.
By the end of this chapter, you should be able to do the following:
Now have a closer look at each of these objectives.
It might sound simple, but you need to keep in mind that every suggestion you come up with as a part of your CTA review board solution should be clear and justified. The Salesforce Core Cloud comes with plenty of different capabilities and out-of-the-box functionalities.
While designing your solution, you should start considering configurable functionalities first. Then, transition to programmatic solutions only when the configurations fall short of meeting the desired functionality. Configuring an existing, mature system is usually much quicker than developing software from scratch. This is one of the main reasons enterprises buy readymade software solutions rather than developing them themselves.
You might find out that the configurable functionality delivers a sub-optimal user experience or leaves some questions unanswered. In this case, feel free to propose a programmatic solution. After all, the programmatic capabilities (such as Apex, Lightning Web Components (LWCs), Visualforce pages, and others) of the platform are there for a reason.
Keep in mind that point-and-click development is quicker and less error-prone than code-based development. So, it should be considered first. You need to be up to date with the latest capabilities of some of the core platform tools, such as Salesforce Flows. Flows have recently evolved and matured well, and they are becoming a popular tool to build automation with clicks rather than code. But there are still many other functionalities that would require a programmatic solution of some sort: an LWC, a Visualforce page, an Apex-based trigger, a Batch job, or a custom Apex web service.
To select the right combination of configurable versus programmatic functionalities, you must have deep hands-on experience with the platform’s capabilities. You are encouraged to try every single configurable solution proposed in this book. Make yourself familiar with the key sales, service, and marketing processes. For example, in sales, you need to understand the following:
Similarly, you need to fully understand the capabilities offered for service and marketing. Make yourself familiar with other general functionalities, such as email alerts, multilingual support, the translation workbench, multi-currency support, flows, flow actions, time-based workflows, profiles, permission sets, App builder, validation rules, custom settings, custom metadata types, reports, analytics, and so on.
On the programmatic side, you need to have a good understanding of the platform’s available capabilities. Hands-on experience is an advantage. Make yourself familiar with the structure of Apex and its keywords. Take a look at some examples of Apex classes, triggers, LWCs, and Visualforce pages.
Note
You can learn more about Apex at the following link: https://packt.link/8Ux8K.
Another way to handle requirements that cannot be met with out-of-the-box capabilities is via third-party applications. You are going to cover that next.
After concluding that the out-of-the-box capabilities are not enough to fulfill the desired functionality, you can consider a programmatic solution or even an external one. In some cases, the decision is easy to make. In other cases, it may turn out to be a complicated build or buy decision.
In real life, build versus buy decisions are not easy to make. You need to consider the following points:
On the other hand, the cost of buying an external solution can be easily calculated and forecasted. They are easier to deploy and less error-prone.
Fully custom-developed solutions or solutions built on top of open source frameworks come with even more maintenance overhead, including patching newly discovered security threats. Third-party solutions are not exempt from such challenges. However, they have other companies looking after them, which reduces the overall maintenance cost and overhead for their clients.
Software development houses have frameworks, methodologies, regulations, and processes tailored to deliver high-quality, scalable, configurable, and extendable software products.
It is not easy to calculate the total software cost of ownership. You are not expected to do so during the CTA review board, but assuming that buying a product is always more expensive than developing it is a mistake that a CTA should not fall into.
On the other hand, avoid being hesitant to propose a custom solution developed on top of the force.com platform when it is technically reasonable to do so.
Note the following examples of build versus buy decisions:
When you propose an AppExchange or third-party solution, you are still expected to clearly explain how you see it can be utilized to deliver the desired functionality. You are also expected to mention the name of the proposed product. Make sure you are familiar with some popular products from the Salesforce ecosystem. You will see examples in the mini hypothetical scenario next.
The following mini scenario describes a challenge with a particular client. The scenario is tuned to focus on challenges related to solution architecture specifically. But as you would expect, there are also requirements related to other domains, such as data and security.
As you did in the previous chapters, you will go through the scenario and create a solution step by step. You should try the suggested solutions yourself unless you are already familiar with the described feature. You are also encouraged to try different solutions that could fulfill the requirements.
Remember that the solutions listed are not necessarily the only possible solutions. Alternate solutions are acceptable as long as they are technically correct and logically justified.
Packt visiting angels (PVA) is a home clinical trial company that bridges the gap between clinical research organizations (CROs) and clinical trial volunteers. PVA provides various sets of services, including home visits and site nurse services. They operate across five different European countries (the UK, France, Germany, Italy, and the Netherlands).
PVA has a sales operation team that deals with CROs. They take over from the marketing team, who gather and qualify information about potential deals via multiple sources.
The sales operations team monitors qualified deals, particularly high-value deals (with a total amount above five million euros). It also handles various follow-up activities, such as creating quotes, managing contracts, notifications for other internal team members, follow-up tasks, and scheduling wrap-up meetings.
Once the deal is closed, the nurses get assigned to the project. The nurses should follow an optimized schedule to visit as many sites as possible, considering their skills, location, and the shortest possible route.
PVA’s business is growing rapidly, and they are looking to introduce more automation to increase their internal teams’ efficiency using Salesforce as their central CRM solution.
PVA has shared the following requirements:
PVA is looking for a proposed solution that can increase their internal teams’ efficiency and reduce manual errors using Salesforce.
Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Now, go through it again, section by section, and incrementally build the solution.
The first paragraph of the scenario has some general information about PVA’s business model. It also tells you important information about the different personas that are going to use the system. You now know that they have a marketing team, a sales operations team, and nurses. Each is doing a specific set of activities. Based on that, you can start creating a draft of the actors and licenses diagram. Your diagram could look as follows:
Figure 8.1 – Actors and licenses (first draft)
You can include an assumed nurse manager role in anticipation of needing someone to create and manage the nurses’ schedule. A Salesforce Sales Cloud license for the marketing and sales agents was assumed as they would need to deal with leads, opportunities, and some other objects. At the same time, the nurse and nurse manager would need Field Service licenses if you ended up proposing Salesforce Field Service as part of the solution. You might need to change that later.
Even at this stage, you can see some potential requirements, such as creating quotes, contracts, and optimized site visit schedules. You probably also started to build some early understanding of the likely functionalities, licenses, and third parties you might need.
Create a draft landscape architecture diagram using whatever information you have learned and include any assumptions and early ideas you can think of. Your landscape architecture diagram could look as follows:
Figure 8.2 – Landscape architecture diagram (first draft)
The optimized scheduling requirement should immediately trigger in your mind two possible solutions, that is, Salesforce Maps and Salesforce Field Service. There are other third-party solutions as well, but this is a complex topic that you simply should not think of solving with any custom-developed solution. It is still too early to determine which solution is a better fit for PVA, but for the time being, the best way to avoid losing this information is by adding it to your draft landscape.
Also, based on the bit of information you know so far, you can create an early version draft data model:
Figure 8.3 – Data model diagram (first draft)
PVA’s business is growing rapidly, and they are looking to introduce more automation to increase their internal teams’ efficiency using Salesforce as their central CRM solution. They shared a lengthy list of requirements, which you are going to cover next.
Now, go through PVA’s requirements, craft a proposed solution for each, and update your diagrams accordingly to help with the presentation. You can start with the first requirement, which begins with the following section:
Leads are normally gathered via three different channels.
This is a requirement to ensure lead uniqueness across the channels. Open leads are uniquely identified using the company, drug, and country attributes. You can assume that the values of drug and country are captured using custom fields.
You can use different ways to ensure the lead record is unique based on the given attributes, such as the following:
The performance of this solution is optimized. However, it is difficult to change the matching logic because it relies on persistent data. For example, to introduce a new field to the set of fields considered for deduplication, you need to update all existing open leads. Moreover, this is hard deduplication, always preventing new, similar records from being created. While this is the current requirement, fulfilling it in this way prevents the business from adopting a different strategy in the future, such as allowing duplicate records to be created but marking them as duplicates.
The order of the aforementioned four potential solutions is intentionally reversed to provide more details on the qualifying logic used for each. You would typically start by considering out-of-the-box configurable functionalities and only venture to other solutions when needed.
Your proposed solution for this requirement could be as follows:
Update your diagrams and move on to the next requirement.
Leads that are not created manually should automatically be assigned to a country’s marketing team based on the geographic location (country)
Let’s start by asking ourselves a simple question: is there an out-of-the-box configurable functionality that can be used to fulfill this requirement? As a Salesforce solution architect, you are expected to know the details of the standard platform capabilities. In this case, the lead assignment rule can be used in combination with queues. This solution is configurable, optimized, and fulfills the requirement. Moreover, it is also future embracing, as it is based on a standard configurable Salesforce functionality.
The term future-embracing is preferred over futureproof as a lean and well-architected solution should embrace and welcome future changes rather than prevent them.
Your proposed solution could be as follows:
Now, you can move on to the next requirement.
Once the lead is assigned, it goes through multiple stages. At each stage, a set of activities is expected to be completed by the lead owner.
Starting with the out-of-the-box functionalities, it is easy to recognize that you can utilize the standard lead process functionality to define multiple lead processes, each with different lead statuses. At each stage, you can generate a set of tasks and assign them to the lead owner. This can be achieved using one of the following (in order):
Note
Salesforce has retired Process Builder and workflow rules as of the Winter ‘23 release. While the current workflow rules and process builders will continue to run, you will not be able to create new automations using these tools. These tools should not be considered part of your solution.
Your proposed solution could be as follows:
Once the lead is qualified, it must be converted into an opportunity and automatically handed over to the country’s sales operations team.
This requirement does not specify whether the lead conversion should happen automatically or whether it is fine to stick with the manual process. You can assume one of these and base your solution on it.
By default, when the opportunity is created out of a lead conversion, it is owned by the same user who owns the converted lead. You need an automation process to assign it to the sales agent’s queue in that country.
Your proposed solution could be as follows:
The sales operations agent will follow up with the deal. The agent should be able to create quotes and negotiate them with the client.
This is standard Salesforce functionality. The sales agent has a Sales Cloud license, therefore, can work with the quote object.
Your proposed solution could be as simple as the following:
Remember to use your diagrams while explaining the solution. The actors and licenses diagram (such as the one you saw in Figure 8.1) is particularly useful in this case.
Once a quote is accepted, the agent updates the opportunity to the contracting stage.
The main requirement is to automatically create a contract out of the closed opportunity, which can easily be done using flows or custom-developed code. The scenario did not specify any advanced contract creation logic to justify proposing a third-party solution.
There are several CLM solutions out there on the market, including some available on AppExchange, such as Apttus Contract Management, DocuSign CLM, and Conga Contracts. They provide advanced contract creation and negotiation functionalities. However, that has not been requested in this scenario.
Note
You need to memorize the names of some common third-party products from the Salesforce ecosystem, such as CPQ tools, integration middleware, identity providers and identity management solutions, e-signature solutions, document generation solutions, advanced lead assignment solutions, CTI, version control, release management, backup and restore, and so on.
You will encounter examples throughout this book whenever applicable. As a CTA, you should make yourself familiar and keep up to date with what is available on AppExchange.
Your proposed solution could be as follows:
The agent should ensure the contract’s data is accurate, select the right terms and conditions, and send the contract to the client for an online signature.
Here, you come across a requirement for an e-signature, a functionality that would require extensive efforts to develop. This is totally unjustified, considering that there are several battle-tested solutions available on the market and via AppExchange, such as DocuSign, HelloSign, and Adobe Sign. These products can also help to fulfill the second part of the requirement, which indicates that the contract should be presented in the CRO’s local language.
Your proposed solution could be as follows:
Update your landscape architecture diagram and move on to the next requirement.
The client should receive a request to sign the document online.
Once the document is signed, the contract should be made active, and the opportunity should be updated to closed-won. Luckily, most of this requirement is automatically fulfilled using the third-party e-signature tool you suggested. You still need to explain how that works, though.
Your proposed solution could be as follows:
Now, move on to the next requirement, as follows.
The agent should update lost opportunities to the closed lost stage manually and set a reason for the loss.
You can assume that the loss reason is captured using a custom field. You then need to introduce a mechanism that ensures this field becomes mandatory when the opportunity is updated to the given stage. You can utilize field dependencies and validation rules to ensure that.
Your proposed solution could be as follows:
Once the opportunity is closed-won, a project that contains key information derived from the opportunity should be created automatically.
Do not expect the requirements to be isolated based on their related domain. In many cases, you will come across requirements that cut across different domain knowledge, like in real life. In this, you have two requirements—one related to solution architecture and another to security.
Your proposed solution could be as follows:
Note
This scenario does not have many specifications for data sharing and visibility and does not provide enough details to design a role hierarchy. In this case, you could make some assumptions, such as assuming a role on top of the nurse managers that report to the CEO.
You need to justify introducing custom objects to the data model. You should start by trying to utilize the standard objects, if possible. But if you decided to use a custom object for any reason (for example, the standard object does not fit the requirement or might require significant customizations to be repurposed), then you should clearly justify your rationale. Be crisp and confident; avoid decisions based on personal experiences that could have been impacted by other non-technical factors.
Always keep an eye on the time spent on the presentation. Do not waste valuable time on further explaining the topics you have already explained. For example, you decided not to use the case object in your solution and provided the key reasons behind that decision. Do not waste your presentation time by trying to list every single minor reason behind your decision. Keep your focus on the key decision points.
Your role hierarchy diagram could look as follows:
Figure 8.4 – Role hierarchy (first draft)
Your data model could look as follows:
Figure 8.5 – Data model diagram (second draft)
Now, move on to the next requirement.
The solution should provide the nurses with their daily optimized visit schedule.
Following the same logic you used for other requirements and using the same order, you should conclude that such a feature requires a specific additional product to deliver it.
Luckily, Salesforce has a product that delivers this functionality, and it is probably one of the most advanced Field Service scheduling tools available on the market. Salesforce Field Service allows the creation of optimized site visits for technicians. A technician could be a nurse in this case. The scheduler can consider many factors, such as the different working hours, skillsets, preferred technicians, geographic locations, scheduling policies, and many more.
You do not need to become an expert Field Service consultant to pass the CTA review board. But you need to be aware of the product, understand when to propose it, and what kind of licenses will be required. It is also recommended to become familiar with its underlying data model.
Note
You can learn more about Salesforce Field Service at the following link: https://packt.link/aclKE.
You can learn more about the core Field Service data model at the following link: https://packt.link/HfqJB.
In your presentation, you are not expected to cover the details of how Salesforce Field Service works (remember the exam’s objectives), but you are expected to explain how you are planning to utilize it as part of your overall solution.
Your proposed solution could be as follows:
You can update your diagrams and move on to the next requirement.
Once the opportunity is closed, lock all the opportunity fields for all users except the administrator and the opportunity owner.
Following the same technique and order you used before, you can think of some potential solutions:
Introducing a new custom is_locked__c field and updating it using a flow upon closing the opportunity could be a solution. Your validation rule would then rely on this field alone. However, if you are after a good user experience (and you should be), you need to keep in mind that this solution alone would not prevent the user from attempting to edit the record.
The requirement here can be completely fulfilled using configurations. There is no justification for using an Apex validation. You can propose a solution based on a combination of the first two approaches. Before drafting the end-to-end solution to present, have a look at the next three requirements as they are related to this.
Opportunity line items’ fields should also get locked. No products can be added, edited, or deleted once the opportunity is closed.
You understand that the lock should also be extended to the opportunity line item. You can introduce validation rules on the OpportunityLineItem object as well, which relies on its parent opportunity’s is_locked__c flag. You might want to consider updating the record type as well. The requirement can still be fulfilled using configurable features. Now, explore the next requirement.
The opportunity owner is allowed to change the value of the description field for up to seven days after closing the opportunity.
However, that is the only field they are allowed to change during that period. The owner should be able to change a single field for a limited time period. Can you still cover this using validation rules? Sure, you can. But you need to slightly change your approach.
Instead of using a true or false flag, such as is_locked__c, you can instead use a date field such as locked_date__c. The validation rule would then compare this date to the current date and fire on all cases except if the opportunity owner carries out the change, the value of locked_date__c is less than today’s date by no more than seven days, and the modification is for the description field.
Do you have anything else to consider? Have a look at the next requirement.
After seven days, all fields should be locked for all users except the administrators.
You need to allow the administrator to edit this record at any time. The administrator should also be able to edit any editable field. You can update the validation rule to bypass the validation if the executing user’s profile is set as administrator. This is not very flexible as it includes a hardcoded value. A better approach would be to create a custom permission, assign it to the administrator, then configure the validation rule to bypass if the currently executing user has this custom permission assigned.
Your proposed solution could be as follows:
Now, you can move on to the next and final requirement.
The system should support both euro and pound sterling currencies with dated exchange rates.
This is a straightforward requirement that can be met with an out-of-the-box feature. Your solution could be as simple as the following:
That was the last shared PVA requirement. Update all the diagrams and see how they look. The ordering business process flow diagram looks as follows:
Figure 8.6 – Actors and licenses (final)
The landscape architecture diagram looks as follows:
Figure 8.7 – Landscape architecture (final)
The data model diagram looks as follows:
Figure 8.8 – Data model (final)
That concludes the scenario. Please note that for some of the mini scenarios, you are not creating all the mandatory diagrams. That is because they are simplified scenarios, focusing on a particular domain, and you might not need all the diagrams to solve them. This is totally different for full scenarios, where you need to generate all the mandatory diagrams.
In this chapter, you have dived into the details of the Salesforce solution architecture domain. You learned what is expected from a CTA to cover and at what level of detail. You discovered the process of selecting the right combination of configurable and programmable features to deliver a requirement and learned some guiding principles in selecting third-party solutions to deliver value in a short time.
You then tackled a mini hypothetical scenario that focused on solution architecture and created some catchy presentation pitches while solving it. You practiced the process of selecting the right feature to deliver the required functionality and learned that it is not enough to simply mention the name of the used feature. Instead, you must clearly and crisply explain how it is going to be used, end to end, with no gaps or ambiguity. If it is not clear to you, then it will not be clear to your client or the team delivering it.
You also covered other topics in the mini scenario, including selecting the right third-party solution to deliver value quickly and reduce risks.
In the next chapter, you will move on to the fifth domain a CTA needs to master, that is, integration.
Before you proceed to the next chapter, it is recommended that you go through the flashcards from this chapter first. These flashcards condense all the chapter concepts into smaller and easily manageable chunks that will help you with quick review and retention. By engaging with these flashcards, you will strengthen your understanding of key topics, identify areas that require further study, and build your confidence before moving on to new concepts.
The following image shows an example of the flashcards interface.
Figure 8.9 – CTA flashcards interface
To access the end-of-chapter flashcards from this chapter, follow these steps:
Figure 8.10 – Flashcards interface login
You can also scan the following QR code to access the website:
Figure 8.11 – QR code to access Chapter 8 flashcards
After a successful login, you will see the following screen:
Figure 8.12 – Chapter summary and end-of-chapter flashcards