Add Warnings + Storage Support for IF–THEN–ELSE Columns

[bazd]

Warning + Storage Support for IF–THEN–ELSE Columns

---

Feature Request Summary, from a non-dev

1. Add a warning when creating IF–THEN–ELSE columns
Glide should display a message such as:

“IF–THEN–ELSE columns are computed fields. Their values cannot be written to other tables or stored through Set Column Values.”

2. Provide a supported way to store computed column outputs
Especially for IF–THEN–ELSE, Math, and other computed results — so they can be snapshotted or logged.

---

Why This Matters

IF–THEN–ELSE columns appear fully supported in Glide:

• They can be nested
• They work in logic
• They work in UI
• They appear in workflow pickers

But Glide currently does not warn that:

Their values cannot be written cross-table

Their values often cannot be written even within the same table

Set Column Values cannot read computed outputs at all

Add Row works inconsistently, depending on configuration

No workflow can “freeze” their values for snapshots or history

Builders only discover this late, after building significant logic on top of IF–THEN–ELSE fields — often weeks or months later.

By then, entire table architectures must be rebuilt.

---

Why a Warning Is Essential

A simple alert during creation would prevent major wasted effort.

For example:

“Warning: Values from this IF–THEN–ELSE column cannot be stored or written through workflows. Consider using structured Math + basic columns if you need snapshots.”

This would immediately save builders from accidentally designing themselves into a corner.

---

Why Storage Support Is Needed

Many real applications rely on the ability to freeze computed values at a point in time:

• snapshotting
• forecasting
• period-end reviews
• quota or budget planning
• analytics
• activity logging
• historical comparisons

Without the ability to store computed results, these use cases become impossible in Glide.

A simple new action like:

Store Computed Value → Basic Column

would solve 90% of the problem.

---

Conclusion

The current behavior leads to:

• silent workflow failures
• inconsistent Add Row behavior
• broken snapshot logic
• massive rebuilding effort for creators
• confusion caused by computed columns appearing in workflows despite not being writable

This is an opportunity to dramatically improve the builder experience.

Add warnings

Add a supported way to store computed results

This would prevent huge frustration and unlock many important real-world use cases for Glide.

[Jeff_Hager]

I’m going to be honest. None of this makes any sense. You kind of lost me in your other thread.

It would really help if your answered this question from your other thread because I feel like there is a misunderstanding or miscommunication somewhere along the line, with a bunch of AI responses mucking everything up.

@Jeff_Hager

Maybe we need some clarification on what you are actually trying to do because your statements are contradicting each other.

If we can better understand your exact situation and what exactly you are trying to do, then maybe we can help figure out what’s going on. Writing a computed column value into a basic column is not at all complicated and there shouldn’t be any limitations that you think may exist. It should be pretty straightforward, using a Set Column action, Add Row action, or whatever else.

…and please take AI with a large grain of salt. AI is not a knowledge base. It takes small bits and pieces of text from across the web (usually in chunks of just a few characters), determines which pieces most likely belong together, based on context from your previous conversation with AI, and tries to put them together to build coherent and relatable responses. That also means it can and does hallucinate and make things up that don’t exist. It’s good, but it’s far from perfect.

[Robert_Petitto]

Completely agree. There’s absolutely no reason why we need a warning when creating a computer column.

[bazd]

i created a loom to explain my challenge here: Troubleshooting Data Transfer Between Sales Metrics and Plan History Tables | Loom

[bazd]

Absolutely no reason a new user could do with some guardrails. OK.

[Jeff_Hager]

Tell me more about the IF column used here. How is that configured and what are the column types being returned by the IF column? Where are those values coming from?

I have two theories at the moment. Either the IF column is trying to pull a value that the user does not have access to, or it’s actually writing the value, but it’s being treated as text instead of a number. If you change the local column from numeric to text, does the value show up?

[Darren_Murphy]

@Jeff_Hager

Either the IF column is trying to pull a value that the user does not have access to,

Yeah, my guess would be Row Owners somewhere causing the issue.
The other thing worth noting is that most of the non-computed columns in that Sales Metrics table are User Specific, which could also be coming into play. Given the name of the table, that doesn’t make any sense at all.

[Jeff_Hager]

I’m understanding that Sales Metrics is a helper table for a custom form, so that’s where the user specific columns come in.

[Darren_Murphy]

ah, okay. I missed that

[bazd]

What this field does

This field calculates the final prospecting percentage a rep should use for the current month, based on three things:

1. Whether the period has passed the “effective cutoff” (i.e Months left in the sales cycle > months left in the year so prospecting may not benefit you this year).
2. Whether the user has chosen to allow prospecting after the cutoff.
3. Whether the prospecting after the cutoff should follow a fixed percentage or a tapered percentage.

---

Breakdown of the logic shown in the screenshot

1. If the Effective Period Flag equals 1 → return 100

This means:
If we are before the cutoff period, the rep should prospect at 100 %.
This overrides everything else.

---

2. If “Prospect After Cutoff?” (from User) is empty → return the Fixed Prospecting %

This means:
If the user hasn’t selected anything yet for “Prospect After Cutoff?”, Glide treats that as blank.
In that case, we default to using the Fixed Prospecting % (Post-Cutoff) value.

This avoids breaking the logic when onboarding fields haven’t been filled in yet.

---

3. If “Prospect After Cutoff?” is TRUE → return the Tapered Prospecting % this Month

This means:
If the user explicitly chooses to continue prospecting after cutoff and to use the tapered strategy, then the formula outputs the tapered percentage for this month.

---

ELSE → return the Fixed Prospecting % (Post-Cutoff – Final)

If none of the conditions above apply, the fallback is the final fixed percentage.

---

In short

This field chooses between:

• 100 % (pre-cutoff)
• Fixed % (default or if tapering isn’t chosen)
• Tapered % (if tapering is enabled)

It outputs a single clean number that the rest of the app can use for activity calculations.
below are the 3 additional IF/ELSE columns that are referenced in the above field.

[Darren_Murphy]

I think the important question is - do any of those columns, or any that they in turn reference - make reference to non-computed columns that have Row Owners applied? If yes, this could explain the behaviour you’ve been seeing.