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.
