🔒 Column Locking Switch in the Editor 🧠💡 Hi everyone! 👋 After working on large and complex apps (sometimes late and tired 😅), I've noticed something that could really improve the experience and safety within the editor: 🛑 We need a way to lock columns from being accidentally edited. Here's the idea: Imagine having a simple switch 🔁 next to each column in the editor that lets you lock it. Once locked: ✅ The column becomes read-only in the editor. ✅ It appears with a light gray background or subtle visual cue. ✅ You can't change its settings unless you consciously unlock it. Why this matters: 💥 Prevents accidental changes to critical columns. 🧘‍♂️ Helps you stay focused by visually highlighting only the columns you're working on. 🧠 Encourages cleaner, more intentional editing. By default, all columns stay unlocked 🔓 — no disruption to your current flow. But if you want to reduce mental load and increase safety in your app design process, this feature would be a game-changer. 🚀 What do you all think? ... View more

There is a room to make AppSheet UX better for UX for action. After the Desktop UX is released, we have "tooltips" for actions. However, for the actions which are placed in Prominent position, it is just repetition ..... No meaning to see the same action name as we see. To make this function far more useful and user friendly, we wish to have option for action to config arbitrary text which is rendered as tooltips for any actions. If this option is not used, then stay the current behavior, just show the action/display name when mouse over. Thank you.   Then we can use tooltip as Quick Guide to the app users, telling them what is going to happen when they invoke this action etc. Bunch of usages newly come up. @amyplin @Arthur_Rallu  @Adam-google   ... View more

Problem: AppSheet's "Application Access Keys" currently offer only full permissions. This lacks granular control, preventing users from defining specific CRUD operations (e.g., allowing Adds and Updates but not Deletes) for different third-party services or end-users. This forces over-privileging API keys or complex external validation. Proposed Solution: Implement granular permissions for AppSheet's Application Access Keys. Add toggle options with distinct checkboxes for each operation: Updates: (Checkbox) Allows modification of existing records. Adds: (Checkbox) Allows creation of new records. Deletes: (Checkbox) Allows deletion of existing records. Read-Only: (Toggle/Checkbox) If enabled, allows only read operations and disables other CRUD checkboxes. Benefits: Enhanced Security: Enforces the principle of least privilege, reducing attack surface. Improved Control: Finer control over external system interactions, ensuring data integrity. Wider Integration Capabilities: Enables more sophisticated integrations without custom backend logic. Simplified Development: Reduces need for external permission management. Compliance: Helps meet regulatory requirements for data access control. Use Cases: Reporting Tools: Strictly "Read-Only" API keys (e.g., for Looker Studio). Data Ingestion Service: "Adds" and "Updates" only  User Profile Management: "Read" and "Update" for external user portals. Public Forms: "Adds" only for form submissions. Granular API key permissions will significantly enhance AppSheet's integration capabilities, offering greater security, flexibility, and control.     ... View more

Feature Idea - CSV export functionality for filtered views, specifically when data slicing is involved. It can significantly improve user efficiency and data management. Here are several feature ideas, ranging from basic improvements to more advanced functionalities: Descriptions:  A prominent button within the filtered and sliced view that, when clicked, directly exports only the data currently visible on the screen (i.e., respecting all active filters, data slices, and potentially column selections/order) When initiating an export, provide a simple toggle or checkbox - "Include All Data": Exports the full dataset, ignoring current filters/slices (default for many systems)....while "Include Current View Only": Exports only the filtered and sliced data (your desired feature) Automatically generate a more descriptive CSV filename based on the active filters and data slices Implementation Notes: The CSV export should reflect the exact order of columns and visible columns as displayed in the UI "Include Current View Only" should be the default when exporting from a filtered/sliced view Truncate long filter strings for readability in filenames Benefits: Simplifies the export process, ensures users get exactly what they see, and reduces errors from exporting too much or the wrong data Gives users clear control and flexibility, catering to both needs Improves organization and makes it easier to identify exported files later without opening them   ... View more

