Govern the continuum of UI options actually used against those available on the platform (buttons, mashups, Canvas, Visualforce pages, and Lightning components)

The Salesforce platform offers more configurability than most people can probably remember, and the number of ways in which to initiate bespoke functionality is no exception.

As mentioned previously, Lightning components offer nearly unlimited possibilities, with Lightning Web Components being made even more extensible with the introduction of standard JavaScript libraries such as chart.js, among countless others. However, your governance team will need to understand why a bespoke component was built when a standard component may have delivered the same business outcome. This is important because your bespoke solution will require ongoing maintenance and support, potentially needing to be revisited in the future as the Salesforce platform progresses in its relentless release cadence. In comparison, an inbuilt feature once configured will more than likely require less support and maintenance in the longer term.

This is especially true when integrating with external systems. It is sometimes easy to think only of the data level of integration, making call-outs as necessary when data is required and building a bespoke user interface to interact with that data. An alternative may be to deliver the external system as a Canvas app embedded within the Salesforce UI and then have Salesforce interact with that external application’s user interface. Of course, this is not always possible, or perhaps more often than not a complete set of functions cannot be delivered to the end user due to limitations in the external system’s user interface.

If the necessary knowledge cannot be found within your governance team, the team will need to call upon the appropriate resources to learn what is possible on the Salesforce platform versus what has been proposed by the project team. Ultimately, your governance team is trying to protect your organization from unwanted cost in the longer term as a result of having components developed that basically replicate existing standard functionality.

Govern the sharing and visibility model in code solution

The Salesforce platform will run Apex in the system context, which basically means that it does not consider the user’s permissions when executing the code. This makes sense in most cases because the code your project team has developed may need to operate across the entire data set and not just the data visible to the user.

Your governance team will need to pay close attention to the sharing and visibility model that is utilized within your code. The importance of data visibility was highlighted in Phase D of the Salesforce Platform Governance Method and as such should be your governance team’s initial attempt at governing this area. However, during this phase your governance team is looking for evidence that what was uncovered during the Phase D assessment has in fact been implemented.

Govern the code against security best practices to ensure all Visualforce and Apex code is developed per OWASP standards

As with all platforms that provide a programmatic solution to tailoring end-user functionality, there is always the possibility of inadvertently exposing your organization to security risks. The Open Web Application Security Project (OWASP) provides a set of standards that should be adhered to when developing an application that is exposed to the Web. As the Salesforce platform is an SaaS platform, it is accessible from the Web (in fact, this is the only way it is accessible), and as such any code that is developed by your project is also exposed. Of course, the Salesforce platform offers guard rails when you are using declarative and basic configuration, but once you move into developing on the platform using Apex or other technologies you are opening yourself up to vulnerabilities unless the proper standards are applied.

Given this list, it is easy to see how your project could run into some issues that need to be addressed.

Your governance team should be aware of the OWASP standards or their own organization’s standards to be assured that the project has considered and implemented the proper controls for their bespoke code.

Govern the object-oriented design principles and design patterns that were adhered to when developing the solution (Singleton, etc.)

Apex is an object-oriented language and as such adheres to object-oriented design principles. Lightning components use JavaScript, which is an object-based language; however, some of the principles around object-oriented design still apply.

Your governance team should have a thorough understanding of object-oriented design or access to resources that can perform this governance step on their behalf.

The main thrust of this step is for your governance team to determine whether the appropriate design principles have been applied to the project’s development. Have classes been appropriately used and designed, with appropriate methods encapsulated using public or private? Have attributes also been suitably encapsulated?

The misuse of these principles can be quite easy to identify. If your project is duplicating functionality within several classes, inheritance has probably been overlooked, or possibly abstraction should have been considered. Declaring every attribute and method of a class public can indicate the encapsulation was not fully understood. If many methods have been created that have different names but fundamentally perform similar functions, just using different attributes, then polymorphism is possibly misunderstood.

There are other aspects of the Apex language that could also lead to bad object-oriented design, such as the use of static or the inadvertent creation of a singleton.

Your governance team is really looking at the maintainability of the programs developed by your project’s development team. Object-oriented design principles are fundamentally designed to simplify the reusability of functionality, while protecting the inadvertent modification of that reusable code. This should provide your project teams with accelerated delivery, while minimizing repeated testing.

Govern the appropriate use of the Model-View-Controller pattern

The Model-View-Controller pattern is commonly used for developing user interfaces that divide a program into three interconnected components. This is done to separate internal representations of data from the ways the data can be presented to and accepted from the end user.

The model represents the data and its storage, while the controller represents the processing applied to that data, such as a business process. The view is the representation of the data to the end user.

