Multi-Subject Rules Examples

Learn more about commonly used multi-subject rules for validation and additional transformation.

Overview

Multi-subject rules run on your data when it is close to its final state to use in Visier. Use multi-subject rules to do validation or additional transformations to already-modified data. In this topic, we'll walk you through a series of different examples that illustrate common multi-subject rule uses.

Multi-subject rules use the following format.

1
2
3
4
5
call RULENAME (
    ARG1, 
    ARG2, 
    …
)

• call: Instructs Visier to call the rule.
• RULENAME: Specifies the rule to use. Each rule executes different logic against the arguments in the formula. For more information about the available rules, see Rules.
• ARG1, ARG2: Specifies the objects, such as subjects or properties, to validate. For more information about possible arguments, see Arguments.

For more information about functions you can use in a multi-subject rule, see Visier Multi-Subject Rules Language.

Drop invalid records

When loading data, it's sometimes necessary to exclude data that lacks a direct or relevant association with a designated primary subject to avoid including additional data that could hinder the analysis integrity. Including irrelevant data can introduce significant noise and bias into the analysis, potentially skewing results, hindering the identification of meaningful patterns, and ultimately compromising the validity and reliability of insights derived.

For example:

• Remove applicant records that reference non-existing requisitions or have no reference.
• Remove succession records that reference non-existing employees or have no reference.

Scenario

Let’s say you're loading your Sales data from Salesforce and notice sales opportunities that aren't directly connected to an employee. Instead, the sales opportunities are placeholders or historical entries from an initial data migration, an acquisition, or test data. These opportunities exist in the Salesforce system but lack a connection to a valid employee ID in your Employee subject in Visier.

This is a problem because including unassigned sales opportunities in your analysis can skew your metrics and lead to inaccurate insights. For example:

• Misleading sales performance: Your sales per employee metrics might appear lower than they actually are if you're dividing by an inaccurately large number of opportunities.
• Incorrect attribution: You can't attribute revenue or sales activity to specific teams, regions, or individuals if a significant portion of your opportunities aren't associated with employee IDs.
• Data integrity concerns: The presence of orphaned opportunities can indicate broader data quality issues in your source system, which could impact other analyses.

To ensure the accuracy and integrity of your sales data in Visier, you'll want to use a multi-subject rule. The rule acts as a filter to exclude sales opportunity records that don't have a valid employee ID in the Employee subject.

The following table shows the available data.

You want to use multi-subject rules to drop the Opp-TEST-123 and Opp-1234 sales opportunity that do not reference a valid employee ID.

Formula breakdown

You can solve this by using the referenceRule and removeNullReferenceRuleVeyronWFA functions to check which sales opportunities do not have a valid reference to an employee.

Syntax

1
call referenceRule(source_subject, source_subject.reference_id, target_subject [, {excluded_ids}, default_value, non_active_property])

• call Invokes the function. required
• referenceRule The predefined function. required
• source_subject The subject that has the record with invalid reference. required
• source_subject.reference_id The reference that connects the source and target subject. required
• target_subject The subject to check for a valid reference. required
• {excluded_ids} A set of IDs, separated by commas, from the source_subject to ignore when running the rule.
• default_value The reference property value when its value is not valid.
• non_active_property The target_subject property that indicates whether it is active.

Example: Drop invalid employee references

The first rule checks in Sales_Opportunity if the Sales_Opportunity.Sales_PersonID reference to Employee exists in Employee. The second rule deletes invalid records.

1
call referenceRule(Sales_Opportunity, Sales_Opportunity.Sales_PersonID, Employee)

1
call removeNullReferenceRuleVeyronWFA(Sales_Opportunity, Sales_Opportunity.Sales_PersonID, false)

Result

The following table shows the data after the multi-subject rule executes.

The rule removes Opp-1234 and Opp-TEST-123 so that only Opp-2309 appears as part of the Sales Opportunity subject.

By applying this multi-subject rule, you can ensure that your Salesforce sales data in Visier is a clean and accurate representation of your organization's true sales performance.

Reconciliation rule

A subject usually has a status or stage that defines whether the record is active or inactive, closed, or completed. Sometimes, records aren't set to inactive or closed but they are stale and no longer valuable for analysis. You can use a multi-subject rule to set the records as inactive or closed based on related subjects.

For example:

• Candidates and applicants that applied to a requisition that is already filled or canceled, so the applicants and candidates should be removed from the Applied stage.
• Sales opportunities that aren't closed but the associated account is inactive, so the sales opportunities should be set to closed.

Scenario

You loaded the latest sales data from Salesforce into Visier. As you validate the data, you notice a significant discrepancy in your key sales opportunity metrics. The Total Sales Opportunities and Total Sales Opportunities metrics appear inflated.

Taking a closer look, you notice opportunities that are still in an unclosed stage, such as prospecting or discovery, but the opportunities are linked to accounts that are inactive. These opportunities should not contribute to metric calculations because they skew the overall picture, making it difficult to assess the true state of your sales pipeline and the effectiveness of your sales team. This inaccuracy can lead to flawed strategic decisions, misallocation of resources, and an overly optimistic (and misleading) view of your organization's sales performance.

The following tables show the available data.

