14

Practice the Review Board: Second Mock

In this chapter, you will put all the knowledge you have learned from the past chapters into action. You will be introduced to this book’s second full mock scenario, which is close to a real scenario you may encounter in the review board.

After reading this chapter and the next, you are advised to reread the scenario and devise a solution on your own.

You can repeat that as many times as needed until you feel comfortable. Try to stick to the three-hour solving window. You will learn some handy time management techniques in Appendix, Tips and Tricks, and the Way Forward.

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

• Introducing the full mock scenario: Packt Lightning Utilities
• Analyzing the requirements and creating a draft end-to-end solution

By the end of this chapter, you will be familiar with the intricacies of a full mock scenario, which will help you prepare for the actual exam. You will have also learned how to create an end-to-end solution for the business processes in a scenario. Without further ado, it’s time to have a look at your second full mock scenario.

Introducing the Full Mock Scenario: Packt Lightning Utilities

Packt Lightning Utilities (PLU) is a European utility company that serves cities across Germany, Italy, France, Portugal, Belgium, and the UK. PLU operates in 40 cities. They offer services to both B2C customers (residential) and small and medium B2B customers. They offer a wide range of services related to electricity and natural gas distribution. They currently serve more than 6 million households and over 700,000 small business accounts.

PLU has been struggling with its existing CRM solutions for many years and, as a new strategic movement, has decided to switch to Salesforce. PLU is looking to use its new CRM to launch a new set of unified global sales and service processes. This is part of a bigger digital transformation that PLU is undertaking to become a more customer-centric organization.

The new services should offer the most modern customer experience and maintain an overall low-cost-to-serve operating model. They also plan to use the new CRM to manage a close and special relationship with their most valued B2B customers and boost the performance of their field sales and field service teams.

PLU has a centralized service support center that offers multilingual support for all countries covered. However, the cost to serve has historically been too high in the last three years and PLU would like to explore the possibility of introducing additional modern service channels.

Project Overview

There are multiple types of employees who require access to the system:

• Key customer managers: They manage the relationship with the key B2B customers and are organized by region. Each country contains multiple regions. The key customer managers report to the country’s VP of key customers, who, in turn, reports to the global senior Vice President (SVP) of key customers.
• Support agents: They operate from a central call center. They serve both residential and business customers. Agents are organized into teams depending on the languages they support. Some agents are multilingual. They all report to the global SVP of service.
• Field sales agents: They operate in specific regions in each country and are mainly responsible for developing the B2B business. They regularly visit existing and potential customer sites and try to generate new and renewal deals for PLU. They report to the region’s director of sales, who, in turn, reports to the country’s VP of sales.
• Field service technicians: They operate in specific regions in each country and are responsible for collecting meter readings and fixing reported minor issues with residential and business customers. They report to the country’s VP of service, who, in turn, reports to the global SVP of service.
• Marketing team: They are responsible for generating more leads by executing marketing campaigns to attract and retain B2C and B2B customers. They segment customers and send mass marketing emails. There is a marketing team in each of the countries covered that reports to its VP of marketing. Marketing and sales VPs report to the global SVP of sales and marketing.
• Maintenance partners: PLU works with a network of over 500 maintenance partners across Europe. They handle fixing incidents related to energy supply. Each partner is associated with one or more regions within a country.

Residential customers can have up to two contacts per property and be related to more than one property. On average, residential customers are subscribed to 1.5 different services per account/property. Business customers can have up to five contacts per account and typically have several related properties. More than 80% of business customers are subscribed to both electricity and gas.

PLU has historically received an average of three service requests per customer annually. Legally, they should keep two years’ worth of data such as meter readings and service requests. PLU is expecting its future system to support the local language of operating countries. Now, you can delve into the landscape of PLU.

Current Landscape

PLU is currently using the following systems:

• Country ERP: PLU uses a different ERP system for each country. All these systems except Belgium’s ERP have SOAP-based APIs. Belgium’s ERP is old and based on a flat-file database. It does not offer any APIs and does not support any database adapters. However, it can connect to SMTP servers. PLU would like to retain all ERPs and integrate the new CRM with them.
• Power Sales: This is a heavily customized third-party solution. It is currently used to calculate the tariffs, discounts, and bundles for electricity and gas offers. This system offers a poor API, which is difficult to modify. However, PLU still plans to use it for the coming five years. It has recently signed a maintenance contract with the vendor.
• Radar reader: This is a device that is used to read older-generation meters remotely. It operates within a range of 20 meters and sends a wake-up radio signal to the meter to instruct it to power up and transmit its data. This device supports corded and Bluetooth communications. PLU would like to continue using these devices to read older-generation meters.
• Smart meters: These are the new version of meters. They can transmit their readings directly to a centralized server. In addition, they can also receive data and signals from the server. PLU deals with four different smart meter vendors; each provides its own SaaS cloud-based solution to manage smart meters remotely. All smart meter platforms have REST APIs.
• Legacy CRM: PLU has a different CRM per country. One of them is based on a legacy XML file storage system with poor data quality. The others are all based on MS SQL Server. However, they have different data models and are developed by different vendors. PLU is looking to retire all these systems and replace them with a unified Salesforce-based solution.
• PDF Generator: This is a third-party application that is used to generate PDF versions of invoices. It has bespoke PDF-generating capabilities and offers a rich API. Generated PDFs will be stored temporarily in a related SSH file transfer protocol (SFTP) storage. The application automatically deletes files that have been stored on the SFTP for more than 24 hours.

PLU shared the following business process requirements.

Business Process Requirements

The following sections explain the business processes that PLU expects to have in its new system.

Key Customer Management

PLU needs to maintain a special relationship with its key business customers. The new system must meet the following requirements:

• Key customers are small or medium businesses that consume more than 50,000 kWh of electricity annually at one of their sites. Key business customers usually have between 5 and 15 sites/properties across the country.
• PLU would like the system to regularly identify new key customers and enroll them automatically into a special nurturing program. If any site is consuming more than 5,000 kWh for three months in a year, the enrollment team should be notified. The enrollment team consists of the country’s VP of key customers and the relevant regions’ key customer managers.
• The enrollment team should start the enrollment process. The first stage is to define a leading key customer manager to start the negotiations with the customer. Multiple tailored tariffs and offers could be shared with the customer. These offers should be generated by Power Sales. PLU would like to get a recommendation for the best way to facilitate this without impacting its employees’ efficiency.
• By the end of this process, the customer could be switched to a different, more business-oriented tariff and a new contract should be signed.
• PLU would like to streamline the process by introducing a digital signature. Once the document is signed, the contract is updated, and the process of switching the customer to the new tariff should start.
• The new contract details are sent to the country’s ERP, which facilitates the switching process. This can take up to 48 hours. Once the process is done, the customer and key account managers of the relevant regions should be notified.

