SuccessFactors (SF) Data Source Requirements

Overview

org.manager ingests data extracted from SuccessFactors, supplied as flat files, and uses it to build live, accurate org charts. Your SuccessFactors / P&C systems team extracts the required objects from Employee Central and delivers them to org.manager on an agreed schedule.

This document tells the team which objects and fields to extract, how to structure and format the files, and how to represent the different ways people occupy positions (acting, higher duties, secondment, temporary and concurrent roles). Use it as the specification when configuring your extract, and confirm the exact SuccessFactors field names against your own instance, as configuration varies between organisations.

How org.manager ingests data from SuccessFactors

Data is delivered as flat files (CSV). org.manager can work with almost any structure, as long as the objects and their relationships are identifiable. The two patterns below are the most common, but they are not the only options - for example, you could supply one file for position hierarchy links, another for position-to-person links, and so on. Choose whichever is easiest to produce reliably from SuccessFactors. Complementary data from other systems can also be included, as long as it can be joined to the SuccessFactors objects.

One object per file (recommended)

Each object (Department, Position, Employee, and any optional objects) is supplied as its own file. Every file includes the linking identifier(s) that join it to the others - for example, the Employee file carries the Position ID the person occupies, and the Position file carries its Department ID. org.manager joins the files on these keys.

Single consolidated file

All attributes are flattened into one file, one record per row (typically one row per position or per occupant), carrying the position, occupant, department and any optional attributes as columns on the same row. Suitable where a single combined report is simpler to generate.

Note: Whatever structure you use, the linking identifiers must be present so objects and relationships can be identified and the hierarchy built. We prefer one file per object because some fields are ambiguous about which object they belong to - FTE and cost centre, for example, can each sit on the position or the person. A single consolidated file is fully supported.

Object types

Position and Employee are the primary objects, required to build the charts. Department is required only if you want a department hierarchy. The objects listed as optional are common examples only -any file whose data can appear in the charts is a valid addition - it is your choice whether to supply them.

Recommended filename	Category	SF source (typical)	Purpose & unique ID
OrgManager_Department.csv	Primary (if dept hierarchy)	FO -Department	Department structure and cost centre grouping. ID: Department ID
OrgManager_Position.csv	Primary	Position (MDF)	Positions and reporting lines - the chart backbone. ID: Position ID
OrgManager_Employee.csv	Primary	Person / Employment / Job Info	People, occupied positions and occupancy type. ID: Employee ID
OrgManager_BusinessUnit.csv	Optional	FO - Business Unit / Division	Higher-level org grouping. ID: Business Unit ID
OrgManager_PayRange.csv	Optional	FO - Pay Range / Grade	Pay ranges/grades for remuneration KPIs. ID: Pay Range ID
OrgManager_JobClassification.csv	Optional	FO - Job Classification	Job / classification catalogue. ID: Job Code

Hierarchical Structure

SuccessFactors customers using Position Management typically build a position-based hierarchy. org.manager also supports a department hierarchy where required.

Position structure (recommended for SF Position Management)

Hierarchy is built using Position IDs (each position points to its parent position).
KPIs and calculations are based on the position hierarchy.
Position and Person are the main data fields shown in each box.

Department hierarchy

Hierarchy is built using Department IDs (each department points to its parent department, division or business unit).
KPIs and calculations are based on the department hierarchy.
Department, Position and Person are the main data fields shown.

Note: Confirm which hierarchy you want as primary. The extract must contain the parent identifier for that hierarchy: Parent Position ID for a position structure, or Parent Department ID for a department hierarchy.

Extract Specifications

Apply these formatting and delivery rules to every extract file. They keep imports reliable and repeatable.

