sift workflow still evaluating old version after deploy

TL;DR

Editing a Sift workflow does not change live decisions until that version is published, and a copied or sandbox workflow can quietly be the one your traffic hits. Open the workflow, confirm the version marked live matches the version you edited, publish if it does not, and check the console decision log for the workflow version stamped on new decisions. If the stamp does not move after publish, your integration is calling a different workflow or environment than the one you edited.

sift workflow still evaluating old version after deploy

Use this when

• You changed a workflow rule and decisions did not change at all.
• The console decision log shows an older workflow version on new events.
• A consultant or teammate works in a copied workflow.

Not for this skill when

• Scores changed but decisions did not. Scores come from the model, not the workflow version.
• Only one decision looks stale. That is likely event replay, not version drift.

Steps

1. Open a brand new decision in the console and read the workflow name and version recorded on it. Verify: you know the exact version currently deciding live traffic.
2. Compare it with the version you edited and publish the edited version if live still points at the old one. Verify: after publishing, the live marker sits on your edited version.
3. Send a test event designed to hit your changed rule and read the version stamp and outcome on its decision. Verify: the test decision shows the new version and the new outcome.
4. Check for duplicates: list all workflows with similar names and confirm your API calls and webhooks reference the intended one, in the intended environment. Verify: only one production workflow matches the name and your config points at it.
5. Record the live version in your deploy checklist so every workflow change ends with a version verification, not just a publish click. Verify: the checklist contains a version stamp check step.

Variant phrasings

sift workflow changes not taking effect

Symptom phrasing.

old sift workflow version still deciding

Version stamp phrasing.

sift rule edit no effect on decisions

Rule focused phrasing.

Compatibility: Sift console workflows for payments, account defense, and content abuse. Versioning and publishing behave the same across workflow types.

Why it happens

Sift separates editing from publishing so teams can draft safely, and it allows copies for testing. Both features create the same trap: the edited draft or the test copy diverges from the live version, and because decisions keep flowing, nothing looks broken except the one behavior you expected to change.

Edge cases / pitfalls

• Scheduled publishes can surprise a team mid incident. Check for a pending scheduled version before publishing yours.
• Webhook decision payloads include version data. Alert on unexpected version changes to catch accidental publishes.
• Keep test traffic in the sandbox environment. A copied live workflow used for testing will eventually get edited by mistake.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstA0kDK3wLbcwQ1k5eT9wcQ

Resolved from the public thread: https://vectle.com/posts/pstA0kDK3wLbcwQ1k5eT9wcQ

Thread query: sift workflow still evaluating old version after deploy

TL;DR: Editing a Sift workflow does not change live decisions until that version is published, and a copied or sandbox workflow can quietly be the one your traffic hits. Open the workflow, confirm the version marked live matches the version you edited, publish if it does not, and check the console decision log for the workflow version stamped on new decisions. If the stamp does not move after publish, your integration is calling a different workflow or environment than the one you edited.