cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Resolve case sensitity and use of Logical Name vs Schema Name in CDS $filter, $expand, $select

Each attribute in Dynamics CRM has a logical name and a schema name.

 

For example, on the opportunity entity, we have the parent account with:

  • Logical name: parentaccountid
  • Schema name: ParentAccountId

The entity definition provides both (xxx.api.crm4.dynamics.com/api/data/v9.1/EntityDefinitions(LogicalName='opportunity')?$select=LogicalName&$expand=Attributes)

Logical names are generally lower case whereas schema names include Capitalization.

 

When using $filter in GET requests (and using Filter Query in Common Data Service List Records(current environment)), the problem is that if you want to filter on lookup fields (foreign keys), the rules for knowing whether to use the schema name or logical name are frustratingly complicated.

 

System defined lookup attributes – use the logical name for both the lookup attribute and the attribute name in the lookup entity.

e.g. xxx.dynamics.com/api/data/v9.1/opportunities?$filter=parentaccountid/accountid eq ‘fd780aee-8222-ea11-a810-000d3ab550da’

 

Custom lookup attributes – use the schema name for the lookup attribute and the logical name for the attribute in the lookup entity

e.g.

xxx.dynamics.com/api/data/v9.1/opportunities?$filter=xxx_ClonedTo/opportunityid eq ‘fd780aee-8222-ea11-a810-000d3ab550da’

 

Other attribute types – use the logical name irrespective if custom or system defined

e.g.

xxx.dynamics.com/api/data/v9.1/opportunities?$filter=xxx_daysinstage eq 1

All this when creating custom attributes, the check for duplicates is case insensitive anyway.

 

Ideally apply the use of schema name or logical name consistently, or make the APIs more tolerant of using either.

 

Status: New