💡 Feature Request: AppSheet Prompt Generator (AI-Friendly Context Extractor) 🔍 Description Add a feature (button or utility) that automatically generates a structured prompt summarizing an AppSheet app, with selectable scope: Tables, Views, Actions, Bots, Formats — or everything. 🎯 Goal Provide users with a clear, concise, and accurate snapshot of their app’s current structure and logic, useful for: Understanding what’s really happening inside the app (self-diagnosis). Generating optimized prompts for AI assistants like Gemini, GPT, etc. Asking better and more focused questions in the AppSheet Community. Quickly documenting the app for personal or team use. 🧠 Why is this useful? Many issues with AI support come not from bad answers, but from poor context provided by the user. This tool would prevent that by auto-generating an accurate and readable technical summary of the app. The user could simply add their question to the end of that prompt. Example: "I have an AppSheet app with the following structure: [Generated summary]... Based on this, how can I improve my notification system?" 🛠️ Suggested Implementation A button in the App Editor with the following options: Scope selector: Tables / Views / Actions / Bots / Formats / Everything Output: pre-formatted text intended to be used as an AI prompt ... View more

When you have a dashboard, each view inside it will have it's own filter setting. It would be great if there was a way where I could designate, at the Dashboard level, that all the views inside should share the same filter.  This would require that all the tables be the same, which is fine in plenty of dashboard scenarios where we've got buckets for the same table's records. This way if we applied a filter to one, it applies to all - smoothing out certain UX issues where we want to filter all at once. -------------------------------------------------------------------------------------------------------------------- Cheers; and as always, thanks for considering! ... View more

People have been asking for event actions inside a calendar view since the calendar view first came onto the scene, yet it's never happened.   Perhaps the reason why is because it's not as straight forward as, say, a table view. With a table view, there's one event: clicking on the row However in the calendar view, there is actually two events: If you're not looking at a day view (so you're looking at an aggregate version (week or month) of the calendar view), when you click on the entry... you're taken to the day version of the calendar view. Then when you're on the day version of the view, when you click the event it takes you to the detail view. So it's not as straight forward as the rest, and perhaps this has been the reason why we've never gotten event actions for the calendar view.  ¯\_(ツ)_/¯  Just guessing. --------------------------------------------------------------------------------------------------------------------- If that's the reason, can't we get an option for each version of the view? Day Week Month Simple, clean, one-for-one... allows for granular control for those who want it - just like how we have 3 options for a deck view (tap, swipe right/left). This sort of feature would really help enhance the usability of the calendar view.  There are plenty of times when we want to display events, but they DON"T have a time aspect... which means going to the individual day view creates a weird situation where the user has to select the event at the top of the view. It would be more professional looking if we could bypass the day view, and just go directly to the detail view.  If I could take control of the view event for the month version, adding a LinkToRow() function to take me to the detail view, problem solved. Could even sneak in additional actions in a stack (like claiming the entry you're clicking on)... I'm just saying, there's so much we WANT to do with this view, but can't because we've never gotten event actions for it. =================================================================================== Maybe it's worth taking some precious time away from the Ai stuff, to round out the core features of the platform. 😉  Cheers; and as always, thanks for considering! ... View more

As a consulting company developing AppSheet applications, we consistently encounter challenges with user onboarding and adoption. Currently, our primary method for guiding users is through the creation of comprehensive documentation detailing app functionality and usage. However, we've observed that users often don't fully engage with these documents due to time constraints or a preference for more immediate, in-app guidance. This can lead to frustration, underutilization of app features, and increased support requests, ultimately impacting project success and client satisfaction.   Solution: Add a tooltip feature to AppSheet. Allow creators to easily add interactive tooltips to buttons, columns, etc., for in-app guidance.The user should have this tooltips displayed when is use the app for the first time Benefits: Faster user onboarding Reduced support Improved user experience Requirements: Easy tooltip creation in the AppSheet editor Options to trigger tooltips on: First app launch First visit to a specific view Tutorial sequencing ... View more

