Native support for Enum (Base type: Ref) to behave like true Ref in views

[Metall]

What’s the issue?

Currently, when using a column with:

• Type: Enum
• Base type: Ref

…the system does not treat the column as a true Ref when it comes to view behavior. Specifically:

• In Table or Deck views, the values are not clickable.
• There is no automatic navigation to the detail view of the referenced row (like you get with a standard Ref).
• The system seems to treat it more like a label or text value than an interactive reference.

This makes for a confusing user experience when users expect to tap on a referenced item and go to its detail screen, but nothing happens.

Would love to see these treated like actual Ref columns: Auto-link to the Detail view like standard Refs.

This would greatly improve UX, reduce extra setup steps, and make Enum+Ref more powerful for building refined UIs.

Thanks for considering! 

[Gustavo_Eduardo]

Hi,

The behavior you mentioned is not a bug but an intentional feature of AppSheet. The reason why an Enum column with Base type: Ref does not behave like a standard Ref is that its purpose is different: it allows you to use values from another table without creating a direct relationship. This helps reduce system load and avoids unnecessary references that could impact performance.

If you need the values to be clickable and automatically navigate to the detail view, the best approach would be to use a Ref column instead of Enum. If AppSheet changed the behavior of Enum + Ref to act like a real reference, it would lose the flexibility and benefit of maintaining a lighter relationship between tables.

In short, this is not a limitation but an advantage, depending on the use case. If you need interactive references, use a Ref column; if you just want to select values without adding structural overhead, Enum + Ref remains the best option.

Best regards.

[Metall]

Ah, I see now. I clearly misunderstood the feature.

Thank you for the clear explanation! This gave me a better perspective on when to use each approach, and I’ve already come up with a cleaner solution in my app because of it. Appreciate you taking the time to explain things so clearly!

Thanks again 🙏

[Gustavo_Eduardo]

Greetings. Everyone in the community is here to help each other!

[MultiTech]

@Gustavo_Eduardo  I can't upvote comments, so... I'll do it here! (^_^)

👍👍👍👍👍👍

[Gustavo_Eduardo]

@MultiTech You know perfectly well how much we all appreciate you, Matt, but it doesn't hurt to say it! Hugs and thanks for being a great member of this community!

In fact, while working today, I realized something I already knew but hadn't paid attention to. The MAXROW() expressions and all those that search for the primary key of another table (in some of their forms) automatically generate a "Ref" type column and, consequently (in the other table), a REF_ROWS().

I tried (in cases where I didn't need a "round trip" between table 1 and table 2) changing the Ref columns to Enum Base Type Ref and this brought a pleasant surprise. The virtual REF_ROWS() is not generated in the destination table and, therefore, there is one less load for each synchronization. This is useful because imagine that every time the user syncs, these columns are calculated again and if there are many records, it's even worse.