8

Creating a Lean Solution Architecture

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:

• It defines and follows standards to reduce the time wasted on recurring challenges and discussions. This should also aim to reduce overall solution inconsistencies.
• It ensures you are establishing an environment that enables smooth feature development. A poorly architected solution could face many difficulties in scalability and extensibility.
• It ensures that all processes are creating value for the customer, reducing wasted time and effort spent on activities that yield no added value.
• It introduces a well-established mechanism to document the key solution artifacts, reducing the time and effort wasted on extensive documentation with low business value.

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.

I always used to say to my mentees that you cannot just pull a solution out of the air. You have to roll up your sleeves and try things out on the ground. You are lucky to deal with a platform that allows you to try out 70-80% of the features before committing to a proposal.

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:

• Understanding what you should be able to do as a Salesforce solution architect
• Introducing the solution architecture domain mini hypothetical scenario: Packt visiting angels
• Selecting the appropriate functionalities to build your solution and presentation

Understanding the Role of a Salesforce Solution Architect

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:

• Select the right combination of declarative and programmatic functionalities
• Augment your solution with the right external applications

Now have a closer look at each of these objectives.

Select the Right Combination of Declarative and Programmatic Functionalities

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:

• Understand the different mechanisms to import leads to the platform, including the import wizard.
• Understand the different out-of-the-box capabilities for lead deduplication and for deduplication in general, regardless of the object.
• Understand how other products could integrate with the core cloud to capture and import leads.
• Understand the typical activities included in lead management business processes, such as lead auto-responding, lead nurturing, lead assignments, and more.
• Understand some fundamental principles behind planning and setting up marketing campaigns.
• Have hands-on experience working with the standard Salesforce sales and marketing object, and familiarity with how to utilize additional products such as Marketing Cloud and Pardot to execute marketing campaigns.
• Understand how to set up recurring and automatic tasks related to leads and other objects.
• Understand how to use the Product, PriceBook, and PriceBookEntry objects and how to use them to model the items/services to sell.
• Have practical experience in the entire lead-to-opportunity conversion process, including the details on how the opportunities get assigned upon conversion. Furthermore, you need to understand how a sales rep can use the Opportunity object and supporting objects such as the quote to drive the sales process.
• Understand the process of opportunity closure and what activities are typically executed before and after an opportunity closure.

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.

Augment Your Solution with the Right External Applications

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:

• Cost and time-to-value: The cost of a custom-built solution could become unpredictable depending on many factors, including complexity and resource availability. Moreover, a custom-developed solution tends to require much more effort to design, plan, test, and deploy.

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.

• Maintenance: Salesforce is offered as Software as a Service (SaaS). It is fully managed software where most of the maintenance overhead is handled by the vendor. The core cloud has three yearly releases. Each includes updates that could impact custom-developed code built on top of the core cloud.

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.

• Scalability: The tools are only as good as the people using them. The quality of the custom-developed solution is hugely impacted by the team designing and developing it. There are several solutions that operate as expected under normal circumstances but fall apart whenever they are challenged to scale up or get extended.

Software development houses have frameworks, methodologies, regulations, and processes tailored to deliver high-quality, scalable, configurable, and extendable software products.

• Quality and peace of mind: Most enterprises are looking for battle-tested solutions, especially for mission-critical processes. A product that has been successfully delivered several times to other customers, especially in the same industry, can give a high level of confidence.

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:

• Avoid proposing to build a custom CPQ solution. There are plenty of great solutions available on the market, including one from Salesforce itself (Salesforce CPQ).
• Avoid proposing to build a custom Field Service solution. Such solutions are complex and will take years to mature if custom developed. There are plenty of capable Field Service solutions on the market including Salesforce Field Service.
• Avoid proposing to build a custom solution for complex contract lifecycle management (CLM) requirements. Salesforce comes with simple capabilities in this field out of the box, and you can surely invest time and money in developing a custom solution either on top of the force.com platform or completely off-platform. But it will take considerable time and effort to get a custom-developed product to the level of maturity expected by an enterprise. There are several mature products on the market, such as DocuSign CLM.
• You can propose building a custom LWC to use as a data entry tool to increase users’ efficiency.
• You can extend out-of-the-box Salesforce capabilities such as opportunity management and case management with custom modules using additional objects, fields, flows, workflows, Apex, and other platform tools.

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.

Introducing the Solution Architecture Domain Mini Hypothetical Scenario: Packt Visiting Angels

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.

Scenario

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).

Current Situation

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.

Requirements

PVA has shared the following requirements:

