Open packages from Buzzbold

Buzzbold Utilities

Buzzbold Utilities are small, free, unlocked Salesforce packages that do unglamorous data work well. Anyone can install them, client or not.

Namespace
bboldutil
Package type
Unlocked
Platform
Salesforce
Price
Free, not gated
Documentation
Buzzbold Hub

Packages

Buzzbold Utilities packages, with what each one does and where to read its documentation.
PackageWhat it doesLinks
bboldutil-contact-dataContact DataData quality

Formats phone numbers to E.164 and resolves messy state values to standard State Codes.

Callable from Apex or Flow, or automatic on save. A value it cannot read is returned untouched rather than blanked, so it can tidy your data but never lose it.

bboldutil-coreCoreFoundation

One trigger per object, with behaviour supplied by functions registered in custom metadata.

Adding a capability is a metadata record, not a code change. Carries an org, profile, or user level kill switch, the usual way to run a bulk load without automation firing.

More packages as we build them. Install links go live when a version is promoted out of a development build, because a link to an unpromoted package is how a stranger ends up with something we did not mean to ship them. Source repositories are private today; this table grows real source links the day that changes, and not before.

Terms

Free, and not gated
No client relationship, no form, no conversation first.
Upgrades come with any plan
Push upgrades come with every Support & Training Success Plan, from the smallest tier up.
Unlocked, whatever happens to us
Unlocked packages. If Buzzbold stopped existing tomorrow, what is installed stays installed, readable, and yours to change.

Upgrades are what a plan buys, not access. See what a Success Plan includes.

Why these exist

Nonprofits rarely start with clean data. You inherit it: two decades of constituent records from three systems, phone numbers in nine formats, states written as Pennsylvania and PA and Penn. The tools that fix this are mostly sold per user, per month, which is a strange thing to charge a food bank for formatting a telephone number. The code itself is not nonprofit-specific and we will not pretend it is, because a phone number normalizes the same for a bank. What is specific is who we built it for, and what we think they should have to pay for it.

These are the tools our own implementations run on.

We did not build these to have something to give away. We built them because our implementation modules needed them, and roughly sixty of those modules run on this code across a hundred and more organizations.

That is the honest reason they stay free and stay current. We are maintaining them anyway, for our own delivery. Handing them to you costs us the maintenance we were already doing, and keeping them behind a subscription would mean charging you for our own plumbing.

It is the same principle as our teach-back sessions. You get the system, and you get the tools we built it with, because a team that owns both is not dependent on us.