Dear AppSheet Team @lizlynch , I would love to propose an enhancement to the Action system in AppSheet that I believe could elevate user experience and reduce confusion during app interaction. 🔔 Idea: Add a property to Actions that allows displaying a custom warning or informational popup message when a condition is not met—before or instead of executing the action. 💡 Use Case Example: Imagine a scenario where a user tries to navigate to a form, but required reference fields are still empty. Instead of silently blocking the action (or allowing them to land in an incomplete form), the system could automatically pop up a message like: "⚠ You cannot proceed because related records have not been added yet." This would make it much clearer why the action cannot proceed and what the user needs to do next, greatly improving app guidance and reducing support overhead. 🚀 Why this matters: Provides immediate feedback to users Avoids silent failures or user confusion Reduces the need for workarounds like overlay messages or dummy actions Would make app interactions more polished and professional 🤓 Possible Implementation: Add an optional 'Condition Failed Message' property to actions. If the condition in the 'Only if this condition is true' is not met, display the configured message in a standard AppSheet popup. ✨ I believe this would be a small but impactful addition to the Actions system, making our apps feel more interactive and user-friendly. Would love to hear what the community and AppSheet team think about this idea! If you also see the value, let’s make some noise and show our support! 💥 ... View more

  Treat UserSettings as a First-Class Table Summary: Allow UserSettings to behave like any other table in AppSheet: usable as a data source for views, actions, bots, format rules, and more—not just in expressions. Current Limitations: UserSettings can only be referenced in certain expressions (e.g., Show_If , Filter , Initial value , etc.). Cannot be selected as a data source when configuring: Views Bots (as triggers or conditions) Actions (as targets or inputs) Format rules The current edit view for UserSettings is fixed to the hamburger menu and cannot be repositioned or redesigned. Feature Proposal: Treat UserSettings as a real, developer-defined table, with a single row per user, but full integration with the AppSheet editor: 📄 Let developers use it as the data source for views (table, form, detail, dashboard). 🧠 Enable its use in actions (navigate to form, update values, etc). 🤖 Allow bots to be triggered based on changes to UserSettings . 🎨 Enable format rules based on values in UserSettings . 💡 Optional: Let devs rename the section and reposition its view anywhere in the app UX. Why This Matters: Right now, UserSettings is a half-implemented feature. It holds great potential for personalizing the app experience, but it's stuck in a limited role, only usable in specific expressions. If treated like a proper table, UserSettings could enable: Seamless preference management without workarounds. Conditional UI behavior across the entire app. Bots that respond to user-specific configuration changes. Cleaner design patterns, removing the need for custom “User Profile” tables just to mimic this behavior. Conclusion: AppSheet is powerful because of its flexibility—but this part feels artificially restricted. Let us use UserSettings like a real table and we’ll build more dynamic, user-centered apps with less friction. +1 if you're tired of hacking around the limitations. Let's make this official.   ... View more

Context: When a view is auto-generated in AppSheet (e.g., upon adding a new table to the data model), the system assigns the root view name based on the original table name. Problem: If the table name is changed later, the root name of the auto-generated view does not update accordingly. This creates inconsistencies, confusion, and can lead to navigation errors—especially in apps with many tables. Proposal: Introduce an option that allows auto-generated views (those created automatically by the system when a table is added) to dynamically sync their names with the name of the underlying table—as long as no custom view name has been assigned. Reduces human error and maintenance friction. Makes app development more intuitive, especially in complex builds. ... View more

The two ideas I have are both related to improving UI for quickly selecting records on a map, so that the user can execute an action on selected records; similar to other multi-record view in AppSheet(Select a list of records > execute action: 'add to route') :  - Long press on a map pin to enter multi-select mode - Lasso tool: create a hand/mouse drawn shape to select a group/region of pins  I'm close with a Sales person for a Steel Manufacturing/Distributer and they pay for an (expensive) third-party SaaS to connect to Hubspot, Visualize customers in a map, build/optimize routes. All of which would be incredible achievable within AppSheet, it's just the multi-select on a map is lacking and would require a tedious 'Click Pin > Run Action' for each waypoint. Out side of this one business/use case. I can immediately think of plenty of new feature this could enable for past/present clients. - Thanks AppSheet team for all the new stuff you have announced in @zito 's AppSheet Roadmap Sneak Peek - Q1 ... View more