• Leads are normally gathered via three channels. These are web forms, third-party providers, and being manually created by the marketing team. PVA wants to ensure that the gathered leads are unique, where no more than one lead per company, per drug, and per country should be open at the same time.
• Leads that are not created manually should automatically be assigned to a country’s marketing team based on the geographic location (country). Leads can have only one associated country.
• Once the lead is assigned, it goes into multiple stages. At each stage, a set of activities is expected to be completed by the lead owner.
• Once the lead is qualified, it must be converted into an opportunity and automatically handed over to the country’s sales operations team. One of the team members (a sales operations agent) should pick up the opportunity to develop it further.
• The sales operations agent will follow up with the deal. The agent should be able to create quotes and negotiate them with the client.
• Once a quote is accepted, the agent updates the opportunity to the contracting stage. Once that is done, the system should automatically generate a contract record using the opportunity information.
• 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. The contract should be presented in the local language of the target country.
• 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.
• The agent should update lost opportunities to the closed-lost stage manually and set a reason for the loss.
• Once the opportunity is closed-won, a project that contains key information derived from the opportunity should be created automatically. Only the nurses in the target country and their managers should be able to view the project details.
• The solution should provide the nurses with their daily optimized visit schedule. This schedule should aim at giving the nurses the opportunity to visit as many sites as possible during their working hours.
• Once the opportunity is closed, lock all the opportunity fields for all users except the administrator and the opportunity owner.
• Opportunity line items’ fields should also get locked. No products can be added, edited, or deleted once the opportunity is closed.
• 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.
• After seven days, all fields should be locked for all users except the administrators.
• If a high-value deal is closed and lost, send an email to notify the sales agent’s manager. The email should include the opportunity name and amount. Create a follow-up task due in 10 days assigned to the sales agent’s manager to review the reasons for loss with the agent.
• The system should support both euro and pound sterling currencies with dated exchange rates.

PVA is looking for a proposed solution that can increase their internal teams’ efficiency and reduce manual errors using Salesforce.

Selecting the Appropriate Functionalities to Build Your Solution and Presentation

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.

Understanding the Current Situation

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.

Diving into the Shared Requirements

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:

• Using custom-developed Apex code and a trigger: Custom-developed code gives you ultimate control of the deduplication logic, but it must be built correctly to ensure optimal performance. Moreover, it is an expensive solution considering the required efforts.
• Using a third-party solution: There are several third-party products that can be integrated with Salesforce, including some solutions from AppExchange (such as Cloudingo and RingLead). They provide advanced configurable capabilities and are optimized for performance. However, they require additional licenses. This is a good option if there is no out-of-the-box Salesforce functionality that can fulfill the requirement.
• Creating a hidden unique custom text field: The field needs to be configured as a unique external key followed by auto-populating it with the concatenated values of the lead attributes. Because the field is unique, it will prevent the creation of other lead records with the same concatenated values. Once the lead is closed, you can automatically empty this field, which will ensure that other similar leads can be created in the future.

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.

• Using Salesforce duplicate rules: This is a standard out-of-the-box functionality that utilizes configurable matching rules. It gives the flexibility to define different actions when a duplicate record is found, such as preventing a new record from being created or allowing it with a prompt. It has its limitations as with any other tool, but it should be good enough to fulfill this requirement.

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:

To fulfill this requirement, I propose using the standard Salesforce deduplication rules. I will create a custom matching rule that relies on the company, drug, country, and lead's status fields. I would set the deduplication rule to prevent creating a lead record if a match was found. I do not believe there is a need to use a third-party solution as this requirement can be fulfilled using an out-of-the-box configurable feature. This is also why I have disregarded using a custom Apex-based solution for it. I assume that the leads created via web forms would be using the web-to-lead functionality, and third-party leads are uploaded manually via the import wizard.

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:

I will utilize the standard lead assignment functionality to assign the lead to the country’s queue based on the country’s field value.

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):

• Flows: Salesforce Flows can be used to execute complex logic upon creating or updating a record. This is a configurable and scalable tool that can deliver the desired functionality. Moreover, it is a modern tool that Salesforce is actively enhancing with each release. Clearly, it has a better chance of receiving more future enhancements than any other tool on this list.
• Custom Apex code: This gives the ultimate capability and flexibility but with unjustified additional development and maintenance costs.

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:

I propose utilizing the lead process functionality to define multiple lead processes with different lead statuses. Then, create a Salesforce record-triggered flow to automatically create tasks and assign them to the lead owner upon updating the lead to a specific status. The flow can be configured to utilize criteria-based branching logic, and this will allow us to create a different set of tasks depending on the lead status.

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 scenario did not specify whether the conversion has to happen automatically; therefore, I am assuming it is done manually by the lead owner. Once the lead is converted into an opportunity. I will utilize a Salesforce record-triggered flow to set a sales agent from the target country as the owner of the opportunity. I am assuming that there is a pre-defined user specified for each country. The flow will also add the country’s sales operations users to the opportunity team. I am also assuming a limited set of users per country.

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:

The sales agents will be assigned a Sales Cloud license; this allows them to create and update quotes. This is standard Salesforce functionality.

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:

There has been no requirement shared about advanced contract creation functionalities. Therefore, I am assuming a simplified solution that utilizes a Salesforce record-triggered flow to automatically create a contract once the opportunity is updated to the mentioned stage.

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:

