Salesforce customization means changing Salesforce to fit how your business works: adding objects and fields, adjusting page layouts and apps, automating processes, and, when necessary, writing code. Most of it can be done with Salesforce's point-and-click (declarative) tools; Apex, Lightning Web Components and Visualforce cover what clicks can't. Salesforce's own advice is to try declarative tools first.
This guide was first published in 2021 as "Salesforce Customization – The Ultimate Guide". It has been rewritten for 2026 and now also covers configuration versus customization, the retirement of Workflow Rules and Process Builder, and how to keep customizations from turning into technical debt.
What is Salesforce customization vs configuration?
Configuration is changing Salesforce with point-and-click tools; customization, in everyday use, means writing code. The two words are used in two ways, which confuses many buyers:
- Common usage among consultants: configuration is anything done with point-and-click tools (fields, layouts, flows); customization is code (Apex, Lightning Web Components, Visualforce).
- Salesforce's usage: Trailhead's guide to Salesforce app-building tools says Salesforce "provides point-and-click tools for configuration and customization", so in Salesforce's documentation customization includes both.
| Configuration (declarative) | Customization with code (programmatic) | |
|---|---|---|
| Who builds it | Admins and consultants | Developers |
| Tools | Object Manager, Lightning App Builder, Flow, validation rules, formulas, reports | Apex, Lightning Web Components, Visualforce, APIs |
| Speed to build | Fast | Slower: code, tests and deployment |
| Maintenance | Low; benefits from new features automatically | Higher; needs a developer, tests and reviews |
| Limits | What the tools support | Very flexible, within governor limits |
When you get a quote, ask which items are declarative and which are code. It tells you how much the work will cost to maintain, and whether your own admins will be able to change it later without calling a developer.
Examples of each
- Configuration: adding a Contract End Date field, a validation rule that blocks a closed-won opportunity without a product, a record-triggered flow that creates a renewal opportunity, a new Lightning record page for the service team.
- Customization with code: an Apex trigger that recalculates territory assignments across thousands of accounts, a Lightning Web Component that shows live shipping status from an ERP, an Apex REST endpoint for a partner portal.
A useful rule of thumb when comparing quotes: every line of code is something you will pay to test before each of the three yearly Salesforce releases, and to hand over when a developer leaves. Configuration changes are usually cheaper to own.
What can you customize in Salesforce?
You can customize the data model, user interface, business logic, security, analytics and integrations, mostly without code.
| Area | Declarative tools | Code, when needed |
|---|---|---|
| Data | Custom objects, fields, relationships, record types, picklists | Rarely needed |
| User interface | Page layouts, Lightning record pages and apps in Lightning App Builder, dynamic forms, list views | Lightning Web Components for custom screens |
| Business logic | Flow, validation rules, formula fields, approval processes | Apex classes and Apex triggers |
| Security | Profiles, permission sets, sharing rules | Apex managed sharing for unusual cases |
| Analytics | Reports and dashboards | CRM Analytics or external tools |
| Integration | External Services, Salesforce Connect, AgentExchange (formerly AppExchange) connectors | Apex callouts, custom APIs, middleware |
For automation, our guide to Salesforce flows covers what Flow can do; for reports, see creating reports in Salesforce.
Clicks or code: how to decide
Use clicks unless the logic, volume or user interface clearly needs code. Trailhead's advice is to try declarative first. Its reasons: declarative tools are easier to create and maintain, they are the better way to take advantage of new Salesforce functionality, and they are easier to test. Code is for customizations that are "too complex or specialized" for the declarative tools, and combining the two often gives the best solution.
In practice, reach for code when:
- The logic is too complex to read or debug in a flow, such as many nested decisions across several objects.
- The automation must process large data volumes efficiently or in bulk.
- You need a user interface the standard components can't produce. Trailhead states that "Lightning Web Components is the preferred way to develop custom UI in Lightning", per its Lightning development module, as it is more performant, easier to build and more portable than Aura components.
- An integration needs logic or error handling beyond what External Services or Flow callouts offer.
Whatever you build, understand the order of execution and governor limits: flows and Apex run in the same transaction and share the same limits.
Retired tools: Workflow Rules and Process Builder
Workflow Rules and Process Builder reached end of support on 31 December 2025; as of November 2026, Flow is the tool to build and migrate to. Older Salesforce customization guides still recommend Workflow Rules and Process Builder. Salesforce Help's end-of-support article says support for both ended on 31 December 2025. Existing rules and processes keep running, but Salesforce no longer provides support or bug fixes for them, and it recommends migrating to Flow Builder. Salesforce's Migrate to Flow tool converts a workflow rule or process into an inactive flow you can test before activating, as the Salesforce Admins blog shows. Our Salesforce workflow guide covers the migration in more detail. Migrate the simplest record updates first, test in a sandbox, and combine several old rules into one flow per object where that makes the logic clearer.
How to plan a Salesforce customization project
Plan from the business process to the data model to the tools, and build in a sandbox with a release process.
- Start with the process, not the screen. Write down who does what, with which data, and what should happen automatically.
- Check what Salesforce already does. Standard objects, features and AgentExchange apps often cover the need.
- Design the data model first. Objects, fields and relationships are the hardest things to change later; see our data model guide and record types guide.
- Prefer declarative, then code. Record the reason each time you choose code.
- Build in a sandbox, never in production; our sandbox guide explains which one to use.
- Use a release process. Source control and automated deployment pay off quickly; see our Salesforce DevOps guide.
- Plan for releases. Salesforce ships three major releases a year, as Trailhead's release module explains; test your customizations in a preview sandbox before each one.
- Document and train. Field descriptions, flow descriptions and short user guides keep the org usable after the project team leaves.
Customization mistakes that create technical debt
Technical debt comes from building what Salesforce already offers, and from automation and code nobody can maintain.
- Rebuilding standard features, such as a custom "Customer" object next to Account, which cuts you off from standard reports and future features.
- Several automations on one object (old workflow rules, flows and triggers) firing in an order nobody can predict.
- Hard-coded IDs and values in flows and Apex that break when moved between sandboxes and production. Use custom metadata types or custom labels.
- Too many fields and page layouts, which slow users down and make reporting unreliable.
- Code without tests that mean anything. High Apex test coverage alone doesn't prove the logic works; tests should check results, not just run lines.
Getting help
Good customization is mostly about choosing what not to build. Techila is a Salesforce Summit Partner; our Salesforce development team configures, codes and cleans up Salesforce orgs, and our implementation guide covers the wider project. Talk to us about your requirements.
Frequently asked questions
What is Salesforce customization?
Changing Salesforce to fit how your business works: adding objects and fields, adjusting page layouts and apps, building automation, and, where needed, writing code such as Apex or Lightning Web Components.
What is the difference between configuration and customization in Salesforce?
In common usage, configuration means changes made with Salesforce's point-and-click tools, such as fields, page layouts and flows, while customization means code such as Apex and Lightning Web Components. Salesforce's own documentation often calls both customization.
Should I use Flow or Apex?
Start with Flow. Salesforce advises trying declarative tools first because they are easier to build, maintain and test. Use Apex when the logic is too complex for Flow, needs to handle very large data volumes efficiently, or calls other systems in ways Flow can't.
Can I still use Workflow Rules and Process Builder?
Existing rules and processes still run, but Salesforce ended support for both on 31 December 2025, so there are no more bug fixes or support. Build new automation in Flow, and use the Migrate to Flow tool to move existing automation.
Does customizing Salesforce affect upgrades?
Declarative changes are generally upgrade-safe. Code also survives the three yearly releases, but it has to be maintained, tested and kept within governor limits, which is why the declarative-first rule saves money over the life of an org.