Designing a Flexible Folder System in Glide Without Breaking Other Users’ Data

TL;DR

While building a place discovery app with Glide, I ran into a major problem: users were accidentally overwriting each other’s saved folders because of how Glide’s Choice Components update data. To fix this, I flipped the data relationship — storing business IDs inside collection rows instead of the other way around. I ditched Choice Components in favor of a custom list view, used user-specific temporary storage for safe editing, and built a fallback system for collection cover images. The result? A smooth, scalable, user-safe folder system built entirely with Glide’s no-code tools.

The Overwrite Nightmare: How One User’s Action Erased Another’s Data

You don’t want an app to catch you at your most vulnerable moment — and for me, that moment was when I realized users were accidentally deleting each other’s carefully curated collections. I was building a place discovery app where users can save their favorite spots into personalized folders, like “Hidden Cocktail Bars” or “Summer Trip Ideas.”

The goal seemed simple:

• Let users add businesses to multiple folders.
• Make sure each user manages their own collections.
• Ensure no user accidentally messes with someone else’s data.

But Glide’s Choice Components, which rewrite entire cells on update, caused chaos: when one user saved a business to a folder, it erased the previous value — wiping out other users’ saved folders for that business.

Why Store Business IDs Inside Collections Instead of the Other Way Around?

At first, it might seem more intuitive to store collections inside each business row — after all, that’s what Choice Components in Glide expect. Since Choice Components can only display and update data based on the visible options tied to the current user, I needed a way to show users their collections when they add a business to a folder.

But here’s the catch:

• Choice Components only work well when the data they display is tied directly to the current user. So I had to make the data type user-specific to show just the user’s folders.
• However, I didn’t want to limit the app to strictly private collections. Users needed the option to share folders publicly or keep them private — allowing a mix of public and private collections.
• To support this flexible privacy model, I couldn’t store folders separately per user; I had to keep all folders together in a single table. This way, collections can be marked as public or private, and users can discover and share public folders easily.
• By storing business IDs inside the collection rows, I made it possible to:
• Show collections in a Choice Component or custom list filtered to the current user’s accessible folders.
• Keep the data user-specific at the UI level without fragmenting the underlying data.
• Support both private and public collections seamlessly.
• This data structure balances Glide’s UI limitations with the app’s social sharing goals.

Flipping the Script: The Power of Reversing Data Relationships

The original setup stored folder IDs inside each business row. But that meant everyone’s data was mashed together in one place, causing overwrite disasters.

Get Emre Davutoğlu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So I flipped the data structure:

• Each folder got its own row in a separate table.
• Each folder row holds a set of business IDs.
• This way, each user edits only their own folder row, keeping everyone else’s data safe.

Think of it like this: previously, each business had a bunch of sticky notes listing folders, but adding a new note replaced the entire set. Now, every folder is its own box holding business cards — no one else’s box gets touched.

Why the Spotify-Inspired Flow Didn’t Survive the New System

My original flow was intentionally modeled after Spotify: one-tap to save to a default “Favorites” collection, and then optionally add the item to other folders later. It felt natural and fast — users didn’t need to think about organization upfront.

I really wanted to keep that experience. But no matter how many workarounds I tried, Glide’s “add element to set” limitations just wouldn’t let it scale. You can’t easily update sets across multiple records or trigger nested logic reliably.

So while the idea worked in a limited case (one default collection), it simply broke down when I tried to extend it to a flexible, multi-folder setup. At some point, I had to let go of the smooth Spotify-style shortcut and embrace a structure that prioritized data integrity and long-term flexibility over instant gratification.

My original flow was intentionally modeled after Spotify: one-tap to save to a default “Favorites” collection, and then optionally add the item to other folders later. It felt natural and fast — users didn’t need to think about organization upfront.

I really wanted to keep that experience. But no matter how many workarounds I tried, Glide’s “add element to set” limitations just wouldn’t let it scale. You can’t easily update sets across multiple records or trigger nested logic reliably.

So while the idea worked in a limited case (one default collection), it simply broke down when I tried to extend it to a flexible, multi-folder setup. At some point, I had to let go of the smooth Spotify-style shortcut and embrace a structure that prioritized data integrity and long-term flexibility over instant gratification.

Building a New UI Without Choice Components

Since I couldn’t rely on Choice Components anymore, I created a custom list view showing the user’s collections while browsing a business. Tapping a collection toggles whether that business is inside it:

• If the business is already there, it gets removed.
• If not, it gets added.

To do this safely, I stored the currently selected business’s Row ID temporarily in the User table. This way, Glide “remembers” what the user is interacting with, even inside the folder rows.

The Cover Photo Dilemma: Keeping Collections Visually Consistent

I wanted collection cover photos to automatically update to the image of the newest added business, and revert gracefully when a business is removed.

Here’s how I managed it:

• Added an Old Image column to store the previous cover photo.
• When a business is added, its image becomes the cover; the old image moves to Old Image.
• When removed, the cover reverts to Old Image.
• Edge case: If the last business is removed, the cover resets to a default “empty collection” image to avoid blank covers.

Conclusion: The Art of Thinking in No-Code

The final product is a flexible, user-safe, scalable folder system built entirely in Glide. But the real lesson wasn’t just about data tables or UI tricks — it was learning to think with the platform, not against it.

No-code tools like Glide have their own logic, their own “physics.” Instead of forcing a component to do something it wasn’t built for, the breakthrough came by stepping back, reversing relationships, and working within Glide’s constraints creatively.

This project taught me that the most powerful no-code development happens when you embrace limitations as opportunities for innovation, not obstacles.