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.
- Force.com Enterprise Application Platform
- Force.com Org Strategy
- Developing on Force.com
- Force.com Architecture - CI
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).
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.
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).
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
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
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.
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.
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 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).
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
Criteria-based Sharing and/or
Sharing must be achieved via
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
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),
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.
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.
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.