PLU shared the following requirements for the customer service process.

Customer Service

PLU is looking to expand the number of support channels. Furthermore, they are looking to introduce a more governed and standardized way of handling their customers. The new system must meet the following requirements:

• All customers should be able to create inquiries or complaints using a self-serve customer portal or by calling the call center. These requests should be assigned to the right agent based on multiple factors, including language, incident type, and customer type.
• If a complaint is not resolved within seven days, the SVP of the service should be notified.
• The system should automatically generate a forecasted meter reading for the next month based on the previous month’s reading.
• The forecasted and actual electricity and gas consumption for every site should be displayed in the customer portal. The data should cover the last 24 months. Customers should also be able to view their past invoices and payments and should be able to view a PDF version of their invoices.
• If an energy failure is reported, a critical incident should be created and assigned to the right maintenance partner based on the property’s address. All customers in the impacted region should receive an SMS and email message upon incident creation, status update, and incident resolution.

PLU shared the following requirements for the scheduled manual meter reading process.

Scheduled Manual Meter Reading

The manual meter reading process is still required for older meter models. PLU shared the following requirements:

• Manual readings are expected to be taken every quarter. In some countries, this must happen every month due to regulations. The field service technicians drive or walk by the residential house or the business establishment and use the radar reader devices to identify nearby compatible readers served by PLU.
• The radar reader device has a screen that displays the meter ID of nearby PLU-served meters. The device can communicate with the meters to get their readings. The radar reader is not connected to the internet. However, it can be paired with a nearby Bluetooth device.
• PLU would like the radar reader devices to be paired with the field service technician’s mobile phone, then use the phone to send the reading data to Salesforce.
• PLU is looking to optimize the visiting time and travel costs for their field service technicians.
• At any given time, PLU would like to track the location of its field service technicians.

PLU shared the following requirements for the scheduled automatic meter reading process.

Scheduled Automatic Meter Reading

The automatic meter reading process is most commonly used across different sites/properties. PLU shared the following requirements:

• Smart meters are widely used across the countries covered. However, PLU has worked with four different vendors during the past three years. Each provided and installed their own smart meter devices. Each vendor has a different cloud-based platform used to control and communicate with the meters. The last three months’ meter readings are also stored on these platforms. PLU currently has subscriptions to all four cloud-based platforms.
• Smart readers must be read monthly. Two of the device models can push data periodically to a server. All models support pull operations. PLU is looking to unify the way it retrieves the smart meter data from all its vendors. All four platforms offer a rich set of SOAP and REST APIs. They offer web services that can be used to pull the meter readings from a smart meter. In addition, two of them also offer a pub/sub interface that allows a real-time recipient of meter readings.

PLU shared the following requirements for the customer registration process.

Customer Registration

The customer portal represents a significant part of PLU’s strategy to modernize customer service. They shared the following requirements for customer registration:

• Customers cannot self-register in the community except via invitation. The B2C customers’ access to the portal should be generated after signing up for a PLU service.
• PLU would like to expose its products to unauthenticated users via a public website. The users can subscribe online to PLU’s service by providing information such as the number of households, expected power consumption, and address details. The system should automatically determine and display the right tariff for the customer. PLU is expecting this to happen via integration with Power Sales. The UI should be responsive to both browsers and mobile phones.
• The customer should be able to confirm the tariff. This should generate the necessary objects in Salesforce to store the customer and contract details. Furthermore, user access to the customer portal should be created.
• Upon the creation of user access, the customer should receive an email notification to set a password. The password must meet strict complexity requirements.
• Once logged in, the customer should be able to view their contact and contract details. Customers should be able to log in to the portal using a PLU-branded mobile application as well.
• Customers should be able to invite one more contact to the portal to co-manage a particular property and contract.

PLU shared the following requirements for the field sales process.

Field Sales

The field sales process is essential to develop the B2B business. PLU shared the following requirements:

• The field sales agent visits a potential B2B lead and walks them through the different offers available using a handheld tablet. PLU would like to track all activities done with the client, even if the client decided not to use PLU’s services.
• Three days after completing the visit, an email survey should be sent to the B2B customer’s primary contact. Two different survey templates should be used, one for successfully signed deals and another for lost deals. If the field sales agent’s score is below 3 out of 10, a case should be automatically created and assigned to the field sales agent’s manager.

PLU shared the following data migration requirements.

Data Migration Requirements

Considering the previously shared information about the current landscape, PLU shared the following data migration requirements:

• PLU has over 80 million customers in its legacy CRMs. The data is expected to contain a significant number of duplicates. The number of unique active customers is likely to be in the range of six million. PLU would like to migrate active customers only to Salesforce. PLU would like to understand how they can deduplicate the migrated records and link them with their corresponding ERP records, knowing that the same duplication also exists in the ERPs. There is no plan to do any significant data cleanup in the ERP.
• The legacy CRMs have details for over 200 million meters. The vast number of records is due to significant record redundancy. The actual number of meters to migrate is expected to be less than 10 million. PLU would like to clean up the data and maintain a single record for each meter to develop a 360-degree view of assets.

PLU shared the following accessibility requirements.

Accessibility and Security Requirements

PLU is looking for guidance to design a secure solution. They shared the following requirements:

• Key customers and their meter readings are only visible to the key customer manager, who manages that customer and their managers, except for support agents, who can view all accounts in the org.
• The key customer manager should be able to delegate the visibility of a customer account to another manager for a specific period. Once that period is up, the record should not be visible to the delegated manager anymore.
• A complaint is only visible to the agent who is managing it and their manager. PLU would also like to define a set of super users who can view all complaints in the system.
• Inquiries should be visible to all support agents.
• The maintenance partner records should be visible to the support agents only. However, they should be editable only to the support agent who manages the direct relationship with that partner.
• B2B customers should be able to manage all properties and meters related to their account.
• B2C customers should be able to manage all their related properties. It is common to have a B2C customer associated with more than one property.

PLU shared the following reporting requirements.

Reporting Requirements

PLU requested a rich set of reporting capabilities, which include the following:

• The global SVP of service would like a report showing service requests handled by the maintenance partners for a given year compared to data from the past four years.
• The global SVP of service would like a dashboard showing the number of inquiries and complaints received and resolved broken down by country and region. The dashboard should indicate the number of incidents resolved within the target timeframe versus those that ran over.
• Key customer managers would like a set of business intelligence reports showing business improvements gained by switching key customers from the previous tariffs to new tariffs.
• PLU would like to offer their customers a dashboard showing the change in their consumption across the past two years.

