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

Dear AppSheet Team,   We’re excited to explore the newly released AI Task feature in AppSheet. After experimenting with it, we’d like to share the following suggestions and improvements that would significantly enhance its usability—especially for field-heavy industries like oil and gas and construction:   ✅ 1. Dynamic Instructions (User-Written Input Support) In many use cases, we want to allow end-users to write custom instructions. It would be great if we could pass a LongText field as an additional or primary instruction to guide the AI dynamically during execution. ✅ 2. Enum / EnumList Value Selection When working with Enum or EnumList fields: The AI should be able to access the list of possible values (from dropdowns) and Select the most relevant option based on the instruction and the available choices. This would help the AI provide more accurate outputs aligned with app logic. ✅ 3. Use of Formula in Instructions There should be support for using expressions or formulas inside the instruction to make them more dynamic and contextual—such as referencing dates, user roles, or other columns for intelligent behavior. ✅ 4. Output Support for HTML / Markdown It would be incredibly helpful if the AI could return output in HTML or Markdown format, especially for LongText fields. This would improve readability and allow formatting like: Bullet points Headings Bold/italic highlights Perfect for descriptions, summaries, or reports. ✅ 5. File Input Support (Video, Excel, CSV) In our industries, video analysis and structured file input are crucial: The ability to upload a video (e.g., of a safety incident or process) and have the AI generate a brief, structured description would be a game-changer. Reading Excel/CSV files would allow extracting tabular data, observations, or logs directly into the app. ✅ 6. Reading Referenced User Tables (Role-Based Assignments) Often, we need to assign tasks based on user roles. For example: “Assign this to someone with the ‘Driver’ position.” If AI could look up user tables, filter based on roles, and assign accordingly, it would allow seamless integration of decision logic into task assignment. We believe implementing these features will make AI Tasks far more flexible, powerful, and enterprise-ready. Looking forward to seeing these capabilities evolve! Best regards, Saddam Hossain AppSheet Expert Dubai, UAE @saddam24k @Jana_Mandic  @amyplin  @lizlynch  @nico  @ShirleyN  @goannsplain  @zito  @Roderick  @Lauren_vdv  @Arthur_Rallu  *I encourage everyone to upvote this and help bring these improvements to reality! ... View more

🎯 Conditional Expressions for "Finish View" Navigation Currently, the Finish View option in AppSheet only allows you to select a static view. But what if we could take this one step further? @amyplin  ✨ Imagine if we could define the "Finish View" using an expression! This would allow developers to dynamically redirect users to different views based on their role, email, or other user-specific logic. 💡 Why This Matters When a user logs into your AppSheet app, they don’t just log in with their email—they log in with their permissions and role. So why not use that to personalize their experience? With conditional navigation in Finish View, we could: ✅ Provide a more polished, role-based onboarding experience ✅ Automatically route users to the most relevant dashboard 🔧 What This Could Look Like   IF( AND( IN( USEREMAIL(), users[id] ), LOOKUP( USEREMAIL(), "users", "id", "user_role" ) = "ADMIN" ), "admin_dashboard", "user_home" ) ☝️ This would allow the form to finish and take the user to different views depending on their role. 🌟 Benefits 🔄 Dynamic navigation based on user data 🧼 Cleaner UX with fewer unnecessary steps or views ⚡ Faster app logic, as no bots or actions are needed to redirect If this idea would make your app better too, please drop a 👍 or a +1 so the AppSheet team knows it matters! Let’s build smarter, more intuitive user journeys together. 🚀 ... 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

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

