-2.png?width=221&height=60&name=Navigo_Logo_High_Res%20(1)-2.png){kind=logo}
org.manager reads position, occupancy and employee data out of TechnologyOne so your org charts reflect what your system of record holds rather than a spreadsheet someone exported last quarter. Reporting lines, org unit hierarchy, vacant positions, acting arrangements, employment terms and remuneration all come across.
This article covers how a TechnologyOne structure translates into a chart, what data org.manager needs, and how to work out what your own configuration holds.
See it working first
Our live demo environment runs on fictional sample data and needs no login. It is the quickest way to see the kind of chart your TechnologyOne data would produce.
Open the org.manager demo chart
Where the data comes from
TechnologyOne Human Resources and Payroll are separate products that can be run independently or together in the same environment. Most of what an org chart needs sits in Human Resources, which covers organisation management and the employee lifecycle. Remuneration and leave balances usually come from Payroll, so if you run Human Resources on its own, some of the chart types below will not be available to you.
The data reaches org.manager as a scheduled extract. Your Navigo Solutions Architect works through the format, the schedule and the transfer method with your team during implementation, so the arrangement fits your environment and your internal controls.
For more information on transferring data securely refer this page.
Extracts are always of current data. org.manager charts reflect the position and occupancy records that are current at the time of the extract. Effective-dated history is not required.
Not sure what your configuration holds? You do not need to answer that before talking to us. Bring your TechnologyOne administrator to a scoping session with your Navigo Solutions Architect and we will work through it together against the list below.
How your structure becomes a chart
Reporting lines can be built from positions, or from organisation units, or from a combination of the two where an entity reports to either. org.manager supports all of these, and which one you have shapes what your charts look like.
- Position-based. Every position carries a reports-to position. The hierarchy is built from those links, and people are attached to the positions they occupy. Vacant positions stay in the chart because the position exists whether or not someone is in it.
- Organisation unit based. Positions sit inside org units and the hierarchy is assembled from the unit structure. This is the more common pattern in local government and education, where the org unit is the durable structure and positions move between units.
Both models produce a chart. The difference shows up in what you can report on: an org unit hierarchy gives you a stable structure to compare against over time, and a position hierarchy gives you a cleaner picture of individual reporting lines.
This is decided during requirements gathering. Your Navigo Solutions Architect will work with you on which hierarchy to build, and the extract then needs to carry the data that supports it. That is why some of the fields below are marked as required only if you are building an org unit hierarchy.
What appears in the chart
Once the hierarchy is built, org.manager shows:
- Filled positions, with the substantive occupant attached
- Acting and higher duties arrangements, where a person appears in a position they are not substantively in, provided your extract carries the acting occupant against the position
- Vacant positions, shown as vacancies rather than dropped, which is what makes establishment reporting possible
- Concurrent roles, where one person holds more than one position and appears in each
Managers are identified from the structure, not from a flag. Any position with child positions reporting to it is treated as a manager position, so you do not need to supply a separate manager or supervisor indicator.
People with no position, and positions with no place in the hierarchy, will not appear. Those are usually worth investigating in the source system rather than working around in the chart.
Charts you can build
Our chart portfolio is listed on the Getting started page, with an article for each chart covering what it shows and who it is intended for.
Which of them you can run depends on what your TechnologyOne configuration holds and whether you run Payroll alongside Human Resources. Read through the list below and tell us which fields you want on your charts, and we will confirm what that supports.
Photos
Employee photos are supplied separately from the HR extract and matched to people using a unique identifier from your data, usually the employee number.
Naming, file format and transfer requirements are covered on the Data Source Requirements page.
What we need from your TechnologyOne data
The tables below describe the data rather than the column names, because TechnologyOne configurations differ between organisations and the field a chart needs is not always where you would expect it. Your TechnologyOne administrator will know where each of these lives in your environment.
What we need from you is the set of fields you are planning to visualise or use in org.manager. Work through the list and flag the ones that matter for your charts.
Structure and hierarchy
This is the minimum. Without it there is no chart.
| Data | Why it is needed |
|---|---|
| Position identifier (required) | The unique key for each position. Everything else hangs off this |
| Reports-to position identifier | Builds the reporting line between positions. Required for a position hierarchy |
| Position title (required) | The label shown in the chart box |
| Organisation unit identifier | Required for an org unit hierarchy, or if you want to group and filter by unit |
| Parent organisation unit identifier | Builds the org unit hierarchy. Required for an org unit hierarchy |
| Organisation unit name and level | Labels and groups the structure, and drives level-based reporting |
| Position status | Distinguishes active positions from abolished or unapproved ones, so the chart does not carry dead structure |
| Position FTE or establishment value | Needed for establishment and vacancy reporting |
People and occupancy
| Data | Why it is needed |
|---|---|
| Employee identifier (required) | The unique key for each person. Also the usual match key for photos and for single sign-on |
| Occupied position identifier (required) | Attaches the person to their position |
| Preferred name and surname (required) | The name shown in the chart box |
| Assignment type | Separates substantive occupancy from acting and higher duties, so both can be shown correctly |
| Substantive position identifier | Where a person is acting, this shows the position they actually hold |
| Acting percentage and effective dates | Qualifies acting arrangements and lets you filter on them |
| Employee status | Keeps terminated and future-dated employees out of the current chart |
| Work email and phone | Drives the Corporate Directory chart |
| Date of birth or age | Generation reporting. Also feeds WGEA reporting |
| Gender | Gender reporting and WGEA |
Employment terms
| Data | Why it is needed |
|---|---|
| Employment type | Permanent, fixed term, casual. Drives employment type charts and workforce composition |
| Full time equivalent | FTE reporting, span of control and establishment |
| Hours per week and days per week | Workforce and leave calculations |
| Commencement date | Length of service reporting |
| Contract or fixed term expiry date | Surfaces upcoming vacancies before they happen |
| Award, agreement or classification | Groups the workforce and underpins remuneration reporting |
| Location | Filtering and geographic views |
| Cost centre or costing code | Budget reporting and reconciliation against Financials |
Remuneration
Usually sourced from Payroll. Charts using this data are normally restricted to People and Culture and Finance.
| Data | Why it is needed |
|---|---|
| Annual salary or FTE annual rate | Compensation and budget charts |
| Hourly rate | Costing for hourly paid staff |
| Classification step or increment | Pay progression and banding views |
| Salary band minimum and maximum | Needed for compa ratio |
| Position budgeted salary | Lets you cost vacant positions, not just filled ones |
Leave
| Data | Why it is needed |
|---|---|
| Annual leave balance | Leave liability reporting |
| Long service leave balance | Leave liability reporting |
| Personal leave balance | Leave liability reporting |
| Currently on leave flag and dates | Flags people who are away, and surfaces the acting arrangement covering them |
Anything beyond this list is fine. There is no fixed limit on what you can bring across. If there is a field in TechnologyOne you want on a chart or in a profile, talk to your Navigo Solutions Architect and we will work out how to bring it in.
Next steps
If TechnologyOne is your system of record and you want to see what your own structure looks like in org.manager, get in touch with your Navigo Solutions Architect. We will walk through which of the data above you already hold, which charts it unlocks and what the extract looks like in practice.