The Model-View-Controller design pattern can help you gain reusability from your investment in developing code. Your projects can deliver multiple user interfaces onto a single controller without having to re-engineer that controller.

Visualforce enforces the Model-View-Controller pattern in that it has a mark-up language very similar to HTML that controls the user representation, which is the view. A controller represents the processing of the data inputted by an end user before it is updated in an object, which represents the model.

Using Lightning components, whether Aura or LWC, the programmer could bypass this pattern, as they could in theory make a direct call from the client to a back-end server-side API, as an example.

Your governance team should be familiar with the MVC design pattern and look for instances where this pattern should have been used. Obvious examples breaching this design pattern are Lightning components that perform business logic, handle the display to the end user, and then push the data model directly to a basic Apex server-side class that really doesn’t do anything.

Govern any Apex controllers against the technical standards (extensions to standard controllers and custom controllers)

All Salesforce platform objects come with a pre-built standard controller, even custom objects. These standard controllers provide the basic functionality that is required by the Salesforce user interface to interact with the object that the standard controller is associated with. For example, if you hit the Save button on an account using the standard Salesforce user interface, the behavior will be the same as if you had your own button within your Visualforce page that triggers a save. You associate the appropriate controller within the Visualforce markup.

As you would expect, the Salesforce platform allows your project teams to create their own custom controller or extend a standard controller.

The main difference between a custom controller and an extension to a standard controller is that your project team will need to develop all the functions it requires within a custom controller, whereas by extending a standard controller, the project inherits the standard functions and then can apply additional functions.

Your governance team must be capable of reviewing the use of extended and custom controllers to determine whether they have been used appropriately. Additionally, your governance team should be assured that data visibility and access have been appropriately considered, given the system context within which Apex code normally executes.

Additionally, your organization may have guidelines and standards to adhere to. If your project teams are building many custom controllers, your governance team will need to consider appropriate standards for naming the functions within those controllers. From a maintenance perspective it would not be wise to have each project use different standards.

Govern the usage of custom settings and synchronous vs. asynchronous patterns, and all the available execution contexts (e.g., batch, trigger, callout, etc.)

Your project may have used custom settings to store configuration information or perhaps credentials for authentication with external systems. Your governance team should review the need for custom settings and the purpose behind the decision; for example, if credentials are being stored, why was this preferred over the use of a named credential?

In the main, custom settings provide some flexibility in terms of how the custom setting data relates to the current user or otherwise. Additionally, when creating sandboxes, the custom settings data is not replicated. Custom settings are effectively a custom object in terms of the Salesforce metadata and should follow your organization’s naming conventions and standards.

As with most modern platforms, the Salesforce platform allows code to be executed synchronously and asynchronously. The main difference is that when code is executed asynchronously the code that triggered the asynchronous code will continue to execute regardless of what the triggered code is doing.

Your governance team will need to assure themselves that the project team fully understands the implications of this, especially in the context of making call-outs to external systems. Additionally, the synchronous code should be reviewed to understand whether this is constructed in the correct manner. If the user is kept waiting due to synchronous code, this is possibly not going to be a great user experience. Additionally, the Salesforce platform will not allow Apex code to run continuously, but rather will timeout long-running processes. Your governance team will need to know whether the project team has taken these issues into account, especially when making external calls, where response time is not always guaranteed.

The Salesforce platform can run Apex in a number of contexts. Each context introduces limitations and requires some awareness of what is possible for the developer when constructing code. For example, you cannot perform Data Manipulation Language (DML) statements before making a call-out to an external system, which might be frustrating to some, especially when multiple call-outs are made and it is desirable to write the data into Salesforce objects.

Additionally, while the Apex code is running in a batch context, your developers are restricted in the number of DML statements they can perform. Therefore, performing DML within loops for Apex that are intended for batch execution is not acceptable. Your governance team should be looking for assurance that the project team has taken the correct steps to “bulkify” their Apex code if it is destined for execution in a batch context.

Apex triggers are a powerful solution to performing additional processing before or after data is inserted, updated within, or deleted from the Salesforce platform. In many cases, the same actions can be performed using Flow or Process Builder. Your governance team should be assured that your project team is using triggers appropriately, and not diluting the implementation across multiple platform capabilities.

If Apex triggers are a preferred solution to performing actions based on a specific set of circumstances, your governance team should recommend using a trigger framework. This is especially the case if multiple project teams are looking to add trigger code to a number of standard or enterprise objects. This will avoid projects’ clashing with one another in code, as well as make sure that each project’s trigger code is discrete.

Govern the usage of batch Apex and the flex queue

Developing batch processes take careful planning and consideration regarding the number of batch jobs created and the size of each of those batch jobs. It is very easy to hit issues in production if the amount of data being processed has not been considered carefully.

Govern the Apex / Visualforce solution against the governor limits