Idea: Add a new data-level action (not a row-level) that triggers a bot to run now.  On the bot side, add "Triggered by Actions" as a new trigger type.  This would greatly simplify a developer's ability to build sophisticated functionality with greater ease.  The new action could include an optional pop-up message to advise the user that data updates are happening.  Perhaps the pop up could include an indication of the bot's progress.  If the bot completes while the user is still viewing the pop-up, invite the user to re-sync when closing the pop-up.   Reason: Currently, on many occasions, the way to trigger a bot involves significant, inelegant workarounds, creating a whole new tables or columns to manage bot run requests.   Example: Let's say that you want to are building a drive dispatching system.  You have a table of drivers and a table of drives.  You've created a webapp that enables a driver to claim a drive by arriving at the webapp with drive and driver parameters in the url.  Now, in appsheet, you want to let the dispatcher press a button to send drivers a list of open drives.  For each drive listed in the email, you want to include a personalized link the driver can use to claim the drive.  Currently, this is very easy in appsheet when the bot has a time-based trigger, but extremely difficult to do if you want to let your driver press a button to send the email.  The simple twist of wanting your user to activate the bot at a given time adds many layers of complexity to the process.  Why?   This is a slight variation/elaboration on this feature idea.   ... View more

Dear AppSheet Team, @amyplin  Today, I would like to request the separation of the display name of an action from the confirmation message value. There are times when it is necessary to set a display name like "Generate Nutritional Info", but for the confirmation message, a simple "Yes" would be sufficient. That’s all for today. Best regards!     ... View more

As we know in dashboard view, we can add multiple individual views. However the user can move and resize each and every individual view within a dashboard. Also on opening the dashboard , the views may not exactly render in the intended position, order and size in the dashboard view. Will request AppSheet development team to introduce grouping of the selected individual views in the editor as desired by the app creator,  so that those always render in the same relative position and size and together. This will enable more creative ways of grouping and thereby using individual views within a dashboard. The example below shows grouping option in Google slides as an example.   ... View more

It would be very useful if AppSheet implemented a feature that triggers an error when changing the name of a view referenced in a formula using CONTEXT("view") = "name1". Currently, if a view name is changed from name1 to name2, there is no warning or error, unlike what happens when renaming a field. When a field is renamed, the app fails to run until all references are updated, which helps maintain consistency. The issue with view names is that formulas using CONTEXT("view") do not break or show any errors when the referenced view name changes. This can lead to unintended behavior, especially in cases where visibility rules or security restrictions depend on the correct view context. For example, imagine I have a rule that hides the "Delete" button in a specific view using CONTEXT("view") = "name1". Over time, as the app grows, I may rename the view to name2 without remembering that this context condition exists. Since no error is displayed, the formula remains but no longer functions as expected, meaning the "Delete" button that was previously hidden might now become visible. A warning or error message—similar to what happens when renaming fields—would help developers identify and fix these issues before they cause unintended consequences. ... View more

I would like to have an option in AppSheet to color entire rows in views (such as table or detail views) based on Format Rules. This feature would enhance the visual appeal and clarity of apps, especially for status tracking, priority settings, or highlighting important information. ... View more

Dear AppSheet Team, While AppSheet was created to democratize application development, the reality is that the community is learning and striving for professionalization. Due to the editor's characteristics, we've developed our own naming conventions. I personally inquired about a "standard naming protocol" and, receiving "everyone writes as they wish" as a response (which I accepted at the time), I decided to create a naming protocol for AppSheet. Unintentionally, I've become responsible for many people, as any change to the protocol affects numerous users (developers and app users alike). Given this, I researched how systems engineers name database tables for international teams and found these basic rules: ✅ 1. Table names should be descriptive and unambiguous. ✅ 2. Use plural names consistently. ✅ 3. Avoid unnecessary prefixes. ✅ 4. Do not include relationship types in table names. ✅ 5. Use underscores (_) instead of spaces. ✅ 6. Avoid cryptic abbreviations. ✅ 7. Foreign keys should reflect relationships but avoid changing table names. This protocol change aims to improve productivity for many developers by reducing "downstream" impact. However, a native editor feature to order tables by index, rather than alphabetically, would be extremely helpful. To elaborate: Tables are currently ordered alphabetically. Adding a field for a unique natural number index would allow ordering tables based on this number. This index would visually order the editor and be flexible, changeable at any time, without affecting table naming. For consecutive elements, they could be numbered sequentially with an index, avoiding naming limitations. Consider the difficulty of adding a new table and renumbering existing ones. Therefore, I strongly request adding a numerical field to order tables by number instead of alphabetically. Thank you very much for considering this request. ... View more