PLU shared the following project development requirements.

Project Development Requirements

Considering the complexity of PLU’s program, they have requested the following project development requirements:

• PLU would like to start realizing value quickly and get Salesforce functionalities as soon as possible.
• The team maintaining the ERPs works in a six-month release cycle, and they are unable to modify their timeline to suit this project.
• Historically, the customer support team is used to high-productivity systems, and they have a regulatory requirement to handle calls in no more than 10 minutes. They desire a similar experience in Salesforce.
• PLU would like to get support in identifying potential project risks.
• PLU would like to have a clear, traceable way to track features developed throughout the project life cycle.
• PLU is looking for recommendations for the right environment management strategy to ensure the proper tests are executed at each stage. PLU is keen to understand how to ensure the reliability of its integration interfaces.
• PLU is looking for an appropriate methodology to manage the project delivery and ensure proper technical governance.

PLU also shared the following other requirements.

Other Requirements

PLU’s business is growing, and they are looking to expand to the renewable energy business. They shared the following requirement:

• PLU has recently acquired a company working in renewable energy. They manufacture and install solar system panels as well as electric batteries. The acquired company is also utilizing Salesforce as its central CRM. PLU would like to know whether they should plan to merge this Salesforce instance with theirs or keep it separate and are looking for your support in this decision.

That concludes the hypothetical scenario. Ensure you have gone through all the pages and requirements of your hypothetical scenario before proceeding further.

Start identifying requirements and create the draft solution following the same methodology you used in previous scenarios.

Analyzing the Requirements and Creating a Draft End-to-End Solution

Give yourself enough time to go through the scenario and understand the big picture. You can even start adding notes with potential solutions.

Similar to what you experienced in Chapter 12, Practice the Review Board: First Mock, and Chapter 13, Present and Defend: First Mock, the solutioning and presentation creation activities will be split over two chapters. This is due to the size of the full scenarios and the number of shared requirements. You will cover the business process requirements in this chapter. Then, in the next chapter, you will continue with the remaining requirements and create the presentation pitch.

As you did in all previous mocks, start by understanding the current landscape and creating the first draft of the diagrams.

Understanding the Current Situation

Starting with the first set of paragraphs, you can find a description of PLU’s activities and geographical presence. You will also encounter a description of the actors, their activities, and to whom they report.

By merely following the description in this section, you can understand the potential role hierarchy. You might also consider using enterprise territory management. However, using a role hierarchy for this scenario is much simpler. It is always better to avoid complications.

Note

You can learn more about enterprise territory management at the following link: https://packt.link/URbEf.

You can learn more about using a role hierarchy at the following link: https://packt.link/lzXI5.

At this stage, you might be able to create the following draft role hierarchy:

Figure 14.1 – Role hierarchy (first draft)

Considering the shared info, you can also plan some targeted licenses for the actors. The following section explains this.

Determining the Actors and Licenses

PLU shared a brief description of the foreseen actors and their activities. You can use that to generate an early draft of their required licenses. During the presentation, you will also need to explain the rationale behind the suggested licenses. For this scenario, this could be something like the following:

• Field sales: Considering they need to deal with B2B customers and create new and renewal deals, they would likely need to work with the Account, Opportunity, and Contract objects. The Sales Cloud license seems like a good fit.
• Support agents: Considering they need to handle different incidents and that you would likely end up using the Case object to model an incident, they might need a Service Cloud license. In fact, many other licenses can work with the Case object. However, the scenario also mentioned that support agents are divided into teams based on their skills. This could be achieved using either queues or Omni-Channel. The support agents will need the Service Cloud license if you end up utilizing Omni-Channel. Therefore, assume this license for the time being. Call centers might also require some CTI capabilities. Pencil in the Service Cloud Voice license for the support agents.
• SVP of service: These actors will likely need the same license as the support agents, considering that they need access to the same objects.
• Marketing team: Considering they need to generate and nurture leads, they need a Sales Cloud license. They also need to segment customers and send them mass emails. The ability to mass email 6 million customers is not a capability to be solved using Salesforce Core. There are several other mass email tools. Salesforce Marketing Cloud integrates very well with Salesforce Core Cloud. Assume a Marketing Cloud license for the marketing team members as well.
• SVP for sales and marketing: There are not many details about the activities of this role. But assuming this role will need access to the same objects and tools used by the sales and marketing teams, it will need Sales Cloud and Marketing Cloud licenses.
• Key customer manager: Considering that this actor needs to interact with B2B customers and generate new deals with them, there will likely be a need to interact with the Opportunity object. The Sales Cloud license seems like a good fit.
• SVP of key customers: Assuming this role will need access to the same objects used by the key customer manager, you can assume it will also need the Sales Cloud license.
• Field service: This actor needs to collect readings and fix minor issues. Issues here could be another name for incidents, which you are likely to use the Case object with. Assume this actor will need the Service Cloud license. You should also pay attention to the field actors as they might indicate a need for additional solutions to help them execute their field visits, such as Salesforce Field Service. Pencil in that license for this actor and adjust it later if needed.
• Maintenance partners: Partners usually do not use any of the internal Salesforce licenses. In most cases, they would need a Partner Community or a Customer Community Plus license. At this stage, you cannot determine which one would be more suitable. Assume the Partner Community license for the time being.
• Customers: Customers need access to an online portal where they can manage their account details. Considering that you have around 6 million customers, you should have no second thoughts about the required license. This actor will use a Customer Community license, whether it is a login-based or named-user license.

Your actors and licenses diagram could look like the following:

Figure 14.2 – Actors and licenses (first draft)

You have a good idea of some of the objects that you might end up using. Use that to create the draft data model.

Creating the Draft Data Model

PLU shared an interesting statement, suggesting a need for a complex account model to achieve such behavior. The statement starts with the following:

Residential customers can have up to two contacts per property and be related to more than one property.

This indicates that the same customer can be linked to multiple properties. Moreover, up to two customers can also be related to the same property. Knowing that you are planning to use the Customer Community license and understanding its limited sharing capabilities, you have the following challenges:

• How are you going to model the property? Will you use the Account object or a Custom object?
• How are you going to model the customers? It is easy to assume using Person Accounts, but how can you relate multiple person accounts to multiple properties?
• How can you ensure that you can control user visibility using Sharing Sets (the sharing mechanism available for the Customer Community license)? You have not reached that requirement yet, but it is obvious that customers should only be able to see the properties they are related to.
• How can you model other data, such as the Contract, Meters, and Meter readings, so that they are visible to the user who has access to the Property record?

