Surface the "last login" data Glide already collects for the Dashboard as a native column on the default Users table, so builders can filter, segment, and act on it directly.
Summary
Glide's Dashboard already displays "most recent logins" at a per-user level, which means this data is being collected and stored somewhere in the platform. However, that same data is not exposed inside the default Users table, so builders and Experts have no native way to reference it in filters, workflows, or visibility conditions. Today, replicating this requires manual workarounds (e.g., writing a timestamp to a column via an action every time a user opens the app), which is fragile and easy to miss.
Current Problem
- Last-login data exists at the Dashboard/analytics level but is not surfaced as a column on the Users table.
- Builders who want to use "last active" data for in-app logic (targeting, segmentation, deactivation flows, etc.) must build their own tracking system from scratch, typically via an action tied to app-open events writing a timestamp to a column.
- This DIY approach is inconsistent across apps, adds unnecessary workflow overhead, and can silently fail to fire (e.g., if the triggering action isn't wired into every entry point).
- Net result: data Glide already has is invisible to the builder at the row level, where it would actually be usable.
Examples/Scenarios
- An Expert managing a client's employee directory app wants to build a "Users inactive 30+ days" view to prompt re-engagement or flag stale accounts — this requires a native, reliable "Last Login" column rather than a hand-rolled action.
- A partner wants to show an "Active" vs. "Inactive" tag on a user's profile based on recent login recency, without instrumenting every screen with a logging action.
- An agency running apps for multiple clients wants a consistent, guaranteed-accurate way to report on user engagement across apps, rather than trusting each app's custom (and potentially incomplete) tracking setup.
Why This Matters
- Removes a workaround for data Glide already owns: This isn't new data collection — it's exposing data the Dashboard already has access to.
- Improves reliability over DIY tracking: A native column is guaranteed to be accurate and consistently captured, unlike action-based tracking that depends on builders wiring it into every relevant trigger.
- Enables real segmentation and lifecycle use cases: Re-engagement prompts, inactive-user cleanup, engagement-based row visibility, and reporting all become straightforward once "last login" is a queryable field.
- Underserved Expert/agency need: Experts managing user bases for clients need dependable engagement data without building custom instrumentation per app.
Suggested UX
- Native "Last Login" column on the default Users table (system-managed, read-only by default), automatically populated whenever a user authenticates into the app.
- Optional companion column: "Login Count" for basic engagement/frequency tracking, mirroring what's likely already tracked for the Dashboard.
- Make both columns usable like any other Users table column: filterable, sortable, and referenceable in Row Owner logic, visibility conditions, and workflow triggers.
- Consider a toggle to enable/disable this tracking per app, in case builders have privacy or compliance concerns about storing login timestamps.
Surface the "last login" data Glide already collects for the Dashboard as a native column on the default Users table, so builders can filter, segment, and act on it directly.
Summary
Glide's Dashboard already displays "most recent logins" at a per-user level, which means this data is being collected and stored somewhere in the platform. However, that same data is not exposed inside the default Users table, so builders and Experts have no native way to reference it in filters, workflows, or visibility conditions. Today, replicating this requires manual workarounds (e.g., writing a timestamp to a column via an action every time a user opens the app), which is fragile and easy to miss.
Current Problem
Examples/Scenarios
Why This Matters
Suggested UX