Thanks Sanford. What do you mean by Commit Latency? Would a longer wait step, such as 10 minutes, be useful for allowing all the systems to fire and populate the important data?
Given Rhune Kincaid's question, I still think that Option A is the best, followed by Option C. I only list Option B as a way to meet the request to have people added with a Lead is Created in the nurture program.
. What do you mean by Commit Latency?
That's the time before data that's requested to be written to the database (firing triggers) is available for reads from the database (filters).
There's an essential race condition (race = 2 processes are "racing" to complete and may complete in either order) when you try to pair reads from the database with triggered events. It's unfortunate but unavoidable.
Would a longer wait step, such as 10 minutes, be useful for allowing all the systems to fire and populate the important data?
No wait step is guaranteed to be long enough, so you must find a more reliable mechanism.
(I'm still not convinced btw that the situation described here is due to the commit-read race. The race gives unpredictable results, not predictably wrong results every time.)
Hey Sanford Whiteman-
If I'm understanding you correctly, this seems to be another example of multiple tiers of the database having inconsistent information (as you discussed in this related thread: Trigger fires due to Data Value Change but Filter for the same field doesn't reflect the change - fo... ).
In that other thread, the issue was related to a new value in a Data Value Changes trigger not being consistent with a filter on the same field.
For some reason, I (naively?) assumed that a Person Is Created trigger wouldn't be subject to this same limitation and that all fields would be accessible via filters upon insert. But based on your response above, it seems this isn't guaranteed either.
Would this mean that a Person Is Created trigger + any field filter would never be 100% reliable? I'm sure every Marketo instance out there uses this pattern at least a few times, especially as DVC doesn't fire when field value is present upon initial insert.
The more I encounter this issue, the more the inability to reliably combine triggers and filters seems like a major design flaw in the platform.
Thanks for the additional information Sanford Whiteman. That makes more sense now. It sounds like the hard part is that you won't fully know or understand wrong results.
Do you feel that a solution would include some sort of independent batch campaigns that look for inconsistent data and then fix it?