Salesforce Customization vs Configuration: What Each Means and When You Need a Developer

The Platform Developer exam guide asks candidates to weigh “declarative versus programmatic customizations”, so Salesforce itself uses the word customization for clicks and for code. In everyday talk, configuration means clicks and customization means code, while Salesforce’s own docs say declarative and programmatic. That gap makes it easy to talk past each other when you scope a requirement.

Salesforce customization vs configuration comes down to clicks versus code. Configuration means the declarative tools in Setup, and customization in the strict sense means Apex, Lightning Web Components and the APIs. A wrong call leaves you with code your team can’t maintain, flows that hit the same limits Apex does, or an edition that can’t run code at all.

Here’s where we’re headed: what each side builds in Setup and in code, a side-by-side table, the retired automation to skip and the point where Flow hands off to Apex. Then come 10 signs a change needs code, what your edition allows, a requirement matrix, the trouble with mixing Flow and Apex on one object, a checklist, the costs, a case study and 15 FAQs. When a requirement lands on the code side, that work falls under Salesforce customization services.

What Configuration and Customization Mean in Salesforce

Salesforce customization vs configuration is really a question about how you build the thing. We found no Salesforce page that defines either word as strictly clicks or code, so we use the everyday split here and sort each tool by how you build with it.

Configuration Means Building With Clicks

Trailhead’s name for developing without code is no-code development, and it lists declarative and point-and-click as other names for it. That’s the work you do in Setup, Object Manager, Lightning App Builder and Flow Builder: custom fields, validation rules, page changes and flows.

A certified Salesforce administrator owns most of it day to day, from roles and permissions to record types and layouts. Flow sits on this side too, and Trailhead says low-code tools like Flow Builder can be extended, combined or further customized with code, which is where the line between the two words blurs.

Customization Means Building With Code

Salesforce also offers programmatic development, built on Apex, Lightning Web Components and Visualforce. Apex is a strongly typed, object-oriented programming language that a developer writes in a code editor and deploys, and a Lightning web component is a custom screen element built the same way. Trailhead even says Salesforce provides point-and-click tools for configuration and customization, so the word customization covers both sides, and declarative vs programmatic is the cleaner pair when precision matters.

Why the Difference Matters Before You Build Anything

The choice changes who can maintain the build, what it takes to review it and what each later change costs you. Salesforce’s own guidance gives 3 reasons to decide on purpose.

• Salesforce’s default is to try declarative first. Trailhead’s comparison of the two approaches rates declarative as easier to create and maintain, and easier to test. Its advice for the other case is short: when declarative is not enough, bring in programmatic. In practice, that means you ask what Setup can do first and write code only for the gap.

• Code needs people who can maintain it. The Salesforce Architects Record-Triggered Automation guide says Apex requires properly skilled software developers to implement, test and maintain the code. Salesforce’s forms guide adds that when a low-code team will maintain a form, you should keep it configurable. So before you approve any code, ask who will own it a year from now.

• Clicks build debt too. Salesforce’s DevOps guidance says flows, validation rules and permission changes deserve the same review rigor as code. Its anti-pattern list names configuration that deploys without review while Apex gets scrutiny. A flow deserves a reviewer just as a trigger does.

Configuration should carry the bulk of your requirements, and a developer can add Apex or a Lightning web component when it reaches its limit. Our write-up on the implementation mistakes that create technical debt shows what that looks like in a real org.

What Can You Build With Clicks Alone?

Clicks vs code starts with what clicks already cover, which is a lot. These 7 tools cover the everyday ground of Salesforce configuration, each with a fact worth knowing, and flow-based work falls under Salesforce workflow automation. If a requirement fits one of them, you can build it in Setup and hand it to an admin to maintain.

