Lifecycle Status Description Values Vary Between Gas and Electric Asset Packages

GISP00

The Coded Value Domains for LifecycleStatus in the Electric Expanded Asset Package are different from the Gas UPDM Asset Packages. See screenshots attached.

I am working with a client that is a multi-utility, with electric, gas and water. In previous posts here I read that changing Lifecycle Status values is discouraged (or even not recommended?). For automation in the future I was considering using the same Lifecycle Status list from Gas. Electric & Water

1. Why are the coded value descriptions different between the electric and gas asset packages (I have not yet verified the values in water). In Electric it is 2-In Service, but in Gas it is 2-Approved. And in Electric it is 4-Planned Removal while in Gas it is 4-Under Construction

2. Can I add the coded value '32 - Abandoned' that is in Gas UPDM to the Electric Lifecycle Status?

3. This client currently moves abandoned electric features to a different feature class in the GN. Should we map those abandoned features into the ElectricLine UN feature class with the newly added Lifecycle Status 32-Abandoned in Electric?

4. The client uses a subtype UG Primary "Spare" in the GN, should we map that to the ElectricLine with LifecycleStatus 0-Out Of Service?

5. I am aware of the newer Construction Status coded value domain. What role do the Lifecycle Status and Construction Status play when tracing. 

lifecyclestatus.png

MitchellDrennan_3-1744734617469.png

JSchroeder

Great questions @GISP00,

We are currently working on publishing additional guidance around the latest Foundations updates related to Asset State (formerly Lifecycle Status) and Asset Lifecycle Status (formerly Construction Status). That information should be available soon and will address many of these questions.

Before addressing your questions individually, one important note: with the latest release, Asset State values are now aligned across foundations, while Asset Lifecycle Status values are intended to be more flexible and can be adapted to your workflows. This should help multi-utility organizations standardize where it matters, while still allowing operational differences where needed.

 

1.) Why are the coded value descriptions different?

Previously, the Gas foundation did not include a separate Construction Status field like other foundations. Instead, all lifecycle-related values were combined into a single Lifecycle Status field.

Because of this, the Lifecycle Status domain in Gas evolved differently and included both operational state and lifecycle progression values. This is why you see differences such as Approved or Under Construction in Gas versus In Service or Planned Removal in Electric.

 

In the latest release, we’ve improved alignment:

• Lifecycle Status gets renamed to Asset State and is standardized across foundations
• For foundations that had a Construction Status field it is renamed to Asset Lifecycle Status. For foundations that did not have a Construction Status field, Asset Lifecycle Status is new.

For Gas, Asset Lifecycle Status is a new field. Some legacy values were migrated, so you may still see slight differences in coded values and descriptions depending on workflows and historical usage.

 

2.) Can I add '32 - Abandoned' to Electric?

With the updated model:

• It is strongly recommended not to modify Asset State values (formerly Lifecycle Status), as these are tightly integrated with trace configurations and tier definitions.
• You are free to configure Asset Lifecycle Status values to meet your business needs.

If you need to represent Abandoned, it is appropriate to add it as an Asset Lifecycle Status value, and when something is set to abandoned its corresponding value in Asset State should be set to Out of Service.

To support consistency, we’ve also introduced a geoprocessing tool that can create an attribute rule to keep Asset State and Asset Lifecycle Status in sync, if desired Configure (your domain) Utility Network Foundation.

 

3.) Should abandoned features stay in the UN?

You can represent abandoned assets using:

• Asset State = Out of Service
• Asset Lifecycle Status = Abandoned

However, over time, it is generally recommended to establish a workflow to retire or move abandoned assets out of the utility network. This helps:

• Improve performance
• Reduce network complexity
• Simplify ongoing maintenance

Your current approach of moving abandoned assets to a separate feature class is still a valid and common pattern.

 

4.) How should “Spare” be handled?

Yes — mapping a "Spare" subtype to:

• Asset State = Out of Service

is a reasonable approach, assuming the asset is not actively participating in the network (e.g., not carrying load or flow).

This ensures the asset is still modeled in the utility network but will not participate in traces, which aligns with how spare infrastructure is typically treated.

5.) Role of Asset State vs Asset Lifecycle Status in tracing

• Asset State (formerly Lifecycle Status) is the primary driver for tracing and subnetwork participation.
  • Values of In Service and Planned Removal are considered active and will participate in traces or subnetworks.
  • Values of Out of Service or Proposed are considered inactive and will not participate in traces or subnetworks.
• Asset Lifecycle Status (formerly Construction Status) does not directly affect tracing.
  
  • It is used for tracking the lifecycle stage of an asset (e.g., planned, under construction, abandoned) for workflows, reporting, and asset management.
     

You can review how Asset State is used in tracing by looking at the trace configuration defined for each tier.