Some of these questions can impact the potential ways you solve others.

This is a critical requirement. This is one of those that could make things trickier if not solved right in the first place.

Salesforce has made a lot of improvements in the past few years to support such use cases. It introduced the AccountContactRelation object, which allows contacts to be linked with multiple accounts. It also updated Sharing Sets to allow record sharing based on the AccountContactRelation object. This was a massive boost to the Communities’ sharing model at that time.

Based on that, you can model the data to utilize Person Accounts, AccountContactRelation, and a custom record type of the Account object to represent a Property. This will allow you to use the Contract and Asset objects to describe a particular deal with the customer and the related enabled services (for example, electricity).

The following diagram represents a data example of how the account structure would look for B2C customers:

Figure 14.3 – Example of B2C account structure data

When you come across such a crucial data-modeling requirement, do not hesitate to check the Accessibility and Security Requirements section to ensure your model will fulfill the requirements related to Community Cloud users.

In that section, you will also notice a need for B2B customers to manage multiple properties. Following the same principles, you can come up with the following data example of the proposed account structure for B2B users:

Figure 14.4 – B2B account structure data example

It is beneficial to create such supporting diagrams for your presentation. You can create whatever diagrams will help you further explain your solution. Just remember to stick to standards while creating any additional diagrams. The data example diagrams could help you put your thoughts in order and imagine how the solution will look.

Now that you have arranged your thoughts, create a draft data model using the objects you plan to use:

Figure 14.5 – Data model diagram (first draft)

At this stage, you are just creating sketches and drafts. Do not concern yourself with tidying up your diagrams. You can take care of that later. One other interesting paragraph starts with the following:

On average, residential customers are subscribed to 1.5 different services per account/property.

Note

Take note of these numbers and keep an eye on them. By now, you should know the importance of such numbers in a scenario.

Finally, have a look at the landscape architecture.

Compiling the Current Landscape Architecture

This part is straightforward. PLU shared a set of systems that are used today. You know that the Salesforce Core Cloud (also known as the Force.com platform) will be at the center of the proposed solution. If you put all of that together, you get the following diagram:

Figure 14.6 – Landscape architecture (first draft)

Now that you have developed an understanding of the current situation and potential solution, proceed with analyzing and solutioning the shared requirements.

Analyzing the Business Process Requirements

PLU shared six key business processes. This part of the scenario usually contains the most significant chunk of requirements. You are strongly advised to create a business process diagram for each of these processes. This will help you spot the tricky parts of the solution and will also give you an engaging and attractive tool to use during your presentation.

Start with the first shared business process.

Key Customer Management

PLU shared five key requirements for the key customer management process, as the first bullet point is just a definition of this type of customer. You will go through each of the shared requirements and analyze and solution them. By the end of this exercise, you will have a business process diagram that can help you explain the end-to-end solution. Now, start with the first requirement.

PLU would like the system to regularly identify new key customers and enroll them automatically into a special nurturing program.

The three questions that might immediately come to your mind are as follows:

• How can you execute a process to scan and evaluate customer consumption regularly?
• How do you model the monthly consumption considering that there are 6 million B2C customers and 700,000 B2B customers? You do not know how many properties you have for each group, but you know that key customers have between 5 and 15 sites/properties.
• What would the enrollment process look like? What objects would they use?

The first question is the easiest, as you can simply use a Batch Apex class or a Schedule-Triggered Flow. However, depending on how you model your data, even a Batch Apex could perform poorly with such an amount of data.

The second question is critical. It is another example of a data model-related design decision that could impact many other things. Pay extra attention to such requirements. Start by exploring the common and most straightforward option of modeling monthly consumption as a normalized third normal form (3NF). As a reminder, you covered the three primary normal forms in Chapter 2, Core Architectural Concepts: Data Life Cycle. The following diagram illustrates what the data would look like:

Figure 14.7 – Modeling the meter readings using the 3NF

You can see that using the 3NF here will create 12 records every year for every asset. You need to validate this design by doing some math.

There are six million B2C customers. On average, half of them have subscriptions to both electricity and gas. This is nine million potential assets (based on your plans to use the Asset object to represent a customer’s subscription to a service via a meter).

There are also 700,000 B2B customers. You do not know how many of them are key customers, so you need to assume a reasonable percentage. Assume that 25% of the B2B customers are key customers, which is 175,000.

You know that 80% of B2B customers are signed up for both electricity and gas. Moreover, you know that key customers will have an average of 10 properties. That means you have around 3,150,000 assets used for B2B (around 945,000 for regular B2B customers and 2,205,000 for B2B key customers). In total, you have approximately 12,150,000 assets.

In a 3NF, you will get 12 records annually per asset. That is nearly 146 million records. Around 38 million of them belong to B2B customers. Any batch job that attempts to deal with this number of records would experience performance challenges.

A potential solution would be to shift all the meter reading data to an external platform such as Heroku and develop the logic that triggers the enrollment process there as well. But then you will come across other challenges related to data visibility and access management.

An alternate solution would be to use a denormalized object to store each meter’s monthly readings (or even for multiple meters if the business has a maximum limit). The following diagram is an illustrated data example:

Figure 14.8 – Modeling the meter readings using a denormalized object

You can even extend the Asset objects with these additional fields unless you want to keep more than one year’s worth of data in Salesforce, which is the case here (there is a requirement to keep up to two years’ worth of data in the system). You can even make the batch query simpler by introducing a formula field on the Meter_Reading__c object that determines whether any of the three meter readings in the year are above the given threshold or not.

Denormalized objects have their limitations and challenges, but they have their strengths and useful use cases as well. You can propose such an approach if you have a reasonable justification.

Now, on to the third question, which is about how you can model an enrollment process.

Is there a standard object in Salesforce that allows you to run a sales process with existing clients that involves multiple stages and activities? That is, is there an object that enables a set of sales-related capabilities, such as sales teams, reports, and forecasts?

You guessed right! You can use the Opportunity object to model such sales processes.

If you put this solution together, you are planning to use a batch job to query the new denormalized Meter_Reading__c custom object. If certain conditions are met, create an Opportunity and assign the right Opportunity team members to it based on the relevant regions. This task looks too complicated for a Flow, so you can use a Batch Apex (the complexity justifies it).

Update your data model and business process diagrams, then move on to the next requirement, which starts with the following:

The enrollment team should start the enrollment process.

Determining the leading key customer manager can be done manually. By the end of that process, that user would own the customer account record. The requirement also indicates a need to negotiate different offers and tariffs with the customer. This is a common use case for the Quote object, and the entire requirement is ideal for Configure, Price, Quote (CPQ). The challenge here is that PLU insists on using Power Sales as the CPQ engine.