• Validation rules. They check that the data a user enters meets the standards you set, and invalid data shows a message without saving the record. Quick Create doesn’t run them.
• Formula fields. They calculate a value from other fields. A formula can run up to 3,900 characters including spaces and compiles to 15,000 bytes, and the displayed result stops at 1,300 characters.
• Roll-up summary fields. They count detail records or take their sum, minimum or maximum, and show the result on the parent. The detail records must connect through a master-detail relationship.
• Dynamic Forms. They move fields and sections out of the page layout editor and into Lightning App Builder, with visibility rules. Products, Events and Tasks still use page layouts.
• Before-save flows. Salesforce reports that a record-triggered flow can update a record up to 10 times faster than a record-change process in Process Builder. They update fields on the record that started the flow.
• Scheduled paths and schedule-triggered flows. A scheduled path runs flow elements at a set time after a record change. A schedule-triggered flow runs once, daily or weekly for a batch of records.
• Screen Flow. It’s a Low Code tool, like Dynamic Forms, for guided screens that collect input. Salesforce lists no extra license for Dynamic Forms, Screen Flow or Lightning Web Components.

When a requirement sits outside all 7 tools, the next section shows what code adds.

What Code Adds When Clicks Run Out

When a requirement needs logic or a screen that Setup can’t build, clicks vs code gets settled for you. That’s the point where declarative vs programmatic becomes a build decision, and 4 things come with the code side.

Apex for Logic Behind the Save

Salesforce lists Apex for complex business processes that Flow Builder doesn’t support, for custom transactional logic and for logic attached to another operation, such as saving a record. In plain terms, Apex is what runs behind the save when the flow canvas runs out of room, and it’s where a developer earns their keep.

Lightning Web Components for Custom Screens

Salesforce recommends the Lightning Web Components model for custom user interfaces, and for Visualforce, which is still available, it recommends building Lightning web components instead. Salesforce describes Lightning web components as having the fewest guardrails, which buys full styling and reuse and leaves more to maintain. HyphenX writes that code when a requirement outgrows the declarative tools, and Apex and Lightning Web Components development is the work involved.

The Testing Gate

Apex needs unit tests before it reaches production. Salesforce’s Apex docs say unit tests must cover at least 75% of your Apex code, every trigger needs some coverage and the tests must pass. Its Well-Architected guidance warns against tests written only to reach 75%, so budget time for tests that check real business rules.

The Deployment Path

Per Salesforce, you can’t develop Apex in your production org, so code gets built elsewhere and deployed. The named routes are Change Sets, VS Code extensions, Metadata API, Tooling API and DevOps Center, which Salesforce is renaming Lifecycle Center beginning October 2026, and that tool tracks configuration and code changes alike. Apex fixes follow the same path as new builds, so plan on a deployment step and someone who knows the tooling.

How Configuration and Customization Compare Side by Side

Here’s Salesforce customization vs configuration on the 8 points that decide most projects, and one row surprises people: flows run under the same per-transaction limits as Apex.

Flow can also call a small piece of Apex, which Salesforce calls a hybrid pattern, so treat Salesforce configuration vs customization as a row-by-row call on each requirement.

Why Workflow Rules and Process Builder No Longer Belong in a New Build

Salesforce ended support for Workflow Rules and Process Builder as of December 31, 2025. It no longer provides customer support or bug fixes for either feature, and it recommends moving to Flow Builder with its Migrate to Flow tool. Active processes continue to run as they did before.

Anything you build in them today adds work to retire later, so build new automation in Flow. The ones you already have keep running, which gives you time to plan the move, so start with a list of what each active one does and which objects it touches. Because both keep firing, an older org can run them beside newer flows, so check what already fires on an object before you add another automation.

Where Flow Stops and Apex Starts

Salesforce’s Record-Triggered Automation guide sorts objects into 3 density bands and names a standard tool for each. Count what already fires on the object before you pick Flow or Apex, and our Flow vs Apex decision framework goes deeper on automation-only choices.

The guide’s advice is to weigh all dimensions of automation density together, along with total daily DML operations. In the middle band it positions Record-Triggered Flow as the orchestration layer and moves complex work, such as SLA calculations that need BusinessHours, into an invocable Apex method that runs after the save. Its 15-row capability matrix marks Flow Recommended in 5 rows and Apex in 4.

HyphenX uses a three-question worksheet on each object: how many automations already run on it, the largest load it takes and how much downstream DML each save causes. Say an object has 12 automations, takes small API loads and fires 1 downstream DML per save; every answer lands in the low band, so Flow is the standard tool. Change the load to Bulk API jobs of 5,000 records and the answers split, so we plan for the higher band, which is our own reading of the guide.

