How to use this guide
I've created these guides to help fellow admins and developers work through the struggles of building out a Salesforce org. Whether you are an enterprise sized org with thousands of users or a small business with a couple, the principles that I have outlined below hopefully will help you create a strong, organized, and efficient Salesforce org.
Triggers, batch APEX, workflow rules, and validation rules are the focus tools. Salesforce does offer other tools such as flows and the process builder, but after developing in Salesforce for over three years, I have found that they are not able to scale to the performance requirements of an hyper-growth company. At Procore, we decided in 2016 to convert all process builders and flows into APEX and workflow rules.
Documentation is one of the most critical yet most neglected aspects of an SFDC org. Quality documentation can save admins hundreds of hours auditing their org or finding answers to process questions. Using tools such as JIRA/Confluence and Lucidchart (two of my favorite softwares), building, modifying, and searching documentation can be a breeze. After three years of building out a Salesforce org that has many scores triggers, hundreds workflow rules, and thousands of fields, I have realized that stronger documentation requirements from the get go would have streamlined current development, whether it be new or updating old.
This guide also briefly covers custom settings and custom metadata types. They are incredibly powerful tools that can help maintain quick changes to an org without significant development work. You will also find how to leverage my documentation tools while building out your Salesforce architecture.
Please let me know what you think of these guides, I am always eager to learn from my mistakes and hear how I can improve my development and architecture skills.
Triggers are the lifeline of a Salesforce org. They are able to expand the abilities of the platform in ways that are completely un-accessible via point-and-click solutions. With this incredible power however, there is a huge requirement to maintain strict policies on creation and documentation on all triggers to ensure the org is running at maximum efficiency. Over the last three years of developing in APEX and testing many different methods on how to structure triggers, I have discovered the optimum architecture for any trigger on any object.
The main goals of this trigger guild are to provide a solid understanding on how to properly name all triggers and related APEX methods, how to properly provide commenting, and how to document all your development work.
Batch APEX act as CRON jobs in Salesforce. They are incredibly powerful and useful to help monitor and cleanse data in your org. One of the biggest draw backs to batch APEX is the limit on the number of jobs you are able to run at any given point and the number of schedule jobs you are allow to maintain on the calendar.
To solve these problems, I build the Batch Master app. Its 100% free and allows admins to schedule as many jobs as they'd like to anytime of the day.
Workflow rules are an integral piece to the Salesforce architecture that greatly enhances the platform. They can be used to update fields, send emails, assign tasks to users, and send outbound messages via the API. One of the most challenging aspects of workflow rules, like most other metadata types in SFDC, is organizing them in a matter that allows admins to quickly search and modify outdate flows.
After working in SFDC for three years, I have develop a naming technique that will greatly increase the admin's ability to search and modify workflow rules. One of the biggest hurdles that I encountered was trying to develop a naming convention that allowed me to quickly add the modified rule in a change set.
Validation rules are tremendous Salesforce tools. They can be used in all aspects of the platform and help maintain data integrity. But validation rules, when used unchecked, can lead to scores of problems and issues in your org. For example, users might not understand which fields are required for which stage an opportunity is in, or they might have missed a required field for one stage because they skipped a particular stage with a validation.
Just as with workflow rules, documentation of validation rules is critical. A central source of truth for documenting validation rules is critical to the management and audit of them. Naming convention is also important when building your validation rules.
Custom fields, settings, and metadata types are all incredibly powerful tools that can enhance the Salesforce platform to another dimension. They can be used to support APEX development to increase speed and reduce code redundancy. Implementing custom settings and metadata types can help maintain a clean and organized database. There are some caveats to using formula fields, picklists, and other types of field value types that can really impact the long term scalability of an org. Certain fields should be implemented with particular types to ensure the field is dynamic. Using global picklist values are incredibly important to maintain a clean database.
Custom settings and metadata types are great ways to provide non-developers access into customizing trigger, batch or Visualforce controller logic. Querying them does not add to the query limit and custom metadata type records can be pushed between orgs, which prevents duplication of effort for admins and developers.
Sandboxes & QA'ing, best practices
Sandboxes and production should be thought of as two entirely different worlds, yet are exact replicas of each other. Production is the read-only version of your Salesforce org and the sandbox is exactly what is sounds like, a testing environment where you can break, build, and modify anything you wish. Fixes made directly in your production environment are highly ill-advised and when are done incorrectly can cause serious implications to productivity. Small changes that seem innocent, even slight modifications to formula fields, can lead to signification shutouts across your org. This is especially true in highly customized orgs with APEX, workflows, validation rules, etc. all working and linking together a wide breadth of objects.
At a very minimum all development should take place in a sandbox that is separated from your production environment by at least one other sandbox. For example your deployment process should look like this :
Sandbox #1 >>>> Sandbox #2 >>>> Production
Changes are initially made in Sandbox #1, then deployed to Sandbox #2, where QA'ing on the user level is done. Once a change set passes all QA validations in Sandbox #2, the original change set from Sandbox #1 should be deployed to Production. Keeping the same change set when deploying from Sandbox #1 is critical to maintaining metadata integrity. If a new change set (even with the same components) is created in Sandbox #2, and that change set is deployed to Production, unintended consequences might occur because there is potential for the metadata to be modified.