During the review board, you cannot assume that you will convince PLU to use a different CPQ solution. This is mainly because the scenario clearly indicated PLU’s intention to continue using Power Sales. PLU is looking for a recommendation for the best way to facilitate the use of Power Sales by its users without impacting their efficiency.

You can generally suggest one of the following approaches:

• Establish SSO between Salesforce and Power Sales. The users are expected to swivel their chairs and jump from one system to another to complete the task.
• Use Salesforce Canvas to view the Power Sales UI from within Salesforce. This simplifies the chair-swiveling process, but you still need to handle authentication.
• Develop full integration with Power Sales and build a custom UI on top of it.

The third option is the most appealing, but it usually has high costs associated with it. Building a totally new UI on top of another system’s business logic is not an easy task and should never be underestimated.

If this were the only requirement related to Power Sales, the first two approaches would be good to go. However, you will come across multiple other requirements later in the scenario where there is a need to integrate with Power Sales and develop a custom UI on top of it, such as the requirements in the customer registration business process. Therefore, it makes sense to use the same integration interfaces and UIs for this process as well. The custom UI can be a set of Lightning components.

Before you can wrap up this requirement’s solution, you need to sort out the challenge of integrating with Power Sales. You already know that it offers a poor API, which is difficult to modify. You cannot develop custom UIs based on such poor APIs. You need a way to connect directly to Power Sales’ database, in addition to its APIs, and create a granular set of APIs on top of them.

This is a perfect use case for middleware such as MuleSoft. There are several more requirements in the scenario that justify the need for an ESB, such as orchestrating communications with multiple on-premises ERP systems.

Putting this solution together, you will develop a custom UI on top of integration with Power Sales using MuleSoft. You will use that interface to generate and populate the Quote object in Salesforce. The Quote object can then be used to generate and share a PDF with the customer.

Defining the leading key account manager will be a manual process that ends up assigning the account ownership to the selected user.

Update your landscape architecture diagram, data model, and integration list. Then, move on to the next requirement, which starts with the following:

By the end of this process, the customer could be switched to a different, more business-oriented tariff and a new contract should be signed.

This is a common requirement. Once the Opportunity is closed-won, you can automatically use its data to create a Contract. You can use Salesforce Flows to achieve that. The Contract status will display as draft and pending the client’s signature.

It is worth mentioning that the Contract object does not have an out-of-the-box relationship with the Asset object. The Service Contract object does (via the confusingly named ContractLineItem object). The Service Contract object is not available for Customer Community users, though. Therefore, you need to extend the Contract object with a custom object that enables relating it to Assets.

Assets would represent a relationship with a meter rather than the meter itself. The reason behind that is to facilitate the usage of the same meter by multiple customers, for example, in a rented property, without losing track of previous customers. This forms the 360-degree view of the Asset, which is usually desired by utility companies.

You will introduce two custom objects: Meter__c and Contract_Linte_Item__c.

It is worth mentioning that you can use the Energy & Utilities Cloud Data Model from Salesforce Industries (formerly Vlocity) as long as you can explain its objects, their use, and how to identify and mitigate any LDV objects. Similarly, if you plan to use other Vlocity-based functionalities, such as OmniScript, DataRaptor, or FlexCards, then be prepared to explain how they work and justify their usage.

Note

If you do not have enough experience with a Salesforce vertical product, just stick with a solution you know would work. This extends to specialized solutions such as Salesforce Field Service.

In short, if you are planning to use any of these products, you must ensure you have a fair amount of knowledge about it, why it is used, how to use it (at a high level), what its data model is, and what the pitfalls to be aware of are.

Salesforce Field Service is increasingly becoming one of the products that a CTA should be aware of.

Update your data model and move on to the next requirement.

PLU would like to streamline the process by introducing a digital signature.

There are plenty of third-party products that enable capturing a digital signature. Most of them can also trigger logic in Salesforce or update records.

You can propose using a product such as DocuSign. Once the signature is captured, DocuSign can update the Contract status, which initiates the switching process. Update your landscape architecture diagram to include DocuSign.

According to the next requirement, the switching process is fulfilled by the ERP. Move on to the following requirement and clarify the rest of the solution further.

The new contract details are sent to the country’s ERP, which facilitates the switching process.

This process can take up to 48 hours. Once the process is done, the customer and key account managers of relevant regions should be notified.

The requirement did not specify the expected timeframe to send the contract details to the ERP. You can assume that this can be fulfilled using a batch sync job from MuleSoft. You can also utilize functionality such as platform events to send a near-real-time payload to MuleSoft, which, in turn, sends it across to the right ERP. You can also utilize an outbound message for the same purpose considering that you are only sending details from one object (Contract).

Platform events offer an excellent added capability that is usually overlooked. As their name indicates, they fire an event that the platform itself can subscribe to. This allows you to develop a loosely coupled, scalable, event-driven architecture within the platform.

You might ask yourself whether signing is considered an event that you want to execute specific platform logic based on, for example, creating a Chatter post or updating some fields on other objects. If the answer is yes or possibly in the near future, then platform events are a great choice. This feature fires platform-based events that can be subscribed to from inside or outside the platform.

In this case, this could be a valuable feature considering that the utility business relies heavily on the status of their contracts with their customers. Firing a platform event upon signing a contract could help you accommodate several other future requirements. This will be the rationale for using it to solve this requirement.

Once the ERP does the switching process, it will initiate an inbound call to Salesforce to update the contract status again. Once that is done, you can launch a Flow to create a Chatter post to notify the key account managers who are part of the Opportunity team and an email alert to inform the customer.

To make it more readable, you have split the business process diagram into two. The first could look like the following:

Figure 14.9 – Key customer management business process diagram (part one)

The second part explains the lengthier part of the process and could look like the following:

Figure 14.10 – Key customer management business process diagram (part two)

One interesting challenge would be the integration with the Belgium ERP. You know that it does not offer any APIs, it is based on a flat-file database, and it does not support a database adapter.

MuleSoft can connect and communicate with flat files. They are generally simple text or XML-based. Writing to it should not be a challenge. However, the Belgium ERP is a legacy system that is incapable of consuming APIs. But it can communicate with a Simple Mail Transfer Protocol (SMTP) server. This way, it can send an email once the switching process is complete. You can develop a custom Apex Email Service to receive the emails, parse them, and then update the relevant records accordingly.

That concludes the first business process. Update your landscape architecture diagram and your list of integration interfaces, then move on to the next business process.

Customer Service

PLU shared five key requirements for the customer service process. You will go through each of the shared requirements and analyze and solution them. Start with the first requirement, which begins with the following:

All customers should be able to create inquiries or complaints using a self-serve customer portal or by calling the call center.

Customers will be able to raise inquiries and complaints using the Customer Community. You can utilize the Case object with multiple record types to represent inquiries and complaints.

The scenario did not specify whether PLU is looking to modernize its call center with softphone and CTI capabilities, but you can assume that and add Service Cloud Voice to the landscape architecture diagram.

You learned the differences between queues and Salesforce Omni-Channel in Chapter 13, Present and Defend: First Mock, and learned that queues are suitable to represent a single skill. This requirement requires implementing skills-based routing, which will consider all necessary skills to fulfill a particular case, something that is offered by Salesforce Omni-Channel.

Update your landscape architecture diagram to include both Customer Community and Omni-Channel, then move on to the next requirement.

If a complaint is not resolved within seven days, the SVP of the service should be notified.

This requirement can be met using Case Escalation Rules. You can configure the escalation rules to send an email to the SVP of the service when the mentioned conditions are met.

The system should automatically generate a forecasted meter reading for the next month based on the previous month’s reading.

You modeled annual meter readings using a denormalized custom object. This requirement can be met by introducing 12 more fields to represent the forecasted monthly readings for a given year.

In Chapter 2, Core Architectural Concepts: Data Life Cycle, you learned some of the differences between classic RDBMSs and Salesforce, including the fact that in Salesforce, it is acceptable to create an object (table) with many fields (columns) for specific use cases.

You can then have a scheduled Flow to populate the right forecasted field every month automatically. Alternatively, you can use a Before-Save Flow to update the forecasted field value upon updating the actual reading value. For example, the Flow could automatically populate the Feb_Forecasted__c field’s value once the Jan_Actual__c field is updated. This will be more efficient considering the vast number of Meter_Reading__c records you are going to have in the system.

Update your data model and move on to the next requirement, which starts with the following:

The forecasted and actual electricity and gas consumption for every site should be displayed in the customer portal.

The data should cover the last 24 months. Customers should also be able to view their past invoices and payments and be able to view a PDF version of their invoices.

According to this requirement, the Meter_Reading__c object should be visible to the Customer Community users of a particular account. You can achieve that by linking the Meter_Reading__c object to the Asset object using a master-detail relationship. This way, any user who has access to the Asset record will be able to view its related Meter_Reading__c. Customer Community users will get access to the Assets related to the Accounts records they have access to, including any Property records.

This is the first time you’ve come across requirements related to invoices and payments in this scenario. It is fair to assume that these objects will exist in the ERPs. You can then expose them in Salesforce using Salesforce Connect.

Note

You will end up with six external invoice objects if you use a direct connection with the ERPs. Moreover, some of the ERPs are legacy and unable to provide an OData-compatible interface.

You can use MuleSoft to connect to all the ERPs, retrieve the invoices, and aggregate and expose them as an OData interface that Salesforce can subscribe to. Assume that you would be retrieving the invoice headers, line items, and payments as separate external objects. Now, update your data model to include the new external objects.

PLU’s PDF Generator application should generate PDFs. The application receives input data and generates a PDF that is stored on an SFTP. This means it will not provide an interactive user experience where the PDF is generated on the fly. The PDFs need to be generated upfront and stored in a place accessible to the Customer Community users.

PLU does not have a DMS. You can either propose they start using one or use Salesforce Files. The latter option is decent enough, considering that these files’ content will not change after they are generated. No advanced document management capabilities are required.

To generate these PDFs, you can assume a batch MuleSoft job that runs every month, retrieves the invoice details from the ERPs, and passes them to the PDF Generator system to generate PDFs. MuleSoft would then retrieve all files stored on the SFTP and transfer them to Salesforce. You can use a specific file naming convention that includes the account ID. This will allow MuleSoft to attach the files to the correct Account record.

Add the Content Document object to your data model. Your data model could now look like the following:

Figure 14.11 – Data model (second draft)

Your landscape architecture diagram could look like the following:

Figure 14.12 – Landscape architecture (second draft)

Your list of interfaces could look like the following:

Figure 14.13 – Integration interfaces (first draft)

Move on to the next and final requirement in this business process, which starts with the following:

If an energy failure is reported, a critical incident should be created and assigned to the right maintenance partner based on the property’s address.

All customers in the impacted region should receive an SMS and email message upon incident creation, status update, and incident resolution.

You can use the Incident object introduced in the Winter ‘22 release. There are multiple differences between the Case object and the Incident object, including that multiple Cases can be linked to a single Incident but not the other way around. Incidents are best used to handle a disruption that impacts various customers and usually requires a whole team’s collaboration to solve. In contrast, Cases are best used with one-off customer inquiries or complaints that a service agent handles.

You can also design your solution to use a specific Case record type to represent an incident. The Salesforce Partner Community allows read access to the Incident object but does not allow editing. Therefore, the Case object is a better fit for this scenario. In your solution, a critical incident will be another Case record type. You can use Case Assignment Rules to assign it to the right Salesforce Community Partner user or queue, assuming you have a field that indicates the relevant Case region.

You can use a Before-Save Flow to set the value of that field based on the related Property (Account) details.

Once that is done, you need to identify all customers relevant to that particular region and send them all an SMS notification. This is a mass SMS send, a capability not available out of the box on the Salesforce Platform. You can use a third party such as SMS-Magic or utilize Marketing Cloud itself, assuming PLU has the required licenses.

You can send transaction emails and SMS using the Marketing Cloud Transactional Messaging API. This is a REST-based API that can be used to send immediate, non-promotional messages. It is very suitable for this use case.

This API cannot be invoked using the connector. There is a need to execute the following logic:

1. Based on the reported critical Case, create a unique list of customers that need to be notified based on the address of their properties.
2. Use this data to invoke the Marketing Cloud Transactional Messaging API.

How can you achieve both?

You always need to be aware of all the tools that you have. Avoid trying to solve everything using Salesforce Core alone. You have come across multiple examples in this book where it was better to use other platforms, such as Heroku and MuleSoft.

In this case, you can use MuleSoft to handle both tasks. You can fire a platform event from Salesforce to MuleSoft with the necessary Case details. MuleSoft can then query Salesforce to find out the relevant customers, then invoke the Transactional Messaging API. MuleSoft can orchestrate the entire process in a scalable and performant way. If you choose to develop that using custom Apex, you should expect many challenges during the Q&A.

Update your landscape architecture diagram and your list of integration interfaces. There is no need to create a business process diagram for this process as it is simple enough to be explained without it. That concludes the second business process. Now, move on to the next business process.

Scheduled Manual Meter Reading

PLU shared five bullet points to explain this business process (in the Scheduled Manual Meter Reading section). The first two bullet points provided information about the process and technology used, while the remaining three provided detailed requirements.

Go through these three bullet points and analyze and solution them, starting with the first requirement.

PLU would like the radar reader devices to be paired with the field service technician’s mobile phone, then use the phone to send the reading data to Salesforce.

The mobile app with the field service technician must be able to communicate with the radar reader via Bluetooth. This requirement should help you decide on your mobile strategy. This capability is unlikely to be supported by a hybrid app. So, a native app is required. But before you reach a final decision, have a look at the next two requirements.

PLU is looking to optimize the visiting time and travel costs for their field service technicians.

You have two out-of-the-box capabilities in Salesforce to optimize visiting time and travel costs, that is, Salesforce Maps and Salesforce Field Service. The latter has more advanced capabilities and is more geared toward field service requirements and activities, such as skills-based assignments, shift management, and crew management.

Select that to cover this requirement. You need to add the relevant Field Service objects to your data model. Make yourself familiar with the standard Field Service objects and be prepared to explain how they are used.

Note

You can find more details about Field Service objects at the following link: https://packt.link/K6cBm.

Add the WorkOrder and ServiceAppointment objects only to your data model to keep things simple.

Update your data model and landscape architecture, then move on to the next requirement.

At any given time, PLU would like to track the location of its field service technicians.

You know that Salesforce Field Service has a specific mobile app that offers this feature out of the box. This requirement can be fulfilled with that. But can you extend the Salesforce mobile application to communicate with the radar reader over Bluetooth?

You can change some configurations on the mobile app. Still, even if you do not know the app’s full limitations, it is risky to assume that it can be extended to cover such sophisticated requirements.

You can propose developing another native mobile application to handle the communications with the radar reader. In your presentation, you can explain that this is an approach that you are sure works and you aim to investigate this further for a real project.

Update your landscape architecture and the list of integrations. There is no need to create a business process diagram for this process due to its simplicity.

Scheduled Automatic Meter Reading

PLU shared two key requirements for the scheduled automatic meter reading process. Go through each of them and analyze and solution them. Start with the first requirement, which begins with the following:

Smart meters are widely used across the countries covered.

This paragraph does not contain a clear requirement on its own. But it describes a situation where you need some sort of harmonization in the way you interact with the four different cloud-based platforms. Does that ring any bells? Sounds like MuleSoft’s turf. Move on to the next requirement to find out more.

Smart readers must be read monthly.

The key point in this requirement is PLU’s desire for unification. They are after a unified mechanism to get meter readings. The only jointly supported integration capability in these systems is the web services that enable pulling the meter readings.

You can propose developing a scheduled job in MuleSoft that runs every month, pulls the meter readings from all these different platforms, combines them, then updates Salesforce with the combined dataset.

Once that is developed, you can extend the solution by introducing a MuleSoft web service that enables on-demand data pulling. This is not required now, but it is good to have a flexible and extendable design to cover today’s and tomorrow’s requirements.

There is no need to create a business process diagram for this process due to its simplicity. Update your landscape architecture diagram and list of interfaces, then move on to the next business process.

Customer Registration

PLU shared six key requirements for the customer registration process. Go through each and analyze and solution them.

Customers cannot self-register in the community except via invitation. The B2C customers’ access to the portal should be generated after they sign up for a PLU service.

The first part of the requirement is a bit confusing. What is meant here by invitation? There is no standard invitation process in Salesforce. Is the question perhaps referring to the manual process of enabling Contacts as Community users?

This part is unclear, and it will continue to be until you read the sixth requirement of this business process. Real scenarios might raise such questions; therefore, it is important to read the scenario all the way through at least once at the beginning before starting with the accumulative solutioning.

Proceed with the rest of the requirements. You find a need to autogenerate the B2C customer portal users once they sign up for a PLU service. This can easily be automated using the Contract trigger. The trigger will check whether the related customer already has a Community user, and if none is found, the trigger creates a new user.

Does that sound good? Take another look at the described process and identify the potential challenges you could face while handling a happy scenario (a scenario where all the required data is provided and the process is expected to work correctly). Did you spot something missing or that could go wrong? Correct!

Data manipulation language (DML) operations on Salesforce setup objects (such as User) cannot be mixed up, in the same transactions, with DML operations on other objects (such as Account, Contact, and Contract).

In other words, you cannot create a user record in the same transaction where you are updating a Contract record. Your solution will fail in its current condition. This is a point that the judges will notice and pick up on during the Q&A. They would ask more questions to understand whether you missed mentioning that point or were totally unaware of the challenge.

You can overcome this challenge by separating the transaction into synchronous and asynchronous parts. You can launch a future/queueable method that creates the Customer Community user in the Contract trigger. In your presentation, ensure that you highlight that this solution will help you avoid the mixed DML exception.

Move on to the next requirement, which starts with the following:

PLU would like to expose its products to unauthenticated users via a public website.

This requirement is all about exposing your CPQ solution to the public. You have already proposed developing a custom UI (based on Lightning components) on top of a MuleSoft-exposed API that communicates with Power Sales. You can extend the usage of this component to the public Customer Community pages. The responsiveness can be guaranteed using Salesforce Lightning Design System (SLDS).

Move on to the next requirement, which starts with the following:

The customer should be able to confirm the tariff.

This means the Lightning component exposed to the public should be able to create all the necessary objects’ records in Salesforce to start the customer’s Contract. This can be ensured using the right user permissions. It is worth mentioning that this component would be operating under the Guest User context for unauthenticated users. You can grant the guest user access to fields and objects, but ensure you follow minimal data access principles.

Upon the creation of user access, the customer should receive an email notification to set a password.

This is standard functionality. You can create a Customer Community user associated with a Person Account using the Site.createPersonAccountPortalUser method.

Note

You can find more details about this method at the following link: https://packt.link/yKVYN.

The user will receive an autogenerated password that has to be changed upon the first login. You can enforce strict password complexity rules using the profile settings. You can set the value of the Password complexity requirement field on the Customer Community user’s profile to the desired value, such as Must include three of the following: numbers, uppercase letters, lowercase letters, special characters.

Once logged in, the customer should be able to view their contact and contract details.

This will be fulfilled using the proposed data accessibility and sharing model. Sharing sets will ensure the Community user has access to the relevant Property Account. The visibility of Contracts is controlled by the parent (the parent Property Account record). This means record-level accessibility is covered. You need to ensure the Community user has the right object-level and field-level permissions to view all required fields. This can be controlled using profiles and permission sets.

