1

Please help me understand the SF documentation and the proper use of these fields, in terms of accurately identifying an instance of an EntityDefinition or FieldDefinition object.

The use of the word "unique" in the documentation, for these 3 fields, is somewhat confusing.

Use Case

I extract and sync my Salesforce object metadata in an external database. I need an immutable unique identifier for my EntityDefinition and FieldDefinition objects, and unlike other objects, the Id field on these objects is not a unique identifier.

DurableId

This seems like the right field to use. The documentation for this field on both objects' pages states:

Unique identifier for the field. Always retrieve this value before using it, as the value isn’t guaranteed to stay the same from one release to the next. To simplify queries, use this field.

Across releases then, the object's DurableId value is mutable?

And the phrase "always retrieve this value before using it" confuses me.

If I have the following FieldDefintion object stored in my database:

DurableId = Account.00N5e000007f9gt

unless I know that no 'release' has occurred since I last extracted metadata, there's no guarantee that the same object in Salesforce has the same DurableId?

If that's true, then it seems that the unique identifier for a FieldDefinition or EntityDefinition object is the DurableId PLUS some form of Api version number, or am I not understanding what a release is?

DeveloperName

The FieldDefinition.DeveloperName definition states:

"The unique name of the object in the API"

Will EntityDefinitionId + DeveloperName give me an immutable unique identifier for a FieldDefinition object?

QualifiedApiName

"A unique external name for the field"

When evaluating the FieldDefinition object's data, I did some data profiling of my extracted metadata and the combination of EntityDefinitionId + QualifiedApiName gave me a unique record.

So maybe those two fields will work?

Improve this question

1 Answer 1

Reset to default
1

Metadata objects behave a little differently than data objects, as I believe they are virtual tables exposing some memory structure, hence the typical 'mental model' that we build (for ex., id is unique), which works for most data objects, may not work for metadata objects.

About DurableId, ignore the term "durable" and assume it is just some internal id they are exposing which will be unique unless they push a new release. So they are saying, do not store externally but you can safely use this within a transaction to build some references to link records.

QualifiedApiName is the object/field name that user specifies and it stays same unless a user updates the metadata, to rename the object/field. So I would use EntityDefinition.QualifiedApiName + FieldDefinition.QualifiedApiName as the absolute unique way to identify a field.

Some data for reference

SELECT EntityDefinition.DurableId, EntityDefinition.DeveloperName, EntityDefinition.QualifiedApiName,  
DurableId, DeveloperName, QualifiedApiName
FROM FieldDefinition where EntityDefinition.QualifiedApiName = 'App_Log__c'

enter image description here

Improve this answer

You must log in to answer this question.