I've seen this a few times, and in many cases the action wasn't actually being "randomly skipped." The flow logic was evaluating differently than expected, or a Run After configuration was causing behavior that wasn't obvious from the designer.
My typical troubleshooting approach is:
1. Compare a successful run vs. a problematic run
Open both run histories side-by-side and compare:
- Trigger inputs
- Outputs of the action immediately before the condition
- Condition evaluation results
- Variables and Compose outputs
Often you'll find that a field is occasionally null, blank, differently formatted, or a different data type than expected. What looks correct in the designer may not exactly match the runtime value.
2. Inspect the Condition details carefully
Click the condition in the run history and review:
- The actual expression being evaluated
- Left and right values
- Whether the condition evaluated to True or False
I've seen issues caused by:
- String vs. number comparisons ("1" vs 1)
- Extra spaces
- Null values
- Date/time conversions
- Boolean values stored as text ("true" vs true)
3. Check "Configure run after"
This is one of the most overlooked areas.
An action can run or skip depending on whether a previous action:
- Succeeded
- Failed
- Timed out
- Was skipped
If Run After settings were modified, downstream actions may behave in ways that don't immediately make sense from the visual flow layout.
4. Check for concurrency and timing issues
If your flow processes multiple records simultaneously, you may be hitting:
- Concurrency conflicts
- Delayed updates
- Data not yet committed when the next action executes
In those cases, adding a short delay, retry policy, or disabling concurrency (for testing) can help isolate the problem.
5. Add a Try/Catch pattern
For production flows, I often use:
- Scope - Try
- Scope - Catch
- Scope - Finally
combined with Configure Run After. This makes it easier to log failures and unexpected states without losing diagnostic information.
