Your point about patching a broken sync is valid, but I can't agree we should skip the logs. The rule is the mechanism, but the logs contain the evidence you need to force a vendor fix.
If your deactivation rule is firing on garbage data, that's a mapping and validation failure in the platform. Without structured log analysis tying the garbage payload to the rule execution, you're just submitting a vague support ticket. You need the timestamp correlation user1086 mentioned to prove the platform accepted and acted on invalid input.
Treating it as a simple rule misconfiguration lets the vendor off the hook for their schema handling. The rule is the symptom; the log analysis is the diagnosis.
—at
Logs first. Everyone says deactivation rules, and they're probably right. But logs tell you *which* rule and *why*.
Go to System Log, filter for `user.account.update_profile` and `group.user_membership.remove` around a drop time. The initiator will be something like "Okta Universal Directory - Provisioning." That's your culprit.
Then, and this is key, check the mapping preview *for that exact user at that exact sync time*. The API payload shown there is what triggered it. You'll usually find a null or empty string where there shouldn't be.
If you don't find it, your HR system's "flexible schema" is sending different data on full vs delta syncs. The preview lies.
-- old school
Your point about the preview lying is the real takeaway. The preview uses a test API call. That payload is often sanitized and nothing like the production sync data.
Vendors treat the preview as a validation tool. It's not. It's a demo. Correlating logs with actual job payloads proves the platform is defective, not just misconfigured.
read the fine print
I get where you're coming from, and the frustration is totally warranted. A sync shouldn't require digital forensics.
But treating deactivation rules as a symptom, while true, ignores that you still need that mechanism to stop the bleeding *while* you fight for a fix. Disabling them might stop the deletions, but then your directory fills with stale, orphaned accounts, which is a whole different security risk.
The reality is you're forced to triage: logs and payload storage (like user1086 mentioned) give you the evidence to make your vendor case, and tweaking the rules is the temporary bandage that keeps the system running in the meantime. It's not a choice between one or the other, you're stuck doing both.
You're right about the triage. It's a temporary state, but that state can stretch on for months. I've had teams burn weeks cycling between rule tweaks and vendor escalations because they weren't documenting the interim.
My approach is to version the deactivation rules with a comment like "2024-03-RuleSet-BandAid-For-HR-Schema-Issue-123". Then, when the vendor finally pushes a schema validation fix, you can diff the rule history to confirm the workaround is no longer needed before you revert. Without that, you risk forgetting which changes were permanent and which were temporary patches.
Measure twice, buy once.
I get the frustration with "trust the logs" being the standard reply, but you're hitting on the real issue: it's a product failure, not a troubleshooting exercise. The deactivation rule is just the trapdoor.
Your point about treating the symptom is spot on, but even if you start there, you can use it to build a better case. When you find the rule that fired, look at the exact attribute condition. That specific condition, like "department IS BLANK," becomes your exhibit A. It's no longer "your sync is broken," it's "your system deactivated 50 users because it accepted a null department from our API, violating the sync contract." That's the evidence you take to support.
Still, it's exhausting to have to build a legal brief just to keep your directory intact.
Clean data, happy life.
Exactly, and that's where the real engineering failure hides. You've built this entire diagnostic pipeline - log correlation, rule forensics, payload storage - just to prove the vendor broke their own contract. It's like installing a surveillance system because your door lock randomly unlocks itself.
The trapdoor metaphor is perfect, but we keep blaming the trapdoor design instead of asking why the floor is so full of holes. A platform that silently accepts nulls for required attributes, then punishes you for it with automated deletions, has a fundamental validation gap. We treat it as a configuration puzzle, but it's a data integrity bug masked by "flexible" provisioning.
monoliths are not evil
Logs first, but they're a trap. You'll spend hours chasing deactivation rules when the root cause is your HR system's API sending junk.
You can't configure around garbage data. Check the mapping preview, but know it's a lie. The real sync payload is different.
Welcome to the black box. The real fix is pushing back on the vendor, but good luck with that.
Keep it simple
The preview doesn't just lie, it's a clean-room simulation. They test against a known-good snapshot, not the real-time garbage data in the sync pipeline.
You're right about finding the null. But logging the culprit rule is only step one. You need to capture the raw inbound API event from your HR system at that exact moment to prove the platform accepted the null. Otherwise, they'll claim your source sent bad data, which ends the conversation.
That timestamp correlation is the only leverage you have.
I'm also pretty new to Okta, so I'm following this closely. You mentioned checking deactivation rules. Is that the same as the deprovisioning settings under the app itself, or is it a separate rules engine somewhere?