12

Practice the Review Board: First Mock

In this chapter, you will put all the knowledge you learned in the past chapters into action. You will be introduced to this book’s first 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 reread the scenario and devise solutions as many times as needed until you feel comfortable enough with them. 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 Pioneer Auto (PPA)
• Analyzing the requirements and creating a draft end-to-end solution

By the end of this chapter, you will be familiar with the shape, size, and complexity 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, you can now move on to have a look at your first full mock scenario.

Introducing the Full Mock Scenario: Packt Pioneer Auto

PPA is a global car rental company that provides services to end customers in AMER, EMEA, and APAC. PPA operates in 50 major cities across 10 different countries, including Italy, Spain, France, Australia, Japan, the USA, and the UK. Each city has an average of 5,000 cars available for rental through the PPA offices. Each city has an average of 10 offices.

PPA allows its customers to pre-book their car rental for up to three months up front. Earlier, they used their call center to handle customer bookings, but they are looking to modernize their services. Customers can also walk into any of PPA’s offices to rent an available car directly.

PPA has around a million registered users globally and an average of 10 million car rentals every year.

PPA works with a network of partners to clean, repair, and maintain their fleet of cars. Each car is fitted with a modern GPS tracking device that is able to send the car’s location periodically in addition to other services, such as detecting harsh braking and going over the speed limit.

PPA’s offices are staffed by sales and support teams responsible for managing customers and their relationship with partners. Currently, each country has a bespoke solution for tracking customer and rental information. These solutions are known to be bug prone and difficult to maintain.

PPA recently decided to use Salesforce as the central CRM solution for unified customer, rental, and partner processes.

Project Overview

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

• Sales agents: They are responsible for staffing the regional offices, helping walk-in customers to register, and booking car rentals. They are also accountable for inspecting returned cars for any damages and providing the final customer invoice.
• Support agents: They are responsible for supporting registered customers and resolving reported issues with the rental or car. They also support car reservations via the call center. Support agents work from a single support office in each region (AMER, EMEA, and APAC).
• Office technicians: They ensure returned cars are fully functional; they deeply inspect the vehicles and provide maintenance reports to the office manager.
• Office managers: Each office has a manager responsible for running the business from end to end, including managing the relationships with the partners.
• Regional executive team: They are responsible for analyzing the customer and rental data across the AMER, EMEA, and APAC regions.

There are two types of external system users:

• Registered customers: They need access to a whole new set of modern services.
• Partners: They have access to the system to receive and update maintenance requests. Some partners are open to utilizing PPA’s solution, while others have expressed their interest in using their own systems and only integrating with PPA’s solution.

PPA has the following landscape.

Current Landscape

PPA is currently using the following systems:

• Regional ERPs: The regional ERPs are used to manage the partners’ accounting and payments. Each ERP is based on different technology, and they are hosted on-premises.
• Global tracking system: This is a cloud-based solution used to control car tracking devices remotely. The solution is expensive to change or modify and has a limited capability to configure or extend any logic beyond its standard features.
• Customer and rental management applications: PPA has over five different applications used across the globe for customer and rental management. Historically, these systems had a lot of redundant and duplicate data. PPA is planning to replace them all with a new solution.
• Violation databases: PPA purchased a subscription-based service from a global provider specializing in collecting vehicle violation data. As a part of this subscription, PPA gets access to a database containing all received violations, penalties, and tickets for their cars in a particular region. PPA has access to three AWS-hosted Oracle databases across the AMER, EMEA, and APAC regions.
• Global car rental calculator: PPA has developed an in-house application to calculate car rental costs based on multiple factors, such as location, start and end dates, car model, car specs, and many more. The application has a built-in REST API and is hosted on AWS.
• PPA uses LDAP to authenticate all its employees: PPA would like to keep using LDAP for the foreseeable future.

PPA has shared the following business process requirements.

Business Process Requirements

The following subsections explain the business processes that PPA expects to have in its new system.

Customer Registration

PPA requires specific information to be captured for all its customers regardless of the channel used to rent the car. The new system must support the following processes:

• Customers should be able to self-register using an online portal and a mobile application.
• Sales agents can also register new customers who walk into a PPA office.
• The following information must be captured while registering a customer:
  • Full customer name
  • Email address
  • Mobile number
  • Preferred language
  • Driving license number
• The customer must also accept PPA’s privacy terms and conditions. The customer can optionally opt in to receive marketing materials via email, phone, or mail.
• The driving license validity must be checked in real time using the national driver and vehicle licensing agency services.

PPA has shared the following requirements for the reservation process.

Car Reservation

Customers should be able to reserve cars for up to three months upfront either by using the online services (portal and mobile application) or by calling the national customer services number. The online process should use the following steps:

1. The customer should be able to enter the pickup location (city) and start and end dates. The system should show a list of cars available at that location and point in time.
2. The system should calculate and display the price for renting each car. The price could differ by date and the total number of reserved days. PPA has a pricing policy that reduces the daily cost if the customer is reserving the car for extended periods.
3. Customers should select the desired car and proceed to online payment. The solution should support PayPal as well as all major credit cards.
4. Once the payment is collected, the transaction is considered complete. An email confirmation should be sent to the customer with a specific activation code. The car should immediately become unavailable for the reserved date.

The reservation process is very similar when using the call center, with slight differences:

1. The support agent should be able to search for available cars in a particular location (city) using the start and end dates.
2. The support agent can then verbally inform the customer of the available cars and the associated price. The price calculation rules are consistent across all channels.
3. Once the customer confirms the car selection, the agent should capture the customer’s payment details and confirm the reservation.
4. Once the payment is collected, the transaction is considered complete. An email confirmation should be sent to the customer with a specific activation code. The car should immediately become unavailable for the reserved date.