You want to use multi-subject rules to close the Opp-4326 and Opp-1267 sales opportunities because they belong to accounts that are no longer active.

Formula breakdown

You can solve this with the stateReconciliationRule function to check which sales opportunities are linked to inactive accounts.

Syntax

1
2
3
4
5
6
7
8
9
10
11
call stateReconciliationRule(
    reference_id_Property,
    source_property,
    target_Property,
    source_subject,
    target_subject,
    state_map{
        source_property_value -> {list_target_property_value_when_valid} ->  target_property_value
    },
    grace_period
)

• call Invokes the function. required
• stateReconciliationRule The predefined function. required
• reference_id_Property The reference ID property that links the source subject with target subject. required
• source_property The source subject property to validate against. required
• target_Property The target subject property whose state to update for reconciliation. required
• source_subject The source subject to use for reconciliation. required
• target_subject The target subject to update. required
• state_map Defines whether to update the target property based on the source property value and the target property value. required
  • source_property_value The trigger to apply this rule if the source property has this value. required
  • list_target_property_value_when_valid The list of valid values in the target property that do not require an update even if source_property_value matches. required
  • target_property_value The value to update the target property to after satisfying the source_property_value and target_property_value conditions. required
• grace_period The period that the target subject's state can be invalid without being corrected by the rule with respect to the reference subject's state changes. The default is 0 (apply the rule immediately).

Example: Reconcile Sales Opportunity and Account

This rule uses the Sales_Opportunity.AccountReferenceID reference to connect the Sales_Opportunity and Account subjects.

1
2
3
4
5
6
7
8
9
10
11
12
13
call stateReconciliationRule(
    Sales_Opportunity.AccountReferenceID,
    Account.Account_Status,
    Sales_Opportunity.Opportunity_Stage,
    Account,
    Sales_Opportunity,
    {  
        "Inactive" -> { 
            {"Closed Won", "Closed Lost", "Closed Other", "Cancelled"} -> "System Rejected"},
        "Churned" -> { 
            {"Closed Won", "Closed Lost", "Closed Other", "Cancelled"} -> "System Rejected"}
    }
)

In the above example:

• Account.Account_Status is the source_property from Account to validate against.
• Sales_Opportunity.Opportunity_Stage is the target_property from Sales_Opportunity to update and reconcile.
• Account is the source_subject.
• Sales_Opportunity is the target_subject to update.
• If the Account.Account_Status is Inactive or Churned, else if Sales_Opportunity.Opportunity_Stage is not in {Closed Won, Closed Lost, Closed Other, Cancelled}, then update Sales_Opportunity.Opportunity_Stage to System Rejected.

Result

The following table shows the data after the multi-subject rule executes.

The rule removes Opp-4326 and Opp-1267 from metric calculations.

By applying this multi-subject rule, you can ensure that your Salesforce sales data in Visier represents the true state of your sales pipeline and the effectiveness of your sales team.

Extend subject validity

One common concern with loading data for different subjects that come from different source systems is that the data might have different validity.

For example, employee data starts from the time the employee was hired, but compensation data comes later. When analyzing Employee Start Count data group by Base Pay, you might see a lot of employees that don't have a corresponding base compensation.

Scenario

After loading compensation data, you look at Employee Start Count by Base Pay and notice it returns $0 for a large population of employees that were hired in the period. You're certain that the file you loaded has data for these employees. The most likely cause is that the employees' compensation is valid at a date after they were hired.

The following tables show the available data.

In the Employee Start Count by Base Pay visualization, you notice that Emp-5461 is showing in the $0 group. After investigating, you discover that the hire date for Emp-5461 is before the compensation validity start.

Formula breakdown

You can solve this with the adjustProfile function to extend the compensation data to an earlier date.

Syntax

1
2
3
4
5
6
7
call adjustProfile(
    source_subject,
    target_subject,
    keyMapper,
    useNonActiveAttribute,
    adjustToTermination
)

• call Invokes the function. required
• source_subject The subject to use as reference to adjust the target subject. required
• target_subject The subject to adjust the validity. required
• keyMapper Controls how the source subject key is translated to the target subject key.The adjustProfile rule requires that the key from source_subject exactly matches the reference key from target_subject. If the target_subject reference key has additional strings, use keyMapper to drop the additional strings.
• useNonActiveAttribute If true, the rule accounts for the non-active attribute and doesn't extend the target subject profiles beyond periods where the source subject is active. Default is false.
• adjustToTermination If true, the rule pulls back the target subject's profile changes to match the source subject's first termination within the valid range, if available. This modifies the target subject's profile change events; it does not modify termination.

Example: 

1
call adjustProfile(Employee, Employee.Employee_Budgeted_Compensation, keyDropAfter("_"))

In the above example:

• Adjust the Employee.Employee_Budgeted_Compensation validity based on Employee validity.
• keyDropAfter("_") drops strings from the underscore onward so the target key can join back to the source key. In this example, Emp-5461_BasePay becomes Emp-5461.

Result

The following table shows the data after the multi-subject rule executes.

After the rule runs, you can return to the Employee Start Count by Base Pay visualization and see that Emp-5461 is in the $89K group.

By applying this multi-subject rule, you can ensure that your data in Visier is accurate and complete in your visualizations.