Current Issue:
Virtual Data Rules already support an aggregation method (sum, average, maximum, or minimum) when a destination measure is populated by multiple source accounts or meters. However, the source accounts, meters, or attributes available to populate a Virtual Account are restricted to accounts that belong to the same Location as the Virtual Account itself. There is currently no way to select source accounts from other Locations, which means it is not possible to build a Virtual Account for a Location using data from other, comparable Locations elsewhere in the portfolio. This is a real barrier for any Location that has an area account but no reliable utility account of its own, since there is no mechanism available today to estimate that missing data using consumption or EUI patterns from similar Locations. Compounding this, Virtual Data Rules also fail closed: if any one variable or source referenced in the rule does not have data for a given month, the entire Virtual Account is left unpopulated for that month rather than falling back to an average of whichever source accounts do have data. As the number of source accounts referenced in a rule grows, this makes the rule progressively less reliable rather than more, which actively discourages building rules with multiple sources even where the underlying use case calls for it.
Proposed Solution:
Allow Virtual Data Rules to source data from multiple Locations, not just the Location of the Virtual Account itself. Specifically:
- Allow an administrator to manually select a custom set of accounts and Locations to act as the source for a Virtual Data Rule, independent of any existing hierarchy, for cases where the comparable Locations do not fall neatly into an existing Group.
- Alternatively, allow an existing Classification Group or Portfolio Group to be selected as the source scope, so the rule automatically pulls the relevant measure, for example utility consumption or EUI, from every account of a given data type across all Locations in that Group, without needing to rebuild that structure manually.
- In either case, apply the existing aggregation method (average, sum, maximum, or minimum) across the selected source accounts to calculate a representative value, such as average consumption per square foot, and scale that value by the target Location's own floor area attribute to populate the Virtual Account.
- Allow individual accounts to be added or excluded from either a manual selection or a Group-based selection, so outliers can be handled without restructuring the underlying Group.
- Update the aggregation logic so the Virtual Account is still populated using whichever selected source accounts have data for a given month, instead of being left blank because one contributing account has a data gap.
Business Value:
This would give administrators two flexible paths, a manually defined set of accounts and Locations or an existing Classification and Portfolio Group, to generate reasonable, defensible utility estimates for Locations that fall outside the reach of standard Accruals, rather than being limited to same-Location data or one-to-one account relationships. It would also make multi-source Virtual Data Rules more reliable and scalable across a large portfolio, since a rule would no longer fail simply because one of several contributing accounts has a temporary data gap.
To reference accounts and meters from other locations all the relevant locations need to belong to the same facility group. Facility groups are a group type that can be enabled in the partner-facing admin settings (ADMIN --> ORGANIZATION SETTINGS --> Enable Facility Groups = YES). This same restriction applies to virtual meters.
THe IBM Docs area will be updated to include better information regarding the enabling of facility groups for virtual account configuration across locations.