40% of Job Changes Auto-Approved, and the Rule That Ignores the Import
A 3,500-employee manufacturer uses manager self-service. A Job Information change workflow routes to the manager, then to a dynamic role representing 'next-level manager'. Last month, 40% of Job Information changes completed without any approval, and the affected employees cluster in two recently acquired legal entities. Separately, a business rule that derives Division from Department on change works perfectly when an HR admin edits a record in the UI, but the same field combination arrives with Division blank when 600 records are loaded by the monthly data import. Finally, an internal audit found that three HR administrators are both the initiators and the approvers on their own compensation changes.
1. Explain how 40% of changes completed with no approval, and how the clustering by legal entity narrows the diagnosis.
Read the worked answer
An Employee Central workflow step resolves its approver when the request is submitted. If a step cannot resolve anyone, the system skips the step; if every step skips, the request completes without approval. So 'no approval' usually means 'approver could not be resolved', not 'approval was bypassed'.
Likely causes, each testable:
- The manager field on the new record is empty or points at the initiator (self-approval is skipped), so the manager step resolves to nobody.
- The dynamic role's membership is scoped by legal entity or by a job/position criterion, and the two acquired entities sit outside that target population - which is exactly why the failures cluster there. New entities frequently lack the role assignments or manager hierarchy the dynamic role depends on.
- The next-level-manager step resolves upward via a hierarchy that was never built for those entities.
Diagnostic sequence: take 10 of the 40% and read the workflow log step by step. Note for each request whether a step was skipped and why. Then check manager assignment coverage and dynamic role membership for the two acquired entities specifically. The clustering tells you this is a role/hierarchy population gap, not a random data quality problem, and the fix is configuration plus a data backfill of managers, followed by re-approval of the affected changes rather than leaving them as completed.
2. The derive-Division rule fires in the UI but not in the 600-record import. Explain why, and give two remedies with trade-offs.
Read the worked answer
Business rules fire on defined triggers - typically on-change in the UI, on-save, and on-load. An on-change rule depends on a user changing a field in a session; a bulk import writes values directly and may not present the same change event, or may set all fields in a single save so dependent derivations never see an intermediate state. That is why the same data produces different results depending on the entry path.
Remedies:
- Re-trigger the rule on save so the derivation applies regardless of entry path. Trade-off: on-save rules add processing time to every save and can cascade with other rules; you must confirm field-level execution order so Division is derived after Department is populated in the same save.
- Pre-compute in the import file. Have the source system supply Division. Trade-off: shifts the logic out of EC, duplicates it in the source, and any future rule change must be coordinated across systems - acceptable only if the source is genuinely the master of that relationship.
A third option worth naming: pass the changes through a UI-equivalent transaction or integration API that honours on-change semantics. Trade-off: slower for 600 records and not always possible with the chosen loading tool.
Whichever remedy, the immediate control is a pre-load validation query on Division-blank counts, so a silent 600-record gap never reaches production again. Verify rule trigger behaviour in your instance before committing - the exact set of supported triggers depends on your release and rule type.
3. Three HR administrators can initiate and approve their own compensation changes. Propose the control design, and say what to do about the changes already made.
Read the worked answer
This is a segregation-of-duties problem that permissions alone will not solve, because the same person holds an edit permission and an approval permission.
Control design:
- Separate the permission roles: an 'HR initiator' role that can edit job and compensation data, and an 'HR approver' role that can approve but cannot initiate. No person holds both for the same population.
- Scope both roles with a target population so approvals are limited to the group the approver is genuinely independent of; a role that is global in scope defeats the design.
- Add a workflow-level restriction that an approver cannot be the initiator of the request, and verify it is enforced rather than assumed - self-approval skipping is a known source of silent bypass.
- Give the compensation fields a change-approval scenario that routes outside the initiating team entirely.
On past changes: do not quietly amend the records. Extract the full list of requests where initiator equals approver, re-review each with an independent reviewer, document the outcome, and report the count and value to audit. The re-review is the evidence; silent correction destroys it. Then fix the records only where the review shows a genuine error, using a single dated correction per employee.