Before commissioning one

Every custom component is a permanent developer dependency. Standard configuration can be changed by an admin in an afternoon; a component cannot. Build them where the workflow problem is real and configuration has genuinely been exhausted.

Lightning Web Components are the modern way to build custom interfaces in Salesforce. This is a manager's guide to when they are worth it and what commissioning one commits you to.

What only custom components can do

RequirementStandard configurationCustom component
Show related records on a pageYesUnnecessary
Conditional field displayDynamic formsUnnecessary
Multi-object data entry on one screenLimitedSuited
Custom visualisation of your dataNoSuited
Guided multi-step processScreen Flow, often adequateWhen Flow is too rigid
Live data from an external systemNoSuited
Highly specific interaction designNoSuited

Try Screen Flow before commissioning a component. A great many "we need a custom interface" requirements turn out to be guided data entry, which Screen Flow handles and an admin can modify. Reaching for a component first is the expensive default.

Where they genuinely earn their cost

  • High-frequency workflows — a screen used fifty times a day, where saving thirty seconds compounds.
  • Multi-object entry that would otherwise mean navigating between several records.
  • Consolidated views pulling data users currently gather from several places.
  • External system data shown inline rather than in another browser tab.
  • Error-prone processes where guided input measurably reduces mistakes.

Frequency is the deciding factor. A component that saves two minutes on a task performed twice a month is a hobby. The same component on a task performed hourly pays for itself in weeks.

What a well-built component includes

  1. Security enforcement — respecting sharing, object and field permissions rather than assuming.
  2. Configurable properties so admins can adjust behaviour without a developer.
  3. Genuine error handling with messages a user can act on.
  4. Accessibility — keyboard navigation and screen reader support.
  5. Mobile behaviour tested on the Salesforce mobile app, not assumed.
  6. Bulk-safe server calls that do not query per row.
  7. Tests, both Apex and component-level.

Ask for configurable properties explicitly. A component with exposed settings — which object, which fields, what limit — can be reused across contexts and adjusted by an admin. The same component with values hardcoded needs a developer for every variation, and you will want variations.

Performance mistakes that show up later

  • Server calls in a loop instead of one call returning everything.
  • No caching on data that rarely changes.
  • Loading everything when the user needs the first twenty rows.
  • Several components on one page each making their own calls.
  • Heavy processing client-side that belongs on the server.

These are invisible in development with sample data and obvious in production with real volumes — which is why testing with realistic data matters more than it seems.

The maintenance commitment

Over timeWhat it means
Three Salesforce releases per yearOccasional compatibility work
Business process changesDeveloper time, not admin time
New fields to displayCode change unless configurable
Bug reports from usersSomeone must own them
Original developer leavesDocumentation and tests become critical

A reasonable decision path

  1. Describe the workflow problem, not the desired interface.
  2. Exhaust standard configuration — page layouts, dynamic forms, standard components.
  3. Try a Screen Flow if it is a guided process.
  4. Quantify the frequency — how often, by how many people?
  5. If it still justifies a component, build one, with configurable properties.
  6. Measure whether it was used after three months.

Considering custom components? Describe the workflow rather than the screen — we will tell you if configuration solves it. See our Salesforce service, Apex vs Flow, and over-customisation warning signs.

Frequently asked questions

Frequently not. Standard Lightning pages, dynamic forms and configurable components handle a great deal. Custom components are worth building when a genuine workflow problem persists after configuration has been exhausted — not because the standard page looks plain.
They still work. Migrate the ones users interact with daily and that cause friction; leave the rest. Wholesale migration for consistency alone rarely returns the effort.
They can configure exposed properties if you design for it — which is worth doing deliberately. They cannot change the component logic. Every custom component you build is a permanent developer dependency, and that should factor into whether you build it.