How does custom-field logic work in workflows?

Say you've got a field in your contact database called industry, and some contacts have it set to "healthcare", others to "retail", and some have nothing there at all. Custom field logic is what lets your workflow look at that field and do something different for each scenario. It's the difference between one email that half your list ignores and three targeted emails that each feel like they were written just for them.

Here's how the logic actually works in practice. When a contact enters a workflow, the platform checks the condition you've set up. Think of it as a simple question the workflow asks: "What does this field say right now?" Based on the answer, it sends the contact down a specific path.

Take a real split-path example. You run a software product and you have a field called account_tier with three possible values: "free", "pro", and "enterprise". Your onboarding workflow hits a decision branch at step three:

• If account_tier equals "free", send the upgrade nudge with a discount code.
• If account_tier equals "pro", send the advanced feature walkthrough.
• If account_tier equals "enterprise", route to a personal onboarding call invitation.
• If the field is empty, send a fallback email asking them to confirm their account type.

That last branch matters a lot. Always build a fallback path for missing or unexpected field values. Skipping it is how you end up with silent gaps in your workflow where contacts just fall off the edge.

The types of custom fields that tend to power this kind of logic most usefully:

• Preference fields like product interests or content topics (things your subscriber told you about themselves at signup or in a preference center)
• Status fields like subscription level, customer type, or account status
• History fields like first purchase date, total spend, or last product category bought
• Calculated fields like days since last login or a lead score your CRM computes and writes back to the contact record

Beyond branching, custom fields do two other useful things inside workflows. First, they let you insert values directly into your message content (merge fields). Something like "We noticed you're in the healthcare space" pulls from that stored field and makes the email feel specific without you manually writing 40 versions. Second, they work as suppression conditions. If a field called opt_out_category is set to "promotions", the workflow can skip sending that contact the discount email entirely, even if they're mid-sequence.

Still the one gotcha worth knowing: logic only works as well as your data. If a field that drives a critical branch is empty for 30% of your list, those contacts hit your fallback path every single time. That's worth auditing before you build anything complex. Pull a quick count of how populated each field actually is before making it the hinge of a split path. (This is less glamorous than building the workflow but it will save you a lot of head-scratching later.)

If you want to see how this fits into broader dynamic conditions inside flows, that's worth reading next. Or if you're worried about what happens when the data is missing mid-sequence, the next question in this series covers exactly that.