Signs a Change Needs a Developer

Some requirements settle the build before anyone opens Flow Builder. These 10 signs mark a change that needs code, and each traces to the Salesforce docs, starting with its guidance on when to use Apex.

• Part of the save must roll back. Flow has no access to Database.savepoint, Database.rollback or partially successful DML operations, so all-or-nothing logic across steps lands in Apex, where a failed step can undo the ones before it.

• Logic must run when a record is restored. Record-Triggered Flow currently doesn’t support the after-undelete context, so logic that fires on a restored record needs an Apex trigger.

• The logic needs Map or Set structures. Salesforce notes that Flow lacks native Map and Set data structures, and Apex uses them for fast lookups across a set of records, such as matching incoming rows to existing ones.

• The same expensive computation repeats across records. Flow can’t cache across flows or invocations, while Apex can use static variables and Platform Cache to compute once and reuse the result, which matters when the same lookup repeats for every record in a load.

• Validation spans several objects, or one save needs several field messages. Salesforce documents Apex for complex validation over multiple objects, and addError gives flexible field-level messages. The Flow Custom Error element blocks a save but is missing from some flow types, including subflows.

• Another system must call into Salesforce. Apex can create web services and email services, which give outside systems a custom endpoint to call or an address to send mail to, with logic of your own behind each one.

• A form needs custom field validation, CSS-level styling or reuse. The forms guide’s table lists custom field-level validation as Not Available for Dynamic Forms and Screen Flow, and Screen Flow allows no CSS overrides. Lightning Web Components cover all three, so custom UI work calls for a Lightning developer.

• A callout is complex enough to endanger the save. Flow’s async path suits a simple callout to an external system. Anything heavier takes a developer, and Salesforce itself calls enqueuing a Queueable job from a trigger a risky pattern.

• Heavy logic has to run before the save. Invocable actions are available only in the after-save context, so the hybrid pattern can’t hand before-save work to Apex, which means before-save work that outgrows a flow has to live in Apex itself.

• One save touches several objects and needs tight control. The guide describes Flow as suited to simple, low-complexity cross-object cases, and Apex gives superior control over deduplication, error handling and performance.

If none of the 10 describes your requirement, the matrix further down is the place to look up the closest match.

What Your Salesforce Edition Allows Before Code Is an Option

Before you plan any Salesforce configuration or code beyond the basics, check what your edition allows. Salesforce publishes which editions include API access and keeps a separate list of Apex editions.

• Essentials and Group. API access isn’t available and can’t be bought as an add-on, and neither edition appears on Salesforce’s list of Apex editions. On either one, anything that needs the API is off the table, so plan on configuration.
• Professional. Apex isn’t listed for Professional Edition. API access must be purchased as an add-on, and you order it as the Web Services API product. An integration on Professional starts with a purchase, before anyone builds anything.
• Enterprise, Unlimited, Performance and Developer. All four are on the Apex list and include API access by default. Database.com is on the Apex list too. On these editions the requirement decides the path, and the rest of this page applies in full.

Newer plan names add a wrinkle. Salesforce’s Sales pricing page lists Starter Suite, Pro Suite, Core, Advanced and Max, and we found no Salesforce page that maps those names to the Apex edition list. Confirm with Salesforce before you plan code on any of them, and treat code as unconfirmed until you have that answer.

Clicks or Code for Common Requirements

This is HyphenX’s matrix, compiled from Salesforce’s own decision guides, for settling clicks vs code on 12 everyday requirements. Find the row closest to yours, start with the tool in the middle column and read the right column for what would push you toward code. The form rows lean on Salesforce’s guide to building forms.

The undo and restore rows have no declarative route in Flow, so they start with code. The two rows about outside systems are the territory of Salesforce integration services.

Why Does Running Flow and Apex on the Same Object Get Messy?

Because both fire during one save, in a fixed order that Salesforce publishes, and some of them can overwrite or miss each other’s work. These 5 steps from Salesforce’s order of execution show where flows and triggers collide.

• Step 3. Record-triggered flows set to run before the record is saved fire here, ahead of any trigger code, so a before-save flow gets the first write.

• Step 4. All before triggers run. The order implies that a trigger writing the same field as a before-save flow writes last.

