In map Contents pane, show table name instead of alias

[MichaelMannion]

If a feature class has an alias, and I add that feature class to a map, Pro uses the alias as the layer name in the Contents pane automatically.

• Is there a way to toggle the Contents pane to show for each layer its table name instead of its alias name?

I'm looking for something equivalent to the Show Field Aliases and Show domain and subtype descriptions toggles that we have for attribute tables:

I apologize for asking what seems like such a simple question, but I haven't been able to answer this for myself through exploring the UI or reading web search results. I have that same feeling as when I ask my wife if we're out of milk, knowing she's going to walk to the fridge and point to the carton, right at eye level, that I failed to notice.

For context, I use Pro exclusively for database design/management, and not for mapping/editing/analysis. Correspondingly, the aliases and descriptions tend to obfuscate, rather than facilitate, my workflows. Ideally, I'd like to disable table, field, subtype, and domain aliases/descriptions by default.

(FYI, there is an existing idea for disabling field aliases by default; please upvote if you'd find that useful.)

Thanks in advance.

[Robert_LeClair]

There is an ENH-000123595 - Add option to switch between displaying Actual Field Names and Alias Field Names for feature classes at a Map/Project Level in ArcMap and ArcGIS Pro.  It's in the Product Plan but I don't know when it will be implemented.

[MichaelMannion]

Thank you for your reply; that is good to know.

I think there are three types of aliases (I'll use that as the general term) that one may want to control in this way:

1. Field names / aliases
2. Subtype and domain values / descriptions
3. Table names / aliases

Broadly, the business case is the same for all three - one usually wants to see the physical names when managing objects, and the alias names when consuming them.

My question for you is:

• What is the best way to communicate this need in a way that is most effective for Esri to track - one idea/enhancement with all three types, or a three separate ideas/enhancements?

Thanks again for taking the time to respond.

[Robert_LeClair]

You're welcome!  With regards to your follow up question, please see the image below first:

In the Table Options, it seems #1 and #2 are already part of the ArcGIS Pro options to switch between Field Names/Aliases or Subtype and Domain Values and descriptions already.  #3 is the previously mentioned ENH request.  One way to get feedback on the ENH status is to call Esri Support Services and add your Customer Number to the ENH request.

[MichaelMannion]

I think there are two outstanding issues that need ideas/enhancements.

Scope

Per the screenshot above, we can currently toggle two types of aliases: field, and subtype/domain.

The issue is that we have to do this on a per-table basis. I routinely work with geodatabases with hundreds of registered tables, which makes for a lot of clicks to disable all those aliases.

If I'm understanding the enhancement correctly from its title, it is seeking specifically to facilitate this issue:

ENH-000123595 - Add option to switch between displaying Actual Field Names and Alias Field Names for feature classes at a Map/Project Level in ArcMap and ArcGIS Pro

Personally, I think this would be best handled at the application level via Project > Options.

Type

One of the three types of aliases currently has no solution: table names. We need some option for this, so we don't need to hand-jam names for every layer in every map.

From reading the comments in the existing idea referenced in the OP, those of us that want to disable aliases want to disable them generally - not on a case-by-case basis. Aliases aren't bad, there are just different categories of users whose workflows are helped and hindered by the aliases - basically ArcMap vs ArcCatalog users, respectively, who are all now using a single, consolidated ArcGIS Pro app.

To summarize, I see the situation as:

Alias type	Current solution	Desired solution
Field name	Per table window	Customizable application default
Subtype / domain	Per table window	Customizable application default
Table name	None	Customizable application default

I'll wait a while to see what transpires here and on that other idea. Once I see a consensus (or stagnation) I'll open a support case and ask them to 1) add me to the existing enhancement, and 2) update that enhancement, or create new ones, to include these closely related requirements.