Google Workspace OU assignment wrong for new hire: provisioning rule failed error

TL;DR

Fix the rule input or the rule order so the hire lands in the intended OU. Read which rule the provisioning tool evaluated for the hire, compare the HR attributes it consumed, department, location, worker type, against the rule conditions and their priority order, correct the bad value or shadowed rule, then move the hire and prove the next similar hire routes correctly.

Google Workspace OU assignment wrong for new hire: provisioning rule failed

Use this when

• New hires from one department or location land in a default or wrong OU and inherit wrong policies.
• The provisioning log shows a rule matched that should not have, or no rule matched at all.
• Manually moving the user fixes settings, proving OU is the problem.

Not for this skill when

• The OU itself has wrong policies applied. Fix the OU policy inheritance instead.
• All hires land correctly except those moved manually afterwards. That is admin practice, not the rule.

Steps

1. Open the provisioning rule evaluation log and the Google Admin console user record for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. List the OU assignment rules in evaluation order and simulate the hire through them on paper using the exact HR attribute values the feed sent, noting the first matching rule and whether a broader earlier rule shadows the specific one intended. Verify: the rule that fired and the reason are identified
3. Correct the cause: fix the HR attribute value if it was wrong or in a variant form the rule does not expect, or reorder and tighten the rules so specific populations match before general ones, keeping a documented default OU for true unknowns. Verify: the saved rule set evaluates the test hire to the intended OU
4. Apply the correction in Google Workspace provisioning and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Move the affected hire to the correct OU in the Admin console now and confirm the policy change takes effect, such as device or app restrictions appropriate to the role, without disturbing the user mailbox or files, since OU moves do not affect data. Verify: the hire record shows the correct OU and policies apply
6. Run a placement audit across recent hires comparing HR department and location with assigned OU, and repair any other misplacements from the same rule flaw in one batch. Verify: the hire downstream audit check passes with no mismatches

Why it happens

OU placement is rule-driven and order-sensitive: the first matching rule wins, and rules match on HR attribute strings that change as the business evolves. A broader rule placed above a specific one, or a department value arriving in a new form, quietly routes a whole hire class to the wrong policy set while provisioning itself reports success. Because OU drives policies, the symptom appears as odd restrictions rather than a provisioning error. Evaluating the real values through the real rule order exposes the shadowing or mismatch in minutes.

Variants and edge cases

No rule matches and users land at the root

A missing catch for a new worker type is typical. Add an explicit rule for the type instead of relying on the root default.

Contractors need a restrictive OU

Give contingent workers their own rule keyed on worker type so their placement never depends on department strings.

OU correct but policies still wrong

Check policy inheritance and exceptions on the OU itself after placement is proven right; placement and policy are separate layers.

Compatibility: Applies to Google Workspace provisioning via Admin SDK, GAM, or HR connectors with OU rules. Requires Workspace admin access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstJj35W7uCHehkO-zCXmopg