Data Issues Reported by Users

Find out what is required for users to report data issues (flag and fix) in the solution experience.

Overview

Users can be given the ability to report issues such as incorrect values and missing data in the solution experience. For example, if they notice an incorrect job name for an employee, they can report the issue and suggest a new value for an administrator to review.

For more information about:

Data issues can be reported for attributes and events:

  • Attributes are characteristics that pertain to a given subject or event that can be used for analysis. Attributes of the Employee subject include Birth Date, Education, Job Name, and Hourly Rate. For example, you can submit a data issue if you see the wrong Hourly Rate value listed for one of your reports.
  • Events represent an incident at a specific point in time that occurred to a subject. An Interview is an event that occurs at a point in time and is associated with an Employee subject (the interviewer) and an Applicant subject (the interviewee). For example, you can report a data issue to request the removal of a duplicate event such as an Interview.

Note: Users can report data issues for all properties except calculated properties such as Age, Compa Ratio, and Tenure. A calculated property takes a value that comes directly from the data and expression. It provides a value calculated for a given subject member. For more information about the different property types, see For more information about the different property types, see Properties.

Configuration details

The following requirements must be configured in order for this feature to work correctly:

  • Users must have access to the Flag & Fix capability. For more information on how to set capabilities in a permission, see Create a Permission.
    • This feature is only available in production. As a result, you won't be able to check if the correct capabilities have been assigned as you cannot report an issue when previewing the solution as another user.

  • In order for users to report data issues for event occurrences in the Detailed View visual (request a change to validity dates or the removal of an event), all properties of the event must be displayed in Detailed View. For example, if you want users to report an incorrect date or request the removal of an Absence event, all of its properties must be displayed in Detailed View, as shown in the following screenshot.

    Note:  

    • For properties that have more than one level, all nested values must be selected. In this example, the nested values of Absence Reason must be displayed in Detailed View (Absence Reason 0 and Absence Reason 1) before users can report data issues for this event.
    • Subject references do not have to be selected. Subject references are special properties defining links between objects by connecting a subject or event to a subject. In this example, Employee is a subject reference to the Absence event so its properties do not need to be displayed in Detailed View before users can report data issues for this event.

    For instructions on how to edit the list of properties displayed in Detailed View, see Configure View Details.

Frequently asked questions

Do reported issues ever get deleted?

No. For auditing purposes, reported issues are never deleted. You can find and download a list of all the issues that have ever been reported in the Reported Issues tab of the Data room in the global workspace of the studio experience.

What type of data load job is used to generate a data version to preview my corrections?

A partial data load job is used to generate a data version when you run a data load job in the Reported Issues room of your project. The partial data load job may take several minutes to complete.

Do I need to remove a published correction when the data in the source system is fixed?

After the data issue is fixed in the source system and the published correction is no longer needed, we recommend that you roll back the correction by removing the resolved issue in a project and publishing it. For instructions, see Roll back a correction.

Published corrections are applied at the very last stage of data loading and do not affect source files:

What happens when there are conflicting attribute values between the source system and published corrections?

Published corrections are applied at the very last stage of data loading and do not affect source files. They are applied on top of the data that you upload to Visier. As a result, the corrections will override the uploaded data if there are conflicting attribute values in the same time period unless the correction's validity end date is set to Valid until next update. Corrections with a start and end date will override new data loads.

For example, you published a correction that changed Brooke Davis' job name from Manager to Senior Manager. This new value is valid from January 23, 2020 to December 13, 2020. Let's say, Brook Davis' job name was changed in the source system from Manager to Developer and this new value is valid starting July 14, 2020. The correction overrides the source data during its validity period.

In the solution experience, you would see Brooke Davis' job name as:

  • Senior Manager from January 23, 2020 to December 13, 2020
  • Developer from December 13, 2020 onward

However, if the published correction did not have a specific end date and is set to be valid from January 23, 2020 to Valid until next update, then the source data will take precedence over the published correction.

In the solution experience, you would see Brooke Davis' job name as:

  • Senior Manager from January 23, 2020 to July 14, 2020
  • Developer from July 14, 2020 onward

What attribute value is shown when the published correction has passed its validity date?

The attribute value from the source data will appear once the end date for the published correction has passed.

For example, you published a correction that changed Brooke Davis' job name from Manager to Senior Manager. This new value is valid from January 23, 2020 to December 13, 2020. Let's say, the data issue is not corrected in your source system and Brooke's job name remains Manager.

After the published correction has passed its validity date, you would see Brooke Davis' job name as:

  • Manager from December 13, 2020 onward.

When are new events from published corrections created?

Published corrections are applied at the very last stage of data loading and do not affect source files. As a result, new events created by the corrections are added on top of the uploaded data. A new event will be added even if there's a duplicate event on the same day in the source files.

For example, you notice a missing Compensation Payout event for Haley James, so you publish a correction that creates a new Pay Change event on February 14, 2020. Months later, the data issue is corrected in your source system and the missing Compensation Payout event on February 14, 2020 is added. Until you remove the published correction, you will see two Pay Change events for Haley James on February 14, 2020 (one event from the source file and one event from the correction) in the solution experience.

To avoid duplicate events, you should remove the published correction after you fix the data issue in your source system. For instructions, see Roll back a correction.

Why can't I find an event in Visier after I publish a correction that changes the event date?

Visier automatically drops events if the event occurs at a point in time when the subject member profile (such as an employee, requisition, or learning activity) doesn't exist. If you can no longer find the event in Visier, ensure the event date of your correction falls within the valid date range where the profile exists.

Can I use this feature to correct system events?

Yes. You can offset system events by publishing a correction that removes the system event and a correction that adds the missing event. However, the date for the new event must occur at a point in time where the employee profile also exists. If the event date falls outside of the valid date range where the profile exists, the event will be dropped. As a result, you will see discrepancies between your employee Headcount and your employee Starts and Exits. This discrepancy occurs because the system event was removed, but the missing event was not added.

For example, in your source data:

  • There is no record for Employee 100 in the Employee Profile for December 2021.
  • There is a record for Employee 100 in the Employee Profile for January 2022.
  • There is no record of a start event for Employee 100 in the Starts Events file for January 2022.

Visier notices the discrepancy between the Employee Profile and Starts Events file for January 2022, so a System Start event is created. The assumption is that Employee 100 was hired in January 2022 because they are included in the Employee Profile for January.

To offset this System Start event, you publish corrections to:

  • Remove the System Start event for Employee 100 in January 2022.
  • Add a Start event for Employee 100.

Let's say in your correction, you set the date for the Start event as December 15, 2021. This would result in a discrepancy between your employee Headcount and your employee Starts because the System Start event is removed, but the Start event is not added. The Start event is dropped because the event date falls outside of the valid date range where the profile exists. There is no record of Employee 100 in the Employee Profile in December 2021. In order for the correction to offset the system event, the date for the Start event must be in January 2022 where there is a record of Employee 100 in the Employee Profile.

Why does this employee appear under the Unknown data item after I publish a correction that changes their Organization ID?

This feature cannot be used to create new values for the Organization Hierarchy. The Organization ID that you provided in your correction does not match any existing values in your Organization Hierarchy so the employee is counted as Unknown.

In this section