Org changes scramble permissions? Make org master data the single source for rights and workflows
It is easy to issue a single order, and it is difficult to make attendance, performance, approvers, and data permissions effective at the same time. If the organization is not the only source, each system becomes an outdated address book. Permission confusion is a symptom of the fragmentation of the organization's master data.
What you'll take away
- Org and assignment need one master-data source; attendance, performance, approvals, and data scope all consume the same copy.
- Appointments need an effective date; permissions switch on that date—not the click date—so people are not already on post with old-department rights.
- Approvers and data scopes follow the position, not the individual private chat designation
- Part-time/seconded/agent should explicitly model and set deadlines to avoid “seemingly permissioned”
- Pre-boarding can open a minimal account, then switch to full rights on hire effective date; connect org–assignment–permission first, then expand self-service.
The transfer order takes effect on Monday, and reimbursements still go through the old manager.
On Monday morning, the new manager of the manufacturing department discovered that subordinates were still submitting leave requests to the predecessor, the reimbursement approval chain was stuck in the email of someone who had already left, and the attendance group was still following the old workshop rules. The transfer order had been issued last week, and IT said, 'Wait for each system to be manually updated,' with OA, MES, and finance each making their own changes—some were updated, some were not. The audit didn’t uncover a hacker intrusion, but rather a split in the organization’s master data: each system had its own outdated contact list.
Issuing a transfer order is easy, but having the attendance team, performance evaluators, approvers, and data scope switch on the same day is difficult. Permission confusion is a symptom; the root cause is that there is no single truth about 'who belongs to which position on which effective date.' Continuing to maintain a separate organizational tree in each system is equivalent to ensuring that someone will miss updating it every time there is a job transfer.
There is another, more covert type: verbally assigned to a position, but the system shows a salary that shouldn't be visible; or 'let him use the old account for now,' where the person has already moved to the new position, but the permissions are still in the old department. The convenience comes at the cost of both security and efficiency, and the longer it is delayed, the harder it becomes to clean up all at once.
The only source: organization engine writes, EHR consumes
The division of labor for JEDP is suggested to be fixed in governance: the organization tree and position master data are primarily managed by the organization engine; EHR is mainly responsible for HR processes, attendance results, performance applications, and the payroll distribution chain; permissions and workflow handlers consume organization positions and permission engine rules — the HR system should not create a separate directory.
Master data minimum set: Organizational units (tree type), positions, appointments (person-position-effective period), reporting relationships, concurrent/acting positions, staffing. Without the appointment period, all 'inheritance' is guesswork. Downstream systems only read the synchronized results, and modifying the tree in reverse is prohibited. The day anyone can change the organizational tree is the day permissions permanently drift.
| Breaking point | On-site performance | What's missing |
|---|---|---|
| Multi-head maintenance of organization tree | One copy each for OA/HR/Business | Authoritative Sources and Synchronization Discipline |
| No effective date | Change rights according to the operation date | Term Start-End Range |
| Tie approval to someone | Manager resignation approvals all blocked | Find people by position/role |
| Dual-position verbalization | ‘Seems like it can be approved’ | Explicit Record and Term |
| Legal entities and administrative hybrid | Salary, taxes, and management are inextricably tangled | Dual Model Mapping |
| Pre-employment without boundaries | High permissions before joining | Minimal privilege package |
The staffing plan is also linked to the same tree: overstaffing, vacant positions not being filled for a long time, will all be amplified in recruitment pre-employment and scheduling. Transfer and departure documents should be the only legitimate entry for changes in position; changing permissions via WeChat notification is equivalent to declaring the master data invalid.
The effective date is not the operation date
The transfer order takes effect on March 1, but if the operation is recorded on March 5, the system should recalculate permissions and attendance affiliation based on March 1, and provide an explanatory rule (recalculation or adjustment document) for documents from March 1 to 4, rather than having the operation date override historical data. Future organizational adjustments that take effect should support pre-setting: completing mapping and permission package rehearsals before the merger date to avoid 'all employees being unable to approve on Monday morning.'
Historical versions of the organization must be retained. Attendance, performance, and approval records must be interpretable according to their original affiliation; otherwise, you won't have a consistent explanation during labor disputes and audits. 'The organization merged, so the history counts as a new department' — overwriting history is the most expensive form of laziness.
The approval matrix should gradually be changed to 'find people by position/role'; exceptions are handled through delegation forms. The model of assigning a specific individual without a delegate naturally conflicts with organizational adjustments—leave, job transfers, and resignations will all break the flow. The sampling criteria are very strict: randomly select a job transfer within the past 30 days and check on the effective date whether the attendance group, direct manager, approval chain, and data permissions all switch simultaneously. If even one item lags, the master data is still not the single source of truth.
Concurrent post, secondment, acting position: enter into the system, including the duration
Concurrent positions should specify the held position, data scope, whether it includes salary-sensitive fields, and the end date; secondments should distinguish attendance and performance attribution when ‘administratively still belongs to A but work instructions come from B’; acting roles are for managers' leave and are automatically revoked upon expiration. Any permanent additional permissions kept 'open for convenience to work' should be regularly audited and cleared— the number of expired but unreclaimed acting roles/concurrent positions is a barometer of permissions only increasing and never decreasing.
Temporary authorization should all go through agents/entrustment orders, and "grant permissions first and complete procedures later" is prohibited. It automatically expires at the end of the term and retains audits, which is recoverable temporary authorization; "temporary" without an expiration date becomes a ghost account after six months.
After separating legal entities from administrative organizations, staffing and approvals follow the administrative hierarchy, while contracts and personal income tax subjects follow the legal entity mapping. Factories in many regions are particularly prone to confusion: employees work at Factory A, but their contract is with Company B. If there is only one hierarchy, either permissions or salary/taxes will inevitably be wrong. Separating them in the model and associating them through mapping is much safer than forcefully merging them into one big tree.
Pre-employment and resignation: the two ends of the permission rhythm
Pre-onboarding can be done in advance for: data submission, contract signing, and onboarding tasks; however, business system permissions, salary viewing, and sensitive rosters must wait until the effective date of employment — the pre-onboarding account is a processing channel, not a pass to start work early. The recruitment session talks about permission changes from hiring to the effective date; this session discusses position inheritance and transfer effective dates — both depend on the effective date, so do not create separate address books for each.
Symmetry on departure: Rights are automatically revoked on the day of leaving, and if the handover by the proxy is not completed, it needs to be escalated. Account residues and 'the person leaves but rights remain' are common audit issues. On the day of joining, formal rights are granted; on the day of a position transfer, the approver is switched; on the day of departure, rights are withdrawn — only this same set of time discipline can make sense to auditors.
It is recommended to post the change trigger checklist on the HR and IT joint wall:
| Change | Should trigger |
|---|---|
| Job transfer | Data permissions, approvers, attendance groups, and performance relationships switch according to the effective date |
| Resign | Account deactivation, proxy handover, permission revocation |
| Concurrent Post/Secondment | Extra permission packages and scopes will be revoked upon expiration |
| Organizational Merge/Split | Historical ownership can be traced, and documents are interpreted according to the organization at that time. |
| Pre-employment → Onboarding | Minimize account switching official permission package |
| Agent | Limited-time authorization, expires upon maturity |
How does JEDP-EHR Organizational Personnel Delegate Authority
JEDP-EHR covers organizational staffing, employee records, and onboarding, transfers, and departures; permissions are inherited according to organizational positions, with the effective date of transfer orders driving the switch of permission packages and approvers. Pre-employment recruitment covers document review and onboarding procedures; attendance, performance, and salary expenses are tied to the same position. The query and approval scope for self-service and manager services is consistent with organizational permissions—agency and concurrent positions must be recoverable, and operations must be auditable.
Phase one usually starts with building the organizational engine framework and handling EHR onboarding, transfers, resignations, contracts, and rosters, and conducting spot checks on permissions effective from job transfers; phase two expands to include the attendance group along with position changes; phase three considers more employee/manager self-service. Until the authoritative source is confirmed, do not expand the scope of self-service approvals—automation will amplify the wrong structure.
Pause when not applicable: When multiple organizational charts coexist and authority cannot be determined in the short term, first establish authority and synchronize discipline; when past appointments cannot be traced, first supplement key personnel appointments and then interpret by effective date; when approvals are still mostly offline with designated individuals, first change the matrix to positions and then implement in the system; when there are gaps in the agent and concurrent position system, first supplement the term and audit requirements. For extremely small micro-enterprises with unchanged organization for half a year, manual costs are low, but once there are multiple entities or locations, preparing the template in advance is still worthwhile.
Job rotation in the past thirty days, three-question random inspection
No need to purchase new modules this week. List all systems that maintain the 'department' field, designate a single writable party, and make the rest read-only — this step is closer to 'keeping permissions orderly' than purchasing any module.
Draw nearly thirty more days of transfer samples, three questions:
- On the effective date, will the attendance group, direct manager, approval chain, and data permissions all switch at the same time?
- Are there accounts that have no positions but still hold business system permissions?
- Has the expired concurrent/acting position been withdrawn? How much are there respectively for pre-employment over-authorization and post-resignation leftovers?
If a random inspection fails, first synchronize the fixes with the effective date, then consider expanding self-service. Keep records for auditing; if the authoritative source is uncertain, stop the channel of 'email notification to systems to change permissions' and change it to read-only consumption for the sole position. Minimize pre-employment access and collect permissions on the resignation date, recommended as a fixed monthly item—establish discipline at both ends so that mid-term job transfers won’t repeat every month.
- EHR HR solution
- Recruiting pre-board
- Attendance Abnormality Closed Loop
- Performance Closed Loop
- Compensation data is reliable
Want to apply this in your plant?Resources has matching self-assessments and templates—or book a live demo.
FAQ
Quick answers on this topic—still stuck?Contact
How to distinguish between a subsidiary's legal entity and administrative organization?
Legal entities are used for contracts and payroll taxes, administrative organizations are used for management and approval, and are separated and mapped on the model; mixing into a tree is the beginning of the confusion between authority and payroll taxes.
How to do temporary authorization?
Agents/delegates with a deadline, automatically withdrawn upon expiry, and audit retention; permanent “open first” is prohibited.
Can an employee who hasn't completed onboarding be given an account?
Pre-employment accounts can be used to minimize permissions (fill in information, see onboarding tasks), and switch the official permission package on the effective date of conversion/onboarding.
What should I do about frequent organizational changes?
Use the version and effective date, do not rely on overwriting history; historical documents should be interpreted according to the organization at the time.
What should be done if the approval still specifies a large number of specific people?
Shift toward assignee-by-position/role; exceptions use delegation forms. Named-person assignment conflicts with org changes by design.