To fulfill this requirement, I propose using a third-party application from AppExchange, such as DocuSign. This will allow selecting the right contract template with the appropriate language before sending the contract over to the customer. The tool will also allow the selection of suitable terms and conditions to include in the contract.

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:

This capability is built into the proposed e-signature solution. Using DocuSign, you can update the contract status once the document is signed. Then, you can use a Salesforce record-triggered flow to update the opportunity stage back to closed-won. The flow will kickstart once the contract status is updated.

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:

To fulfill this requirement, I propose introducing a custom picklist field with predefined values for the possible reasons for losing an opportunity. Then, utilize the standard field dependency feature to make this field dependent on the opportunity stage value. I also propose introducing a custom validation rule to ensure a value is always entered in this field when the opportunity is updated to the closed-lost stage, regardless of whether the update took place via the UI, code, or an API call.

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:

To fulfill this requirement, I propose to use a custom object to store the project details and use a Salesforce record-triggered flow to create and populate a record of this object once the opportunity is closed. I considered using one of the standard objects, such as the case object, to represent a project but decided to use a custom object as there were no shared requirements that justify using the case object, such as SLA requirements or escalations. Moreover, I assumed that the case object might be utilized for customer support-related topics in the future and preferred not to repurpose it.

The custom object’s OWD will be set to private to restrict the record visibility to its owner, which by default will be the sales agent. Considering that the record will be created upon closing the opportunity, which is an action carried out by the sales agent, I assumed that it is acceptable to keep this record visible to the sales agent.

I propose introducing a role hierarchy to include the nurses and their managers. Then, use criteria-based sharing rules to share the project record with the nurses, granting their managers automatic access.

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:

To fulfill this requirement, I propose using Salesforce Field Service. It provides the ability to create an optimized schedule for nurses based on multiple factors, such as the geographic site location, the required skills, the nurse’s work hours, and many more.

In the actors and licenses diagram, I assumed that the nurses would be assigned a Field Service Technician (Mobile employee) license. This will allow them to log in to Salesforce and view their optimized schedule.

I also assumed that there would be one or more users managing and creating the optimized nurses schedule. I called this actor in my diagram a nurse manager. The nurse managers would need a Field Service dispatcher license to use the Field Service scheduler and dispatcher console.

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:

• Use custom validation rules: They can be configured to trigger upon attempting to save an edited record. However, they do not prevent the user from attempting to edit the record. They will fire only upon attempting to save the record. If you are going to use validation rules, you need to come up with an efficient way to prevent editing the record’s fields. You cannot simply list every single field in your validation rule.

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.

• Update the record type upon closing the opportunity: A flow can be used for this job too. You can then assign a page layout with read-only fields to that record type. Some fields cannot be set to read-only, such as name, currency, closed date, stage, and some others. This solution also does not prevent the record from being edited via code or an API (for example, via a data loader). You should consider this solution as complementary to other approaches but not as a comprehensive solution on its own.
• Use Apex validations in a before-update trigger: This gives you the ultimate capability and flexibility, but with additional development efforts. This approach will also cause a loss of agility as any future changes would require code edits. You should consider this option only for sophisticated use cases.
• Lock the record via an approval process: You can lock the record completely using an approval process. However, note that only the administrator or users with Modify All access can edit the record in this case, which does not meet the requirement.

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:

To fulfill this requirement, I propose introducing a custom field to store the opportunity’s locked date. A Salesforce record-triggered flow can be used to set the value of that field upon closing the opportunity. I propose using a custom field instead of the standard opportunity close date field because the latter’s value could be used for other purposes.

You can then introduce a custom validation rule on the Opportunity object. The validation will ensure that no one can modify the opportunity record. An exception is provided for the opportunity owner for up to seven days and only when attempting to update the description field. This can all be achieved by configuring the right logic in the validation rule.

I also propose introducing custom permission to bypass this validation and assign it to the administrator. The validation rule will check whether the executing user has that permission or not. This will give us the flexibility to assign this permission to other users in the future if needed.

A similar validation rule will be introduced on the opportunity line item object, which will check the same custom field on the Opportunity object and have a similar bypass mechanism for administrators.

Finally, I propose using a record-triggered flow to update the opportunity’s record type upon opportunity closure. You can assign a page layout with read-only fields to this record type. This will give a better and friendlier user experience.

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:

For this requirement, I propose enabling the advanced currency management feature in Salesforce. Then, enter the suitable dated exchange rates.

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.

Summary

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.

Chapter Review Flashcards

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:

1. Open your web browser and go to https://packt.link/ctach8. You will see the following screen:

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

2. Log in to your account using your credentials. If you haven’t activated your account yet, refer to Instructions for Unlocking the Online Content in the Preface for detailed instructions.

After a successful login, you will see the following screen:

Figure 8.12 – Chapter summary and end-of-chapter flashcards

3. Click Start on a flashcards stack to begin your review.