• Step 5. System validation and custom validation rules run on the record after both of those before-save steps have changed it.

• Step 8. All after triggers run, so this is where trigger code reacts to the saved record, before any after-save flow has run.

• Step 14. Record-triggered flows set to run after the record is saved fire here. By the order, a trigger can’t see what an after-save flow changes, because the triggers have already run.

The guidance is to avoid mixing Flow and Apex triggers as entry points for the same object. It calls a mixed object a tolerated operational state that architects should treat as a calculated trade-off.

Trigger order isn’t guaranteed when more than one trigger exists for the same event, and Flow Trigger Explorer gives each flow an order value. Recursion control compares new and prior values, and flows use $Record and $RecordPrior in their entry criteria. If you inherit a mixed object, list every flow and trigger on it before you change any of them.

Questions to Answer Before You Bring In a Developer

This is HyphenX’s checklist, built from Salesforce’s own criteria. Answer each box with a yes, a no or a number. Run Salesforce configuration vs customization through these 12 questions, and the pattern of your yeses answers “do I need a developer”.

☐Does your edition appear on Salesforce’s list of Apex editions, so code is even an option?

☐How many automations already run on this object: under 15, 15 to 30, or over 30?

☐Will the object take bulk loads of 2,000 or more records, or fire 5 or more downstream DML operations per save?

☐Do you need to roll back part of a transaction, such as undoing earlier steps when a later one fails?

☐Does the logic need Map or Set lookups, or caching across records, to avoid repeating the same work?

☐Do you need a web service for outside systems to call, or validation that spans several objects?

☐Does the screen need custom field validation, CSS styling or a reusable component?

☐Is the callout simple enough for Flow’s async path, or complex enough to endanger the save?

☐Do Apex triggers already sit on the object that a new flow will share, so the order of execution matters?

☐Who maintains the build after go-live, and does that work sit inside an admin’s job?

☐Can you budget for 75% test coverage on every Apex deploy and for reviewing configuration changes?

☐Could the hybrid pattern work, so a developer writes one invocable method and Flow does the rest?

A yes on the rollback, Map and Set, web service, screen and callout questions points to code by itself. The edition, maintenance and testing-budget questions tell you whether you can support it.

What Each Path Costs in Licenses, Skills and Upkeep

Salesforce customization vs configuration carries a price on both sides, and you can price part of it from Salesforce’s published list prices and public pay data. Every labor figure here is a proxy, and the arithmetic is shown.

Salesforce publishes no hours per feature and no build-time comparison for Flow and Apex, so any hours figure on this page would be a guess. Its pricing page says it’s provided for information purposes only and subject to change, so check the live page before you budget.

After launch, someone has to look after both the configuration and the code, and Salesforce managed services cover that ongoing care of configurations and automation.

People Who Know When to Click and When to Code

Choosing between clicks and code is a judgment call that gets expensive when it goes wrong. HyphenX Solutions has 250+ Salesforce professionals, so the admin who sketches a Flow and the developer who would write the Apex sit on one team and review each object together before anything is built. You pay for code only where declarative tools run out. Learn more about the people behind our builds.

A Case Study in Connecting Outside Tools to Salesforce

Two rows of the matrix involve outside systems, so here’s a build from our own work that connects three of them.

From Swivel-Chair Prospecting to Single-Click Pipeline

A B2B SaaS team running structured outbound had Apollo, Lusha and Hunter beside a Sales Cloud org that none of them touched. Reps moved data between tabs by hand with no deduplication, so the same account was sometimes created three different ways and unverified emails raised bounce rates. HyphenX connected the three tools through their APIs inside Salesforce, with cascading source logic, a single-click identify and insert button on Lead, Contact and Account records, real-time deduplication and Hunter email verification before each write, and reps now prospect entirely inside Salesforce with only Hunter-verified emails entering the system.

Key takeaway: Outside tools can run inside Salesforce when API connections, record-page buttons, deduplication and email verification are built as one structured process, and in our reading that is integration work that goes past standard setup.

Read the full case study: Swivel-Chair Prospecting Case Study
Explore more case studies: All HyphenX Case Studies

Frequently Asked Questions About Salesforce Configuration and Customization

