This section describes new features and functionality included in this release of Oracle Utilities Customer Program Management including the following:

This section describes new and enhanced product usability features introduced in this release, including:

In line with the strategic rebranding of "Digital Asset Management" to "Customer Program Management (CPM)", this feature updates all display names throughout the application’s user interface to reflect the new product identity. Key entities impacted include Field Meta Data, Help Text, Business Services, Message Text, Business Objects, Algorithms, Scripts, Zones, Service Programs, Batch Controls, To Do's, Data Areas, Application Services, Lookups, Insight Types, Process Flow Types, Web Catalog, UI Maps, and Inbound Web Services, among others.

Rebranding from “Digital Asset Management” to “Customer Program Management” delivers substantial business benefits by more accurately reflecting the solution’s expanded capabilities and renewed strategic focus. This shift enhances market clarity, aligns product messaging with evolving customer needs, and strengthens brand recognition.

You don't need to do anything to enable this feature.

Currently, controllable devices can be uniquely identified in the system using identifiers such as Serial Number or NIC ID. This enhancement adds support for an additional identifier to capture the device’s network address, providing another reliable way to reference and reconcile devices across integrated systems. To enable this, both the Controllable Asset and Controllable Device entities have been extended to include Network Address as a new identifier attribute. Following a successful enrollment or device replacement, the application’s outbound synchronization message will include the network address identifier along with the existing device identifiers, improving downstream device matching, inventory alignment, and operational processing.

Adding a network address as an additional device identifier and including it in outbound sync messages improves end-to-end device identification and reconciliation across integrated systems, especially when existing identifiers such as serial number or NIC ID are missing, duplicated, or change over time. Overall, it increases confidence that the right devices are being targeted and controlled during events, improving operational execution, performance measurement accuracy, and audit traceability.

You don't need to do anything to enable this feature.

Currently, the application lets you configure baseline calculation rules to produce load-based baselines after an event, and those baselines are derived only from a customer’s consumption interval meter reads. This enhancement expands the baseline calculation framework in two important ways. First, it adds support for temperature-driven baseline configurations, enabling baseline selection and/or adjustments based on weather conditions so the reference baseline better reflects temperature-sensitive load behavior. Second, it introduces logic for net-metered customers by calculating net energy—the difference between interval consumption and generation—and using that net value to derive the customer’s baseline, improving accuracy for customers with behind-the-meter generation.

To enable temperature-driven baseline calculations, customers must first be linked to a reliable source of temperature data (a “weather hub”). To support this, the data model has been enhanced to associate each customer service point with a weather station entity, and to store the station’s temperature measurements for use in baseline and other calculations. In addition, the existing Network Location sync request has been extended to transmit weather station details alongside the transformer–feeder–substation attributes. This sync process will create (or update) the weather station record as needed and establish the association between the weather station and the service point. When configuring an “X of Y” baseline rule, if you set X Selection to Temperature, the application will use temperature as the selection criterion to choose the X days from the Y eligible baseline days. Specifically, it compares the temperature values over the event window on each candidate day and selects the X days that best meet the temperature-based criteria.

The baseline calculation process has been enhanced to also check for energy generation measurements (export) in addition to the existing energy consumption measurements (import) when it evaluates the event-period interval window. When generation interval reads are present — that is, an interval contains both consumption and generation values—the application computes a net consumption value for that interval (typically consumption minus generation) and uses this net value as the basis for constructing the customer’s baseline.

These enhancements improve baseline accuracy and credibility by selecting and/or adjusting reference baselines based on temperature values across the event window and by correctly handling net-metered customers through using net consumption. By linking each service point to a weather station and storing temperature measurements via an extended network location sync, the solution establishes a scalable, reusable data foundation for weather-aware analytics.

Refer to the Defining Program Settlement Calculation Rules and Baseline Calculation Rule sections in Administrative User Guide.

Measurement & Verification (M&V) Impact Measurement quantifies the actual hourly effect of a program event—typically the change in energy use or demand—using a method that is repeatable, auditable, and statistically robust. This feature applies a Difference-in-Differences (DiD) regression technique to estimate program-level reductions for individual events; most commonly used for direct device control programs where interval meter data is available for enrolled participants. The DiD Regression technique analyzes the change in electricity consumption between a group of customers participating in a demand response program (referred to as the Treatment group) compared to a similar group not participating (referred to as the Control group), both before (pre-treatment period) and after (treatment period) the demand response event, allowing the outcome to isolate the causal effect of the program on electricity usage by accounting for any pre-existing trends in consumption patterns across the groups.