As automations get more and more complex, there are more possibilities for failures along the way. As of right now, there is now way to catch an error and do something If things encounter an error where the automation chain fails, it simply fails. There is no way for us to say, if something goes wrong... do "this". But this behavior is actually critical for maintaining stable running systems.  We live in the real world where data is messy; despite our best efforts to get clean data all the time, invariably this will fail and something weird will come through. In times like this, say we have a number (ie: 116) inside the timestamp column, we need a way to catch these and do something - because the standard things we're trying to do will fail (because 116 is not a timestamp, so timestamp stuff won't work). Kinda like how we have a custom-timeout when using a "wait" task If there was an "On Failure" branch at the end of the automation chain, that would allow us to define something to do in this instance (send an email, call a process, mark the record as an error record, etc.), we could catch these instances and maintain stability. -------------------------------------------------------------------------------------------------------------------- Cheers; and as always, thanks for considering! ... View more

Dear AppSheet Team, @lizlynch and AppSheet Community! I’ve been using AppSheet for several years now for my own internal projects, but recently I’ve started offering my services to other companies. Until now, I always managed my apps just for myself, so I never really stopped to think much about user management. As many of you know, I like to share tips and suggestions whenever I find something useful or realize there’s room for improvement — and this is one of those times. I’d like to suggest that AppSheet offer a native section for managing users in a more complete and dynamic way. Something beyond just "adding emails to an allowed users list." For example: What about a dedicated space to automatically invite users after a payment? Or the ability to define the duration of a user’s access at the time of activation? Or let users choose their own plan (free, premium, etc.) and have the system handle the rest? Even better, a built-in table and automation setup to manage user access based on events or dates (like subscription expiration), similar to what we currently build manually — but more deeply integrated into the AppSheet platform. How are you all handling this right now? Do you use a custom Users table or another approach? I’d love to hear your solutions and ideas. I really believe this would benefit both creators and AppSheet itself — helping to support more scalable, sustainable business models built directly within the platform. ... View more

  Dear AppSheet Team, allow the same action names if they belong to different tables In our ongoing effort to keep the editor organized, actions are grouped by tables. Additionally, system actions are always the same (add, delete, edit, etc.) and are automatically named by the system based on their context {the table}. However, when we create an action—let's say "update" for one table, and "update" for another table—the system renames the second table's "update" as "update 2" because it assumes there are two actions with the same name. While this makes sense within the context of the same table, it would be helpful to allow identical names for actions across different tables, since actions are understood in their context (just like add, delete, edit). This current behavior forces us to rewrite the table name (even though the action is already organized by table), which seems entirely redundant. For example: For the "customers" table: our actions {customers_update}, system actions {add, delete, edit} For the "works" table: our actions {works_update}, system actions {add, delete, edit} When it could simply be: For the "customers" table: update, add, delete, edit For the "works" table: update, add, delete, edit But this doesn't happen, what happens is this if we try: For the "customers" table: update, add, delete, edit For the "works" table: update 2, add, delete, edit Don't you agree? This would allow the names to focus solely on the purpose of the action, making them shorter, and we wouldn't need to differentiate them by adding redundant information. I appreciate your attention to this matter, as it doesn't seem like a small issue. Thank you in advance! The same goes for bots and format rules Best regards! ... View more

In this case scenario, we created a leave balance app and our employees get paid bi-monthly. It would be useful if there was an additional input field “Day of the month” so the bot is scheduled to trigger twice in the month. These two bots  have the same workflow logic and this would help remove duplicate bots in the application.  ... View more

