Skip to main content
On June 24, 2026, we pushed updated files and ID mapping references to the SFTP server. A few things changed, some of which may require action on your end. Quick summary:
  • Policy joins are working again. The Policy file was the last dataset still using the old hash-format Broker IDs after June 6. That’s fixed.
  • ID mapping files are now on the server. A cumulative reference that resolves any older ID to its current one. Join against it to keep stored IDs current.
  • Employer IDs may also have changed. An entity accuracy improvement affected some employer records.
  • Known issue. A small number of broker records appear as duplicates. We’re working on it.
For the full current schema reference, see Bulk Data Schema.

​
Policy Joins Are Working Again

On June 6, 2026, BenefitFlow migrated all Broker and Office IDs from 32-character hash strings to UUIDs. Most files updated at that time, but the Policy file didn’t ship with the new IDs right away. That meant from June 6 through June 24, any join between POLICY.Broker ID and BROKER.Broker ID returned zero matches. Both columns look like IDs, but one was a hash and one was a UUID, so they never matched. The new POLICY-20260617.csv uses UUID Broker IDs. Joins work again. If you haven’t pulled the latest Policy snapshot, do that now.

​
ID Mapping Files

Three mapping files are now available on the server, one each for Broker IDs, Office IDs, and Employer IDs. They map any ID you may have stored from before the June migration to its current canonical UUID. Each file has two columns: Source ID (an older ID) and the current canonical ID. Join your stored ID against Source ID to get the current one. Each Source ID resolves to exactly one current ID, so a straight join is safe. The mapping is many-to-one, so multiple older IDs can resolve to the same current ID. Dedupe the result if you only need distinct current IDs. These files are cumulative. They contain every ID that has ever changed, and the full table is republished with each release. That’s why they’re large and why they stay roughly this size over time. Join against the latest file as a standing step in your pipeline, and your stored IDs stay current without manual cleanup.

​
Employer IDs May Have Changed

BenefitFlow improved entity accuracy for employer records, which reassigned a large batch of Employer IDs. If you cached Employer IDs from before June 21, 2026, some of those may no longer match records in the current Employer file. Check your stored Employer IDs against EMPLOYER_ID_MAPPING_20260621.csv. If an ID appears in the Source ID column, use the corresponding current ID going forward. If your IDs don’t appear in the mapping file, they’re current and no action is needed.

​
Known Issue: Duplicate Broker Records

We’re aware that a number of broker records are showing up with more than one Broker ID: same name, same location, but two separate entries. This isn’t related to the hash-to-UUID migration. It’s a grouping issue in our entity resolution pipeline that we’re actively investigating. We expect to have a fix in the coming weeks. We’ll update this page when it’s resolved. If this is causing active problems for your pipeline, reach out to your customer success manager.

​
Questions?

Reach out to your customer success manager or email support@benefitflow.com.
Last modified on June 25, 2026