Skip to content

Platform governance

(Code) deployment.

One of the great benefits of Salesforce is its platform and how you can leverage it in making your business a success. Many business systems allow only a specific and limited amount of flexibility while the force.com platform allows you to develop and extend your own business application.

Few years back building your own 'homebrew' solutions where considered high cost, risk and maintenance.  In many cases these solutions where developed by skilled employees, often poorly documented and only maintained when effected by other changes.  The force.com platform allows you to develop your own applications hosted within the cloud, fully integrated with your CRM while Salesforce takes care of all the infrastructure and platform changes. And you can rely on high skilled resources who develop solutions on the force.com platform every single day.

However using such platform comes with some rules and standards which is being governed by .... Salesforce.

So when it comes to the development of code there's the  object orientedApexlanguage. Once someone understands the concept of the platform, the apex syntax , functions and API calls .... combined with lot's of creativity .. almost anything can be build on the platform. When someone starts developing lightning componentsJavaScriptis also important to know and understand. The word 'Visualforce' (VF)is commonly mentioned in combination with Salesforce and Apex code while Visualforce is theHTMLmarkup language on the force.com platform. All this combined with 'Cascading Style Sheets' (CSS) and you can build state of the art modern and fully integrated solutions hosted on the force.com platform.

Apex code is mainly used for data manipulation and data access. So this means Apex allows you to control the data you store on the platform in various objects (standard or custom). So it allows you to create, change and delete data using all kinds of statements.

Salesforce does not allow you to write apex code in production. So all development takes place in a so called Sandbox environment. There are different types of these sandboxes  each to support a specific goal.

When writing code .... the code the syntax must be valid. Then Salesforce compiles the code making sure the runtime interpreter can understand the code, which then stores it as metadata in your org.

Once you are ready to move your code to production you need to writeunit tests. These unit tests are so called Apex Class methods to facilitate automated testing of every single line of code you wrote.  When such unit test is executed Salesforce reveals which lines of code are actually touched by these tests. This will not only allow a developer to test while writing code but also to think and work with the concept of processing large data volumes, various conditions and code efficiency.

Although unit tests do not submit any transactions to the database, when running unit tests .... whatever data exists in your database is not exposed to the unit test by default. So this means the unit tests need to run thru all scenario's while it cannot reach the actual data.

Imagine you have two profiles setup. One for direct sales and one for trade deals. Both have different workflows while working with opportunities. Testing these two workflows means you need to touch all conditions and constraints for both profiles. And because unit tests do not see data, ..... you need to create you own crash test dummy users as... test data.

In general Salesforce enforces 75% code coverage, meaning 75% of all the apex code lines must be touched by unit tests.  There's no way to deploy any code when the code coverage is below 75%.  In general aiming to reach 85-95% is very well feasable and considered to be the best-practice level of acceptable coverage.

Why would you reach for 85-95% if 75% is also accepted. All apex code is subject to configuration changes performed by, for example, a system administrator. Imagine a new mandatory field was created in production while your test classes do not (yet) populate this field as part of your test data. So once you run the test, the field has no value and the test fails .. dropping the code coverage on potentially several apex classes. This means if you need to move code to production .. the code coverage fails because of the configuration change in production. Having some 'code coverage' percentage available will help you to overcome some practical difficulties. You are prepared for the unexpected.

Architecture Review Board (ARB).

An Architecture Review Board is a governance mechanism designed to ensure that customisations in your Salesforce organisation deliver value, align with architectural principles and do not introduce unmanaged technical debt.

In theory, an ARB brings together business and IT stakeholders to assess proposed changes before development begins. In practice, ARBs often encounter recurring challenges:

  • The ARB becomes a rubber-stamp due to a backlog of items waiting for review.
  • Conflicting goals between IT and the business make the ARB contentious rather than constructive.
  • Review backlogs mean recommendations arrive too late in the development cycle to be acted on.
  • Development teams bypass the process because the ARB has no visibility of items unless they are voluntarily submitted.

Making an ARB effective. The following practices address the most common failure patterns:

  • Publish guiding principles and development standards. Development teams should be able to resolve most architectural questions themselves by referring to documented standards — reducing the volume of items requiring formal review.
  • Automate extraction of items to review. Rather than relying on voluntary submission, automate the identification of Visualforce pages, Apex classes, triggers and other artefacts that meet the criteria for review.
  • Right-size the membership. An ARB should include the minimum number of people who have the authority to make decisions — both business and IT representation, with a clear mandate.
  • Translate decisions into principles. Every decision made by the ARB should feed back into the published standards, so that development teams can self-serve on similar questions in future.

An effective ARB publishes and regularly updates guiding principles, uses automation to ensure the process is not bypassed, groups and filters review items to keep the volume manageable, and is minimally staffed with appropriate authority from both business and IT.