What separates configuration from customization?

Configuration uses declarative, point-and-click tools, and customization in the strict sense uses code, meaning Apex, Lightning Web Components, Visualforce and the APIs. A quick test: if you can build it in Setup without writing code, it’s configuration. Salesforce’s own terms are declarative and programmatic.

Does Salesforce use the term configuration at all?

Yes, mostly for declarative setup. Trailhead refers to point-and-click tools for configuration and customization, and the Administrator exam names declarative configuration of the user interface. The Developer exam talks about declarative versus programmatic customizations, so customization covers both sides while configuration stays on the clicks side.

Is Flow configuration or customization?

Flow is configuration, with a code extension point. Trailhead calls Flow Builder a low-code tool that can be extended, combined or further customized with code. In practice, a flow can call an invocable Apex method when one piece of logic outgrows the canvas.

When should I use Apex instead of Flow?

Reach for Apex when an object carries more than 30 automations, takes bulk loads of 2,000 to 10,000 or more records, or fires 5 or more downstream DML operations. Also use it when you need rollback, after-undelete logic or Map and Set structures. Weigh all of these together.

Do flows have governor limits?

Yes. Salesforce says per-transaction limits, which Apex enforces, govern flows: 100 SOQL queries, 150 DML statements and 10,000 ms of CPU time. By the same math, a flow that queries inside a loop can hit the same 100-query ceiling a careless trigger would.

Can I still use Workflow Rules and Process Builder?

Existing ones keep running, but Salesforce ended support on December 31, 2025, so there’s no customer support or bug fixing. Build nothing new in them. Salesforce recommends its Migrate to Flow tool, so inventory what you have and rebuild it in Flow.

Which Salesforce editions include Apex?

Salesforce lists Enterprise, Performance, Unlimited, Developer and Database.com. Professional isn’t listed. We found no Salesforce page that maps Starter Suite, Pro Suite, Core, Advanced or Max to that list, so confirm with Salesforce before you plan code on a newer plan name.

Can Professional Edition use the Salesforce API?

Yes, but only by buying the Web Services API add-on, ordered as a separate product. Group and Essentials can’t buy it at all. Enterprise, Unlimited, Developer and Performance Editions include API access by default, so those are the editions where an integration needs no extra purchase.

Can a developer write Apex directly in production?

No. Salesforce says you can’t develop Apex in your production org. Developers build elsewhere and deploy with Change Sets, VS Code extensions, the Metadata API, the Tooling API or DevOps Center, which Salesforce is renaming Lifecycle Center, and the 75% coverage rule applies on the way in.

How much test coverage does Apex need to deploy?

At least 75% of your Apex code must be covered by unit tests, all tests must pass, and every trigger needs some coverage. Salesforce also warns against tests written only to hit 75%, because coverage without checks on business rules proves very little.

Can Flow and Apex triggers run on the same object?

They can, but Salesforce advises against using both as entry points on one object and calls the mix a tolerated operational state. Trigger order isn’t guaranteed when several exist for one event. If you inherit this setup, use Flow Trigger Explorer to set the order of your flows.

When does a form need Lightning Web Components?

When it needs custom field-level validation, full CSS control or reuse. Salesforce’s forms guide lists custom field validation as not available in Dynamic Forms and Screen Flow, and Screen Flow allows no CSS overrides. Lightning Web Components have the fewest guardrails, so a developer has to maintain them.

Can configuration create technical debt?

Yes. Salesforce says flows, validation rules and permission changes need the same review as code, and its anti-pattern is configuration that deploys without review. Process Builder shows the risk: logic built with clicks lost support and now needs a rebuild in Flow.

Is Visualforce still supported?

Visualforce is still available in Contact Manager, Group, Professional, Enterprise, Unlimited, Performance and Developer Editions. Salesforce recommends building Lightning web components instead, yet its documentation doesn’t call Visualforce deprecated or legacy. For new screens, that recommendation is the better one to follow.

How much more does a developer cost than an admin?

BLS has no Salesforce occupation, so these are proxies. Its May 2025 median pay is $135,980 for software developers and $105,850 for computer systems analysts, a gap of $30,130 a year. Analysts stand in for admins here, and developers for Apex and Lightning Web Components work.