Over the past few years, Salesforce.com have been making a big push into enterprise application development.

In previous articles, I’ve shared why I believe Force.com is a great place to build applications, as well as made recommendations regarding the architecture and development environment.

This article will focus on standards, providing a set of recommendations when positioning Force.com as an enterprise application platform. I will however assume you have read the previous articles (outlined above).

Why Standards?

Standards are important to ensure the platform remains secure, supportable, accessible and reliable. I’ve seen organisations start building applications on Force.com without first establishing any standards. This is a dangerous path, which quickly becomes problematic when scaling.

Prerequisites:

These standards are not a replacement for the Force.com developer materials created and maintained by Salesforce.com. These materials can be found at developer.salesforce.com.

I also believe it’s important to ensure all development teams writing APEX have Force.com expertise and experience, preferably “Salesforce Certified Platform Developer I”, “Salesforce Certified Platform Developer II” certifications (or equivalent).

Citizen Developers (building declarative applications on Force.com) should have completed the “Developer Beginner” and “Developer Intermediate” Trailhead trails.

Namespacing:

Namespacing will ensure that you have clear logical separation between your applications, helping you to deploy, maintain and support the environment.

If the asset is unique to a specific application, the API Name must include a unique four-character prefix. For example, if my application is called LifeinTECH, the prefix could be TECH_.

If the asset is reusable (can be shared across multiple applications), the API Name must include the GLBL_ prefix. All GLBL_ assets must be maintained within a searchable registry and include the relevant governance (e.g. who can consume and modify the asset).

Assets include Objects, Fields, Classes, Test Classes, Validation Rules, Permission Sets, etc.

Org Wide Defaults:

By default, all objects must be set to Private.

System Administrator:

In production, only the org admin team (e.g. platform support) will ever be granted System Administrator privileges.

However, development teams will have System Administrator privileges in development sandboxes.

Profiles:

I recommend making Profiles a reserved asset, owned by the org admin team. As a result, Profiles must not be created or modified by development teams. Instead, Permission Sets and Field Level Security must be used to drive application security.

With this recommendation in mind, I would pre-deploy a minimum of three Profiles, which would be owned by the org admin team:

  • Platform Profile: The default Profile for all users.
  • Integration Profile: The default Profile used for integration (API Only) users.
  • Loading Profile: A special Profile used for data loading activities via Apex Data Loader.

The Platform Profile would be assigned to all users within the org by default, but offer no application access. The Integration Profile is an “API-Only” Profile, used specifically for integrations. The Loading Profile is used for data loads, usually via Apex Data Loader, this Profile will only be assigned to specific users for planned periods.

The only time a Profile can be modified by a development team, is to create a new Page Layout for a Standard Object. When this is done, the development team must also create a Record Type, secured by a Permission Set to restrict the Page Layout to only their application.

Permission Sets:

Permission Sets are the primary method used by development teams to enable access to the application.

It is likely that a single application will have multiple Permission Sets, used to enable different levels of access to the application. For example:

  • Admin Permission Set: Providing full access to the application and data, used by application support teams.
  • Power User Permission Set: Providing enhanced access to the application.
  • User Permission Set: The default Permission Set for all users, providing standard access to the application.

Permission Sets offer a lot of flexibility; therefore, I would also recommend defining as set of standards outlining which options a development team can enable.

Field Level Security:

Development teams must configure Field Level Security for all of their applications. Field Level Security must only grant access to fields that are required by the users of the application. This approach helps to ensure fields are not accidently exposed to users when working with shared assets (e.g. Standard Objects).

Roles:

The Role Hierarchy (in my opinion) is the least flexible part of Salesforce.com, as it’s really positioned for CRM usage, not application development.

In my experience, it’s difficult to deliver a single Role Hierarchy that meets the needs of all applications (this is especially true in large enterprise organisations).

In this scenario, I recommend that you don’t use Roles and/or the Role Hierarchy when developing applications. Instead other sharing mechanisms must be used, for example Manual Sharing, Criteria-based Sharing and/or Groups.

Sharing Rules:

Sharing must be achieved via Manual Sharing, Criteria-based Sharing and/or Groups. Development teams must avoid nesting Groups, as this creates challenges for user management and access auditing.

It is the responsibility of the development team to define which users should be added to any Groups, including Public Groups.

Apex-based Sharing is acceptable, but it must first be discussed with an org admin, as it can be difficult to identify data being shared via Apex.

Where possible, I recommend managing security (Permission Sets and Sharing) via integration with a pre-established directory service (e.g. Active Directory),

Reusable Assets:

Standard Objects and assets prefixed with the GLBL_ designation are viable for reuse.

Development teams can consume these assets without restrictions, however they must not modify the asset. If a development team needs to modify a reusable asset, they must first gain approval from the org admin team.

Test Classes:

All Classes must have a corresponding Test Class, which must reach a minimum of 85% code coverage (10% above the Salesforce.com required minimum).

Test Classes must include meaningful asserts where possible. Creation of Test Classes purely to cover code, but not validate execution flow is not permitted.

Batch Jobs:

Apex code can be scheduled to execute as a Batch Job at a defined time and/or interval.

Each production org has a maximum number of Batch Jobs that can be queued or running concurrently. As a result, any development team that needs to create a batch job must first gain approval from the org admin team.

development programming architecture salesforce.com force.com apex visualforce standards lifeinwork