Indicate what caused type of join to be used (1:1 vs 1:M)

[Bud]

Edited.

It is my understanding that there are two join scenarios in Pro (via Add Join):

1. Forced one-to-first join (1:1), even if underlying data is one-to-many.
   
   1. Possible reasons Pro used a one-to-first join:
      1. At least one of the tables doesn’t have an ObjectId.
      2. Or, the tables are not in the same workspace (aka the same geodatabase).
      3. Or, at least one of the tables isn’t registered with the geodatabase (not documented)
      4. Or, the user specified the join type in Add Join in Pro 3.3.0+. Choose if join will be one-to-first or 1:Many
2. A one-to-many (1:M) join is used/allowed, but the data might not actually have any 1:M records.
   1. Possible reasons Pro used a one-to-many join:
      1. The tables have ObjectIDs, are in the same workspace, and are registered with the geodatabase.
      2. Or, the user specified the one-to-many join type in Add Join in Pro 3.3.0+
         2.a.i above would also need to apply.

Idea:

In the Catalog layer properties, indicate what caused the type of join to be used since it isn’t always obvious, especially when using a map made by someone else. For example, Pro 3.2.2 Will Not Do a 1:M Join

[Bud]

Note:

The “Duplicate rows” warning at the bottom of the attribute table is only displayed if duplicate records are present in the data. This warning doesn’t necessarily indicate if the join type is #1 vs #2. It could be #2, but no 1:M records exist in the data, so the message wouldn’t be displayed in that case. So we can’t rely on that message to indicate if the join is #1 or #2.

With that said, the Layer Properties —> Joins tab does indicate the type of join in the cardinality section. 

[Bud]

It would also help if the Add Join geoprocessing tool could indicate why a 1:1 join is being forced, etc.