General Architecture

As shown in Figure 2-2, general architecture is the initial area in which to focus your governance activity.

When you are governing the general architecture of an application, your governing body looks to understand the construction of your application and whether it has considered a number of key points.

Has the project considered whether the application has been designed for optimal performance, scalability, usability, and ease of maintenance?

This is heavily context driven, as understanding the context in which your application will be used is important. There are big differences between constructing an application targeted for a few hundred concurrent users and doing so for tens of thousands of concurrent users (yes, the Salesforce platform can inherently scale from one extreme to the other). In general, the more users, the more processes are active, and the more data are created and consumed. These all play a part in the performance and scalability of your application.

If the application has an apex batch element to it, knowing whether you are going to process thousands of records or millions of records makes a big difference in how that aspect of the application should be constructed. Additionally, you want to govern the application in that context. If the application was only designed to be used by one hundred users, then it should be governed within that context. Equally, if the application was designed for a hundred thousand users, the governance should perhaps be a little more stringent. That is not to say the method of governance should be different.

Maintenance is a big issue. It can be very easy to create a mess in any platform, and Salesforce’s platform is no different. When governing the application architecture, determining the maintainability of your application is key, not only in the context of maintaining the application in its own isolation, but also in its coexistence with other applications that reside within the same Salesforce org.

The ability to customize standard components within the Salesforce platform is second to none, but that customization becomes a bottleneck when several projects all try to modify those standard components. Take the Account object as a simple example. All too often, different projects try to trigger different processes based on things occurring to an account (like its creation). These things need to be considered during the governance process. Equally, it is not desirable for every project to invent its own Account object in an attempt to avoid the governance required on standard objects used across multiple projects (yes, we’ve seen this happen).

Govern the appropriate use of declarative and programmatic functionality.

This is key and often a difficult area to govern; after all, governance can be subjective. However, the main goal when governing declarative versus programmatic functionality should be to remind ourselves of what was just discussed: maintenance. If you have a development team that has transitioned to the Salesforce platform from more traditional development technologies, then it would not be surprising to find a high number of programmatic solutions being used.

This is where the resources governing the organization’s Salesforce solution really do need to know the platform. Understanding that a declarative solution could have been used rather than a programmatic solution is very important. Typically, programmatic solutions are more costly, simply because the resources needed to maintain them are more expensive, and working at the coding level is usually more of an art form. Therefore, reading other people’s code is not always straightforward.

This point cannot be stressed enough: having someone (or multiple people) within your organization who understands the capabilities of the Salesforce platform is paramount; otherwise, you run the risk of duplicating existing functionality, or going about building a solution in a less-than-platform-friendly and less-efficient manner. It’s clear that duplicating existing functionality is time and money wasted.

Govern the considerations for a single-org or dedicated-org strategy.

Depending on the scale of your enterprise, there could be numerous applications being developed or in operation on a single Salesforce org at any one time. If this is the case, careful consideration must be given to the coexistence of these applications. This coexistence can take several forms.

Firstly, the use of standard objects. Have the record types been used appropriately, for example? If triggers exist on standard objects within your application, how will you manage them across projects and applications?

Secondly, the duplication of functionality should be minimized. In some cases, objects might be created at the project level, and over time they might become promoted to enterprise objects so that they can be reused by many applications spanning multiple projects. This could also apply to components and services. Recognizing that this scenario will occur, and in fact encouraging it, should be a key part of the governance process.

Thirdly, the consumption of the platform limits should be carefully considered. Governance should consider any platform-limit consumption in the overall landscape of your enterprise. Salesforce has several limits that may be impacted by the application’s architecture, such as API calls or the number of custom objects. Projects that want to consume many specific platform limits may require further consideration in terms of the architecture.

Govern the usage of license types (capabilities and constraints).

Make sure the functionality and features used by your application are appropriately aligned to the licensing available, or have a plan to enhance the licensing as required. Licensing could be at the user level. In addition, the edition of the Salesforce platform that is being used will also carry limitations.

If multiple applications are being deployed by different projects, then some consideration around fairly distributing the licensing may be required so as to avoid one project’s consuming the premium licenses, leaving nothing for the follow-up projects your organization has in the pipeline of work.

You will need to question your project’s longevity, as well as consider how the application usage may change over time and whether that has been factored into the long-term maintainability of the application and associated costs.

Govern the data modeling concepts and implications of database design.

Standardizing your approach to documenting a data model will help accelerate governance and help your governance team to hone their skills in particular areas.

It is easy to create a poor data model within the Salesforce platform. A low-code approach can sometimes give people the false impression that this means low skills. That is not the case. To create a performant and maintainable application, your data model should be fit for the purpose.

