System Rules

System rules enforce constraints on your data, such as how to deal with inactive members.

Who can use this feature?

Users can view the Rules room with this profile:

  • Data: Read (access level), Simple (view level)

Users can configure rules with this profile:

  • Data: Write (access level), Detailed (view level)

Not sure if you have this feature or capability? Reach out to your administrator.

Overview

System rules are defined by configuration settings. You can configure existing system rules, but cannot create additional rules. There is only one system rule configuration per object; you cannot configure multiple system rules per object.

Configure a system rule

  1. In a project, on the navigation bar, click Data > Rules > System Rules.
  2. Select the data category that the rule belongs to. For more information, see Data Categories.
  3. Select an object from the list.

    Note: Events are not listed. Instead, events inherit the system rules of their parent subject.

  4. Change the rule settings. For more information, see Subject system rules and Parent-child hierarchy system rules below.

Subject system rules

Subject system rules are a collection of settings that define how subject data is handled.

The following table describes each subject system rule setting.

Subject system rule Description
Profile tolerance The interval over which a subject member or profile may be inactive following a conception event before the loader triggers a system event. For more information, see Profile tolerance below.
Pair filter The corresponding events that the loader should ignore. For example, not loading conception and termination events that happen on the same day.
  • Filter none: Do not ignore any events. This is the default.
  • Filter same date: Ignore system events that happen on the same day.
Profile adjustment Sets how the loader handles change events for inactive subject members. The change event will not be made an inactive profile but the loader can either ignore the event and keep it or drop the event.
  • Ignore while inactive: Does nothing with change events that occurred while the member was inactive. This is the default.
  • Drop while inactive: Deletes all change events that occurred while the member was inactive.
Tenant start range An interval during which the loader does not generate system events. Typically, tenants use one month from the tenant start date but an explicit interval may be provided.
  • One month from start date: The loader does not create any system events for the first month of the tenant's existence. For more information about tenant start dates, see Tenant Settings.
  • Explicit start range: The loader does not create system events between the user-defined start and end dates.
Regular event handling The regular events to ignore. The loader moves the system events so the not ignored regular events occur for a valid profile.
  • Ignore None: Doesn’t exclude any events. This is the default.
  • Ignore Change Events Sources: Excludes events from the given object name of the data source.
Reset auxiliary mappings on profile start If enabled, all attributes that are mapped in any auxiliary temporal mappings will reset whenever the primary profile starts, such as a rehire.
Filter out conception and termination event pairs with overlapping validity ranges Used when a subject has data in the same time period from multiple mappings.
Set period between termination and rehire to inactive if it’s within profile tolerance period Used to set the period between termination and rehire to inactive if it's within profile tolerance period.

Profile tolerance

Profile tolerance defines a gap over which a profile may be inactive following a conception or termination event before Visier triggers a system event. The tolerance is the gap between events that will avoid an interruption in the profile. The following table describes each tolerance option.

Profile tolerance Description
Zero tolerance Conception events following termination events lead to an interruption in the profile.
Within days When a conception event follows within days of a termination event, no new profile is created. This tolerance option specifies an integer number of days. If the second event occurs in the next month but within the specified number of days, there is no interruption in the profile.
Same week When a conception event occurs in the same week as a termination event, there is no interruption in the profile. This option is rarely used and generally used with tenants loading weekly data.
Same month The default tolerance. When a conception event occurs in the same month as a termination event, there is no interruption in the profile.
Back-to-back weeks There is no interruption in the profile when a termination event happens in the same week as the conception event, or the termination event happens on the last day of the previous week.

Tip: We recommend you use this tolerance instead of the “same week” or “same month” tolerance. An exception to this recommendation is if your termination event dates are the first date not worked instead of the last date worked that Visier expects.

Back-to-back months There is no interruption in the profile when a termination event happens in the same month as the conception event, or the termination event happens on the last day of the previous month. This option is commonly used for tenants loading monthly data.

Tip: We recommend you use this tolerance instead of the “same week” or “same month” tolerance. An exception to this recommendation is if your termination event dates are the first date not worked instead of the last date worked that Visier expects.

Parent-child hierarchy system rules

Parent-child hierarchy system rules are a collection of settings that define how parent-child hierarchy data is handled. Most settings can use the default values, except super root member.

The following table describes each subject system rule setting.

Parent-child hierarchy system rule Description
Unknown member The container to hold members that are missing a property value.
Super root member A number and display name for the super root member, the root of all other members in the hierarchy.
Super root member child assignment Sets how members without parents are assigned the super root as their parent.
  • Automatic: The loader places all members without a parent under super root.
  • Explicit: The loader places specified members under the super root.

    Note: This is time insensitive. The specified organizations will report to the super root at all times in history regardless of what the data says.

Invalid reference Provides a default value for broken references. The loader checks for references to subject members that are invalid at some point in time and uses the specified default value.
  • Unknown member: Uses the configured unknown member ID. This is the default.
  • Constant value: Uses a constant ID. This may be different to the default value of the property, and allows members with bad references to be assigned to a particular chosen member.
  • Future value: Uses the ID of the next valid parent within the specified interval in milliseconds to assign to the current time.
  • Next valid parent: Uses the ID of the grandparent. You can specify the IDs that are not used to find the next valid parent. This skips the specified IDs to find the next valid parent.
Reset auxiliary mappings on profile start Enable when loading temporal data with an auxiliary mapping.
Cyclic relationship member The loader checks for and breaks cycles. If enabled, the loader places members of a former cycle under member -998 "Cyclic relationship" rather than the configured unknown member.