As with all aspects of the Salesforce platform, governor limits apply to Apex and Visualforce, perhaps even more so. The governor limits for Apex and Visualforce have a larger impact on the execution of your code than does a consumption of resources within a 24-hour-type limit, as seen in other limitations of the platform.

Your governance team should have a good understanding of the main governor limits that commonly affect Apex and Visualforce, and with Apex, the contexts in which the Apex is being used.

Visualforce limits are slightly simpler than the Apex limits, and are mainly focused on the number of records the Visualforce page is dealing with or the amount of data.

Your governance team is basically looking to be assured that the project team has made a concerted effort to understand the use of the Visualforce and Apex code that they have developed and that it will accommodate those use cases. Additionally, your governance team will want to understand the edge cases that the project team has considered so that it is clear as to when problems may be seen in the production environment. This at least will give the operations teams something to monitor, and they can raise the appropriate concern if production workloads are edging toward causing problems with the project’s implementation.

Govern the order of execution of transactions within the platform (specifically against pre-existing triggers)

The Salesforce platform can have numerous automation processes running when something happens to an object. This could be due to data changes or the insertion of a new object record. As you would expect, Salesforce has implemented an order of execution to the processes that can be triggered by changes occurring on the platform.

The order of execution can create a lot of confusion if it is not clearly understood, and can generate many hours of debugging if the results your project team expects are not what is being experienced.

Lastly, your governance team should be assured that your project team has performed the relevant testing, taking into account edge cases and with sufficient data volumes.

Govern the quality of test coverage (required for production deployment, call-out testing is a special case)

Test coverage is critical to the successful deployment of your project’s Apex code. As mentioned previously, the Salesforce platform enforces test coverage on Apex code. Your project’s Apex code must reach a test coverage of 75% before it is allowed to be deployed into the production org.

Your governance team should review the test coverage results from your project’s test deployment. Where code has not been covered by the test classes, your governance team should review to understand whether this is acceptable or not. Where call-outs are made, the project team should put in additional effort to simulate the endpoints in the call-out.

Ultimately, your governance team is looking to understand whether the project has taken the development of Apex test classes seriously, or simply manufactured tests to meet the 75% code coverage requirement.

Govern the approach to error/exception handling

Most programming code includes a significant amount of error and exception handling. It is widely accepted that up to 90% of a program’s code will be error and exception handling code rather than business logic. The Apex programming language is no different.

Your governance team will need to be assured that the project team has implemented sufficient error and exception handling within its code so that the end user does not experience errors and therefore report them to the operations team.

As an example, try/catch blocks should be placed around any SOQL. It is easy during development to assume that a consistent result will be seen, given the limited data most development environments have. However, once the code is deployed into the production org, it is often the case that issues arise because the developer made certain assumptions and therefore did not properly check for error conditions.

Your governance team should be wary of any hard coding within the Apex code; for example, making assumptions around the name of a RecordType when creating a new object record of a certain type.

Equally, your test classes (as discussed earlier) should be testing that error and exception handling has been implemented correctly.

Govern that performance and scalability best practices have been considered within Visualforce pages and Apex code (performance profiling, use of static resources)

Your governance team is looking to be assured that the project team has taken the time to consider and test the performance of its application. Your project team may be using the standard tools mentioned previously, or your organization may have invested in alternatives. Whatever solution your project teams have available to them, performance testing—similar to the unit testing of Apex code—should be a key deliverable in your projects.

As with most governance roles for any other platform, your governance team is trying to establish that the project team has undertaken its due diligence in terms of understanding the impact its application has on the Salesforce platform given the potential usage it is going to see.

It may be that your project team has created an application for a specific set of users at a specific scale, or at least is comfortable that the application will work as expected up to a particular usage. This is a good approach in setting boundaries for application usage. Taking this approach could trigger future testing if, for example, your company acquires another and you are suddenly increasing your user base.

Govern the Apex and Visualforce performance to include LDV scenarios (Pagination, JavaScript remoting)

Your governance team may come across a project that uses large data volumes (LDVs); however, the definition of a large data volume is not exact. Your project team may be looking to create tens of millions of records with a relatively simple custom object, or hundreds of thousands of records with a very complex object.

Your governance team is looking to understand the steps your project team has taken to accommodate its large data volumes. In most cases, when dealing with LDVs, it is normal for processes to take longer to execute; after all, there are many more records that could be affected by any changes that your project’s users make or other processes that the project creates.

The Salesforce platform provides some features that your project team can take advantage of when dealing with large data volumes. JavaScript remoting provides your developers with the ability to create asynchronous calls to your Visualforce controllers so as to lazy-load data, or load data as it becomes relevant to the end user. Pagination allows your project to request pages of information rather than everything, providing your end users with the ability to move through pages of data at their own pace, rather than long lists of data that take a while to load.

