Mapping Settings
Learn how to configure your mappings.
Overview
Ensure users see the correct data when using Visier by correctly configuring your mappings. Choosing the right mapping configuration depends on how your data is structured and how you want to load your data on an ongoing basis.
Note:
- When loading data in Visier, mappings dictate how your data should be extracted, transformed, and loaded. For more information, see Mappings and Add a Mapping.
- You should create a mapping for each source containing data you want to extract, transform, and load in to Visier. For more information, see Sources. Depending on how your data is structured, the number of mappings you need can vary. For example, you can have your employee and employee performance data in one or multiple CSV files.
Data file type
Data file type determines how Visier treats your file uploads. For example, you can configure your mapping to treat each file upload as a snapshot of all your data at a point-in-time or an incremental update that only includes new and updated data.
Temporal
Choose temporal when taking the snapshot approach and uploading files that contain all your data at a point-in-time.
Let's say you work at an organization with three employees and you want to load all employees in April, capture a promotion that occurs for your IT Manager in May, and capture a resignation that occurs by your Finance Manager in June.
Your file for April may look like:
Snapshot date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Your file for May may look like:
Snapshot date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
05-31-2024 |
EID101 |
HR |
HR Manager |
05-31-2024 |
EID102 |
IT |
IT Director |
05-31-2024 |
EID103 |
Finance |
Finance Manager |
Your file for June may look like:
Snapshot date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
06-30-2024 |
EID101 |
HR |
HR Manager |
06-30-2024 |
EID102 |
IT |
IT Director |
Since we're using the temporal data file type, each of the files must contain the updated records for all employees even if there are no changes to the records.
Transactional profile
Choose transactional profile when you plan to upload files that only contain new or changed records.
Let's say you work at an organization with three employees and you want to load all employees in April, capture a promotion that occurs for your IT Manager in May, and capture a resignation that occurs by your Finance Manager in June.
Your file for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Your file for May may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
05-15-2024 |
EID102 |
IT |
IT Director |
Your file for June may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Status |
---|---|---|---|---|
06-16-2024 |
EID103 |
Finance |
Finance Manager |
Inactive |
Since we're using the transactional profile data file type, each file only contains employee records that have changed since the load. To remove an employee from the application completely, send the data again without the employee record.
Transactional log
Choose transactional log when you plan to upload files that are structured to be tall rather than wide and where each row represents a single property value change.
Let's say you work at an organization with three employees and you want to load all employees in April, capture a promotion that occurs for your IT Manager in May, and capture a resignation that occurs by your Finance Manager in June.
Your file for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Attribute |
Value |
---|---|---|---|
04-30-2024 |
EID101 |
Department |
HR |
04-30-2024 |
EID101 |
Job name |
HR Manager |
04-30-2024 |
EID102 |
Department |
IT |
04-30-2024 |
EID102 |
Job name |
IT Manager |
04-30-2024 |
EID103 |
Department |
Finance |
04-30-2024 |
EID103 |
Job name |
Finance Manager |
Your file for May may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Attribute |
Value |
---|---|---|---|
05-15-2024 |
EID102 |
Job name |
IT Director |
Your file for June may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Attribute |
Value |
---|---|---|---|
06-16-2024 |
EID103 |
Status |
Inactive |
Since we're using the transactional log data file type, each file only contains employee records that have changed since the load and each record consists of a column value pair. To remove an employee we had to remove their record from all previous file uploads and re-upload those files.
Validity range
Choose validity range for data that has a known start and end date.
Let's say you load employee performance data for the year 2023. Your file for may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Performance Rating |
Start date (mm-dd-yyyy) |
End date (mm-dd-yyyy) |
---|---|---|---|---|
01-01-2023 |
EID101 |
4 |
01-01-2023 |
12-31-2023 |
01-01-2023 |
EID102 |
4 |
01-01-2023 |
12-31-2023 |
01-01-2023 |
EID103 |
5 |
01-01-2023 |
12-31-2023 |
Data file types by mapping type
The available data file types change with the selected mapping type. The following table shows the data file types that can be used per mapping type.
Mapping type | Data file types |
---|---|
Regular | Temporal, transaction log, transactional profile, validity range |
Auxiliary | Temporal, transaction log, transactional profile |
Lookup | Temporal, transactional log, transactional profile, static map |
Correction | Various |
The following table describes data types for lookup mappings.
Data file type | Description |
---|---|
Temporal |
Temporal data is snapshot-style data comprising a set of records at a point in time. This data is "wide" and includes all the columns in the schema for each record. Typically, temporal data is loaded period-to-period. The loader compares the incoming data and infers if members of the subject need a system event (conception or termination). The loader needs few rules to move the records into the platform. |
Transactional log |
Transactional log is journal-style data comprising changes to data over an interval. This data is "tall" and lists only the changed attributes with the new attribute value. Each line includes a time associated with the change. This data file type makes it simpler to find changed values and fewer records are moved. Changes are not inferred but taken from the log. The loader needs additional extraction rules to move the data into the platform. |
Transactional profile |
Transactional profile is a hybrid of temporal and transactional log types. The data excludes any unchanged records and includes each changed record in its entirety. The data is "wide", where each row is included if one or more attributes have changed. The time associated with the change is included in the record. Transactional data, both log and profile types, are less verbose than temporal data and require more data business rules to create system events. |
Static map |
Static map is a special transactional profile data for lookup mappings that do not require business rules to augment the data. Static maps are useful when a lookup is used in mapping formulas. |
The following table describes the data file types for event mappings. Each data type has a key for the record that includes the key of the associated member of a subject and a timestamp.
Data file type | Description |
---|---|
Regular events | Regular events are journal-style data types where each record is an occurrence of an event—anything that happens to a subject. |
Conception events | Conception events are journal-style data types where each record is the start of the validity interval for a member of a subject. For example, employment start is event data that indicates the start of an employee profile (a profile conception event). |
Termination events | Termination events are journal-style data types where each record is the end of the validity interval for a member of a subject. For example, employee exit is event data that indicates the end of an employee's profile (a profile termination event). |
Mapping type
Mapping type is how you load and combine data from multiple sources. For example, you can populate an employee object in Visier with data that is stored in one or more files.
Regular
Choose a regular mapping type when loading primary data that you consider to be the source of truth for a selected target. Regular mapping types create and remove objects in Visier based on the records that exist in the selected data source.
Example: Let's say you want to load employee data and you have a file that you consider to be the source of truth for whether an employee currently exists or does not exist in your organization. You can create a regular mapping to ensure employees are added or removed based on the records that exist in your employee data file. Your employee data file may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Auxiliary
Choose an auxiliary mapping type when you want to augment existing data with data loaded from a different source.
Note: This only works if the auxiliary data contains an ID that matches the ID of the records you want to merge with.
Example: Building off the previous example for regular mappings, let's say you want to load employee performance data using an auxiliary mapping type. In addition to the regular mapping for your core employee data, you can create an auxiliary mapping to load your employee performance data. Your employee performance data file may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Performance Rating |
---|---|---|
04-30-2024 |
EID101 |
3 |
04-30-2024 |
EID103 |
5 |
In this example, EID102 is missing from the performance data file. Because EID102 exists in the core employee data file, EID102 will still exist in the headcount, but their performance rating is "Unknown" until you send a performance data file with a Performance Rating value for EID102.
You can use this approach to populate the employee objects in Visier with employee and employee performance data stored in separate files.
Lookup
Choose a lookup mapping type when you want to augment existing data with data loaded from a different source.
Note: This only works if the existing data contains an ID that matches the ID of the records in the lookup data source, sometimes called a foreign key.
Example: Let's say you want to load employee performance data using a lookup mapping type. You can create a regular mapping to load your core employee data. Your employee data file may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Performance ID |
---|---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
300 |
04-30-2024 |
EID102 |
IT |
IT Manager |
300 |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
500 |
You can then create a lookup mapping to load your employee performance data. Your employee performance data file may look like:
Event date (mm-dd-yyyy) |
Performance ID |
Performance Rating |
---|---|---|
04-30-2024 |
100 |
1 |
04-30-2024 |
200 |
2 |
04-30-2024 |
300 |
3 |
04-30-2024 |
400 |
4 |
04-30-2024 |
500 |
5 |
You can use this approach to populate the employee objects in Visier with employee and employee performance data stored in separate files.
Override behavior
Override behavior is how you specify which records to load when loading data on an ongoing basis. For example, let's say you load incorrect employee data for January 2024, you can re-upload the correct employee data for January 2024 and configure the override behavior to load the correct employee data and ignore the incorrect employee data.
In Visier, override behavior serves the following purposes:
- Restate data at any point in time without manually excluding previously-uploaded files.
- Group data flexibly.
- Configure override behavior once and never have to configure it again.
Visier determines whether a data file is newer or older using snapshot time. By default, snapshot time is the file's upload time, but you can set a different snapshot time in the global workspace in Data > Sources > Uploaded Files. For more information about snapshot time, see How Time Is Represented in a Source.
In each mapping, choose one of the following override behaviors:
- Event date
- Event date and subject member ID
- Record period date
- Record period date and subject member ID
Note: You can change a mapping's override behavior at any time without losing files or data.
Event date
Choose event date when you want to ignore records from previous file uploads that have an event date that matches the event date of a record in a newer file upload.
Let's say you want to load employee data for April 2024 and then reload that data with some corrections using the event date override behavior.
Your first file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Your second file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Director |
How your employee data appears in Visier:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Director |
Since the new file has a record with an event date of 04-30-2024, we only load the one record and ignore any record from previous file uploads that have an event date that matches 04-30-2024.
Event date and subject member ID
Choose event date and subject member ID when you want to ignore records from previous file uploads that have an event date and subject member ID that matches the event date and subject member ID of a record in a newer file upload.
Let's say you want to load employee data for April 2024 and then reload that data with some corrections using the event date and subject member ID override behavior.
Your first file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Your second file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Director |
How your employee data appears in Visier:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
---|---|---|---|
04-30-2024 |
EID101 |
HR |
HR Director |
04-30-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
EID103 |
Finance |
Finance Manager |
Since the new file has a record with an event date of 04-30-2024 and subject member ID of EID101, we only load the record for EID101 in the second file and load the records for EID102 and EID103 from the first file upload.
Record period date
Choose record period date when you want to ignore records from previous file uploads that have a record period date that matches the record period date of a record in a newer file upload.
Note: "Record Period Date" does not have to be a named column in your source file. Instead of a record period column, you can alternatively use the Visier Formula Language to group events based on the event date column; for example, lastDateInMonth(dateColumn("Event Date")). This is useful to load the accuracy of EventDate while also grouping events to represent the "month of" they exist in.
Let's say you want to load employee data for April 2024 and then reload that data with some corrections using the record period date override behavior.
Your first file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
04-12-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
04-18-2024 |
EID103 |
Finance |
Finance Manager |
04-30-2024 |
Your second file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Director |
04-30-2024 |
How your employee data appears in Visier:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Director |
04-30-2024 |
Since the new file has a record with an record period date of 04-30-2024, we only load the one record and ignore any record from previous file uploads that have an record period date that matches 04-30-2024.
Record period date and subject member ID
Choose record period date and subject member ID when you want to ignore records from previous file uploads that have a record period date and subject member ID that matches the record period date and subject member ID of a record in a newer file upload.
Let's say you want to load employee data for April 2024 and then reload that data with some corrections using the record period date override behavior.
Your first file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Manager |
04-30-2024 |
04-12-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
04-18-2024 |
EID103 |
Finance |
Finance Manager |
04-30-2024 |
Your second file upload for April may look like:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Director |
04-30-2024 |
How your employee data appears in Visier:
Event date (mm-dd-yyyy) |
Employee ID (EID) |
Department |
Job name |
Record period date (mm-dd-yyyy) |
---|---|---|---|---|
04-10-2024 |
EID101 |
HR |
HR Director |
04-30-2024 |
04-12-2024 |
EID102 |
IT |
IT Manager |
04-30-2024 |
04-18-2024 |
EID103 |
Finance |
Finance Manager |
04-30-2024 |
Since the new file has a record with an record period date of 04-30-2024 and subject member ID of EID101, we only load the record for EID101 in the second file and load the records for EID102 and EID103 from the first file upload.
Target group
An optional label that groups mappings together. Use target groups to update a selection of mappings for a target. The job compares changes within the same target group, so that data in other mappings is not considered missing or terminated.
Example: Let’s say you load your employee data from two files: full-time workers and contingent workers. Both files represent the same time periods and map to the Employee subject, but they're uploaded at different times. When creating mappings to load this data, you can set the target group as "Full-Time" for the full-time workers mapping and "Contingent" for the contingent workers mapping. This ensures that Employee data isn't considered missing when it's uploaded at different times.