Maybe you *don't* have a race condition

Denise G. opened a great Community thread some months back, and Justin from Perkuto has an authoritative blog post out there on race conditions in Marketo.

For the uninitiated, race conditions are those feature combos in which multiple database processes finish in an indeterminate (thus effectively random) order depending on system load.

You think the order is guaranteed to be the same every time — whatever you think that order is — but it's not. The UI doesn't provide a visible warning about race conditions. You just have to learn (and reason them out if you have bit of a systems engineering background).

Race conditions are typically the province of programmers, as opposed to mere users of a commercial SaaS platform. But since Marketo is a workflow builder, it's with good reason that we interrogate which Trigger, Flow, and Filter interrelationships can be depended on 100% of the time. If it's any less than 100% it must be treated as 0%.

Again, the key is that there's not a fixed order, but you assume there is based on insufficient experience and/or incomplete testing.

An example is trying to use a webhook-updated field after a Call Webhook step, in the same Flow. Depending on where the load is felt on an instance, and how many steps are between the two, that may work, may not. Such uncertainty must round down to does not work.[1]

But that doesn't mean that no Flow steps finish doing their stuff in the exact order shown in the UI. A distinct counterexample to the webhook is if you do a Change Data Value, the new value is available in the very next step, every time! So there's no general rule like “data value changes aren't ready right away.”

Unfortunately, recent attention to these danger zones has made users overly skittish. It's not that there's explicit misinformation out there, as far as I've seen, but the mere concept of race conditions is making people think standard features can't be trusted.

Take this Community question from an experienced user:

When a person is created, does it get added to my Smart List that filters on Person fields fast enough to qualify?

First, let's rephrase that to fit the feature set a little better (I don't like the expression “added to” with Smart Lists):

When I trigger on Person is Created, can I filter on the person being a member of a nested Smart List, if that nested SL in turn filters on a value that was on the person from the moment of creation?

The answer is Yes.

When a person is created, it has a set of initial fields. For a form source, those fields come with the form; for a list source, they were in the original file; for an API-based import, they were in the JSON payload.

There's no moment at which you [a] can trigger on is Created, but [b] can't reliably read/filter/constrain on those initial fields. Even via a nested Smart List. There's no race condition here.

To be clear: this is not the same as fields that are populated at any point after creation. Two separate Smart Campaigns that both trigger on Person is Created, one of which does a Change Data Value that the other one expects to be complete, absolutely have a race condition.

And it's not the same as lots of other danger-ridden scenarios with existing leads, either.

But this is one combo you can trust.

Notes

[1] Trigger on Change Data Value after calling a webhook, as I've noted before. Don't guess with a Wait step. Just don't.