Your governance team will be looking for assurance from the project team that where large data volumes are expected, the project has taken steps to provide a means for the end user to interact with that data in a sensible manner.

Govern the use of external web technologies and complementary UI technologies

With Visualforce and Lightning components your project teams can leverage libraries that are available from multiple developers. Lightning components have made it easier than ever to add libraries to the Salesforce platform’s user interface to create a user experience that end users now expect from a modern Web-based application.

Your governance team will need to pay close attention to the external libraries and technologies that your project team has utilized and from where these external libraries and components have come. The AppExchange is a great source for Lightning components that can be “plugged” into your project’s Lightning pages. Additionally, if your project team is building its own Lightning components, then third-party JavaScript libraries may be of use to provide specific features and functionality.

Although your governance team is not going to try to restrict what the project team is attempting to deliver, it will need to be assured that the proper commercial and support requirements have been reviewed across the entire project’s solution. Where a third-party JavaScript library is in use, the project team should be able to provide assurance that the library complies with your company’s commercial and security requirements. It is likely that your supplier or purchasing department may need to be involved to put the correct procedures in place to pay any subscription costs for using the third-party components and libraries.

Your security team may need to review the data policy of the third party to be assured that there is no possibility of data leakage and that the third party is a reputable organization.

Additionally, your governance team will be looking to understand any support requirements for business needs across all the components that are being used in the development of the solution.

Govern multi-language support and determine the appropriate solution has been used to support globalization

Your governance team will need to understand the language capabilities of the Salesforce platform.

To provide further flexibility, the Salesforce platform provides a tool called the translation workbench. When enabled, this tool allows your project team to specify languages for translation, assign translators, and manage those translations through the workbench or bulk translation.

As language support can have a great effect on the end-user community, your governance team will need to be assured that the project team has understood the language requirements from the business, then compared those requirements to the capabilities of the Salesforce platform given the three options mentioned previously. If additional work is required to provide translations, then additional testing will be required. Your business will also need to understand what is possible and any limitations for specific languages.

Govern the options and techniques used to make programmatic components maintainable and reusable on the platform (custom settings, skeleton templates, custom metadata types)

Creating maintainable and reusable components is the desire of nearly all development projects. It is unlikely that any programmer sets out to deliver code that is impossible to maintain. However, not all programmers intend for their programs to be reusable.

Creating reusable components typically requires more thought and effort than building a component meant to be used solely at the project level. However, your governance team may be the only group within your company that has a holistic view of all the projects and what is being built. Recognizing reusability could save your company significant money, while delivering functionality to the business more quickly.

However, implementing reusability within your company may not be as straightforward as many would hope. Once a component becomes reusable, it usually means that more than one project makes use of the component. This simple action typically makes way for the inevitable question: “Who will maintain the component on an ongoing basis?”

Initially, your company may be able to support reusable components at the project level, depending on the workload of the project-allocated developers and the impact of issues and enhancements from other projects using the component.

If your company has identified a number of reusable components, it may be time to consider a centralized development team that has the sole task of maintaining and enhancing, and potentially delivering, new components in the future to all other projects. This configuration does, however, come at additional cost.

It is good practice for your governance team to keep in mind that what your project team is developing may one day be reused somewhere else. This helps elevate the quality and avoids those “good enough” scenarios. That is not to say that your governance team should go to extremes to make sure everything developed within your company could be reused, but it should at least make some effort to keep that possibility alive.

Code standards should be in place and adhered to. This is especially true for Apex, where you are aiming for all code to at least follow the same standards in naming convention and code layout. This will provide for a more easily maintainable code base, in that all developers will be able to read the code that other developers have written without getting frustrated that every class they look at is different. Your coding standards should extend to comments and any header-type documentation that should be present at the top of every class’s source code. Providing useful information about the changes that have occurred to a specific Apex class via the use of the header and a brief change list could save other developers a lot of time trying to understand what has happened to the code and why.

Your governance team should make sure that your project team has used the correct solution given what the project is trying to achieve. Make sure that any custom components are not used to define reusable Visualforce pages. Your project should use one of the two templating methods to reuse the content of an entire Visualforce page.

Ultimately, your governance team is looking to be assured that the project has used the appropriate solution to meet the business requirements, taking into account maintainability and best practices on the Salesforce platform. Additionally, it may be that your governance team needs to take into account an element of pragmatism to assist the project team in meeting project timelines. Taking a dispensation approach for any areas where a project has strayed from best practices may be a good approach, allowing the project to meet project timelines and refactor any areas where corners may have been cut to meet a deadline.

Design and Functionality

Performance and Scalability

Maintainability and Reuse