Display Record Number/Name in Retired by/Created by fields instead of GUID

[SamMontoia1]

Display Record Numbers/Names in Parcel/Parcel line Fields that depict "Retired by" and "Created by" attributes instead of GUID of the Record.  The GUID is definitely less useful when trying to determine parcel lineage to a user. 

[AmirBar-Maor]

@SamMontoia1 

I assume you already know you can navigate the relationship in the attribute pane to see the records name for parcels:

And for lines:

Question 1:
Where would you like to see the record name? In the display expression for the parcel? in the Popup? both?

There is a post that shows how you can add the record name to the parcel popup here using an Arcade expression: https://community.esri.com/t5/arcgis-parcel-fabric-blog/how-to-show-the-record-name-in-the-parcels-p...

Since lines don't have a relationship class with the records table, another approach, that would work for both parcel and lines is to use the records's GlobalID in a SQL expression with the 'Filter' arcade method.

Question 2:

Should we ship the parcel fabric with those popup expressions?

Question3:

Should we also show the name of the retired record for historic parcels?

[SamMontoia1]

For me the attribute table is where this issue exists.  But really any where the Record GUID appears in the context of a parcel or parcel line.  i.e. retired by: Record Number or name created by: Record Number or Name is more useful information to display in my workflow than the Record GUID.  Historic Parcels same story.  I think it should be the default behavior, as the Parcel Fabric is Records-Driven and as a user,  I certainly care more about  the Name/Number I have assigned a record than the Record GUID that the system assigns for me automatically.    

Below in Green I have highlighted a sample of my table of the field view. It's my parcel layer.   

Thanks for the links about adding this info to a popup.  I will try that too.

The active record  doesn't display the GUID, similar story for the attribute editor displayed in your message. 

[AmirBar-Maor]

To see the record name in the attribute table instead if the GlobalID you will need to:

1. In the fields design view hide any field you don't want to see like ObjectID, GlobalID and any GUID field.

2. Add a field CreatedByRecordName (string) and RetiredByRecordName (string). The string size should be the same size as the name field on the records table.

3. Add an attribute Rule that gets triggered on Create and Update of the feature to calculate those fields using the same Arcade expression you use in the Popups.

The advantage of using a popup or a display expression is that it displays the value 'on the fly' without performing any edit operation and taking more space. If you like to see it in the attribute table you will have to populate it using attribute rules.

[SamMontoia1]

Thanks for the suggestions @AmirBar-Maor .  And yes, I could hide the Created by Record; and Retired by Record GUIDs on my Parcels attribute table.  Though, I do hope it's clear that I am suggesting to have Created by and Retired by Name/Number instead of the Record GUID appear in the Parcels Table. Just like the Name/Number appears in the Active record Box (not the GUID).  Sorry I can't think of the term used to describe this Active Record Box:  

Regarding your suggestions 2. and 3. and in context to the Record GUID as it appears in the Attribute Table; 

Is this understanding correct:  ArcGIS Pro is assigning the Record GUID to the parcel and parcel lines features as they are created and updated.  Based on the Active Record and the actions taken.  Retiring a parcel assigns the Active Record's GUID to the Retired by field in the Parcel layer, and of course creating features pushes the active record's GUID to the Created_by field in the parcels layer.  And the phrase "among other things" seems apt for both retiring and creating features. 

What about making a pair of joins to the record table based on Created by and Retired by and Record GUIDs?  At the very least one join to the Records Table based on the Parcels Created by: to the Record GUID seems to work.  (and then I have hidden all the other fields except Record Name). 

Multiple joins probably isn't a great approach, and also multiple joins to the same table doesn't seem to be allowed.  Seems to cause a 'glitch in the matrix'.  But one join is allowed.

I do like the idea of "on the fly" displays, and creating attribute fields and rules <- I will try that too.  

[jcarlson]

@SamMontoia1  For what it's worth, we do preceisely what Amir has suggested, populating string and date fields from an attribute rule, and it's great. If you'd like, I can share the expressions we use to do it.

[AmirBar-Maor]

@SamMontoia1 

Please think of GlobalID as 'very unique' objectIDs.
We are transitioning to using them because they are unique across databases, which means data can be more easily disconnected, updated and synced back to the production system.

The relationship classes between the parcel feature class and line features class use a relationship class to the records table. A relationship class cannot rely on a string field that is entered by a human being. It is not reliable to be unique.

ObjectIDs, GlobalIDs and GUIDs are meaningless and not fun to look at - the best thing is to hide them in the layer.

Joins can be used by they also have an overhead (performance hit). Another reason for using relationship classes over joins is that relationships are exposed in the Attribute Pane and popups and let you navigate the relationship.
If it is very important for you to see the record name all the time you can also consider adding it to the parcel label expression. Of course - at any time you can turn on the records layer to see their footprints.

We will have more cool and useful depictions of parcel lineage in future releases.

[PascalVezina]

Good day,

I like this suggestion. Our record names are "Plan Numbers". If would could see instead of the GUID something meaningful, then I am all for it. Seeing Retired by {01002-42304-33005-33aaeE4} is way less meaningful than Retired by "Plan 110530 CLSR BC".

Regards,

[jcarlson]

Followup: attribute rules on parcels are great. But I would strongly advise against a similar setup for lines.

Auto-populating a field on parcel lines causes issues when using Copy Lines To, as the parent line and copied line will now have different attributes, and thus all copied lines will be re-created and kept for the record, even if you don't actively edit most of them, and you'll end up with a lot of needlessly duplicated lines.

[SamMontoia1]

@AmirBar-Maorthanks for the idea "GUID a very unique FeatureID."  That's helpful in understanding their use.  And I also understand why the model uses them and their favored status.  I reckon the trade-off is that as they are designed as much for computers and the software to understand, and their autogeneration is both a blessing and a curse. 

My argument/point is that the GUID for a record does not appear in the Active Record box; instead it's the Name field value for the active record; and that's likely because it's more understandable to the human users. Also the Record information is what is being displayed there; vs. Parcel Table that is the subject of this thread;  It seems like I am not the only one, but most often I am looking at the Table of selected parcel features.  And it would be more meaningful to have a list of names/document numbers than Record GUIDs in the each parcel's retired by and created by fields in the table.  It's a combination of it matching the documents I am working from and that the number is simpler than a GUID. 

Your answers certainly help me understand the structure of the parcel fabric and GUIDs, so again thank you. 

@jcarlsonI would be interested in some sample code/attribute rules depicting how you accomplish Amir's suggestion.  Thank you.