App switch to work in logical names

[GregLi]

Entities, columns, and option sets have two names in CDS and SharePoint: 

• Logical name: the concise, unique, unchanging, no spaces, no punctuation, hard to read name that is used at the API level.  CDS adds a random publisher prefix to custom names that is particularly ugly.
• Display name: the long, non-unique, easily changed, localized, sure use spaces and hyphens, easy to read names that appear to end users in the apps.

We recently switched to using Display names for CDS and SharePoint.  During the Preview period, there was a switch to change back to using Logical names.  Very few authors used this switch.  Still some in the community voiced their desire for Display names to be optional and asked us to keep the switch.

We are trying to keep the permanent switch count as low as possible.  There is only one today: the non-delegation record limit.  A multitude of switches makes debugging an app harder especially when reaching out to someone else for help; the first thing that has to be done is a careful review of the switches.  We're better off if the experience is consistent across apps.

Note that you can still use logical names in formulas.  We won't advertise logical names in the formula suggestions, but they can still be used.  These formulas, working with the standard Accounts entity in CDS, refer to the same field, first with the display name:

And using the logical name:

After much debate we ultiamtely decided to remove the switch for now.  I have created this idea to capture votes to bring the switch back.  If you feel strongly about first class support for Logical names please help build the case for bringing the switch back.

[Christoph_G]

Hey Greg,

I know I am the first one voting this one up, but I would really like to keep the logical names because if you come more from a developer-side it is just the better way to go...

Reason A) Display names could be in other languages (Japanese, German, whatever) whereas technical names can be always and nicely kept in English in order to make working with them easier.

Reason B) Display Names can exist twice. I can very well make 2 "Description" fields in the CDS which are named:
DN: Description
LN: abc123_description1

DN: Description
LN: abc123_description2

It maybe doesn't make sense in this example but it COULD happen. How do I then know which field is which if I only see the display field.

And one last comment to your telemetry:
I don't know how you looked at it, but if it was simply looking at quantitative data I would question whether this represents the truth.
Casual users who just try PowerApps out (and make a couple small apps to play around) maybe don't even know about the button to switch to logical names and thus don't do it.
I also have loads of small try-out or demo-apps where I don't always make the effort to turn it to logical, because it doesn't matter on those. On bigger apps with many fields out of many entities, however, I really do prefer the logical names out of the above-mentioned reasons.
And i guess there is fewer users who really go deep into PowerApps and make big apps (and switch to logical) compared to those who either don't know or don't need to turn it off due to the purpose of the app.

I also doubt that everybody who would want the logical names back will find his/her way to this idea to cast a vote 😞

Kind regards
Christoph

[tonttu]

This might be ok if Power Apps used display names in the authoring experience, but internally stored logical names, but the current implementation is catastrophic in situations where display names are not stable, or where they become ambiguous:

• Where logical names infer much more meaning about the intended use of the column (for example the default Dataverse Account table has a column "Time Spent by me" with the logical name "timespentbymeonemailandmeetings", with the latter providing much more context)
• Where someone accidentally gives the same duplicate display name to a new field (this is not possible with unique logical names)
• Where display name translations are done at a later point in the project, causing a need to update all Power App formula references after translation (performing column translations should not be an operation that logically breaks applications)
• In multilingual authoring contexts where not all authors share the same environment language setting (their display names for the same column will differ)