Start by making sure you have named your objects in an informative way. Using nouns from the business domain can sometimes help you determine a good name for a custom object. Make sure you have applied the same principles down to the custom fields within your custom or standard objects. If you are supporting multiple projects that are working on the same Salesforce org (coexisting), you may want to enforce a name-spacing solution. See the resource base for more details on this.

Consider the search requirements of your data model. Salesforce by default allows you to search text fields on an object. Fields with a formula type are excluded from search.

Use record types within your custom or standard objects if you are using a single object to support multiple business requirements and processes. For example, you may have internal accounts and external accounts, which are treated differently. This could be modeled as two record types.

Select the correct data types and sizes for your custom fields. Although there is nothing stopping you from being over generous in sizing text fields within the constraints of the Salesforce platform, it is good practice to keep things sensible, remembering that Salesforce takes a broad 2K assumption of record sizes, except where rich text and file uploads are concerns. Additionally, the PersonAccount standard object is a mash-up of Account and Contact objects, and as such will consume 4K per record. However, the definition of “sensible” is beyond the scope of this book.

Once you have a clear understanding of the objects and fields used, you will want to move into the relationships the objects have with one another. Again, you can lean on the business domain to get an understanding of the relationships between objects. What is important to remember from a governance perspective is the types of relationships, taking a longer-term view of how the application will work and the types of data that will be created.

Keep platform limits in mind; for example, an object can have up to two master–detail relationships and up to twenty-five total relationships. Look to best practices, such as limiting the number of child records in a master–detail relationship to 10,000 to avoid record skew. Most of all, create your own best practices based on what works from the experience within your organization. This is highlighted further in Phase B.

Take into account the testing required for the data model being governed. From a governance perspective, you should encourage your project to have testing taking place. As such, test data will be required to underpin that testing. Although not something the governance process should take a firm view on, it is important to make sure that it has been considered. As part of the governance checks and balances, a complex data model by its very nature creates complex testing requirements, and therefore a complex set of test data. So, as you’d expect your project to manage its code in a secure and structured manner, you would expect the project to do the same for test data. This is highlighted further in Phase I.

Lastly, consider the complexity of data access. Does your project require complex data visibility? This is highlighted further in Phase D.

Govern the usage of reports and analytics (platform considerations and trade-offs).

Leading on from the data model, reporting becomes an important aspect of your project. It is more than likely that your business will want some level of reporting and analytics back from all the hard work it has put into creating data via the application your project has built. A complex data model more than likely creates complexity in creating reports. A data model that is highly normalized might be difficult to report on.

The more complex your data model, the slower reports will be to run and analytics will be to execute. Keep in mind the reporting strategy of your organization. Do you have standard tools that should be used in certain circumstances? Is the project introducing a new product (e.g., Tableau) that will need to be managed and governed? In the long term, who is responsible for creating reports?

Govern the usage of external applications (Salesforce AppExchange and application integration).

It is more common than not for a project to require the use of an external application. Such an application could be a pre-built component from the Salesforce AppExchange, or an existing system within your organization that contains important information or is part of your end-to-end business process.

When it comes to AppExchange components, from a governance perspective, you are going to look at a few areas.

Does the AppExchange component meet your security requirements? You may need to seek further clarification from your project regarding the due diligence they have performed in determining the security credentials of the component they want to use. Salesforce undertakes a significant number of checks for any component that is available within the AppExchange, but those may not be completely in line with your own security requirements.

Does the AppExchange component meet your commercial requirements? There may be support requirements that are needed by your business. If your application is required 24/7, and you provide in-house support to deliver this, you will need to make sure that any components you use within your application are aligned to these requirements.

The method will detail more areas you will want to govern to make sure you are happy that an AppExchange component is aligned with your organization and business requirements.

Integrating with external systems is a complex area. There are many tools on the market to help simplify this process (such as Salesforce’s MuleSoft platform). However, as with the data model, integrating with external systems carries a number of complexities. In fact, the data model may extend into external systems, where data resides elsewhere in your organization’s portfolio of systems. From an application architecture perspective, you are going to look at the relationship between those systems and the integration needed. As mentioned earlier with the application usage requirement of 24/7, you will need to make sure any integration with external systems is in alignment with your business requirements. If an external system only offers “near-time” integration, this may not be appropriate for a business process that has an end-user waiting.

Overall, from a governance perspective, you are looking to understand the holistic application architecture. What systems are integrated to deliver your end-to-end business requirements?

Phase E will go into more detail as to how to go about governing integration with external systems.

Localization / Global Deployments

As shown in Figure 2-3, localization and global deployments is the next area in which to focus your governance activity.

