Exporting Approved Changes to Your HRIS
Exporting Approved Changes to Your HRIS
Once a model has been approved, org.manager produces a file of every change it contains, laid out to match the bulk import template of your HRIS or payroll system. Your HR systems team loads that file through the import process they already use, under your own approval and change control. Nothing is written into your HRIS by org.manager itself, so your system of record stays in your hands and every change passes through your usual checks before it lands.
This article covers org.manager Cloud Hosted. If you use org.manager for SAP SuccessFactors, see Writeback your data into SuccessFactors instead, which describes the MDF export route.
How it works
org.manager keeps a record of every modelling action in a model: positions created, edited, moved or disestablished, org units created, renamed or disestablished, and employees moved between positions. The Modelling Audit Log shows who made each change and when, and the Simulation Report lists every changed attribute against the original value.
An export profile turns that change list into a file in the column order, headings and codes your HRIS expects. Navigo configures the profile during your implementation to match the import template for your system, so the file your HR systems team receives looks like the one they already load by hand today, with the values filled in from the approved model. Most systems in use across Australia and New Zealand accept a bulk position or org unit import in CSV or Excel, including Chris21, Ascender, Aurion, Workday, Dayforce and SAP HCM, and the profile is built against whichever template your system uses.
The same model can have more than one export profile. A common setup is one file for the HR systems team in the HRIS load layout, a second for the org design team listing every change with old and new values for review, and a third for finance with the cost impact by business unit.
Before you export
Export from the final, approved version of the model, not a working copy. New positions and org units carry a temporary key in org.manager until your HRIS assigns a permanent ID on import, and those keys are reissued if the model is later replayed onto refreshed data. Exporting once, from the approved model, avoids a mismatch between what was reviewed and what was loaded.
If you have been merging business unit models into a master version, export from the master (see Merge Multiple Models into a Master Version). If the restructure is being implemented in phases, each phase is its own model and produces its own file.
Confirm the effective date with your HR systems team before you export. The file carries the date you set on the model, and the import will apply the changes from that date.
Export the file
Open the approved model and click the download icon under “Print & Export” in the toolbar. In the dialog, choose the HRIS profile from the “Export Profile” drop-down. Under “Start Object”, choose “Entire company” to include every change in the model, or “Root object” to export only the changes below the position or org unit you have selected on the chart, which is useful when business units are being loaded separately. Choose “CSV” or “XLSX” as the format and click “Export”.
The file downloads to your browser's download folder with the model name and date in the file name. Calculated fields such as FTE roll-ups are refreshed as part of the export, so the figures reflect the model as it stands.
What the file contains
The columns and their order depend on your HRIS template, so the layout below is an example rather than a fixed format. A position file configured for a typical bulk import looks like this:
| Column | Example | Notes |
|---|---|---|
| Action | Create / Update / Inactivate | Derived from the change type in the model |
| Position ID | 100234 or NEW_0017 | Temporary key for new positions until your HRIS assigns one |
| Position title | Senior Analyst, Workforce Planning | |
| Reports to (position ID) | 100198 | The new manager position after the move |
| Org unit code | OU-4120 | Code of the org unit the position sits in after the change |
| Cost centre | CC-88041 | |
| Job code / classification | JC-ANL3 | |
| FTE | 1.0 | |
| Effective date | 01/02/2027 | From the model's effective date |
Only positions with a change appear in the file, so a model of two thousand positions with forty changes produces a file of forty rows. Where your HRIS loads org units and employee assignments through separate templates, the profile produces a separate file for each, in the same way: one row per changed org unit with its new name and parent, and one row per employee moved to a new position with the old and new position IDs. Employee moves are included only where your HRIS import template supports them, because some systems treat a position change as an employment event that must be keyed individually.
Load the file into your HRIS
Hand the file to your HR systems or payroll team to load through the bulk import process they already use. They should validate the file in a test environment first where your HRIS offers one, then run the production import under the approvals your organisation requires for structural change. org.manager has no access to your HRIS and does not run the import, so the import sits inside your existing controls, audit trail and segregation of duties.
Once the import has run and your next data feed reaches org.manager, the live structure reflects the new design. Open the model alongside the current structure in Parallel View & Split Screen to confirm the two now match, then close the model.
Tips
If a change does not import cleanly, use the org design team's review export, which lists each attribute with its old and new value, to trace the row back to the modelling action that produced it.
If your import template changes, or you move to a new HRIS, Navigo updates the export profile to the new layout. Contact Navigo Support with a copy of the new template.
Dependent changes that your HRIS derives automatically, such as cost centre inheritance from a parent org unit, are applied by your HRIS on import according to its own rules. Check with your HR systems team which fields need to be in the file and which the system fills in.