PPA has shared the following requirements for the car check-in process.

Car Check-In

PPA wants to automate its processes as much as possible. The check-in process should look like the following:

1. Each office has multiple tablets with a particular application to allow customers to check in using the activation code they received during the reservation. Once the code is entered, the application should validate the code, booking location, and date. If the validation is successful, a confirmation message will be displayed on the screen, and the reservation record is updated to indicate the customer has checked in for collection. All tablets are connected to the internet.
2. Once the customer checks in, a sales agent can hand over the car keys and update the reservation status to indicate that they collected the keys.

PPA has shared the following requirements for the car check-out process.

Car Check-Out

The check-out process should look like the following:

1. When the customer returns the car, the sales agent should collect the keys and quickly inspect the vehicle. The sales agent should enter any notes related to changes in the car’s condition, such as dents or scratches. If major damage is detected, the office technicians should be informed and asked to further investigate the car’s condition.
2. This information should be sent to the ERP, which generates a customer invoice after 72 hours.
3. Once an invoice is generated, a notification would be sent to the client with the invoice amount and instructions to settle any remaining balance.
4. The sales agent updates the reservation status to closed once the inspection is done.

PPA has shared the following requirements for the car status update.

Car Status Update and Penalty Settlement

As mentioned before, all cars are fitted with a GPS tracking device. The following details describe the car status update and penalty settlement process:

• All tracking devices can communicate over 4G and 3G. They send the car’s location every 30 seconds. For security reasons, this continues to happen even if the car is turned off.
• PPA would like to gather information that describes the behavior of drivers, including going over speed limits and harsh braking. That all should be analyzed for PPA to calculate driving patterns during specific dates and times of the year.
• PPA would like to use GPS tracking devices to detect possible vehicle theft. If the device is reporting a change in the car’s location while the car is turned off, this could be a possible theft incident that the support team should be notified about within no more than 15 minutes.
• Every day, the violation databases should be checked. If they contain a violation record for a PPA car on a given date, the system should look up the car’s driver details on the given date, then transfer the penalty amount to the ERP to calculate a new invoice and send it to the customer.

PPA has shared the following data migration requirements.

Data Migration Requirements

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

• PPA would like to migrate the data from all its current customer and rental management applications to the new system.
• PPA is aware that the current data contains many redundancies and duplicates and is looking for your guidance to deal with the situation and achieve high data quality in the target system.
• PPA has around 50 million rental records in each of its current rental management applications. Most of them are stored for historical purposes as PPA wants to keep rental records for at least 10 years. PPA would like to continue allowing its sales and support agents to access these records in the new system.

PPA has shared the following accessibility requirements.

Accessibility and Security Requirements

PPA is looking for guidance to design a secure solution; they shared the following requirements:

• Customer accounts should be visible to office managers, sales agents, and service agents worldwide. However, technicians should only see customers from their specific country.
• Support incidents should be visible to support agents and their managers only.
• Only office technicians can update the car status to indicate that it is out of service and requires repairs.
• Office technicians should not be able to view the customer’s driving license number.
• Once a theft incident is detected, only the support agents trained for such incidents, their managers, and regional executives can view the incident’s details.
• The regional executive team should have access to all regional data, including drivers’ behavior, such as harsh braking.
• Office managers should be able to see the details of the partner accounts in their own country only.
• Partners should be able to log in to Salesforce using Salesforce-managed credentials only.
• Customers can self-register on the online portal and mobile application.
• Customers should also be able to log in to the online portal and the mobile application using their Facebook accounts.
• PPA employees who are logged in to the corporate network should be able to automatically log in to Salesforce without the need to provide their credentials again.
• PPA employees can log in to Salesforce from outside the corporate network using the LDAP credentials. However, if they log in from outside the network, they should provide a second factor of authentication, such as a text message received on their mobile phone.

PPA has shared the following reporting requirements.

Reporting Requirements

PPA has requested a rich set of reporting capabilities, including the following:

• The regional executive team would like a report that shows relations between customers’ driving behavior and particular times of the year across the past 10 years.
• The regional executive team would like a trending monthly report that shows the pickup and dropoff locations of each rental to determine the appropriate distribution of cars across their offices.
• Customers should be able to view a full history of their rental bookings, including bookings from the past three years.
• Customers should also be able to view their full trip history for each completed rental.
• Partners should be able to view a monthly report showing the repair jobs completed for PPA.

PPA has shared the following project development requirements.

Project Development Requirements

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

• PPA plans to have three different service implementers (SIs), delivering different functionalities across parallel projects. PPA would like to avoid conflicts across the teams, such as code overwriting or breaking each other’s logic. PPA requires your help to define a way to manage the code base to avoid such conflicts and reduce the chances of breaking existing functionalities.
• Historically, SIs used to follow their own coding standards while dealing with other platforms. On many occasions, they introduced duplicate functionalities. PPA would like to understand how to control and avoid this situation in Salesforce and enable better code reuse.
• PPA has a new platform owner who joined from another company that also used Salesforce. They reported that on several occasions, bugs were fixed in UAT but then showed up again in production. PPA would like to understand the likely cause of such an incident and how to avoid it in their program.
• PPA would like to release the solution to Italy first, then roll out the same solution to other countries based on a pre-agreed schedule. Each region country may have country-specific requirements that need to be defined and accommodated in the solution. PPA is looking for your support to determine the right development methodology and governance to achieve that.

PPA has also shared the following other requirements.

Other Requirements

PPA would like to know the best practices to manage their customer consent. They have shared the following requirement:

PPA wants to ensure that data in development environments is always anonymized.

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