The Salesforce platform is designed to be used by any business, from a local corner shop through to a multi-national enterprise. As such, it offers many features to support its being used by people all over the world. These features include multiple currencies, translations, and multiple languages.

Fortunately, from an enterprise perspective, Salesforce has taken all the hard work out of deploying the solution to your organization, as they already have a globally accessible deployment of the platform. This leaves you to focus on the business of multiple users in varying countries getting the most out of the solutions you deploy on the platform.

Govern the usage of the platform’s internationalization functionality (multiple currencies, translations, and languages).

From a governance perspective, you are focusing on the end-user community to whom the project is hoping to deliver its application. Given this, your governance should consider whether the project has covered the languages and currencies that are required for locations in which you do business.

These are just a few examples, so you must consider the implications to your Salesforce org when multiple currencies are enabled. Additionally, if you have multiple applications developed and delivered by many different projects, regression testing or some level of impact assessment should be made on those projects.

This may be complicated further if the original projects that created those applications have effectively shut down and are in maintenance mode only. The project that is instigating the multiple-currency change may have to provide support for testing and remediation on projects that are no longer actively in development.

There are two aspects to supporting multiple languages. Setting the language of the Salesforce user interface changes Salesforce to a supported language. This will change the language for any Salesforce-supported text and fields.

Projects that have created data labels for custom objects may introduce the need to use the Salesforce Translation Workbench. This tool allows the project to maintain translated values for metadata and data labels. This will drive another artifact to be potentially managed just like the source code for the application in question. Additionally, the project may be looking to import translation files, so testing and assurance may be required. Governance should look to the project to provide the correct assurances that they have assessed any risk associated with a change against any existing projects deployed within your Salesforce org.

Workflow & Processes

As shown in Figure 2-4, workflow and processes is the next area on which to focus your governance activity.

As touched on previously, Salesforce offers a lot of workflow and process automation out-of-the-box tools. This can create some complexity for organizations that have multiple applications deployed by multiple projects. This is especially true for any sharing of standard enterprise objects.

It can become quite difficult to unpick a Salesforce org that has allowed projects to create automation across objects without any type of control in place. The classic scenario that everyone wants to avoid is the circular process, where a change triggers automation that then triggers other automation that then has a trigger that starts the whole thing over again.

From a governance perspective, you are looking at this in the entirety of the Salesforce org, especially if you have multiple projects that must coexist. At the project level, you want to make sure the appropriate automation solutions have been used. Keep in mind that multiple services on the Salesforce platform can achieve the same results.

It may be useful to create a policy around Workflow within your organization that provides guidance on appropriate use. You want to avoid building up a maintenance issue where several applications are conflicting over rules for the same objects.

Govern the use of Workflow capabilities (rules, tasks, emails, field updates, and approvals) within the solution.

When assessing the workflow, consider other automation that may have been introduced by earlier projects. Apex triggers could cause a conflict with a workflow rule. Equally, although Workflow only supports a single if/then statement, the same functionality could be achieved in Process Builder.

Govern the use of Flow by taking into account the limitations and considerations of a Flow solution.

Flow provides a declarative solution for complex automation tasks and as such can be used to develop very complex solutions, which can also include end-user interaction. As such, you should carefully consider the flows developed by a project and how these fit into your larger Salesforce platform usage.

With the complexity that can be achieved in Flow, it deserves the same attention from a governance perspective as perhaps Apex would.

Govern the capabilities and limitations of Salesforce actions.

Salesforce actions are a great way to add quick solutions for your end users. However, from a governance perspective, you want to make sure that any actions added to standard or enterprise objects are relevant for the end-user base. It may not be appropriate for all actions to be available for all end users.

As with making sure you have appropriate actions for the correct end-user base, you will want to determine whether the project has clearly defined the target end-user devices that are in scope for the actions.

Govern the use of Process Builder, taking into account the limitations.

In some ways, Process Builder is quickly replacing Workflow. It can do pretty much the same thing, but has many more features, though it is still more limited in functionality than Flow. However, Process Builder has some key capabilities that warrant more governance.

With Process Builder it is possible to invoke Apex or a flow. This adds complexity to the governance process in that you will need to determine whether the project is creating a challenge in the future. Set out guidelines regarding the use of Process Builder and perhaps limit what you will allow your projects to do. This will largely depend on what sort of organization you are building. If you have a single Salesforce org, with multiple business areas creating applications for that org, you will need to implement strong governance and controls so as to avoid conflicts between applications.

As Salesforce has no means of cleanly separating each application running on an org, any automation attached to standard or enterprise objects is subject to challenges later.

Formulas