Calendars are a terrific perspective (view) to visualize data (rows in a table) when time (which is literally the only unit of measure agreed upon by every locale in the world) is involved  We can easily see overlaps or conflicts, we can visualize different tracks/types of scheduled events, etc. Being able to direct users to a focus time period is a critical need. Slices can be created to only show events meeting a day/date criteria, however, a calendar view is forcing to start with today which often has zero relevance in event planning. Please provide us more granularity in how we can configure this view, such as: Initial Value = Expression (forcing this type to Date makes sense with this specific view type) Customizable range = Expression (currently labeled as Default View where we choose Month/Week/Day) - let users define an expression to describe these subview definitions and how they are ordered (ie, 5 day weeks (weekdays only), week, months where Monday is the far left column, even says 4 days "weeks" (long weekends, etc) Confined data/time range = Toggle (directly next to View Options pulldown/selections) use the slice's data to determine what range of days/dates should be visible in the view (ie, remove the backward/forward advance buttons if data does not exist beyond the current range). if the slice literally is confined to a single day then users should not be able to advance  I have included a mock-up to help in visualizing said suggestions   ... View more

RE: the following issue: https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/Unfortunate-Side-Effect-for-Desktop-UX-Dashboard-FAB/m-p/839989#M257970 ======================================================================================== Since the addition of the new desktop UX, and having buttons in the Primary position moving themselves to the header bar of a view: it would really help us with the customization of the UX if we were to split "Primary" into two options: FAB Header Having this granular control would really be helpful.  There are plenty of times when I would want the button to be in the header, but also times when it would be helpful to have it float - so it's right in everyone's face. Having these two separate options would really allow me to have fine grain control over certain buttons. -------------------------------------------------------------------------------------------------------------------- Cheers; and as always, thanks for considering!   ... View more

It is not unusual for developers to have certain parts of an application that can be included in any of the ones we make: - Task management. - Management of acronyms used in the company. - User Setting management. - ... I don't know if it would be possible, as has been done with Location, to be able to copy and paste -between applications - all the definitions associated with a certain table. (The Data, its Views, Format rules, Actions and Bots) ... View more

Dear AppSheet Community, Often, when developing applications, we find ourselves creating modules or features that repeat across different projects. I’d like to share an idea that could optimize this process and save valuable development time: module reuse. Let’s imagine we are building apps for businesses. There’s probably a customer module, where we enter all client data—name, address, contact information, etc. This module, designed for a specific application, could easily be reused in other apps without having to build it from scratch. The same could apply to other common modules like inventory, products, or invoicing. What am I suggesting? I’m proposing the creation of reusable modules in AppSheet—small, predefined components or objects that have already been designed and tested, ready to be cloned and combined with others to create new apps. This way, instead of starting each app from scratch, we could combine existing modules and adjust them to fit the project's needs. Examples: Module 1 (Customers) + Module 3 (Inventory) + Module 7 (Sales) = App1 (Store Management). Module 1 (Customers) + Module 4 (Orders) + Module 8 (Logistics) = App2 (Supply Chain Management). Now, App1 + App2 = App3, where both apps combine and their functionalities work together in a single environment. Advantages Time-saving: We wouldn’t need to design the same components from scratch every time. We could create a library of standard modules (customers, products, invoicing, etc.) and reuse them across different apps. Standardized methodology: We’d maintain consistency in our projects by using the same structure for columns, names, and relationships. This would not only simplify development but also reduce the chances of errors. Scalability: These modular apps could grow and be combined. For example, if a business needs additional features, we could simply integrate a new module without disrupting the functionality of the existing ones. Combining apps With this idea, we could even combine entire apps. For instance, a customer and sales management app could be integrated with an inventory app to create a more robust solution. App1 + App2 = App3, where two previously developed apps work together as one. Is this possible? Thanks to advancements in artificial intelligence, this is not only imaginable—it’s entirely possible! With AI support and advanced development tools like AppSheet, we could automate the creation of these reusable modules and optimize the entire process. In summary, the idea is to be able to reuse and combine modules across apps to accelerate development and improve efficiency. I’d love to hear your thoughts and how you see the potential of implementing something like this! ... View more