"Flaky" is a symptom, not a diagnosis. When a Provar test passes alone but fails in a full suite run, or passes locally but fails in CI, there's almost always one of three specific causes underneath it.
1. Test Data Collisions
Tests that create or mutate shared records (the same Account, the same Queue) will pass in isolation and fail when run in parallel or in a different order, because another test changed the state first. Fix: give every test its own isolated data set, generated fresh per run rather than reused across the suite.
2. Timing Assumptions Baked Into Steps
Static waits ("wait 5 seconds") work on a fast CI runner and fail on a slower one, or vice versa. Fix: replace static waits with explicit waits on the actual condition you care about — element state, record status, or API response — not a fixed clock.
3. Environment State Drift
Sandbox refreshes, metadata changes, or leftover records from a previous failed run leave the org in a state the test didn't expect. Fix: build teardown and environment-reset steps into the suite itself, and treat "clean org state" as a precondition your suite verifies, not assumes.
The Pattern We See Most
In our experience restructuring client suites, data collisions caused by parallel execution are the single biggest source of intermittent failures — more common than timing issues. If your suite got noticeably flakier right after you turned on parallel execution to save time, start there.