Description of the Problem/Current Behavior: Currently, the default display order of items in a dropdown list for a Ref type column can be inconsistent between the desktop preview and the mobile preview/mobile app. In the desktop preview, the dropdown items often (but not always) appear to follow the order of the data in the source table (e.g., the row order in a Google Sheet) or the key column order. In the mobile preview (and often in the deployed mobile app), the default order of these same dropdown items can appear arbitrary or "mixed up." This order is not consistently the source data order nor the key column order, but it is typically reproducible, suggesting an internal AppSheet sorting mechanism that differs from the desktop preview's default. This discrepancy requires app developers to explicitly implement sorting logic (e.g., using ORDERBY()) even for basic, predictable ordering, simply to achieve consistency between preview environments and the actual mobile app. Desired Behavior/Proposed Feature: I request that AppSheet provide a consistent default sort order for items in Ref column dropdowns across all client environments (desktop browser preview, mobile preview, and deployed mobile apps) without requiring an explicit ORDERBY() expression in Valid If or Suggested Values. Ideally, this default order should be predictable and align with one of the following, applied uniformly: The order of records in the referenced data source. The order of the key column of the referenced table. The key is consistency by default, so developers only need to use ORDERBY() for specific, non-default sorting requirements, not for achieving basic platform consistency. Why this is important/Benefits: Improved Developer Efficiency: Reduces the need for developers to manually add ORDERBY() expressions to every Ref column simply to ensure a standard, predictable order that is consistent between development/preview and deployment. Enhanced User Experience (UX) Consistency: Provides a more predictable and reliable user experience, as dropdowns will behave the same way regardless of whether the user is interacting with a desktop view or a mobile view. Reduced Confusion: Eliminates confusion for both developers (during testing) and end-users when seeing different orderings on different platforms for the same data. Better "Out-of-the-Box" Experience: A consistent default behavior would make AppSheet apps feel more polished and reliable from the outset without extra configuration. Current Workaround (and its limitations): The current workaround, as recommended by support, is to use the ORDERBY() expression within the Valid If or Suggested Values property of the Ref column. While this provides control, it feels like a patch for what should be consistent default behavior. Forcing developers to implement this for every Ref column to achieve basic consistency adds unnecessary development overhead. In summary: While ORDERBY() is a powerful tool for custom sorting, the default behavior for Ref dropdowns should be consistent across platforms. This change would streamline development and improve the overall consistency and predictability of AppSheet applications. ... View more

👋 Hey AppSheet Team! I’m bringing a simple yet powerful idea to the table: take visual customization to the next level. 🚀 Why settle for one global look? Right now, everything under Customize the look and feel applies globally across the entire app. But... 🔍 What if we want specific views to look different? 🌘 What if we want dark mode only in certain sections, based on USERSETTINGS ? 📱 What if we want to show or hide the header/footer depending on the context? 💡 The Proposal Enable per-view Look & Feel settings, with the following enhancements: 🌓 Dark/Light Mode per View Should be formula-driven (e.g., IF(USERSETTINGS("Theme") = "Dark", "Dark", "Light") ) Perfect for mixed-mode apps or advanced UX cases 🧩 Header & Footer by Table or View Toggle visibility at the view or table level Control header and footer independently ( Header ON + Footer OFF , for example) Conditional visibility based on role, UX flow, etc. 🎛️ Separate Menu and Search Button Toggles Currently linked: disabling search also removes the menu Let’s decouple these controls for true flexibility ⚙️ Benefits Dynamic, context-aware UX Cleaner customization without hacks Visually coherent per workflow or role 📣 If you’d love to see this implemented, give it a LIKE and leave a comment! The more support it gets, the more likely the AppSheet team will notice 🙌 ... View more

