✅ Check List: When to Use REF vs ENUM BaseType REF

[Gustavo_Eduardo]

Check List: When to Use REF vs ENUM BaseType REF

? “A real-world checklist for app performance and architecture”

Hi everyone,

I’ve been experimenting with AppSheet at scale, optimizing my apps for performance across multiple modules, and I’ve been questioning one core concept:

Should I always use REF columns, or are there cases where ENUM with BaseType REF is better?

Let me say this upfront — I’m not here to go against the tide. I’m here to bring data, testing, and real-life comparison to the table.

So I created this checklist to help choose intentionally, not blindly.

---

Checklist: When to Use REF or ENUM REF

1. Do you use the [Related_*] virtual column?

• Yes → Use REF

• No → Consider ENUM REF

That virtual column recalculates every sync — powerful if used, wasteful if ignored.

---

2. Do you want automatic navigation, inline views, and system-generated actions?

• Yes → REF will make your life easier

• No, I prefer full manual control → ENUM REF is fine

AppSheet gives you free UX enhancements with REF. ENUM REF requires extra work.

---

3. Do you have thousands of rows and slow syncs?

• Yes → ENUM REF can drastically improve sync speed

• No → REF is fine

REF adds hidden cost during sync via [Related_*] recalculations.

---

4. Do you need IsPartOf or cascading delete?

• Yes → Stick with REF

• No → You can replace it with bots when using ENUM REF

---

5. Do you need multiple “parent” relationships?

• Yes → ENUM REF allows much more flexible modeling

• No, it’s a classic one-to-many → REF is cleaner

---

6. Are you frequently dereferencing like [RefCol].[Name]?

• Yes → REF is more efficient and native

• No → ENUM REF works fine for structure only

---

7. Is the table read-only in this app?

• Yes → ENUM REF is usually the smarter choice

• No → Weigh the other points carefully

---

8. Are you willing to manually manage what AppSheet would auto-generate?

• Yes → Go with ENUM REF for full control

• No → Use REF and let the platform help you

---

Summary Table

Situation	Use REF	Use ENUM REF
Need [Related_*]
Use inline views / system actions
Use IsPartOf / cascading delete		(requires bots)
Optimize sync performance
Table is read-only in this app
One parent only
Multi-parent model
App has low row count		(not worth it)

---

[Follow-up] Dropdown Performance: REF vs ENUM BaseType REF in Real Time UX

What would be the UX?

The user’s experience when interacting with dropdowns (especially in forms).

Let’s get into it.

---

? What happens when a user clicks on a dropdown?

Case A: Using a REF column

• The reference table is pre-loaded during the sync.

• If there’s no Valid If, AppSheet just displays the full list — super fast.

• If there is a Valid If, it’s evaluated at click time, but:

  • If it’s simple ([Active]=TRUE), it’s instant.

  • If it’s complex (FILTER(...) or SELECT(...)), it may introduce a slight delay.

• The best practice: use a slice as the source — the filtering is done once at sync, and then it loads instantly in the dropdown.

** Result:**Lightning-fast dropdown, even with lots of rows.

---

Case B: Using an ENUM with BaseType REF

• You must define a Valid If with a formula like:

  FILTER("Products", [Active] = TRUE)
  
  

• That formula is evaluated every single time the dropdown is opened.

• Even if the data is synced, AppSheet treats it like a regular expression — it doesn’t know it’s part of a structural relationship.

• So:

  • With a short list: all good.

  • With hundreds or thousands of rows: noticeable lag.

  • Every dropdown click = new calculation.

** Result:**Smooth sync… but UX latency at click time, especially with large datasets or complex filters.

---

Comparison Table

Feature	REF	ENUM BaseType REF
Data preloaded	Yes	No
Response on dropdown click	Fast (especially with slice)	Can lag
Calculation reuse	Slice is preprocessed	Re-evaluated each time
Sync speed	Heavier	Light & fast
Best for large tables	With slices	Risky for UX
Best for read-only apps	Unnecessary	Excellent choice

---

Pro Tip: Best of Both Worlds

If you’re feeling bold, try this hybrid pattern:

• Create a hidden REF column linked to a filtered slice for fast selection.

• Use a visible Text or Enum field to store the selected value.

• Populate it from the REF via an action or Initial Value logic.

This gives you fast dropdown performance while avoiding structural overhead.

---

? Final Note

This is not about REF vs ENUM REF.
This is about architecture vs automation.
If you’re intentional, both tools are great — as long as you take full ownership of the tradeoffs.

In my case, I’ve decided to test both side by side — building mirror apps — to really feel the difference between sync time and click latency.

Feel free to try the checklist above on your own builds, and let me know how it works for you.

Absolutely, Gustavo. Here’s your post translated and polished for the AppSheet Community – Tips & Tricks section, perfectly aligned to follow up your earlier article. You can copy-paste it right away.

This isn’t just about performance — it’s about UX quality at the field level.

So if your field lives in a form and points to lots of rows, use a REF with a pre-filtered slice.
If it’s used in read-only contexts or light apps — ENUM REF still shines.

Just keep this in mind:

A slow sync is annoying,> But a laggy click breaks flow.

I hope this helps you take one more step toward clean, scalable apps.
Thanks again for all the discussions that fuel this thinking — I’ll keep testing and sharing!

Let’s elevate the way we architect in AppSheet.
Thanks for reading!

— Gustavo

[jyothis_m]

very useful tip. Thanks for sharing and thumbs up for your effort put into this

[Gustavo_Eduardo]

Thank you so much for your comment @jyothis_m . We all grow together here!