What's the deal with Deno? We talk with a major contributor to find out. Listen now.

When developing functionality for your Salesforce users, you can use declarative features (clicks) or programmatic tools (code). Configuration centers around these declarative features.

Visual Development – When to Click Instead of Write Code

Examples for Declarative Development versus Code

Here are some use cases and examples for functionality that can easily be build declaratively, without writing a single line of code:

  • Instead of writing Triggers, we can automate Field Updates using Workflow – automatically populating a field with a default value or updating a field based on the value of another field is a pretty common requirement. Workflow can address the basic use cases just as well as writing an Apex Trigger.
  • Use Formula Fields and Roll-Up Summary Fields for field calculations instead of writing a Visualforce page and calculate the field values in a controller extension – a good example is a simple Order Management app. On the Order Lines, the order line total is calculated by multiplying the item price with the ordered quantity. A formula field can easily achieve this. And if we want to have the sum of all order line totals on the order header, we can use a Roll-up Summary field, as long as there is a Master-Detail relationship between the order and the order lines object.
  • Enforce Business Rules with Validation Rules whenever possible instead of Triggers and code Don’t want to allow users to save the order if a piece of information is missing? Validation Rules is a fast and easy-to-use alternative to writing custom Visualforce pages and controllers or Apex Triggers.
  • Use Approval Processes and Flows to implement logic and processes A lot of complex custom business logic and business processes can be defined using these two powerful tools. And probably the nicest benefit is that Approval Processes and Flows visualize the process, which makes it much easier to understand what’s going on than looking at lines and lines of Apex code.
  • Using Standard vs. Custom Objects We see this more often than one would think. Before creating a new custom object, check if there’s a standard object available that can address the functional requirements and/or can be customized to close the gap. Not only will this potentially save a lot of time, but also help control the number of custom objects in Salesforce, which is limited as we all know. A great example here is the Orders object that was released with Salesforce Spring ‘14. Before the Orders object was a Standard object, developers spent a lot of time and resources building functionality that is now available out-of-the-box. Keep in mind that there are three major Salesforce releases per year, so Salesforce is constantly adding new features and functionality. It’s always a good idea to check both the Salesforce1 Platform Release Notes and the Force.com Release Pages on Salesforce Developers for new standard objects and/or new features that may have required custom building in the past.