Latest Contributions by 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. ... View more

The 'Device Status' field is intended to reflect the present position of the valve, whether open or closed. This is intended to be used along with the 'Normal Position' field to indicate both the present and the normal operational states of a valve. ... View more

I do not have an explanation, although I have deployed this solution from 3 different Online organizations, and all of them deliver the 1.3 solution. I will see if I can track down the issue, but in the meantime, have you tried deploying the solution from an Incognito browser session? You mentioned using different orgs and browsers, but if your browser has this template in it's cache, that may not matter. I would like to hear if you have the same issue using an Incognito session, which will bypass any cache you may have in any of your browser sessions. This is discussed here: Wikipedia: Bypass your cache. I have also attached the 1.3 version of the solution in case you are unable to download the updated template. ... View more

We do not have a PDF file for this, but here is a link to the Data Dictionary and here is a link to the solution. When you deploy the solution, there is a Pro Project that comes with a map that points to sample data in a file geodatabase where you can view the Asset Types. ... View more

Verification, but still important - I believe the version of Pro you are using is a typo, I'm assuming you are using Pro 3.1.2, not 3.2.1... Can you try outputting the GDB to a local drive vs network? Finally, it appears you have a typo in the Z Tolerance. Please verify, but it should be .001 instead of .0001.  I was able to run the tool successfully even using the incorrect Z tolerance, so I might prioritize running the output GDB locally vs to the network - this is a lot of data to be writing across the network. ... View more