Next, it is time to start identifying requirements and creating a draft solution following the same methodology you used to solve the domain-specific mock scenarios in Chapters 5-11.

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 of potential solutions. If you plan to do the in-person review board, you can make the notes on a separate paper or on the printed scenario itself, while you can use Excel sheets for the virtual review board. You can use a combination of the two for both experiences; it depends on your preference and what you feel comfortable with.

You will cover two possible ways to prepare and play your presentation in Appendix, Tips and Tricks, and the Way Forward. You will also see an example of a time plan for the solution and presentation phases, where you allocate a specific period to do pre-planned activities.

Considering the size of the full scenarios and the number of shared requirements, the proposed solution and presentation will be split over two chapters. You will cover most of the scenario’s requirements in this chapter. In Chapter 13, Present and Defend: First Mock, you will continue with the remaining requirements and create the presentation pitch.

Continue to follow the same method you are now familiar with, incremental solution development. Start by understanding the current landscape and create your first draft of the diagrams.

Understanding The Current Situation

Starting with the first set of paragraphs, you see a description of PPA’s activities and geographical presence. By going through the requirements for the first time, you encounter several incidents for accessibility requirements that indicated granting access to users and their managers.

This should point you directly to a potential need for role hierarchies. Moreover, you should expect a likely need for role hierarchies and/or territory management once you see a description of multiple geographical locations.

Create a draft role hierarchy based on what you know so far. You know that PPA operates in AMER, EMEA, and APAC. They cover 50 cities in 10 countries. You can adjust the diagram later once you learn more about the requirements.

Create an initial draft for the actors and licenses diagram. PPA has sales agents, support agents, office technicians, office managers, and regional executives. PPA also has customers and partners. The scenario provided an initial description of the actors’ activities. Please note that you might figure out more activities while going through the scenario. This is where you need to go back and adjust the diagram accordingly.

You can even start allocating potential licenses to the different actors. You can always adjust that if needed. For the time being, add your best guess about potential licenses because that is the best way to ensure you do not miss any requirements later.

Your role hierarchy diagram could look like the following:

Figure 12.1 – Role hierarchy (first draft)

Please note that the Director of Sales roles are not mentioned in the scenario. They were proposed in this diagram to make the role hierarchy more structured. You can decide whether you would like to keep them or not later while solving the sharing and visibility requirements.

Your actors and licenses diagram could look similar to the following:

Figure 12.2 – Actors and licenses (first draft)

At this stage, it is recommended to leave question marks on the diagram for the not-very-clear topics. This helps you identify any gaps later on.

The scenario also provided some interesting figures, such as 5,000 cars, 10 offices per city, one million registered users globally, and an average of 10 million car rentals annually. Pay attention to these numbers because they typically would lead to some data challenges, such as LDV objects. Take note of these numbers, keep them at the top of your paper, notes, or sheets, and keep checking them while designing your solution.

It is very unlikely to encounter a CTA review board scenario that does not have a requirement related to LDV. If you do not manage to identify one in your scenario, it is strongly recommended to go through the scenario again and ensure you fully understand the requirements and the scope.

Moving on to the current landscape description, you can use the provided details to create the draft landscape architecture diagram. Remember that you need to indicate all the systems involved in it, including those that are retiring.

Your landscape architecture could look like the following:

Figure 12.3 – Landscape architecture (first draft)

The full scenarios are typically structured in a specific way, where there is a section for each related set of requirements. Sections such as the business process requirements contain subsections explaining all the key business processes in this scenario.

In Appendix, Tips and Tricks, and the Way Forward, you will better understand a full scenario’s typical structure. For the time being, proceed with analyzing and working on a solution for the shared requirements.

Analyzing the Business Process Requirements

PPA has shared five key business processes, that is, customer registration, car reservation, car check-in, car check-out, and car status update and penalty settlement. This part of the scenario usually contains the most significant chunk of the 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 would also give you an engaging and attractive tool to use during your presentation. Now, start with the first shared business process.

Customer Registration

PPA has shared five key requirements for the customer registration process. Perhaps you have already noticed this, but some requirements in the Accessibility and security requirements section might add a few more requirements to this process. This is why the incremental solution development processes are particularly useful to ensure you do not accidentally miss any requirements.

Start with the first requirement for this process.

Customers should be able to self-register using an online portal and a mobile application.

Self-registration can be easily enabled in Salesforce communities. However, this requirement raises two main questions:

• What type of community license is required?
• What is the right strategy for the mobile app?

This is a customer-related requirement, so you should be choosing between the Customer Community and Customer Community Plus licenses. So far, you have not come across any accessibility requirements that would direct you toward the Customer Community Plus license. Therefore, it is better to stick with the Customer Community license for the time being and modify it if needed.

Note

The persona’s name does not necessarily map to the name of the proposed license. For example, the partner persona might not necessarily map to the Partner Community license and, in some scenarios, could be better represented using the Customer Community Plus license. You must fully understand the shared requirement and select the proposed license type accordingly.

The Customer Community license is more optimized to handle a vast number of end customers, unlike the Customer Community Plus license, which is more suitable for use cases that require complex sharing mechanisms.

You should also specify whether you are going to use named users or per-login licenses. You do not have a requirement to help you decide, so you need to assume. For example, you can assume that the customers will not be logging in frequently, and therefore a Salesforce Customer Community Login license should be an ideal fit.

That sorts out the first half of the requirement. Next, you need to figure out the right mobile strategy. There are a few options. As you learned in Chapter 5, Developing a Scalable System Architecture, the possible options are Salesforce mobile app (with or without Mobile Publisher), native app, hybrid app, or HTML5 app.

The requirements of the scenario you are aware of so far can be fulfilled using all of these options. So, use the one that is easiest to develop and deploy, that is, the option that allows you to save development effort and focus on delivering value to the customer. Salesforce Mobile Publisher can be used to create and deploy a branded mobile app of your Salesforce Community.