This process leverages existing entity grouping to automatically assign participating devices to a Treatment Group and define a preferred Control Group by creating a “dummy” program made up of non-participating customers. Several new objects have been introduced including a new Measuring Component set, a new Aggregator measuring component type, a M&V Usage Subscription, and an M&V Usage Transaction entity to allow associating the treatment group to the control groups, capturing the details for triggering the M&V Impact estimation process and storing the calculated values. You can also configure the number of days after the current business date post which the M&V Impact estimation process will be triggered. In addition, a new maintenance object has been introduced to capture the summary of event data at the service point level for program participants.

As the first step, the application determines the relevant program and identifies qualifying program events within a configured date range. For each event, it retrieves constituent data for both the pre-treatment and treatment periods, loads it into a staging area, and filters out records based on criteria such as event outcome and the number of participating devices for the same service point. Once the dataset is finalized, the process aggregates data across entity groups and applies DiD regression to compute the “difference of differences”: (1) the Treatment Group’s change from pre-treatment to treatment, and (2) the difference between the Treatment and Control Groups during the treatment period. The regression results are then recorded on an M&V transaction for each Treatment/Control group pairing.

After the DiD analysis is complete, separate batch processes produce the following outputs: (1) an Event Impact Extract for Program Participants, which calculates an average impact for each Treatment Group and applies it to all devices in that group behind a metered service point, (2) another Event Impact Extract for the control group service points’ consumption interval data for the same treatment/event period to serve as the comparison baseline and (3) a Statistics Extract, which generates a Regression and Coefficient Data file containing the regression-specific details for each Treatment/Control group combination.

This provides a reliable, defensible way to quantify the true hourly load reduction delivered by program events by comparing participants to a well-matched control group, minimizing distortion from weather and broader system conditions. These insights support better forecasting and target setting, smarter dispatch and enrollment strategies, and earlier identification of under-performing segments or operational issues—ultimately improving program effectiveness, cost-efficiency, and the quality of reporting to internal leadership and external stakeholders.

To enable and configure this feature, refer to the Configuring M&V Options section in the Administrative User Guide.

Currently, the application lets you configure only one Event Settlement Method as a program-level attribute, while the associated Settlement Calculation Group is maintained separately in a different zone. The settlement calculation group can include one or more calculation rules that define the baseline methodology, any variable-level computations (such as Vector and Service Quantity Math), and other settlement-specific logic such as deferred calculations. This feature will allow the application to support a more flexible settlement configuration by allowing you to associate multiple settlement methods to a single program and, when a customer or device participates in an event, to run settlement calculations independently for each method based on its configured calculation group. As part of this change, the current model that restricts a program to a single “Event Settlement Method” program-level attribute will be discontinued and replaced with the new multi-method configuration approach.

To support configuring multiple settlement methods for a program, the Settlement Calculation Group zone has been enhanced to capture the settlement method (such as Post Event or End of Season) along with the associated calculation group. This update allows you to create multiple entries in the zone—one per settlement method—to link several settlement methods to the same program. The application enforces uniqueness by preventing duplicate effective calculation groups for a given settlement method.

For instance, you can now configure a Residential Program to use a 'Post Event' settlement method with a 'kWh Settlement' calculation group that applies a baseline rule, calculates kWh savings via a VSM rule, and then settles those savings at the end of the event. Similarly, a Commercial Program can be configured to support multiple calculation groups (such as kWh settlement and kW settlement) under 'Post Event', each with its own baseline, calculation, and end-of-event settlement rule. While another Commercial Program can further be configured to support 'Post Event' kWh settlement, 'Post Event' kW settlement that is deferred, and an 'End of Season' method that finalizes kW settlement later—each handled through its own calculation group and rule set.

Allowing multiple settlement methods at the program level lets a utility support different settlement constructs (for example, kWh savings, kW drop, post-event payments, deferred or end-of-season true-ups) within a single program instead of creating and managing duplicate programs. This increases flexibility to meet tariff, regulatory, and market timelines, improves accuracy and fairness by applying the right calculation rules per settlement path, and reduces administrative overhead and configuration risk. It also strengthens transparency and auditability by clearly separating rule sets and results per method, making reporting and dispute resolution easier while enabling faster evolution and piloting of new settlement approaches.

You don't need to do anything to enable this feature.

Customer Program Management (CPM) has been enhanced to improve how Metered Service Points are associated with Weather Stations used for weather-dependent DER operations. The enhancement can use geographic location information and externally provided Weather Zone information to identify the appropriate Weather Station, while postal code provides a fallback when precise latitude/longitude is unavailable. The capability supports automatic Weather Station identification when a Service Point is created or changed and provides batch processing to identify or replace Weather Stations that are missing or no longer active. Network Location processing also validates that the identified Weather Station is active before accepting the update.

