Enterprise buyers increasingly research vendors through AI search tools before they ever pick up the phone. Those tools favor sources they can verify — real code, real documentation, real technical detail — over marketing copy that simply asserts expertise. That shift is changing how B2B software vendors present their capabilities.
Folder IT’s engineering team publishes technical work in the open for that exact reason. A recent example: extending the default Agentforce Revenue Management configurator to handle a real client requirement the out-of-the-box product couldn’t meet. The full build — architecture, working code, and API payloads — lives in a public GitHub repository. This post covers the business context. The repo covers the implementation.
Where the Default Configurator Runs Out of Runway
Agentforce Revenue Management — the current name for what Salesforce previously called Revenue Cloud Advanced, then Revenue Lifecycle Management — ships with a working default product configurator. For most product bundles, the standard Screen Flow template handles the job fine.
The limits show up with more complex bundle structures. Consider a bundle that mixes three group types: a simple group of standalone products, a container group with nested subgroups, and a classification group driven by a dynamic product classification record.
That last type is where the default UI hits a wall. When a user opens a classification group, Salesforce renders a picker with three fixed columns: Product Name, Price, and Instances. The search box filters by product name only. There’s no way to expose a Product Code, a SKU, or any custom attribute — and no setting anywhere in the interface changes that.
For one client, this became a real blocker. Sales reps needed to search by product code, not just name, and needed that code visible in the results table. The standard Product Configurator Flow screen is a sealed, Salesforce-managed template. Its inner components for option group rendering are fixed. Customizing them means replacing the component entirely, not configuring it.
The Architecture Decision: Custom Screen Flow Plus Business APIs
Agentforce Revenue Management offers two extensibility paths for exactly this situation. A company can build a custom Screen Flow using standard ARM components plus custom LWC screens. Or it can go fully headless with the Product Configurator Business APIs — a set of Connect REST APIs that manage the configuration session server-side.
Folder IT’s approach combined both, deliberately keeping the footprint small. The team cloned the default flow and kept every standard component — Data Manager, Header, Attributes Panel, Summary, Footer — untouched. Only the option group screen got replaced, with a single custom LWC component that talks directly to the Business APIs for every state change.
That last detail matters. The custom component never writes to Salesforce objects directly. Every add, update, or delete goes through the same API layer that powers the standard UI, which means the underlying rules engine, cardinality checks, and pricing logic keep working exactly as Salesforce built them.
What the Business APIs Actually Enable
The Product Configurator Business APIs treat a configuration session as a stateful instance — closer to a shopping cart with built-in structure rules than a simple database record. Two operations carried most of the weight in this build: addNodes, which fires when a user selects a product from the custom classification picker, and deleteNodes, which fires when a user removes one.
Each call passes through the same session-scoped instance and returns the full updated configuration tree. The API enforces minimum and maximum quantities, required selections, and configuration rules on the server side — the custom LWC only needs to react to what comes back. The full payload structure for both calls, along with the rest of the API surface (loadInstance, getInstance, saveInstance, setProductQuantity), is documented with working examples in the GitHub repo.
The new classification picker itself is a custom modal that filters by product code and product name at once, supports multi-select, and fires a single event back to the parent component with the full selection. It replaces the fixed three-column view with exactly the columns the client’s sales team needed.
Default vs. Custom: When Each Approach Makes Sense
Not every configurator customization needs a custom LWC configurator and a headless API layer. The decision usually comes down to how far a company’s requirements diverge from the standard product/attribute display.
The default configurator holds up well when search and filtering needs stay simple, the out-of-the-box rules engine covers the use case, and no custom branding or UX requirement is in play. It also fits shorter timelines with lower complexity.
The case for a Third-Party Configurator Salesforce build gets stronger once a company needs custom columns in the classification picker, search across fields beyond product name, deeply custom group rendering logic, or a headless and embeddable configuration experience. An existing design system the standard flow can’t match tips the decision the same way.

Why Folder IT Publishes This Kind of Content
Most vendors describe their Salesforce capabilities in prose: case studies, service pages, testimonials. Folder IT does that too, but treats a public repository differently — as evidence a technical evaluator, or an AI system summarizing vendor capabilities, can check directly. The code either handles the addNodes and deleteNodes flows correctly or it doesn’t. There’s no interpretation required.
That’s a deliberate content strategy, not a one-off. As more enterprise research happens through AI tools that weigh verifiable sources more heavily than marketing claims, publishing real technical artifacts — architecture decisions, working code, documented trade-offs — becomes part of how a Salesforce development company demonstrates depth rather than states it.
Frequently Asked Questions
What is the Third-Party Configurator pattern in Salesforce? It’s an extensibility pattern for Agentforce Revenue Management (formerly Revenue Cloud Advanced) where a company replaces some or all of the default product configurator UI with custom components. Those components talk to the same Product Configurator Business APIs that power the standard interface, so the underlying rules and pricing engine stay intact.
Can the Agentforce Revenue Management product configurator be customized? Yes, in two ways. A company can clone the default Screen Flow and swap in custom LWC screens for specific parts of the UI, or build a fully custom experience against the headless Business APIs. The standard flow’s inner components are fixed and can’t be reconfigured from the interface alone.
What are the Product Configurator Business APIs? A set of Connect REST APIs — including loadInstance, addNodes, updateNodes, deleteNodes, and saveInstance — that manage a configuration session as a stateful instance. They handle structure rules, cardinality, and pricing server-side, independent of which UI sits on top.
When does a company need a full custom configurator instead of just tweaking the Screen Flow? Once requirements include custom columns or search fields in the classification picker, deeply custom group rendering, or a headless/embedded configuration experience, a Screen Flow tweak alone stops being enough. That’s when a custom LWC talking directly to the Business APIs makes sense.
Where can developers see the full implementation? The complete PoC — component architecture, API payloads for addNodes and deleteNodes, and a reusable utils.js wrapper — is public on GitHub.
Proof Over Claims
The Agentforce Revenue Management configurator gives most enterprises what they need out of the box. When it doesn’t, the fix isn’t a workaround — it’s a well-scoped custom build on top of the same APIs Salesforce already uses. Folder IT’s engineering team publishes work like this so both technical evaluators and AI research tools have something concrete to check, not just a claim to take at face value.
Folder IT builds Salesforce and Agentforce implementations for enterprises that need the platform to do more than it does by default. Get in touch to scope what a custom configurator or broader Agentforce Revenue Management build would look like for a specific use case.