But is Salesforce Mobile Publisher the most cost-effective option? If you do not consider the time-to-market and the return-of-investment calculations, then the answer will probably be no. At the review board, you should be looking for the best technical solution (based on best practices and expert judgment). In this case, it makes sense to recommend using Salesforce Mobile Publisher.

Update your landscape architecture and actors and licenses diagrams, then move on to the next requirement.

Sales agents can also register new customers who walk into a PPA office.

This is an out-of-the-box capability in Salesforce. Sales agents can simply create a person account for the customer (or a separate account and contact; however, a person account is more suitable in this case), then enable a Customer Community user for it. This is an easy-to-collect point; do not fail to identify or solve such requirements in your presentation. Now, move on to the next requirement.

The following information must be captured while registering a customer.

Again, this is an easy-to-collect point. You just need to mention that you will be capturing these fields upon registration and that you will be making them mandatory to ensure you always capture an input value in them. There is no standard field on the contact object to hold the driving license value, so you need to introduce it as a custom field.

You need to mention that this field will be custom; this is how you ensure you capture this question’s points. Make sure not to lose such an easy point!

It is recommended to add all custom fields to the data model. This is not what you usually have on your data model’s logical level, but this is particularly useful for the review board. This will ensure you still collect the points even if you fail to mention the custom fields in the presentation. Your diagram will answer the question on your behalf.

Create or update your data model diagram, then move on to the next requirement.

The customer must also accept PPA’s privacy terms and conditions.

Salesforce introduced the individual object as part of a rich set of consent management objects. When you come across a consent management requirement, you need to think about utilizing the standard objects to fulfill it. In most cases, you will not have to introduce any additional custom objects or fields. You just need to make sure you are familiar with the use of each of the standard consent management objects.

Note

A full description can be found at the following link: https://packt.link/Q13tY.

In this case, you can use the individual, contact point type consent, and data use purpose objects. Update your data model diagram, and move on to the next requirement.

The driving license validity must be checked in real time using the national driver and vehicle licensing agency services.

This requirement contains two challenges:

• How do you achieve the desired functionality as part of the customer’s self-registering process?
• How do you achieve the desired functionality for sales agents registering walk-in customers?

To fulfill this requirement, you need to design an integration interface with national agency services. You can assume that the agency has publicly accessible APIs. Still, you need to decide which integration pattern to use, how that interface would work, whether there is a need for middleware, and how the authentication and data security will be handled.

The word real time should give you a hint about the integration pattern. The desired pattern should invoke logic in a remote system, get the result in real-time, and return it to the caller. Sound familiar? It should, because that is precisely what the Remote Process Invocation–Request and Reply pattern is all about.

You know that this pattern needs to be triggered by the caller and then wait for the response. In the online self-registration form, this can be achieved in multiple ways, such as invoking the remote service upon clicking on the submit button. You will have to use a custom registration page, giving you control over all its behavior.

You need to introduce a different mechanism for the sales agents as they will be using the standard Salesforce UI. You can introduce a custom validate driving license action that triggers a Salesforce Screen Flow. In turn, a Flow can use Salesforce External Services to invoke a remote web service and get the result.

The middleware can add value even for such simple requirements, as it can handle any required retry mechanisms. Moreover, it provides a unified interface for Salesforce to communicate with. Behind the scenes, it communicates with the right national agency depending on the issuing country of the driving license. You can assume that this middleware is MuleSoft.

Authentication from Salesforce to MuleSoft should always use one of the common authentication standards, such as OAuth 2.0. You can use either the web server authentication flow (for the first time, followed by a refresh token flow) or the JWT flow. In both cases, data will be protected in transit using two-way TLS between Salesforce and MuleSoft and one-way TLS between MuleSoft and the agency’s web service, as you can safely assume that you do not have enough control over the agency’s network security to request hosting your MuleSoft instance’s digital certificate.

Authentication from the middleware to the agency’s web services depends on the agency itself. You can assume that the agency’s web services only support simple authentication (username/password).

Update your landscape architecture diagram and list of integration interfaces. At this stage, you should also create your first business process diagram. It will help you significantly during the presentation. It could look like the following:

Figure 12.4 – Customer registration business process diagram

You can add as much detail to the process flow as required. Just remember that this will be your tool to tell the story during the presentation. In real life, this diagram is likely to get more detailed.

Now that you have solved the first business process, move on to the second.

Car Reservation

PPA has shared three modes of the car reservation process: the first is via the online services (the online portal and the mobile application), the second is via the call center, and the third is via a walk-in visit to a PPA branch.

Start with the first requirement of the car reservation process.

The customer should be able to enter the pickup location (city) and start and end dates.

The system should show a list of cars available at that location and point in time. This will require a custom Visualforce page or Lightning component. The page would query the available cars based on the given parameters and display the results. Are you missing anything here? Actually, yes.

You need to think of the end-to-end solution. It is your responsibility as the lead architect of this project. One of the biggest mistakes a candidate could commit is to assume that someone else would take care of it. You need to consider the following challenges:

• Which object is going to be used to represent a car?
• How do you maintain the availability of cars?
• How are you going to organize the cars per location?
• What are the accessibility settings that will allow customers to view cars?

Note

It is a common misunderstanding to assume that the way to prepare for the CTA review board is via engaging with more pre-sales activities. Pre-sales activities would significantly enhance your communication skills, but that alone is not enough.

While engaged in pre-sales activities, you rarely dive into the level of detail you encounter in this scenario. That level of detail is a must to pass the CTA review board. You need to have the breadth of knowledge, the consultant mindset, the hard-core technical depth, and a wealth of soft skills. Combining pre-sales activities with hard-core day-to-day implementation work would significantly boost your learning curve.

Can you use any standard object to represent the cars? The Product object is an obvious choice considering that it is also related to the Order object that you might use for the car reservation. You can utilize the PriceBook object to group cars by location.

The pricing is going to be handled by PPA’s global calculator application anyway (you will learn more about this in the next requirement). You can also use a custom object, but you might need to make some adjustments to the Order object in that case.

Your products and price books have to be visible to your customers. Until the Salesforce Spring 22 release, the Product object did not have OWD settings as they were controlled by price books, but this has changed, and you can now configure OWD for Products. PriceBook has special OWD settings and sharing mechanisms. You can share a PriceBook object manually with all portal users from the PriceBook page (currently only supported on Classic). Sharing Products via a PriceBook meant for portal users is the option that will be used for this scenario due to its easy maintenance.

Finally, the page would need to use the Order object’s Order Start Date (EffectiveDate) and Order End Date(EndDate) fields to determine cars’ availability in the provided period.

Update your data model diagram and move on to the next requirement, as follows.

The system should calculate and display the price for renting each car.

PPA already has a specific application to calculate the price of each car based on the given parameters. You need to integrate with that solution, pass the right arguments, and then display the results on the Visualforce page/Lightning component. This is a new integration interface. You are now familiar with the details required for every integration interface in the solution. The pattern is Remote Process Invocation: Request and Reply as you need the response before you can proceed to the next step (which is displaying the results to the customer).

What will be your strategy if the judges decided to take the calculator application out of the landscape? How would you handle this requirement? Be prepared for such challenges as they could be raised during the Q&A.

For now, update your landscape architecture diagram and your list of interfaces. Then move on to the next requirement.

Customers should select the desired car and proceed to online payment.

You should be able to build an integration to a payment gateway or use a product that provides that capability out of the box. The latter is the right solution technically as it saves you time and effort. Moreover, a battle-tested product is usually more reliable than a custom solution.

You still need to explain how the product works (at a high level) and how it would collect the payment details in a PCI-compliant manner. After all, this would be the first point your client would ask about in a real-life scenario.

Try to memorize the names of some ISV products that provide this functionality, such as Bluefin and Chargent. Update your landscape architecture diagram, then move on to the next requirement, as follows.

Once the payment is collected, the transaction is considered complete.

Once the payment is collected, Bluefin can create a payment record (custom object) related to the order. This, in turn, can trigger a Salesforce Flow that updates the order status to complete and sends an email notification to the customer.

The Order Start Date and Order End Date fields will be used to determine the car’s availability.

Have all the requirements been covered? A minor one has been missed, actually. As a lead architect, you are expected to provide an end-to-end solution with all the required details. You need to explain how the activation code will be created and included in the email notification.

This could simply be a custom field on the Order object, with a globally unique identifier (GUID) value that is generated and populated using an Apex trigger before updating the order status to complete.

Once the value is populated into that field, you can use merge fields to include the field’s value in your email notification. The created order will be linked to the customer’s person account, which the rest of the email notification values (such as first name, last name, and so on) can be fetched from. Now, update your data model, which should look like the following:

Figure 12.5 – Data model diagram (first draft)

At this stage, you might have noticed that some objects are labeled as LDV. This is based on the figures you took note of at the beginning of the chapter. You need to do the math to confirm that these objects should indeed be considered LDVs. It is recommended to do that after drafting the business processes’ solution, as you would have a better understanding of the overall usage of the data model’s objects by then.

At this stage, your landscape architecture diagram should look similar to the following:

Figure 12.6 – Landscape architecture (second draft)

The next set of requirements describes the same process executed by a different actor (the support agents). Start with the first requirement.

The support agent should be able to search for available cars in a particular location (city) using the start and end dates.

You can assume that the Visualforce page/Lightning component created for the customers is also available for the support agents. The new Lightning component can be easily embedded into a tab in Salesforce. You can assume that the component has design-time properties that control its capabilities. For example, a property could be set to indicate that the internal team will use it. This property controls the visibility of a specific part of the page where the customer’s person account can be selected.

You can create a wireframe for the page if you wish. This is considered an extra mile that you can cover if you have enough time. It is important to explain how the pre-built Visualforce page or Lightning component can be repurposed for the usage of internal users.

The support agent can then verbally inform the customer of the available cars and the associated price.

This requirement is automatically fulfilled as the support agents would be using the same car search and reservation page exposed to customers. The page is constantly communicating with PPA’s calculator via MuleSoft and should return consistent pricing across the channels.

An email confirmation should be sent to the customer with a specific activation code.

This requirement was requested before in this scenario but for a different actor (customer). It is automatically fulfilled as the support agents use the same car search and reservation page exposed to customers, which should execute the same logic, including sending the email notification.

The business process diagram for this process can look like the following:

Figure 12.7 – Car reservation business process diagram

Now that you have solved the second business process, move on to the third.

Car Check-In

PPA has shared two requirements for this process.

Each office has multiple tablets with a particular application to allow customers to check in using the activation code they received during the reservation.

The customer is expected to interact with the tablets in the office by entering the activation code. The application installed on the tablet should authenticate to Salesforce, look up the order record using the activation code, then update its status (or sub-status) to indicate the customer has checked in. There will probably be validation in place to prevent early check-in.

In your solution, you need to explain the integration pattern used (remote call-in), the authentication mechanism (OpenID Connect User-Agent Flow), and the security measurements to protect data in transit.

Note

Authentication on its own does not protect data in transit (mutual authentication is an exception). Most authentication standards require a secure HTTPS connection. However, this is not mandatory for simple authentication. If a simple authentication took place over a non-secure HTTP connection, there would be no security measures to protect the data in transit. Your data will be transferred in plaintext format, and attackers can sniff the network traffic and get access to your data. The most common way to protect data in transit is using one-way or two-way TLS.

Take a moment to think of the potential changes that could be introduced to this requirement during the Q&A. How can you enhance this process? A possible addition could be to send a push notification to the sales agents in the current office shift to inform them of the check-in. This will make the process more streamlined. This is not a shared requirement at the moment but be prepared for such additions/changes during the Q&A.

Update your landscape architecture diagram, your list of integration interfaces, and your data model (adding any new fields required, such as a sub-status), then move on to the next requirement.

Once the customer checks in, a sales agent can hand over the car keys and update the reservation status to indicate that they collected the keys.

You can assume that this process will happen manually. The agent will search for the reservation, validate the order’s sub-status, then hand over the keys and manually update the order again. Further automation could be requested during the Q&A. So, be prepared for that.

The business process diagram for this process can look like the following:

Figure 12.8 – Car check-in business process diagram

Now that you have solved the third business process, move on to the fourth.

Car Check-Out

The process of returning the car to the leasing office is more straightforward. It can only be done in person by the client. Have a look at the first requirement, as follows:

When the customer returns the car, the sales agent should collect the keys and quickly inspect the vehicle.

The sales agent can look up the order related to this particular rental using the activation code or customer information. But where can you store the inspection details? And how can you inform the technicians about major damage to follow up with?

This is where you need to demonstrate your understanding of the platform’s capabilities. You can propose a solution based on a set of custom fields and workflow rules with email notifications. But then you will find yourself trying to solve other future challenges, such as the following:

• How can you send an email notification to an entire team? You are strongly advised not to propose any solution that is based on a shared email inbox pattern. That pattern was acceptable a few decades ago, but today’s enterprises want something far more traceable and auditable.
• How can you ensure that the technicians are acting on the incident? If they do not act, the right invoice will not be generated. This will impact the main process you are solving.
• If you are planning to introduce a set of new fields on the Order object, how could that impact the user experience? If you are planning to introduce a whole new custom object for the same purpose, then have you considered the standard objects that might deliver the desired functionality?

Considering that you are looking for the best solution technically, you should consider using the Case object whenever you detect a need for a well-governed incident management process, for requirements such as reporting, assigning, progress tracking, and eventually resolving an incident.

For this requirement, the sales agent can create a case (the Sales Cloud license permits that), link it with the customer’s order, and use it to provide structured feedback. If specific criteria are met, the case can be automatically assigned to the technicians’ queue for that office. Once the case is assigned to the queue, all queue members will be notified via an email alert (this feature can be turned on or off).

The queue assignment can also grant the technicians access and visibility to the case records. You could configure escalation rules to ensure that the case is reported to higher management if the technician took no action during a specified period.

This is a scalable and flexible solution. The judges can challenge you and change some requirements on the fly, but your solution is flexible enough to handle these changes.

Your proposed approach must deliver value to your customer that other approaches might not. You truly must believe in this, unlike a salesperson who preaches just to hit a sales target. You are the client’s trusted advisor; when you propose a solution, you must believe in it and clearly articulate its value. Otherwise, your uncertainty will reflect on you during the presentation and Q&A, and you will not radiate the confidence expected from a CTA.

This information should be sent to the ERP, which generates a customer invoice after 72 hours.

PPA has three ERPs hosted on-premises, probably in entirely different physical locations. How can you transfer the data from Salesforce to the right ERP system to generate the invoice? How can you connect a cloud-based application such as Salesforce to an on-premises application?

If your answer is anything but middleware, then you are likely stepping into a minefield. Proposing a point-to-point approach here would likely result in a failure in the integration domain. The first challenge would simply be: how would Salesforce Connect to a system protected behind a firewall?

Coming up with unreasonable assumptions such as moving the ERP to a DMZ (which means it is pretty much exposed to the outer world) will open a can of worms that you would not want to deal with. Making such unreasonable assumptions could draw more challenging questions from the judges that you might not be able to answer correctly.

As you already have MuleSoft in your landscape, use it. If you do not have it yet, then this is a solid reason to propose it. You can suggest other middleware as well. Considering that this requirement would need a system capable of orchestrating the call with multiple systems and considering that this interface is not meant to deal with a massive amount of data, an ESB is a reasonable option.

You can propose any ESB tool you feel comfortable with and not stick with MuleSoft just because it is a Salesforce product. Remember, you have to believe in the value of your solution. In this scenario, you are proposing MuleSoft because it is a leading middleware, according to many credible sources. Moreover, it is assumed that you are more familiar with it than other similar middleware. But feel free to propose whatever tool you believe can deliver a similar functionality and that you feel comfortable with.

You still need to specify the integration pattern, authentication mechanism, and how you will protect your data in transit. You might need to explain how MuleSoft will communicate with an on-premises solution during the presentation. You came across a similar situation in Chapter 11, Communicating and Socializing Your Solution.

When you select the pattern, you need to consider the object(s) you plan to copy over to the ERP.

Based on your proposed data model, you would likely need to sync the Order, OrderItem, and Case objects, assuming that the Account and Contact tables are already synced along with lookup tables such as Product.

Which pattern do you think would serve you best here? Which Salesforce functionality can be used to sync all three objects with as little technical burden as possible? You can think of the following functionalities and tools:

• Outbound messages: Outbound messages can only contain data from one object. However, you can send the lead object (such as Order in this case) to MuleSoft, request MuleSoft to do a callback to retrieve the rest of the objects, and then transfer them to the ERPs. This is a good option that you should shortlist, although it requires a bit of custom development in MuleSoft.
• Platform events: They can be designed to contain data from multiple objects. However, you are dealing with an object that has one-to-many relations here. You cannot model a single platform event that combines data from the parent and the child records except if you go with non-standard solutions such as defining a long text field with JSON content. You are discouraged from proposing such an approach due to the associated technical challenges (creating the JSON structure, populating it, and parsing it at the other end) unless it is unavoidable.
• Future methods: You can develop an Apex callout to invoke a remote service exposed by MuleSoft and pass the data. Considering that this needs to happen in an asynchronous fashion, you would need to use future methods (or queueable interfaces). You are discouraged from proposing such an approach due to the associated technical challenges (additional custom development, retry mechanism, logging mechanism, and so on) unless it is unavoidable.
• Salesforce Flows: Using Flows, you can invoke the remote web service using a configurable point-and-click functionality. This sounds good, but you still need to consider the required supporting functionalities, such as retry and logging mechanisms.
• Batch data sync: This approach might sound old-fashioned, but it is effortless to put in place and, on many occasions, good enough for the business. You can configure a Batch job in MuleSoft to run every hour, pick the relevant records from all target objects, then send them over to the ERP in the right order. This is likely to be the most cost-effective option as well.

The evaluation of the preceding functionalities depends on the use case you are trying to solve. For example, in other use cases, you might find that platform events are optimal.

Once the data is synced to the ERP, you can assume that the ERP has all that is needed to generate the invoice in the given timeframe. Update your landscape architecture diagram and your list of integration interfaces, then move on to the next requirement.

Once an invoice is generated, a notification would be sent to the client with the invoice amount and instructions to settle any remaining balance.

You can solve this requirement in multiple ways. You can assume that the whole process is going to take place off-platform. The ERP generates the invoice and the email, then sends them across to the client.

Alternatively, you can go with a totally on-platform solution, where the ERP generates the invoice and its line items and MuleSoft replicates that to Salesforce, then fires an email notification from Salesforce containing the invoice and its detailed line item. However, in this case, you would need to deal with at least 10 million invoices every year and at least an equal number of invoice line items with the potential to go up by 50% (assuming half the invoices contain two line items). This means you will need to consider the new invoice and invoice line item objects in your LDV strategy.

However, if you read the scenario’s requirement carefully, you will notice that the requirement is to share the invoice amount only, probably with an invoice number, issue date, due date, and a few other attributes, which are usually included in the invoice header.

You can either store this information in a custom object related to Order or as attributes on Order itself. Both options are fair as long as you can clearly communicate why you chose one over the other.

A related custom object will allow you to store multiple invoices if needed, such as a provisional and a final invoice. It adds one LDV to your data model, but that is fine as long as you are articulating the value of this approach accurately and including this object in your LDV mitigation strategy.

Remember, there is no one correct answer. There are many ways to solve a problem, but you just have to rationally justify your approach and back it up with a solid technical understanding of the associated pros and cons.

Introduce a new custom object to the data model to hold the invoice header details. You will also require a new integration interface between the ERPs and Salesforce to copy the data. As usual, you need to provide all the required information to describe the interface.

Update your data model, list of integration interfaces, and landscape architecture diagram, then move on to the next requirement.

The sales agent updates the reservation status to closed once the inspection is done.

This event chronologically precedes the ones mentioned in the last two requirements. However, that is not an issue here because this requirement can easily be fulfilled. You just need to ensure you draw the right chronological order in your diagrams. The agent is expected to update Sub_Status__c on Order to closed. Make sure not to miss such easy points.

The business process diagram for this process can look like the following:

Figure 12.9 – Car check-out business process diagram

Now that you have solved the fourth business process, move on to the fifth and final one.

Car Status Update and Penalty Settlement

PPA has tracking devices in its cars; they are used to track the car’s location by periodically sending its GPS coordinates. The devices also send additional information such as incidents of harsh braking or overspeeding.

What do you call devices equipped with sensors and other technologies that can communicate with other devices and services over the internet to exchange data? Correct, internet of things (IoT) devices.

There are specific authentication flows explicitly designed for IoT devices, such as the device flow and the asset token flow (which is more suitable for IoT devices that are not equipped with a screen). You covered both in Chapter 4, Core Architectural Concepts: Identity and Access Management.

IoT devices tend to send small chunks of data at a high frequency. This typically results in generating a massive amount of data considering the number of connected IoT devices at any given time.

As a rule of thumb, the Salesforce Core Cloud (also known as Force.com) is not an ideal platform to receive such a massive number of inbound communications, nor the best place to store the retrieved data over a long period.

In some scenarios, you might still be able to pitch Salesforce Core for this role. But in that case, you need to carefully calculate the expected inbound calls and compare them with the likely governor limit at the target org. A safer approach would be to utilize an off-platform solution to receive and aggregate the result. Salesforce Heroku is an excellent fit for such scenarios, especially with some add-on products such as Apache Kafka on Heroku, Postgres, and Redis.

Read the shared requirements and start crafting your solution. The first requirement is as follows:

All tracking devices can communicate over 4G and 3G. They send the car’s location every 30 seconds.

PPA has 5,000 cars (and it is fair to assume that this number will grow). The tracking devices send a message every 30 seconds; this takes place day and night for security reasons.

That means two messages every minute, 120 every hour, and 2,880 every day. In total, that would be 14,400,000 daily messages from all cars. That is over 430 million messages every month.

Clearly, Salesforce Core is not the ideal platform for such a massive number of call-ins or create/update operations. But you still have to do the math to justify your rationale. This is precisely what you are expected to do in your real-life project.

You are an architect, and you cannot simply assume that there will be many call-ins. Based on that, I propose the following solution. Make reasonable assumptions and do the required math; numbers are the best way to deliver an unquestionable message.

You also need to keep in mind that PPA already has a global tracking system. It is used to control car tracking devices remotely. This means it can be used to configure the devices remotely, a functionality that you would likely want to retain. However, the global tracking system is expensive to change or modify and cannot be extended via configurations.