The enhancement further improves Weather Station administration by validating latitude and longitude values, providing warnings when a Weather Station is deactivated while still referenced by Service Points or postal-code defaults, and ensuring that only active Weather Meters are associated with a Weather Station. The Service Point user interface is also updated to display Weather Station information only when a value is available, while the Weather Meter portal is streamlined to remove device-specific information that is not applicable to weather measurement.

Together, these changes provide more reliable and maintainable weather associations for Metered Service Points, helping CPMCS use accurate weather information for groups of service points that share a Weather Zone or Weather Station.

This improves the accuracy and reliability of weather data available for Metered Service Points and downstream DER operations. Automated location-based assignment, external Weather Zone support, and postal-code fallback reduce manual configuration, while validation and lifecycle controls help prevent inactive or invalid Weather Stations from being used.

You don't need to do anything to enable this feature.

The sidebar Calculation Rule list zones for the Program Control Score Calculate Rule, Program Settlement Calculate Rule, and Measurement and Verification Calculate Rule have been replaced with a drawer.

Zone header UI maps were removed from affected zones, with existing header behavior moved to the applicable zone parameters. Legacy GIF and PNG icons used in the Customer Program Management Context and Current Global Contexts areas are replaced with SVG icons available through the display-icon list. These updates support consistent Redwood sidebar rendering and avoid reliance on zone header UI map functionality that is planned for deprecation.

The Admin Entities, Program, and Rate List dropdowns on Program and Metered Service have been updated to use Enhanced Lookup. This provides a more consistent and efficient selection experience, with improved search capabilities for locating and selecting applicable records.

This improves usability and accessibility of sidebar content in Redwood by ensuring text and icons remain readable and visually consistent.

You don't need to do anything to enable this feature.

This section describes new integration-related enhancements introduced in this release, including:

Customer Asset synchronization has been enhanced with additional processing intelligence to recognize the business process as customer program subscriptions and associated devices change throughout their lifecycle, and identify the relevant set of devices to synchronize with the external system.

For a new enrollment, only active devices relevant to the new subscription are synchronized, while devices previously removed but retained in the Device Location history are excluded. When a new device is added to an existing active enrollment, the applicable device information is synchronized so that the external system reflects the updated set of devices associated with the enrollment. For a device exchange, the device deactivated as part of the exchange is synchronized along with the applicable active devices, enabling the external system to reconcile the transition to the replacement device. For re-enrollment, when a previously inactive Program Subscription becomes Active again, the subscription and applicable devices are synchronized to restore the active customer and device relationship in the external system. The enhanced processing also recognizes when synchronization is not required; when a Program Subscription remains Inactive following unenrollment, subsequent changes such as Device Population updates do not generate an unnecessary Customer Asset Sync request.

This context-aware processing is particularly important when Device Locations are reused or contain historical device associations. By recognizing the business process and lifecycle context, CPMCS distinguishes between historical device relationships and devices relevant to the current transaction, ensuring that external systems receive an accurate representation of the customer program subscription and its associated devices. This helps maintain synchronized device information across systems, prevents obsolete device relationships from being propagated, preserves information required for lifecycle transitions, and avoids unnecessary synchronization.

Improves the accuracy and reliability of device information exchanged between CPMCS and external systems throughout the customer program and device lifecycle. By intelligently identifying the devices relevant to each business process, CPMCS keeps downstream device relationships synchronized, prevents obsolete device information from being propagated, supports accurate lifecycle transitions, and reduces unnecessary synchronization and downstream reconciliation.

You don't need to do anything to enable this feature.

Customer Program Management (CPM) has been enhanced to synchronize Device Population groups with external systems such as Distributed Energy Resource (DER) management systems. While network topology-based groupings are typically managed within systems such as DERMS, programmatic groupings are maintained in CPMCS, where customers and devices can be organized using business-driven criteria such as active program enrollments, customer rates, device specifications, and other applicable attributes.

The feature synchronizes the administrative definition of an Device Population group, including its identifier, description, and status, when the group is created or updated. Synchronization occurs automatically for applicable changes and can also be initiated on demand, with synchronization status providing visibility into the outcome. The actual group membership of a device is subsequently communicated through Customer Asset Synchronization, allowing the external system to associate devices with the Entity Group definitions it has already received.

This enables CPM and external systems such as DER management systems to maintain a consistent understanding of programmatic device groupings, while allowing each system to continue managing the grouping information appropriate to its business and operational domain.

This enables CPM to serve as the source for programmatic customer and device groupings while keeping those definitions and associated device memberships synchronized with external systems such as DER management systems. This allows DERMS to use business-driven groupings alongside its network topology-based groupings, reduces duplicate configuration and manual maintenance across systems, and supports consistent targeting and management of devices for downstream DER operations.

Enabling Device Population data synchronization involves the following steps: