System Events

Learn what system events are, why Visier generates them, and how to prevent them.

Overview

When incomplete data is submitted, Visier automatically generates system start and system termination events to fill in gaps and reduce inconsistencies.

This is unique to Visier’s data management and is crucial for data accuracy, consistency, and quality. System events are essential for maintaining accurate employee data, especially when there are discrepancies in employment records, such as missing start or termination dates.

Types of system events

System events produced by Visier fall into one of two categories:

  • System start events
  • System termination events

All start and termination events must be balanced. If a termination event exists in Visier, whether included in the original data or generated by Visier, there must be a start event before it.

System start events

Visier generates a system start event to address inconsistencies between an employee's start date and the employee profile. Most system start events are due to a missing start event on an expected date or an employee changing roles on the same day. For example:

  1. An employee profile begins on Jan 3.
  2. The start event file provides a start dated on Jan 2.
  3. The system events will generate a termination event on Jan 2, and a start event on Jan 3 that aligns with the profile.

System termination events

Visier generates a system termination event to address inconsistencies between an employee's termination date and the employee profile. Common scenarios that prompt system termination events include:

  • Missing termination event: When an employee’s profile shows inactive status without a recorded termination event, the system generates a termination event to match. For example, Employee X’s profile is inactive as of Jan, but there’s no termination event. The system creates one on Jan 30.
  • Misinterpreted termination date: The system treats the last working day as the termination date. If this day is the end of the month, the employee remains active for that month. For example, Employee X’s termination date is Jan 31, so their profile is active for Jan and inactive starting in Feb. The misinterpretation is because the Jan profile was sent as Inactive, which did not align with the Jan 31 termination.
  • Different termination date definitions: Some organizations define termination as the first non-working day. In these cases, the system may adjust the termination date to the previous day. For example, if Jan 31, is the first non-working day, the system uses Jan 30 as the termination date, making the Jan profile inactive.
  • End-of-month spill-over: Terminations on the last day of the month may count toward the next month’s turnover. For example, with a Jan 31 termination, Employee X contributes to Feb turnover. Adjusting the termination date to Jan 30 can prevent this, but requires you to manually set the Jan profile to inactive.

How to find system events

By default, system events are not configured to display in visualizations. To turn on system event visibility in your application, configure the Employee Starts Model and Employee Exit Model in a project.

First, configure Employee Starts Model:

  1. In a project, on the navigation bar, click Model > Concepts.

  2. In the list of concepts, select Employee Starts Model.

  3. In Configure, expand System Starts.

  4. Select System Hire.

Use the same process to configure Employee Exit Model.

  1. In a project, on the navigation bar, click Model > Concepts.

  2. In the list of concepts, select Employee Exit Model.

  3. In Configure, expand System Termination.

  4. Select System Termination.

To preview your changes, on the navigation bar, click Preview Solution.

To visualize system events in a Trend visual, search for metrics starting with “System”, for example:

  • System Start Rate
  • System Termination Rate
  • System Termination Count

In the Trend visual, click View details to see more information about the employees who have a system event to reconcile their profile data.

After reviewing your changes, publish your project to put the changes into production. For more information, see Publish Project Changes .

Configure your project to avoid system events

Removing system events will make your data more accurate. The best way to remove system events from your data is to send corrected files containing missing events. Adding missing events will remove the need for system events to be generated to align the data. For more information, see Send Data to Visier.

You can minimize the possibility of system events occurring in your data and visualizations by configuring the System Rules. Generally, the default settings for the following two rules are sufficient for the majority of cases and don’t need adjustment.

However, certain instances of system events make it necessary to adjust these rules to preserve the integrity of your data. To access system rules, open a project and navigate to Data > Rules.

  1. Profile tolerance: This tells the system rules how much time to consider when trying to align events with profiles existing and disappearing. In the event of a misalignment of data the profile tolerance rule can be adjusted. We recommend the back-to-back options, such as Back-to-back months or Back-to-back weeks, to reduce the possibility of gaps in the data and requiring a system event.
  2. Tenant start range: This setting defines the initial period the system will avoid generating certain system events. It is tied to the "Application Start Date" configured in the Tenant Settings and applies across all profiles, rather than being profile-specific. For example, if the application start date is set to Jan 1 and the "Tenant start range" is set to One month from start date the system will treat Jan 1–31 as a restricted period. During this time, no system events will be created. This prevents the system interpreting the first batch of provided data as a sudden influx of new hires without corresponding hiring events.

The tolerable amount and impact of system events that would require changing these rules are up to you. Some users determine that their effect causes no real problem when using the application and choose to ignore them entirely.