Intermediary Object Question

[SanfordWhiteman]

33 bytes, I think you mean.

Unfortunately that’s going to go over the limit of what I was envisioning, which was using a Velocity token as a lookup table. Unless — do the costs vary widely, or are there a fixed number of possible costs?

[michaelstancil]

They are unique to that zip code, and update monthly, so they vary quite a bit.

[SanfordWhiteman]

Hmm. That’s gonna stay over the Velocity limit of 100K, then.

I know it’s annoying to do, but if this is a 1-to-1 mapping from (current) Zip to data, you might as well use flat Lead fields. You can bring them in using FlowBoost (knowing you’re already a user).

[michaelstancil]

Got it.

The other way around it would be uploading just the zips that match back to current records and using that as a link to then carry over the interesting fields, yes? My concern is relying too heavily on webhooks for information that would be updated monthly (the interesting items + new zips & subsequent items) en masse, in addition to being sent to large numbers more frequently.

[SanfordWhiteman]

Yeah, you probably don’t want to run an end-of-month reconciliation for more than ~100,000 people via webhook.

So on the one hand it seems like you should use a Custom Object, where you at least you have a bulk upsert option. Still, the need to duplicate + flatten the CO instead of using 2 dimensions (junction + edge) is suboptimal.  You might as well do a bulk upsert into lead fields IMO.