As shown in Figure 2-5, formulas is the next area in which to focus your governance activity.

Govern the use of advanced formula features and check against limitations.

Some effort should be dedicated to making sure your projects’ formulas are not exposing data that should not otherwise be seen by certain end users.

Cross-object formulas that reference a field on another object and display that formula in a page layout are visible to end users even if they do not have access to that object record. From a governance perspective, you must ensure that your security controls are not by-passed in any way by the formulas used by your projects (see Figure 2-5).

As part of governing the application, you will be looking to make sure the project has done everything possible to avoid these issues; for example, preventing division by zero by using an IF function that determines whether the value of a field is zero before proceeding.

You should consider the limits that are being reached during the governance of formula fields and look at whether the project has worked around limits, such as the character limit, by creating separate formula fields and referencing them in another formula field. This is not an issue as such but may indicate complexity that sets the scene for on-going governance of the project. Additionally, there are hard limits for cross-object formulas, so taking note of how close to the limit a project is taking an object is important for both standard and enterprise objects.

Govern the use of hierarchical custom settings in a declarative solution.

If the project is implementing hierarchical custom settings, you will need to make sure that the correct setting is returned for the users and profiles within your organization. The project will need to provide assurances that any settings implemented provide end users with the correct value given their profile.

Remember that hierarchical custom settings provide different values at the organization, profile, and user levels. The Salesforce platform provides values in a priority order of user, profile, and then organization level.

Files & Social

As shown in Figure 2-6, files and social is the next area in which your governance team should focus their efforts.

Govern the application’s use of files and content, including Chatter files, attachments, content, and knowledge.

There are a number of key aspects to look at from a governance perspective when examining file and content usage (see Figure 2-6).

Storage capacity will be impacted. Ensure there is available capacity on the Salesforce platform initially, and also look at how that capacity will be consumed over the lifecycle of application usage. You should look for a capacity model from the project to detail the numbers and sizes of content being used. Depending on the way files and content are managed, a file could be as large as 2GB.

Given the capacity model, what if any archiving solution will the project have in place to age out old files or content as it becomes unused? How will that be achieved in the longer term, and who will own this responsibility?

Visibility of content and files—you will need to address this with the project to be assured that they have used the correct solution to achieve the content visibility desired.

Salesforce does not provide an anti-virus solution for content loaded onto the platform. It will be your organization’s responsibility to ensure you are protected from any viruses. This might be an important consideration when dealing with files uploaded from your customers rather than internal files.

Govern the integration with social capabilities of the platform.

Over the last few years, Salesforce has also removed a number of key social media platforms, such as LinkedIn and Facebook.

Additionally, Salesforce offers authentication to your customers by using their social media accounts to authenticate to your Salesforce site. You should take some time to assess the security implications and adherence to your own internal security policies to make sure your projects are aligned.

Approach

To help accelerate an application’s governance adherence assessment, a “whitelist” approach is taken, where specific attention is given to determine whether the application only contains certain characteristics so that an optimal approval route can be made through the governance process.

The exact content of the whitelist will be part of the resource base and of course should be tailored for your organization’s requirements.

Fundamentally, this phase determines whether the application’s architecture is within the parameters that the organization deems acceptable. Most organizations will have a technology policy, and therefore this phase should take that into account. For example, an organization may have a standard regarding integration with external applications, and thus this phase should determine whether that standard has been adhered to; for example, all integration must be done via an integration layer rather than peer-to-peer.

As the governance of the application uses the resource base to determine adherence to standards, the resource base should be a reference point for all development on the Salesforce platform. The resource base forms the basis in part or in whole for all standards used throughout the organization for development on the Salesforce platform.

This phase needs to be as objective as possible. There will be some cases where a subjective view will be unavoidable. In those cases, it should be a discussion point. Where this does occur, it could indicate a lack of clarity in the development standards and technical policies used.

The project team should present the application architecture covering the following suggested inputs to the governance team. This should be an interactive session to allow all parties to fully understand the solution being presented.

To avoid governance’s being applied at the end of the construction of an application, Phase A should be used in an iterative manner. A project should present its initial view as to how they are going to construct their application and allow the governance team to highlight any areas of concern.

Inputs

It is up to your organization to determine the formality of the artifacts just mentioned. Some organizations will look for formal notation to be used in the data model, while others will be happy with a high-level slide deck. This governance method should not force projects to undertake more work just for the sake of governance, but rather the governance process should utilize the standard artifacts your organization expects any project to produce.

Steps

At the application architecture level, the steps are specifically high level and attempt to cover the broadest aspects of the project team’s application. The governance team is making sure the project team is heading in the right direction in terms of the construction of their application.

Outputs