Products we build, maintain, and ship.
We don’t only advise on Salesforce. We build and maintain our own managed package, which is why our advice is grounded in how the platform behaves when we’re the ones on the hook for it.
Managed package
B-inspired Flow Utils
A set of Flow components that close gaps Salesforce admins run into constantly, built so you can solve them declaratively instead of reaching for Apex.
A 44 second walkthrough of the multi-select picklist component running inside a live Flow screen.
Multi-select picklist for Flow screens
The component the standard screen flow doesn’t give you.
A genuinely usable multi-select picklist you can drop straight onto a Flow screen, with the selection and validation behaviour admins expect rather than a workaround built from checkboxes.
Picklist value checks
Ask whether a value is selected, wherever you need to ask it.
Check selected values as an invocable action inside record-triggered flows, or inline on the screen component itself, so the same logic works in both places without rebuilding it.
Match on ANY, ALL, or NONE of the values you specify, so the check means exactly what you intend rather than approximating it.
How it’s built
Built to the standard we’d want from a vendor.
- A deliberately small Apex surface. Anything that can be solved declaratively is. Less custom code means less to review and less to inherit.
- User-mode enforcement. Where Apex is needed it runs with the user’s own permissions and sharing rules, not elevated access that bypasses your security model.
- Field access validated against the schema. A renamed field surfaces as a clear error rather than silent data loss.
- Reviewed, not just released. Flow Utils passed AppExchange security review in September 2026 and is publicly listed. The same standard applies to everything we build, whether or not it is headed for a listing.
Beyond the package
Most problems don’t need a product.
Flow Utils exists because the same gaps kept coming up across different orgs. Most of what we build isn’t like that. It’s specific to one business, one process, and one set of constraints, and it belongs in your org rather than in a package.
If you’re not sure which kind of problem you have, that’s a good thing to work out together before anyone writes code.
Tell us what you’re trying to solve.
Whether it’s the package, a custom build, or working out which one you need, start with the problem.
Start the conversation