PLU also requested to allow its customers to log in to the community using a branded mobile application. You can propose using Salesforce Mobile Publisher. It is a quick and easy way to turn a Salesforce Lightning community into a mobile application. You can learn more about Mobile Publisher at the following link: https://packt.link/ampDr.

Note

You have not encountered any requirements for advanced capabilities that justify a native app or even a hybrid app. Of course, you can develop your fully branded mobile app using both, but that will cost time and effort. Always think of the client’s ROI.

Update your landscape architecture and list of interfaces, then move on to the next and final requirement.

Customers should be able to invite one more contact to the portal to co-manage a particular property and contract.

Here, you come back to the invitation requirement, as mentioned in the first requirement of this business process.

You can configure Customer Community users to create other Contact records, but the Customer Community Users cannot convert the newly created contacts into users. Moreover, the data model is based on Person Accounts for B2C, which are related to Properties (another Account record type) via the AccountContactRelation object.

These requirements indicate that you need to customize this functionality, keeping in mind the first requirement, which suggests that Community users cannot self-register unless invited.

You can solve this using a new custom object, which contains all information required to send a unique invitation to an email address. Moreover, the custom object should also include all the necessary information to link the newly created Community user with the correct Property record once created.

You can configure the Community user’s profile to allow the creation of the invitation custom object, Community_Invitation__c. You can control the number of allowed records to be created via a custom validation in a trigger or use custom validation rules that rely on the value of a custom rollup summary field. You can choose the first option (despite the fact it is based on code) to avoid consuming one of the limited numbers of rollup summary fields that you can introduce into a sensitive object, such as Account (representing a Property in this case).

The invitation process could look like the following:

1. The logged-in, existing Community user creates a Community_Invitation__c record and sets the required values, such as the email address and related Property.
2. Once the Community_Invitation__c record is created, an email alert can be sent using Salesforce Flows. The email alert’s template will contain the unique invitation code (this could simply be the Community_Invitation__c record ID) and a link to follow to self-register in the community.
3. The link itself will have the invitation code as a parameter. When the user clicks that link, they will be redirected to the community’s self-registration page with a Lightning component. The invitation number will be passed to the page as a parameter, allowing the page to display the number in a field to the customer and other usual fields such as first name, last name, and email address.
4. Once the customer hits the submit button, the Lightning component’s Apex controller validates the invitation number. If that was successful, it creates a Customer Community user and launches an asynchronous queueable job to create the required additional records, such as AccountContactRelation, to enable this user to access the Property details.
5. The newly created user will not be able to view the related Property details until the asynchronous job is concluded. You cannot guarantee how long that will take but can communicate upfront that it will take several minutes.

Update your data model diagram accordingly. The solution for this business process will be easier to explain using a business process diagram. The diagram could look like the following:

Figure 14.14 – Customer registration business process diagram—the invitation sub-process

That concludes this business process. Move on to the sixth and last business process.

Field Sales

PLU shared two key requirements for the field sales process. Go through each of them and analyze and solution them. Start with the first requirement, which begins with the following:

The field sales agent visits a potential B2B lead and walks them through the different offers.

You came across a similar requirement before in this scenario, but the channel was different. You decided to develop a custom UI on top of APIs exposed by MuleSoft, which are integrated with Power Sales. The UI is basically a set of Lightning components.

The field sales agents can use the same components on their tablets, assuming they are using the Salesforce mobile app. The new Salesforce mobile app supports Lightning app pages, which you can logically assume the custom UI will use.

Update your landscape architecture diagram and list of interfaces and move on to the next requirement, which starts with the following:

Three days after completing the visit, an email survey should be sent to the B2B customer’s primary contact.

Two different survey templates should be used, one for successfully signed deals and another for lost deals. If the score of the Field Sales agent is below 3 out of 10, a Case should be automatically created and assigned to the field sales agent’s manager.

This requirement is becoming more common nowadays as more companies are trying to get closer to their clients and show them that their opinion matters. You have three potential ways to solve this requirement:

• Develop a custom survey module based on custom objects and automation.
• Use a third-party tool such as SurveyMonkey.
• Use Salesforce Surveys.

Salesforce products come with the regular Salesforce promise that they will be updated regularly, and new features will continuously be included. Furthermore, they are products designed for Salesforce, so they integrate with the platform in a more straightforward way than others, and they usually simplify other non-functional requirements, such as data residency.

On some occasions, the Salesforce product will lack certain functionalities, which justifies considering a third party instead. This is not the case here. The mentioned requirement can be fulfilled using Salesforce Surveys.

Similar to other extension products (such as Salesforce Field Service and Vlocity), you need to know how the product works and have a good understanding of its components. The most common element you need to be familiar with is the data model. Add the key objects you plan to use from Salesforce Surveys to the data model diagram.

Note

You can find more information at the following link: https://packt.link/DWKUy.

You still need to add some customizations to deliver certain functionalities, such as scheduling sending the survey, linking the sent surveys to the right object (Lead in this case), and processing feedback to determine whether a Case needs to be created and assigned to the field sales agent’s manager (if the score of the field sales agent is below 3 out of 10).

This automation can get complex if developed using Salesforce Flows. Therefore, you can propose an Apex-based solution.

Note

Complex logic is better delivered using Apex rather than Salesforce Flows. Extremely complex Flows are harder to debug or read than Apex. Flows are still great to solve many other challenges but are still not a full Apex replacement.

Update your data model diagram. Your landscape architecture diagram could now look like the following:

Figure 14.15 – Landscape architecture (third draft)

Your list of integration interfaces could look like the following:

Figure 14.16 – Integration interfaces (second draft)

Your data model diagram could look like the following:

Figure 14.17 – Data model (third draft)

At this stage, you have nearly solutioned 60–70% of the scenario’s requirements. This will be the basis of the next chapter, where you will continue to solution the rest of PLU’s requirements, then create the presentation pitch.

Summary

In this chapter, you were introduced to the second full mock scenario. You are now more familiar with the nature of full scenarios. They are longer and more thorough and contain many more challenges than mini-scenarios.

In this chapter, you tackled the first part of the scenario. The business process requirements are usually the meatiest part of a scenario. This part is also where you start creating your comprehensive solution. You start by understanding each business process, then divide it into digestible chunks and solve it as a whole.

You came across compelling use cases and design decisions, including a complex data model that supports both B2B and B2C. You created several business process diagrams that will help you during the presentation by visualizing your solution.

In the next chapter, you will continue to solution the scenario and then put together a presentation pitch. You covered a sizeable chunk in this chapter, but you still have plenty more to cover in the next one.