✅ 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!