Parameter	Requirement / recommended value
File format	CSV. One file per object, a single consolidated file, or another structure where the objects and relationships are identifiable (see How org.manager ingests data).
Extract structure	One file per object with linking IDs is recommended. A single consolidated file, or any other structure where the objects and relationships are identifiable, is also supported.
Character encoding	UTF-8 recommended (other encodings supported). Agree encoding with Navigo if special characters appear corrupted.
Delimiter & qualifier	Comma delimiter recommended (other delimiters supported). Use a text qualifier around any value containing the delimiter or a line break.
Header row	First row contains column headings. Use identical heading names in every scheduled extract.
Record layout	One record per row, one attribute per column. No merged cells or multi-line headers.
Linking identifiers	Include the keys that join objects (e.g. Position ID on the Employee file, Department ID on the Position file).
Date format	A single consistent format across all files. Navigo renders dates in the format required in the application (for example, Australian).
Effective dating	Supply the current effective-dated record for each entity. Agree with Navigo how future-dated changes are handled.
Unique identifiers	Stable, non-reused IDs for each object. IDs must match across files where they link entities.
Empty values	Leave blank rather than writing “NULL” or placeholder text. Agree treatment of blanks for mandatory fields.
Full vs delta	Full extract each run is recommended for charting (simplest and most reliable). Confirm if delta is required.
Frequency	Agreed schedule, e.g. daily or weekly overnight refresh.
File naming	Consistent and predictable, e.g. OrgManager_Position.csv.
Delivery method	Either customer push (SFTP or agreed endpoint) or Navigo pull from an agreed customer endpoint / API. All data is hosted in Australia (NSW). If pushing the data, PGP encryption is available if required.
Data scope	We only need active positions and employees. Inactive or terminated records can be included, but they are filtered out on load.

Field Specifications

The full field list for each object is maintained in the below spreadsheet, with one tab per object grouped into primary and optional fields. Each entry shows the org.manager field, its indicative SuccessFactors source, a description and whether it is mandatory, plus columns for you to record what you will supply. Use it to confirm your fields and map them to your own SuccessFactors configuration.

The fields listed against each object are provided for reference only. They represent the fields we most commonly see across our customers, and are not a mandatory or exhaustive set. If there is a specific field you want to visualise or highlight in org.manager, that field must be included in your extract/s.

Open the field specification spreadsheet

Occupancy Types

People occupy positions in different ways. org.manager represents these using the occupancy / assignment type and the linking IDs supplied in the Employee and Position extracts. Provide the fields below so each occupancy type can be rendered correctly (for example, keeping a person’s substantive position visible while they act in or are seconded to another).

Occupancy type	What it represents	Identifying SF field(s) / link	org.manager rendering
Substantive / nominal	The permanent, main occupant of a position	Employee’s occupied Position ID with occupancy type = substantive	Shown as the position’s nominal occupant
Vacant	A position with no current occupant	Position.vacant = Yes / no linked employee Or no employee linked to a position	Rendered as a vacant position box
Acting	Temporarily occupying another position on an acting basis	Acting occupant Employee ID against the position; occupancy type = acting	Shown as the position’s acting occupant; substantive role retained
Higher duties (HD)	Temporarily performing a higher-graded role	Occupancy type / event reason = Higher Duties, with the HD Position ID	Person linked to the HD position while keeping their home position
Secondment	Temporarily assigned to another position or area	Secondary / temporary Position ID with occupancy type = secondment; end date supplied	Linked to the seconded position; home position retained
Concurrent / multiple	Holding more than one position at the same time	Multiple assignment records per person (concurrent employment)	Person appears against each position they occupy
Temporary / fixed-term	Position or occupant with a defined end date	Employment type = fixed-term / temporary, plus assignment end date	Flagged via employment type and end date

Note: The exact SuccessFactors mechanism (event reason, secondary assignment, custom occupancy field or concurrent employment) varies by configuration. Confirm how each occupancy type is recorded in your instance so it maps to the correct field in the Employee extract.

Photos

Each person’s record can be linked to a photo so employee pictures appear in the charts. To include photos:

Each photo file is named after a unique identifier in the data (typically Employee ID).
Files are in a supported format (jpg, png or bmp) and all in the same format.
For cloud-hosted environments, photos are zipped and transferred to the hosting application server.
Photo pull using Azure Graph is also supported.

Employee / user identifiers and access

Employee ID and work email address are used to integrate with your identity provider. Email authenticates the user for access to the charts (via SSO), while access levels can be varied - for example, general (non-sensitive) information for employees and broader position/employee detail for HR.

Checklist - what to send to Navigo

Primary extracts: Position and Employee (including occupancy type), plus Department if you want a department hierarchy.
Optional extracts: Business Unit, Pay Range, Job Classification - only if you want to visualise them.
Chosen extract structure: one file per object with linking IDs (recommended), a single consolidated file, or another structure where the objects and relationships are identifiable.
Linking identifiers present so objects can be joined and the hierarchy built.
Email address populated on the Employee extract for authentication.
Occupancy / assignment type populated, covering acting, higher duties, secondment, temporary and concurrent roles.
Consistent date format and stable unique IDs across all files.
Agreed delivery method: customer push (SFTP) or Navigo pull from an agreed endpoint.
Optional: zipped employee photos named by Employee ID.

Questions about your extract? Contact your Navigo technical resource or support@navigo.com.au.