So far, you have not come across a use case where you need to extend it. You can still utilize the global tracking system to receive messages from the car. But proceed further with the process requirements first and see whether that will change. The next requirement is as follows:

PPA would like to gather information that describes the behavior of drivers.

This requirement indicates a need to store a vast amount of data. In addition, there is also a need to analyze this data to create meaningful reports and dashboards. PPA’s global tracking system does not have such capability. It is likely capable of storing the required amount of data but does not have the right capabilities to create such reports and dashboards. You need a BI tool such as Microsoft Power BI, Tableau, or Salesforce CRM Analytics.

You are unlikely to dive into the details of each of these tools’ capabilities during the review board. This is something you would do differently in a real project, but then you have much more time to conduct a proper comparison, probably combined with some proof of concept.

For the time being, you know that you need one of these tools added to the landscape. Feel free to propose other similar tools as well. You still do not have a clear answer on the platform that will store this data, but the next requirement will help you make up your mind. It starts as follows:

PPA would like to use GPS tracking devices to detect possible vehicle theft.

This requirement describes a business process based on the received IoT data. A common use of IoT data is to analyze data and detect patterns, but it can also be used to trigger specific actions based on pre-determined conditions and machine states. It can even go further to enable machine-to-machine (M2M) processes, where one machine determines, based on specific logic, that it is time to communicate with another machine to trigger a remote transaction.

This requirement does not go that far. But there is still a need to introduce custom logic. Which platform would be best suited for such logic? You can probably think of four options:

• Salesforce Core Cloud: Considering the amount of communicated data, this option will be disregarded.
• MuleSoft: MuleSoft can receive the messages and process them based on custom logic. However, it is not the best platform to handle such complex logic, which requires machine-state handling. Moreover, it is also not a platform with a rich UI that is user friendly. This option will be disregarded.
• PPA’s global tracking system: It can be modified to accommodate this logic. However, PPA has clearly communicated that this is an expensive activity. This option is suboptimal.
• Custom-developed app hosted on a scalable PaaS platform: This could be a custom-developed app hosted on AWS, or, more reasonably, on Heroku (considering that Heroku has out-of-the-box connectors to the Salesforce Core Cloud and Salesforce CRM Analytics). Heroku can become the platform that receives all the messages sent by IoT devices. The custom-developed app can add the capabilities of handling the theft detection use case. It can also be extended to handle other use cases in the future, and it can do that in a scalable and reliable manner. Moreover, Heroku Connect can easily synchronize data between Heroku and Salesforce. This allows you to create cases in Salesforce once a theft incident is detected. The case can then be assigned to the right queue, which, in turn, would send an email notification to the queue members. This solution sounds optimal, considering all the factors.

You can now assume you’re using Salesforce CRM Analytics for the previous requirement and make use of the standard connector to transfer the data from Heroku to Salesforce CRM Analytics. Add that to your landscape architecture, update the integration interfaces list, and move on to the next requirement, as follows:

Every day, the violation databases should be checked.

You have three violation databases. You need to check each of them and execute a unified logic based on their data. Which tool can help you achieve this?

The option of developing an Apex Batch job to do this overnight would put you in a very tricky situation during the Q&A. You might feel cornered, and even if you manage to rectify the solution, there is a chance that you might lose some points. This option is mainly proposing a suboptimal pattern that requires extensive custom development (connecting to three different endpoints, exception handling, logging, and retry mechanisms), ignoring the fact that you already have middleware capable of doing this job in a much better way in your landscape. Such mistakes might reflect a lack of understanding of the value of middleware. This is not going to be a fun topic to be challenged on during your Q&A.

Use your middleware. You can schedule a MuleSoft Batch job to run every night, retrieve records from the three databases, execute the desired filtering and lookup logic, and transfer the data to the ERP to generate a new invoice.

Remember to fully describe any new integration interfaces. Also, update your landscape diagram to reflect the latest changes.

The business process diagram for this process has been split into two diagrams to make them more accessible. Feel free to combine them. The car status update process diagram looks like the following:

Figure 12.10 – Car status update business process diagram

The penalty settlement diagram looks like the following:

Figure 12.11 – Penalty settlement business process diagram

Remember that you can add more details to these diagrams if you wish. This is fine as long as you have enough time to do so.

This concludes the fifth and last business process. Have a look at your diagrams after all these updates. The landscape architecture diagram looks as follows:

Figure 12.12 – Landscape architecture (third draft)

The integration interfaces look as follows:

Figure 12.13 – Integration interfaces (first draft)

The data model diagram looks like this:

Figure 12.14 – Data model (second draft)

You have now covered all the requirements related to the business processes. This section is usually the meatiest part of any scenario, so it should be no surprise that it required an entire chapter of this book to cover it.

At this stage, you have satisfied nearly 60–70% of the scenario’s requirements. This will be the base of the next chapter, where you will satisfy the rest of PPA’s requirements, then create the presentation pitch.

Summary

In this chapter, you were introduced to the first full mock scenario in this book. Full scenarios are naturally longer, more thorough, and contain many more challenges and requirements than the mini-scenarios. Yet you learned that the incremental solution methodology is the best way to avoid missing any requirements.

In this chapter, you tackled the first part of the scenario. The business processes are the heart and soul of any digital solution. It should be no surprise that creating a comprehensive solution starts with understanding each business process, dividing it into digestible chunks, and then solving it as a whole.

You came across exciting use cases and design decisions, and you logically selected the right approach knowing that there are other alternatives. You prepared for some potential questions with ready answers, and you picked simple yet scalable architecture that would give you room to change if needed.

You created several business process diagrams that will help you a lot during the presentation by visualizing your solution.

In the next chapter, you will continue solving the scenario and then put together the presentation pitch. You covered a lot of ground in this chapter, but there is still plenty more to cover in the next one.