Currently, it appears that the "Highlight color" field only accepts static color values (either from the palette or as hexadecimal codes). This limitation prevents users from dynamically setting highlight colors based on data values stored in columns. Problem: This restriction necessitates the creation of multiple Format Rules to achieve dynamic color changes, which can become cumbersome and difficult to manage, especially when dealing with a large number of conditions. Requested Feature: We would greatly benefit from the ability to set the "Highlight color" dynamically using column values. Specifically, we request that the "Highlight color" field be enhanced to: Accept Column References: Allow us to enter a column name (e.g., [ColorColumn]) that contains valid hexadecimal color codes. Evaluate Expressions: Allow us to use expressions (e.g., IFS() or SWITCH()) that return hexadecimal color codes. Example Use Case: As an example, we would like to be able to set the highlight color of map pins based on the value of a "ProgramDay" column, using a virtual column to determine the color. Currently we have to create a format rule for every program day, and set the color statically. this is very hard to maintain. Benefits: Increased Flexibility: This enhancement would significantly increase the flexibility of Format Rules, allowing for more dynamic and data-driven styling. Simplified Management: It would reduce the number of Format Rules required for dynamic color changes, simplifying app maintenance. Improved User Experience: It would create a more intuitive and efficient experience for developers. We believe that this feature would be a valuable addition to AppSheet and would greatly improve the app development process. Thank you for your consideration. ... View more

Issue: When using the REST API (Add/Edit actions) to push data to AppSheet DB tables, values sent to columns explicitly defined as Text are being automatically coerced if they resemble numbers or datetimes. Example 1: Sending "0.0" results in 0 being stored. Example 2: Sending "04/30/2025 19:35:56" results in 2025-04-30T19:35:56 being stored. This happens even when the values are correctly formatted as strings (double-quoted) in the JSON request body. Impact: The original string format sent via the API is lost, leading to data integrity issues (e.g., loss of precision like .0, unwanted date/time format changes). Expected behavior for a Text field is to store the value exactly as sent. Request: Provide a mechanism to disable automatic type coercion/reformatting for specific Text fields when data is sent via the REST API to AppSheet DB tables. Possible Solutions (as discussed in thread): An API-level flag or directive sent with the request (for example in the properties object sent in the request) A schema-level property for Text columns (e.g., a toggle in column settings). Need: Essential for maintaining precise data fidelity when using the API with AppSheet DB, especially since AppSheet DB should allow for stricter type control than spreadsheet backends. This avoids the need for complex or potentially error-prone workarounds (like appending/removing characters). ... View more

AppSheet does not support group view in Menu, so if you have many views that need to be shown in Menu view, it isn't very clear for the user. I suggest that the team dev should consider this feature asap for user to be able to customize their menu flexibly as in the picture below: Grouping views on the menu ... View more

    📌 Group Ref Views by Table for Better Organization   Currently, in AppSheet, Ref views (those not directly displayed in navigation) are all listed under Ref Views without a clear structure. This creates clutter and makes managing views in large apps tedious.   To keep things organized, many developers resort to naming Ref views by prefixing them with the table name (e.g., Orders_Detail, Orders_Edit, Orders_Summary). However, this is a manual, redundant, and difficult-to-maintain workaround.   💡 Proposed Solution   AppSheet should automatically group Ref views under their respective tables, just like it does for primary views. This would:   ✅ Make it easier to identify which views belong to each table. ✅ Reduce the need for long, repetitive view names. ✅ Improve app maintenance and navigation within the AppSheet Editor.   🎯 Why This Matters   ✔️ More clarity in view structure. ✔️ Less manual effort in naming and organizing views. ✔️ Better user experience for developers managing apps.   If you agree that this would enhance AppSheet’s usability, vote for this idea! 🚀   ... View more

Is it pssible to place a Check button at Top of app Editor. So that user can select and disselect the table features with single click which will effect for every column. better to see the above image to understand what i talking for.  ... View more