IntegraLogic

Over the past year, I have been heavily involved in designing and implementing increasingly complex Salesforce automations. Alongside these projects, I have also built a growing library of custom components for Salesforce Flows, primarily to help administrators – and, if I’m honest, to solve many of my own challenges along the way.

For years, Salesforce professionals have debated the same question: should a solution be built declaratively, using Flows and configuration, or programmatically, using Apex and custom development?

My answer today is that the most effective solutions often combine both approaches.

The Hybrid Development Philosophy

Over time, I have adopted what I describe as a hybrid development style for Salesforce components.

The idea is simple:

Programmatic deployment. Declarative maintenance.

In practice, this means building a robust framework in code that provides the heavy lifting – data handling, calculations, error management, performance optimisation, and reusable functionality. However, instead of hard-coding business logic, field mappings, layouts, and user interface decisions, these are driven through configuration.

The result is a component that can be deployed once, but adapted endlessly without modifying the underlying code.

A Real Example – KB_WidgetRepeater

One of the best examples of this philosophy is my KB_WidgetRepeater Screen Flow component.

What began as a simple way of displaying records inside a Flow has evolved into an incredibly powerful framework capable of:

• Displaying records as cards or list views
• Inline editing and bulk updates
• Dynamic filtering and searching
• Record selection and manipulation
• Conditional styling and visibility rules
• Customisable layouts using JSON templates
• Formula recalculation without leaving the screen
• Data-table style functionality
• Real-time interaction with selected record collections

One of the most powerful aspects of the component is its ability to accept templates and configuration through variables and JSON structures. Rather than creating a new component for every use case, administrators can define behaviour, styling, visibility, and interactions through configuration alone.

A Flow Builder can completely transform how records are presented, styled, filtered, and interacted with without changing a single line of Apex or JavaScript.

The Problem with Traditional Custom Development

Throughout my career, I have encountered many different approaches to Salesforce development.

I have installed third-party components from marketplaces, worked with consultancy-built solutions, and inherited managed packages that were once excellent but later became impossible to maintain.

The same pattern often emerges:

• A developer builds a highly customised solution.
• Business requirements change.
• Even small updates require development effort.
• Support contracts expire.
• The original developers move on.
• The organisation becomes dependent on code they no longer understand or control.

In the worst cases, businesses are left with solutions that cannot be modified at all because the package is managed and the vendor no longer provides support.

This creates technical debt and significantly increases the long-term cost of ownership.

Building for the Future

When I design components today, I focus heavily on long-term maintainability.

The framework itself is built in code, but the majority of business decisions are exposed through variables, templates, and configuration options.

Sometimes this means spending more time upfront designing a flexible architecture. However, the payoff is enormous:

• Faster implementation of new requirements
• Reduced dependency on developers
• Easier maintenance by administrators
• Lower long-term costs
• Greater adaptability as business processes evolve

A simple colour change, a new field, an additional filter, or a completely different record layout should not require a development project.

In many cases, these updates can be completed in seconds through configuration alone.

Finding the Right Balance

I don’t believe every problem should be solved declaratively, nor do I believe every problem should be solved with code.

Salesforce is at its best when both approaches work together.

The most sustainable solutions are often those where code provides a powerful, reusable framework, while administrators retain the freedom to adapt and evolve the solution through configuration.

That is the principle that guides every component I build today.

Programmatic deployment. Declarative maintenance.

For me, that is where the future of scalable Salesforce development lies.