Feature Flag System Rebuild: From Error-Prone Strings to Company Standard at GAF Energy

The Stakes

GAF Energy's feature flag system was a single text field in Salesforce that stored an array of strings. If you wanted to enable a feature for a roofing partner, you typed the flag name into this field. If you misspelled it, the feature silently failed to activate and nobody knew until someone reported it. The field had a 250-character limit, which partners with many flags regularly hit, causing truncation errors. There was no validation, no discoverability, and no audit trail.

One particularly memorable bug illustrated the problem perfectly. GAF Energy's development team included engineers based in Ukraine. A developer typed a feature flag name using a Cyrillic "C" character, which is visually indistinguishable from a Latin "C" but is a completely different Unicode character. The flag silently failed. It took significant debugging effort to track down because the field looked correct to every human who reviewed it. The system had no mechanism to catch this kind of error because it treated feature flags as arbitrary text rather than structured data.

My Role

I was the Technical Product Manager who identified the problem, designed the replacement system, and drove the migration. The project required coordinating with the engineering team that maintained the Partner Portal (where flags were consumed), the Salesforce administrators who managed partner accounts, and the account management teams who were the primary day-to-day users of feature flags when onboarding and configuring partner accounts.

This was not a large project in terms of engineering scope, but it was a high-coordination one. Feature flags touched every partner account and every feature rollout. Getting the migration wrong would mean features breaking silently across the partner ecosystem, so the sequencing and testing had to be precise.

The Real Problem

The string-based system had three compounding issues.

No input validation. Anyone editing the field could type anything. Misspellings, extra spaces, Cyrillic characters, and inconsistent casing all caused silent failures. The only way to confirm whether a flag was correctly applied was to manually test the feature on the partner's account.

No discoverability. If you were an account manager setting up a new partner, there was no way to see the list of available feature flags. You had to know the exact flag name (often by asking a developer or checking documentation that may or may not be current) and type it correctly into a free-text field. The system required tribal knowledge to operate, which meant non-technical teams who worked in Salesforce daily could not manage flags on their own.

No visibility into adoption. The system made it nearly impossible to answer basic questions like "how many partners have this feature enabled?" or "is this feature fully rolled out?" You could query the text field, but because of inconsistent formatting and typos, the results were unreliable. There was no trustworthy way to confirm whether a feature rollout was complete, which meant there was no reliable system for tracking release adoption across the partner ecosystem.

Approach

The solution was to replace the free-text field with a multi-select picklist field in Salesforce. This sounds simple, and in terms of raw implementation, it was. But the simplicity was the point. The right solution here was not a sophisticated external feature flag platform like LaunchDarkly or Split. Those tools are designed for code-level feature toggling with complex targeting rules. Our feature flags operated at the account level in Salesforce: each partner either had a feature or did not. The system needed to live where the users already worked (Salesforce), be manageable by non-technical teams (account managers), and integrate cleanly with the Partner Portal's existing flag-checking logic.

The multi-select picklist solved every identified problem. Input validation was handled by Salesforce natively: you could only select from predefined values, so misspellings, Cyrillic characters, and formatting inconsistencies were eliminated entirely. Discoverability was built in: the picklist showed every available flag, so account managers could see and select options without needing to know exact string values. Adoption tracking became a simple Salesforce report: query the picklist field, get accurate counts of which partners had which flags enabled.

Migration design

The migration itself required care. We had to preserve the state of every existing feature flag on every partner account while swapping the underlying field. The approach was to first create the new multi-select picklist field, then write a migration script that read the old text field, parsed the string array, matched each value to the corresponding picklist option, and populated the new field. We ran the migration in a sandbox environment first, validated it against a known set of accounts, then executed it in production. After confirming the new field was accurate, we updated the Partner Portal to read from the new field and deprecated the old one.

Lifecycle governance

We also established a governance process for managing flags going forward. New features would be released behind a feature flag in the picklist. As adoption grew and the feature became standard, the flag would be merged into account-level settings rather than remaining as a feature flag indefinitely. This prevented the picklist from growing unbounded and kept the system clean. The lifecycle was: introduce flag, roll out to partners, confirm full adoption, promote to account settings, retire flag.

Results

The system became the company standard for tracking feature rollouts. Before the rebuild, there was no reliable way to confirm whether a feature had been fully released to all intended partners. After, product managers could pull a Salesforce report showing exactly which partners had which features enabled, making rollout status visible for the first time. Account management teams could now manage feature flags themselves as part of their normal Salesforce workflow, which removed a bottleneck that had previously required engineering involvement for basic account configuration.

The most valuable outcome was cultural rather than technical. By making feature flags visible and manageable by non-technical teams, the system became something the entire organization used to understand release status. It was no longer a developer-only mechanism hidden in a text field. It was a shared tool that connected engineering releases to partner-facing operations.

What I'd Do Differently

The governance process for retiring old flags should have been more rigorous from the start. We defined the lifecycle (introduce, roll out, promote, retire) but did not build automation or a regular cadence to enforce it. In practice, flags accumulated faster than they were retired because nobody was accountable for the "promote and retire" step. A quarterly audit of active flags with clear ownership assignments would have kept the system cleaner.

I also would have added automated testing to verify that the Partner Portal's flag-checking logic was reading from the correct field during the migration. We tested manually and it went smoothly, but for a system that affected every partner's feature access, automated regression tests would have been the more responsible approach.

So What

This project reinforced a principle I keep coming back to: the best platform infrastructure is the infrastructure that people actually use without thinking about it. The old system required tribal knowledge, exact string matching, and engineering involvement for basic operations. The new system was just a dropdown in Salesforce. The technical sophistication decreased, and the organizational value increased. That tradeoff is almost always the right one for internal tooling. When the right way to do something is also the easiest way, adoption takes care of itself.