{"id":1176,"date":"2026-09-01T11:00:00","date_gmt":"2026-09-01T05:30:00","guid":{"rendered":"https:\/\/swapnilzambare.com\/blog\/declarative-vs-programmatic-salesforce\/"},"modified":"2026-09-01T11:00:00","modified_gmt":"2026-09-01T05:30:00","slug":"declarative-vs-programmatic-salesforce","status":"publish","type":"post","link":"https:\/\/swapnilzambare.com\/blog\/declarative-vs-programmatic-salesforce\/","title":{"rendered":"Declarative vs Programmatic in Salesforce: When to Write Code"},"content":{"rendered":"\n

Declarative vs Programmatic is the first big choice every Salesforce developer makes on every task. Should you build it with clicks, or should you write code? Picking the wrong side costs time, money and future pain.<\/p>\n\n\n\n

In our last post, What is Salesforce Development?<\/a>, you saw what developers build. Now we will learn how to decide between clicks and code. You will also get a simple checklist you can use at work tomorrow. If you want a refresher on clicks first, read our Flow Builder guide<\/a>.<\/p>\n\n\n\n

What Does Declarative vs Programmatic Mean?<\/h2>\n\n\n\n

Declarative means you build features with point-and-click tools. You describe what you want in Setup, and Salesforce does the work. Programmatic means you write code, such as Apex or JavaScript, to tell Salesforce exactly how to do it.<\/p>\n\n\n\n

Here is an easy way to picture it. Ordering a meal from a menu is declarative, because you pick from ready options. Cooking the meal yourself is programmatic, because you control every step and every ingredient.<\/p>\n\n\n\n

Why the Declarative vs Programmatic Choice Matters<\/h2>\n\n\n\n

Your team must maintain every feature for years. So the declarative vs programmatic choice affects much more than today’s task.<\/p>\n\n\n\n

Clicks are faster to build and easier for admins to change. However, they can become slow or messy when the logic gets complex. Code is flexible and fast at scale, but it needs a developer to change it. It also needs test classes before it can reach production.<\/p>\n\n\n\n

A good choice keeps the org simple. A bad choice, on the other hand, creates a tangle that nobody wants to touch.<\/p>\n\n\n\n

Declarative Tools in Salesforce<\/h2>\n\n\n\n

Salesforce gives you many strong click tools. Most of them come from the Admin series, so you may know them already.<\/p>\n\n\n\n

Flow Builder<\/h3>\n\n\n\n

Flow is the main automation tool today. It can create and update records, send emails, show screens and call Apex. Salesforce has also retired Workflow Rules and Process Builder in favour of Flow.<\/p>\n\n\n\n

Validation Rules and Formulas<\/h3>\n\n\n\n

Validation rules stop bad data from saving. Formula fields calculate values on the fly. Both use a simple formula language, not a programming language.<\/p>\n\n\n\n

Page Layouts and Lightning App Builder<\/h3>\n\n\n\n

These tools control what users see on screen. You can add components, set visibility rules and build whole apps without code.<\/p>\n\n\n\n

Reports, Dashboards and Approvals<\/h3>\n\n\n\n

Reports show data in tables and charts. Approval processes route records to managers for sign-off. Again, they need no code.<\/p>\n\n\n\n

Programmatic Tools in Salesforce<\/h2>\n\n\n\n

When clicks are not enough, developers reach for code. These are the main programmatic tools.<\/p>\n\n\n\n

Apex<\/h3>\n\n\n\n

Apex runs on Salesforce servers. You use it for triggers, complex logic, batch jobs and integrations with other systems.<\/p>\n\n\n\n

Lightning Web Components<\/h3>\n\n\n\n

LWC lets you build custom screens with HTML, JavaScript and CSS. You use it when a standard page cannot show what the user needs.<\/p>\n\n\n\n

APIs and Integrations<\/h3>\n\n\n\n

Salesforce offers REST, SOAP and Bulk APIs. Developers use them to connect Salesforce with outside apps, such as a payment gateway.<\/p>\n\n\n\n

Declarative vs Programmatic: Side by Side<\/h2>\n\n\n\n

The table below compares both approaches across the points that matter most in real projects.<\/p>\n\n\n\n

Feature<\/th>Declarative (clicks)<\/th>Programmatic (code)<\/th><\/tr><\/thead>
Who builds it<\/td>Admins and developers<\/td>Developers<\/td><\/tr>
Build speed<\/td>Fast for simple logic<\/td>Slower to start<\/td><\/tr>
Complex logic<\/td>Gets hard to read<\/td>Handles it well<\/td><\/tr>
Large data volumes<\/td>Can hit limits sooner<\/td>Better control with bulk code<\/td><\/tr>
Testing<\/td>Manual testing, flow tests<\/td>Apex test classes required<\/td><\/tr>
Who can change it<\/td>Most admins<\/td>Only developers<\/td><\/tr>
Custom user interface<\/td>Limited to standard parts<\/td>Fully custom with LWC<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

When to use which comes down to one rule. Start with clicks, and switch to code only when clicks cannot meet the need cleanly.<\/p>\n\n\n\n

\"Declarative<\/a>
Declarative vs Programmatic tools compared side by side.<\/figcaption><\/figure>\n\n\n\n

How to Make the Declarative vs Programmatic Decision<\/h2>\n\n\n\n

You can use a short set of questions for every new requirement. Ask them in order, and stop as soon as you get a clear answer.<\/p>\n\n\n\n

    \n
  1. Can a standard feature do it already? If yes, use it and stop.<\/li>\n\n
  2. Can a formula, validation rule or Flow do it simply? If yes, use clicks.<\/li>\n\n
  3. Will the logic need many decisions, loops or nested conditions? If yes, lean towards code.<\/li>\n\n
  4. Will it process thousands of records at once? If yes, Apex is usually safer.<\/li>\n\n
  5. Does it need a custom screen or an outside system? If yes, use LWC or Apex.<\/li>\n\n
  6. Who will maintain it later? If only admins will, try hard to stay with clicks.<\/li>\n<\/ol>\n\n\n\n
    \"Declarative<\/a>
    A six-question checklist for every declarative vs programmatic decision.<\/figcaption><\/figure>\n\n\n\n

    This checklist is not a strict law. Still, it gives your team a shared language for each declarative vs programmatic decision.<\/p>\n\n\n\n

    A Real Declarative vs Programmatic Example<\/h2>\n\n\n\n

    Let’s solve the same problem both ways at Bright Path Tutors, so you can see declarative vs programmatic in action. The requirement is simple. When a user marks a Course as online, set its Duration_in_Weeks__c to 6 if it is empty.<\/p>\n\n\n\n

    The Declarative Way<\/h3>\n\n\n\n

    An admin can build this with a record-triggered flow in a few minutes.<\/p>\n\n\n\n

      \n
    1. Go to Setup > Process Automation > Flows > New Flow.<\/li>\n\n
    2. Choose Record-Triggered Flow, then select the Course object.<\/li>\n\n
    3. Set it to run when a user creates or updates a record.<\/li>\n\n
    4. Add an entry condition: Is_Online__c equals True and Duration_in_Weeks__c is null.<\/li>\n\n
    5. Choose “Fast Field Updates”, then add an Assignment that sets Duration_in_Weeks__c to 6.<\/li>\n\n
    6. Save the flow as “Course Default Duration” and activate it.<\/li>\n<\/ol>\n\n\n\n

      For this simple rule, the flow is the right choice. It is quick, clear and any admin can change it.<\/p>\n\n\n\n

      The Programmatic Way<\/h3>\n\n\n\n

      A developer could write the same logic as a trigger.<\/p>\n\n\n\n

      trigger CourseDuration on Course__c (before insert, before update) {\n    for (Course__c c : Trigger.new) {\n        \/\/ Only online courses with no duration\n        if (c.Is_Online__c && c.Duration_in_Weeks__c == null) {\n            c.Duration_in_Weeks__c = 6;\n        }\n    }\n}<\/code><\/pre>\n\n\n\n
      The trigger runs before the record saves. It checks two conditions and sets the duration. It works, but it also needs a test class and a deployment. So for this case, code is extra effort with no real gain.<\/p>\n\n\n\n
      When Code Wins<\/h3>\n\n\n\n
      Now imagine a harder rule. The duration must come from an outside timetable system, based on the trainer’s calendar. Flow can call outside systems in some cases, but this needs retries, error logs and data mapping. Here, an Apex class with a callout is the cleaner choice.<\/p>\n\n\n\n
      public class CourseTimetable {\n    \/\/ Gets the duration from an outside timetable service\n    public static Integer getWeeks(String courseCode) {\n        HttpRequest req = new HttpRequest();\n        req.setEndpoint('callout:Timetable_API\/courses\/' + courseCode);\n        req.setMethod('GET');\n        HttpResponse res = new Http().send(req);\n        Map<String, Object> body =\n            (Map<String, Object>) JSON.deserializeUntyped(res.getBody());\n        return (Integer) body.get('weeks');\n    }\n}<\/code><\/pre>\n\n\n\n
      This class sends a GET request through a Named Credential called Timetable_API. Then it reads the JSON reply and returns the number of weeks. We will cover callouts fully in the integration part of this series.<\/p>\n\n\n\n
      Declarative vs Programmatic Examples for Common Needs<\/h2>\n\n\n\n
      Real requirements make the rule easier to understand. The table below lists common requests from Bright Path Tutors and the best tool for each.<\/p>\n\n\n\n
      Requirement<\/th>Best choice<\/th>Why<\/th><\/tr><\/thead>
      Fee must be above 500<\/td>Validation rule<\/td>One simple condition<\/td><\/tr>
      Show total fees of a student<\/td>Roll-up summary field<\/td>Built-in, no logic needed<\/td><\/tr>
      Email the trainer when a course starts<\/td>Scheduled flow<\/td>Simple time-based action<\/td><\/tr>
      Split a fee across 3 installments<\/td>Flow or Apex<\/td>Depends on how complex the rules are<\/td><\/tr>
      Sync courses with an outside LMS<\/td>Apex callout<\/td>Needs retries and error handling<\/td><\/tr>
      Drag-and-drop timetable screen<\/td>Lightning Web Component<\/td>Fully custom user interface<\/td><\/tr>
      Recalculate 50,000 records each night<\/td>Batch Apex<\/td>Large data volume<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Look at the pattern in this table. The simple, single-step rules go to clicks. Rules with heavy data, outside systems or custom screens go to code. That pattern is the heart of every declarative vs programmatic decision.<\/p>\n\n\n\n
      Declarative vs Programmatic and Governor Limits<\/h2>\n\n\n\n
      Salesforce runs many companies on shared servers. So it sets limits on how much work one transaction can do. For example, one transaction can run up to 100 SOQL queries in synchronous Apex.<\/p>\n\n\n\n
      These limits apply to both clicks and code. A flow that gets records inside a loop can hit the same limit as bad Apex. However, code gives you finer control. You can collect records in a list, query once and update once.<\/p>\n\n\n\n
      This means the declarative vs programmatic question is also a performance question. If a flow keeps hitting limits during testing, it may be time to move that part to Apex.<\/p>\n\n\n\n
      Mixing Both Sides of Declarative vs Programmatic<\/h2>\n\n\n\n
      The best orgs do not pick one side forever. Instead, they mix both. A flow can call an Apex action when it needs heavy logic. An LWC can sit inside a screen flow to give users a better form.<\/p>\n\n\n\n
      This mix gives you the best of both worlds. Admins keep control of the simple parts, and developers handle the hard parts. So the declarative vs programmatic question is often “which part goes where”, not “one or the other”.<\/p>\n\n\n\n
      Common Mistakes with Declarative vs Programmatic Choices<\/h2>\n\n\n\n