(En) AppSheet Naming Standard Protocol

Gustavo_Eduardo · 07-09-2024 06:43 AM

(En) AppSheet Naming Standard Protocol

Click "Show more" to expand the protocol:

INTRO

Dear community, today I bring you a new compendium (shorter but concise). This isn't an update of the old version; it's a rework of what was the AppSheet Standard Protocol. These are firm foundations for robust and consistent work (whether you have previous experience or not).

This guide arises from the need to avoid chaos in AppSheet app development by establishing clear rules for organizing and naming elements. It's not a tutorial, but a standard to improve performance and efficiency in individual or team work.

This work has been cleaned up to offer you a simple experience. Without further ado, let's begin.

WHAT IS A STANDARD PROTOCOL?

A standard protocol is a set of rules that eliminates mental noise for developers, allowing them to focus on building instead of wasting time deciding on names. It's like a "language" chosen to proceed, based on experience. Without a standard, chaos reigns in teamwork and personal organization. Adopting it improves clarity, efficiency, and professionalism, boosting creativity by eliminating unnecessary distractions.

1. DATA

1.1. GOOGLE SHEETS AS DATABASES

When using Google Sheets as our database in AppSheet, folders are automatically generated in our Google Drive directory, specifically within the appsheet/data folder. These folders have a default name that matches the app’s name, followed by a hyphen and a number that acts as the app’s unique identifier. This is the name we recommend keeping for the folder, because:

The App ID is unique, trackable, and permanent — CONTEXT("AppName") returns this exact name.
It prevents confusion between the visible app name and the technical identifier.
If you're working as a team, it's clear that the true identity of the app is its App ID, not the “marketing” name.
It allows for unambiguous connections between app ↔ folder ↔ database ↔ logs.
It might look a bit “ugly” at first, but it’s the cleanest and most standardized approach.
This setup can be complemented with a sheet or database listing app names, including extra details and metadata.
Most importantly, it’s sustainable and scalable over time.

If you choose to use Google Sheets, it's recommended that the worksheets have no blank columns or empty rows, and that continuous maintenance is performed by deleting any empty rows during the application's use. This is because deleting a record from AppSheet will leave entire empty rows in the tables of the worksheet used as the database. You can visit this post explaining how to create a script in Google Apps Script to automatically delete blank rows from your Google Sheets databases.

I personally created this one that I'm currently using. You can use mine or create your own, but in any case, be careful adding scripts you don't know to your databases:

function eliminarFilasVacias() {
  // Obtén la hoja activa
  var hoja = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  
  // Obtén el rango de la columna A
  var rango = hoja.getRange("A:A");
  var valores = rango.getValues();
  
  // Variable para contar las filas vacías
  var filasVacias = 0;
  
  // Recorre las filas de abajo hacia arriba (para evitar problemas al eliminar filas)
  for (var i = valores.length - 1; i >= 0; i--) {
    if (valores[i][0] === "" && filasVacias < 1) {
      // Si hay una fila vacía, deja esta fila
      filasVacias++;
    } else if (valores[i][0] === "") {
      // Si la fila está vacía y ya hay una fila vacía, elimina la fila
      hoja.deleteRow(i + 1); // +1 porque las filas en Apps Script son 1-indexed
    }
  }
}

1.2. FILES FOR DATABASES

Google Sheets currently has a limit of 10 million cells per spreadsheet file. See the following link: Google Sheets Best Practices.

If we try to create all tables as sheets within a single spreadsheet file, we can affect performance and information organization.

In this protocol, it is recommended to use a separate spreadsheet file for each table. This way, each spreadsheet file will have its own 10 million cell limit, and each spreadsheet effectively becomes an independent database table with high capacity. This provides greater flexibility, improves performance, and facilitates data organization.

1.3. NAMING AND ORGANIZATION

All spreadsheet files for each application or section should be placed inside a container folder with the same name as the application or section (as created).

The Google Sheets file name, the worksheet name (inside the file), and the table name within AppSheet must match (all three must be the same).

This name must follow these rules:

Written in lowercase, snake_case format.
Plural and in English, regardless of the developer's language.
No special characters. May contain numbers, but must not start with them.
Must clearly express the table's purpose without ambiguity.

Example, if we create a table named categories, this doesn't tell us much, as they could be tax categories, item categories, etc. The name needs to be specific:items_categories
items_families
items_types
items_instances


 

nutrients_categories 
 
nutrients_families 
 
nutrients_types

1.4 DATABASES (Structure/Naming Summary)

📌 Reglas:

snake_case, lowercase, singular (except for special cases detailed later) and in English, regardless of the developer's language.
Clear and descriptive purpose.
Preferably, a maximum of 27 characters to avoid long and unwieldy names.

Container folder name in Google Drive:

<app_name>_<app_section> (the section is optional).

Google Sheets file name:

<table_name>
Worksheet name (inside the Google Sheet file):

<table_name>

Table name (in AppSheet, matching the file/worksheet):
<table_name>Slice names:
<table_name>_<descriptor>
I've requested a new feature for the editor: a checkbox that allows you to add a number so we can organize our tables in the editor (by index, not alphabetically) to separate the table names from their organization in the editor. You can vote for this request here.

1.5 ADDITIONAL RECOMMENDATIONS

Format as Table: It is recommended to use the "Format as table" option in Google Sheets to be able to apply filters within the database view in Sheets.
Protect Headers: It is recommended to use the "Protect range" function in Google Sheets to prevent accidental deletion or modification of table headers.
Freeze the header row: This helps improve the visual organization of data in Sheets.
Name Length: Although not mandatory, it's recommended that names have fewer than 27 characters to avoid complications when writing expressions and ensure names display correctly in the editor without wrapping onto multiple lines.

This will allow the data structure in Google Sheets to function with many features of a traditional database.

1.6 GENERAL FIELD NAMING

📌Rules:

snake_case, lowercase, singular (except for special cases detailed later) and in English, regardless of the developer's language.
Clear and descriptive purpose.
Preferably, a maximum of 20 characters to avoid long and unwieldy names.

Image of Example Table:

1.6.1. COMMON FIELDS

These are fields commonly repeated in many tables:

Field Name	Purpose
Row ID	If using AppSheet DataBase, this field is automatic and doesn't need to be created. It's the row id. Not visible by default in the database. Note that when migrating the application to another database, you must be very careful when using another field as the id. Although it copies without issues when migrating to Google Sheets, returning to the AppSheet database can generate conflicts with duplicate keys. Editable If' unchecked by default
id	If using Google Sheets, mandatory field, primary key of the table, always named "id" in lowercase. You can use: UNIQUEID("UUID"), UNIQUEID("packedUUID"), UNIQUEID(). In specific cases, like tables with constant, read-only content, other values can be used in the id field, such as manually chosen values, as long as they are unique. Editable If' unchecked
_rowNumber	Automatic: This field is automatically created in all tables, numbering the rows.
ia_<purpose>	Optional: it's a virtual text-type field, empty (with a formula like: ""), used to anchor 'actions, usually inline'. There will be as many such fields as actions needed.
created_at	Optional: This field stores the date and time in the database. Configure a YYYY-MM-DD hh:mm:ss format in Google Sheets. DateTime, initial value UTCNOW(), reset on edit off.
edited_at	Optional: This field stores the date and time in the database. Configure a YYYY-MM-DD hh:mm:ss format in Google Sheets. ChangeTimeStamp, initial value UTCNOW().
created_by	Optional: It's typically the email of the user logged into the application, so USEREMAIL() is used in the initial value space, reset on edit off, non editable.
edited_by	Optional: It's typically the email of the user logged into the application, so USEREMAIL() is used in the initial value space, reset on edit on.

1.6.2. FOREIGN KEY FIELDS

Ref:
<singular_table/slice_name>_id
Enum base Ref:
<singular_table/slice_name>_id
Enumlist base Ref:
<singular_table/slice_name>_ids

Assuming special cases where we have two ref, enum base ref, or enumlist base ref fields coming from the same source table within the current table, we cannot name them the same as it would cause an error. We can solve this generically as follows:

The first ref field from a table can be named:

<singular_table/slice_name>_id

The second ref field from the same table can be named:

<singular_table/slice_name>_<aditional_descriptor>_id/s

1.6.3. INHERITED FIELDS

The most common case of an inherited field is a foreign key. As seen previously, they are named <singular_table/slice_name>_id

These fields inherited into other tables have a name in their source table; for inherited fields other than the 'id', the following convention will be used:

<singular_table/slice_name>_<field_name>, Thus, if a field is named “nature” in the “categories” table, in the “types” table it will be named “category_nature”, making it clear it's an inherited field from the “categories” table.

2. VIEWS

2.1. VIEWS - EDITOR'S RESULT

Here's the result, I'll explain it below:

2.2. VIEW TYPES IN APPSHEET (CODE)

In AppSheet, views function as the user interface. Currently, there are 11 view types (as of 2025), but it's anticipated that more will likely be added in the future. A highly requested example is the Gantt Chart view, which is apparently under study and development.

Below, I will detail the view type along with its naming code (in red) and the icon we will use for each ref view. (The views that are displayed directly to the user in the editor will have icons chosen by the developer; we are only referring to ref views.)

Table-Dependent

Calendar (cl): "calendar-alt" regular icon
Deck (dk): "list-alt" regular icon
Table (tb): "table" regular icon
Gallery (gl): "th-large" regular icon
Detail (dt): "indent" regular icon
Map (mp): "map-marker-alt" regular icon
Chart (ch): "chart-pie" regular icon
Form (fr): "edit" regular icon
Onboard (ob): "window-restore" regular icon
Card (cd): "portrait" icon

Table-Independent

Dashboard (db): "layer-group" icon

2.3. VIEW EDITOR STRUCTURE

The AppSheet editor organizes views into four sections:

Primary Navigation
- Contains the views for the app's main panel (not much to say here).
Menu Navigation
- Shows views accessible from the menu (not much to say here).
System Generated
- Views automatically created by AppSheet for each table. Using them directly is not recommended.
Referenced Views
- A disorganized area where all referenced views are stored (Reason for the view naming convention); see below.

2.4. REFERENCED VIEWS

Similar to a bag of trash (because that's what I perceive), they have no organization whatsoever; everything is "thrown in the same bag". It's incredibly tedious to see the views there without even having sorting by table or view type. Anyway, because of this, I have modified the convention that will allow us to have a clean, organized, intuitive editor, and although a bit cryptic, the "app editor" is accessible to the work team who will know the convention, making it less "cryptic". Truthfully, the convention only serves to provide order until AppSheet implements native sorting for this section. By the way, you can vote for this idea by clicking the link to give it relevance. Once AppSheet organizes this section, this naming convention will automatically lose its effect, and we can enjoy native sorting without having to return to the legacy editor.

To solve this, I propose a naming convention that will allow for a clean, organized, and intuitive editor, at least until AppSheet implements a native organization system.

2.5. ORGANIZATION METHOD

Using the “source_prefix_generator” file

Our colleague @yasarcan proposed creating a file to document table names in the old protocol. I have taken his idea as inspiration and created a Google Sheets file called "source_prefix_generator".

This file will serve to:
✔ Generate standardized prefixes for naming views, actions, bots, and format rules.
✔ Keep a record of changes in the app's structures.
✔ Facilitate navigation within the editor.

This file contains the following fields:

table_sufix	slice_sufix	table/slice_name	action_bots_format_prefix	view_prefix
001	-	table_one	001	001_00
002	-	table_two	002	002_00
002	01	slice_of_table_two	-	002_01

The table_sufix field contains a number from 001 to 999 (three digits) and is the identifier for your tables. Each time a table is added to our database structure, we must register that table in the source_prefix_generator with its ID.
The slice_sufix field is a number from 01_99 and represents the slice identifier number. Each time we create a slice, we add it to the source_prefix_generator with its identifier.
table/slice_name is a field that stores the table/slice name exactly as it is in our application. The table/slice name can change, but the table_sufix and slice_sufix should never change.
action_bots_format_prefix is a field with an expression that takes only the table ID (it does not consider slices) since actions, bots, and format rules apply only to tables.
view_prefix is a field that generates a usable prefix for views, since these can be based on slices. Fields with an empty slice_sufix cell are tables, and their view_prefix will always have the table suffix and 00 as the slice suffix.

See the cases in the following example:

2.6. VIEW NAMING

Our colleague @Yahia_DAK suggested table sorting based on prefixes and view types; it was really interesting, so I decided to take his idea as inspiration for this new naming convention (though slightly modified). He starts with numbers, but I realized that starting view names with numbers in the editor while adding expressions doesn't automatically trigger the suggestion popup dialog. Whereas, if we start with letters, filtered suggestions automatically start appearing, which is more intuitive during development and increases typing speed. See it right here:

The first part of the name structure always has the same length and is displayed very orderly, to the point where it eventually goes unnoticed, while the purpose becomes more recognizable.

<view_type_code>_<view_prefix>_<view_purpose>

What is the advantage of using prefixes (even numeric ones within the view_prefix) instead of full names?

If the table name changes, the view name doesn't have to because the prefix is an ID, while the name can change.
Everything becomes much simpler to visualize.
Names are drastically shortened, which is more comfortable in the editor.
Allows quick detection of unused or duplicate views.

2.7. SPECIAL CASES: DASHBOARD

The only view type that doesn't follow the table-based naming format is the Dashboard view, as it can be composed of two or more tables.

For these cases, we use a representative name in lowercase, following this format:

db_<purpose>

📌 Rules:

snake_case, lowercase.
The purpose should be a clear and descriptive noun.
Preferably, a maximum of 30 characters to avoid long and unwieldy names.

2.9. DISPLAY NAMES

The name the user will see in the interface must be inserted within quotes in the Display Name field, as an expression, whether in views, actions, fields, etc.

3. FORMAT RULES

3.1. FORMAT RULE NAMING

f_<table_prefix>_<purpose>

Example: f_008_blank_children

Indicates a format rule applied to the table with prefix 008, to handle rows without children.

📌Rules:

snake_case, lowercase.
Maximum 23 characters.
The purpose should be clear and descriptive.

4. BEHAVIOR ACTIONS

4.1 SYSTEM-GENERATED ACTIONS

System-generated actions receive a default name. Some examples are:

Add
Delete
Edit
Compose Email (User ID)
View Ref (TABLE)

These names are consistent across all tables and should not be modified.

4.2. CUSTOM ACTIONS

For actions we create manually, we will use the "source_prefix_generator" file..

First, I'll show the result, then I'll explain:

As you can see, the actions are already organized by table in the editor UI (in the case of the image above, organized under the “items_types” table), but the naming convention ensures the first part of the name always has the same length and provides a better visualization of the action's purpose.

Now, why is this convention necessary when they are already natively organized by table in the editor?

Because AppSheet doesn't allow us to use the same name for actions in different tables. If we created an action named “update” in one table and then another with the same name in another table, AppSheet would automatically rename it to “update 2”, which creates naming inconsistencies. Note that this problem doesn't occur with system-generated actions, since AppSheet gives them the same name in all tables (i.e., there's no Add 1, Add 2, Add n).

Therefore, until AppSheet allows manually created actions to share the same name if they are in different tables, this convention helps us maintain order and avoid inconsistencies in our apps.

I have created a topic for AppSheet to implement this improvement; you can vote here so this limitation disappears in the future. When this happens, our convention will no longer be necessary, and development will be simpler.

4.3. ACTION CODE(`action_code`)

There are four main sets of behavior actions in AppSheet:

ACTION	CODE
Application	a
Data	d
External	e
Grouped	g

This code convention (action_code) facilitates the organization and quick reference of actions in AppSheet, improving clarity and efficiency in application development.

Each set contains specific actions:

7 Application Actions
4 Data Actions
5 External Actions
1 Grouped Action

4.3.1. Application Actions (`a`)

Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition.

Copy this row and edit the copy → (a1): "clone" icon
Edit this row → (a2):"edit" regular icon
Export this view to a CSV file (not a row-level action)→ (a3): "fiie-csv" regular icon
Go to another AppSheet app → (a4): "rocket"-regular icon
IGo to another view within this app → (a5): "chevron-circle-right" black icon
Import a CSV file for this view (not a row-level action) → (a6): "fiie-csv" black icon
Open a form to add a new row to this table (not a row-level action) → (a7): "plus" regular icon

4.3.2. Data Actions (`d`)

Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition.

Add a new row to another table using values from this row → (d1): "layer-plus" light icon
Delete this row → (d2): "trash-alt" solid icon
Execute an action on a set of rows → (d3): "table" light icon
Set the values of some columns in this row → (d4): "slider-h" regular icon

4.3.3. External Actions (`e`)

Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition.

Go to a website → (e1): "browser" regular icon
Open a file → (e2): "folder-open" regular icon
Start a phone call → (e3): "phone" regular icon
Start an SMS message → (e4): "envelope" regular icon
Start an email → (e5):"comment-alt-lines" regular icon

4.3.4. Grouped Action (`g`)

Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition.

Execute a sequence of actions → (g1): "list-ol" regular icon

4.4. NAMING FOR ACTIONS

<action_code>_<source_table_prefix>_<destination_table_prefix>_<action_purpose>

If the action is applied to a single table, both the source and target tables will use the same prefix.

📌 Rules:

snake_case, lowercase.
The purpose should be a clear and descriptive noun.
Preferably, maximum 30 characters to avoid long and unwieldy names.

5. BOTS

5.1. NAMING CONVENTION FOR BOTS

bot_<table_prefix>_<purpose>

Example:bot_018_adder

Este bot pertenece a la tabla con prefijo 018 y su propósito es agregar filas.

📌Rules:

snake_case, lowercase.
The purpose should be a clear and descriptive noun.
Preferably, maximum 27 characters to avoid long and unwieldy names.

5.2. NAMING CONVENTION FOR EVENTS

Events in AppSheet are triggered when one of these situations occurs:

Event Type	Code
App Event	`app`
AppSheet database	`adb`
Scheduled Change (Time)	`sch`
Chat Application	`cha`
Google Forms	`gfr`
Gmail	`gml`

📌 Event name format:

event_<table_prefix>_<event_type_code>_<n_order_number>

Example: event_008_app_1

Indicates it's an event on table 008, of type app (application event), with order index 1.
If multiple similar events are created, the number is incremented (_2, _3, etc.) to avoid conflicts.

5.3. NAMING CONVENTION FOR STEPS

In the rest of the editor, we use a coded nomenclature, but in this case, we'll use an intuitive one. Processes are organized as a sequence of logical steps whose purpose is to solve a problem (i.e., an algorithm).
It's very interesting to see how steps look in a process when their nomenclature is clear and understandable. Here's a visual example:

Process execute steps in sequence, which can include:

Run a task
Run a data action
Branch on a condition
Wait
Call a process
Return value(s)

📌Rules:

snake_case, lowercase.
Short, clear, and descriptive purpose.
Preferably, maximum 21 characters to avoid long and unwieldy names.

Example: "generate_invoice"

Process name for a process that generates an invoice.

5.4. BOTS - ICONS

It is recommended to keep the default bot icon.

The bot's purpose defines its function, but the icon helps identify it visually in the editor.

This convention ensures order, clarity, and scalability in AppSheet application development.

INTRO Dear community, today I bring you a new compendium (shorter but concise). This isn't an update of the old version; it's a rework of what was the AppSheet Standard Protocol. These are firm foundations for robust and consistent work (whether you have previous experience or not).This guide arises from the need to avoid chaos in AppSheet app development by establishing clear rules for organizing and naming elements. It's not a tutorial, but a standard to improve performance and efficiency in individual or team work.This work has been cleaned up to offer you a simple experience. Without further ado, let's begin.WHAT IS A STANDARD PROTOCOL? A standard protocol is a set of rules that eliminates mental noise for developers, allowing them to focus on building instead of wasting time deciding on names. It's like a "language" chosen to proceed, based on experience. Without a standard, chaos reigns in teamwork and personal organization. Adopting it improves clarity, efficiency, and professionalism, boosting creativity by eliminating unnecessary distractions. 1. DATA 1.1. GOOGLE SHEETS AS DATABASES When using Google Sheets as our database in AppSheet, folders are automatically generated in our Google Drive directory, specifically within the appsheet/data folder. These folders have a default name that matches the app’s name, followed by a hyphen and a number that acts as the app’s unique identifier. This is the name we recommend keeping for the folder, because: The App ID is unique, trackable, and permanent — CONTEXT("AppName") returns this exact name. It prevents confusion between the visible app name and the technical identifier. If you're working as a team, it's clear that the true identity of the app is its App ID, not the “marketing” name. It allows for unambiguous connections between app ↔ folder ↔ database ↔ logs. It might look a bit “ugly” at first, but it’s the cleanest and most standardized approach. This setup can be complemented with a sheet or database listing app names, including extra details and metadata. Most importantly, it’s sustainable and scalable over time. If you choose to use Google Sheets, it's recommended that the worksheets have no blank columns or empty rows, and that continuous maintenance is performed by deleting any empty rows during the application's use. This is because deleting a record from AppSheet will leave entire empty rows in the tables of the worksheet used as the database. You can visit this post explaining how to create a script in Google Apps Script to automatically delete blank rows from your Google Sheets databases. I personally created this one that I'm currently using. You can use mine or create your own, but in any case, be careful adding scripts you don't know to your databases: function eliminarFilasVacias() { // Obtén la hoja activa var hoja = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet(); // Obtén el rango de la columna A var rango = hoja.getRange("A:A"); var valores = rango.getValues(); // Variable para contar las filas vacías var filasVacias = 0; // Recorre las filas de abajo hacia arriba (para evitar problemas al eliminar filas) for (var i = valores.length - 1; i >= 0; i--) { if (valores[i][0] === "" && filasVacias < 1) { // Si hay una fila vacía, deja esta fila filasVacias++; } else if (valores[i][0] === "") { // Si la fila está vacía y ya hay una fila vacía, elimina la fila hoja.deleteRow(i + 1); // +1 porque las filas en Apps Script son 1-indexed } } } 1.2. FILES FOR DATABASES Google Sheets currently has a limit of 10 million cells per spreadsheet file. See the following link: Google Sheets Best Practices. If we try to create all tables as sheets within a single spreadsheet file, we can affect performance and information organization. In this protocol, it is recommended to use a separate spreadsheet file for each table. This way, each spreadsheet file will have its own 10 million cell limit, and each spreadsheet effectively becomes an independent database table with high capacity. This provides greater flexibility, improves performance, and facilitates data organization. 1.3. NAMING AND ORGANIZATION All spreadsheet files for each application or section should be placed inside a container folder with the same name as the application or section (as created). The Google Sheets file name, the worksheet name (inside the file), and the table name within AppSheet must match (all three must be the same). This name must follow these rules: Written in lowercase, snake_case format. Plural and in English, regardless of the developer's language. No special characters. May contain numbers, but must not start with them. Must clearly express the table's purpose without ambiguity. Example, if we create a table named categories, this doesn't tell us much, as they could be tax categories, item categories, etc. The name needs to be specific:items_categoriesitems_familiesitems_typesitems_instances nutrients_categories nutrients_families nutrients_types 1.4 DATABASES (Structure/Naming Summary) Reglas: snake_case, lowercase, singular (except for special cases detailed later) and in English, regardless of the developer's language. Clear and descriptive purpose. Preferably, a maximum of 27 characters to avoid long and unwieldy names. Container folder name in Google Drive: <app_name>_<app_section> (the section is optional).Google Sheets file name: <table_name>Worksheet name (inside the Google Sheet file):<table_name> Table name (in AppSheet, matching the file/worksheet):<table_name>Slice names:<table_name>_<descriptor>I've requested a new feature for the editor: a checkbox that allows you to add a number so we can organize our tables in the editor (by index, not alphabetically) to separate the table names from their organization in the editor. You can vote for this request here. 1.5 ADDITIONAL RECOMMENDATIONS Format as Table: It is recommended to use the "Format as table" option in Google Sheets to be able to apply filters within the database view in Sheets. Protect Headers: It is recommended to use the "Protect range" function in Google Sheets to prevent accidental deletion or modification of table headers. Freeze the header row: This helps improve the visual organization of data in Sheets. Name Length: Although not mandatory, it's recommended that names have fewer than 27 characters to avoid complications when writing expressions and ensure names display correctly in the editor without wrapping onto multiple lines. This will allow the data structure in Google Sheets to function with many features of a traditional database. 1.6 GENERAL FIELD NAMING Rules: snake_case, lowercase, singular (except for special cases detailed later) and in English, regardless of the developer's language. Clear and descriptive purpose. Preferably, a maximum of 20 characters to avoid long and unwieldy names. Image of Example Table: 1.6.1. COMMON FIELDS These are fields commonly repeated in many tables: Field Name Purpose Row ID If using AppSheet DataBase, this field is automatic and doesn't need to be created. It's the row id. Not visible by default in the database. Note that when migrating the application to another database, you must be very careful when using another field as the id. Although it copies without issues when migrating to Google Sheets, returning to the AppSheet database can generate conflicts with duplicate keys.Editable If' unchecked by default id If using Google Sheets, mandatory field, primary key of the table, always named "id" in lowercase. You can use: UNIQUEID("UUID"), UNIQUEID("packedUUID"), UNIQUEID(). In specific cases, like tables with constant, read-only content, other values can be used in the id field, such as manually chosen values, as long as they are unique. Editable If' unchecked _rowNumber Automatic: This field is automatically created in all tables, numbering the rows. ia_<purpose> Optional: it's a virtual text-type field, empty (with a formula like: ""), used to anchor 'actions, usually inline'. There will be as many such fields as actions needed. created_at Optional: This field stores the date and time in the database. Configure a YYYY-MM-DD hh:mm:ss format in Google Sheets.DateTime, initial value UTCNOW(), reset on edit off. edited_at Optional: This field stores the date and time in the database. Configure a YYYY-MM-DD hh:mm:ss format in Google Sheets.ChangeTimeStamp, initial value UTCNOW(). created_by Optional: It's typically the email of the user logged into the application, so USEREMAIL() is used in the initial value space, reset on edit off, non editable. edited_by Optional: It's typically the email of the user logged into the application, so USEREMAIL() is used in the initial value space, reset on edit on. 1.6.2. FOREIGN KEY FIELDS Ref: <singular_table/slice_name>_id Enum base Ref: <singular_table/slice_name>_id Enumlist base Ref: <singular_table/slice_name>_ids Assuming special cases where we have two ref, enum base ref, or enumlist base ref fields coming from the same source table within the current table, we cannot name them the same as it would cause an error. We can solve this generically as follows: The first ref field from a table can be named: <singular_table/slice_name>_id The second ref field from the same table can be named: <singular_table/slice_name>_<aditional_descriptor>_id/s 1.6.3. INHERITED FIELDS The most common case of an inherited field is a foreign key. As seen previously, they are named <singular_table/slice_name>_id These fields inherited into other tables have a name in their source table; for inherited fields other than the 'id', the following convention will be used: <singular_table/slice_name>_<field_name>, Thus, if a field is named “nature” in the “categories” table, in the “types” table it will be named “category_nature”, making it clear it's an inherited field from the “categories” table. 2. VIEWS 2.1. VIEWS - EDITOR'S RESULT Here's the result, I'll explain it below: 2.2. VIEW TYPES IN APPSHEET (CODE) In AppSheet, views function as the user interface. Currently, there are 11 view types (as of 2025), but it's anticipated that more will likely be added in the future. A highly requested example is the Gantt Chart view, which is apparently under study and development.Below, I will detail the view type along with its naming code (in red) and the icon we will use for each ref view. (The views that are displayed directly to the user in the editor will have icons chosen by the developer; we are only referring to ref views.)Table-Dependent Calendar (cl): "calendar-alt" regular icon Deck (dk): "list-alt" regular icon Table (tb): "table" regular icon Gallery (gl): "th-large" regular icon Detail (dt): "indent" regular icon Map (mp): "map-marker-alt" regular icon Chart (ch): "chart-pie" regular icon Form (fr): "edit" regular icon Onboard (ob): "window-restore" regular icon Card (cd): "portrait" icon Table-Independent Dashboard (db): "layer-group" icon 2.3. VIEW EDITOR STRUCTURE The AppSheet editor organizes views into four sections: Primary Navigation Contains the views for the app's main panel (not much to say here). Menu Navigation Shows views accessible from the menu (not much to say here). System Generated Views automatically created by AppSheet for each table. Using them directly is not recommended. Referenced Views A disorganized area where all referenced views are stored (Reason for the view naming convention); see below. 2.4. REFERENCED VIEWS Similar to a bag of trash (because that's what I perceive), they have no organization whatsoever; everything is "thrown in the same bag". It's incredibly tedious to see the views there without even having sorting by table or view type. Anyway, because of this, I have modified the convention that will allow us to have a clean, organized, intuitive editor, and although a bit cryptic, the "app editor" is accessible to the work team who will know the convention, making it less "cryptic". Truthfully, the convention only serves to provide order until AppSheet implements native sorting for this section. By the way, you can vote for this idea by clicking the link to give it relevance. Once AppSheet organizes this section, this naming convention will automatically lose its effect, and we can enjoy native sorting without having to return to the legacy editor.To solve this, I propose a naming convention that will allow for a clean, organized, and intuitive editor, at least until AppSheet implements a native organization system. 2.5. ORGANIZATION METHOD Using the “source_prefix_generator” file Our colleague proposed creating a file to document table names in the old protocol. I have taken his idea as inspiration and created a Google Sheets file called "source_prefix_generator". This file will serve to:✔ Generate standardized prefixes for naming views, actions, bots, and format rules.✔ Keep a record of changes in the app's structures.✔ Facilitate navigation within the editor. This file contains the following fields: table_sufix slice_sufix table/slice_name action_bots_format_prefix view_prefix 001 - table_one 001 001_00 002 - table_two 002 002_00 002 01 slice_of_table_two - 002_01 The table_sufix field contains a number from 001 to 999 (three digits) and is the identifier for your tables. Each time a table is added to our database structure, we must register that table in the source_prefix_generator with its ID. The slice_sufix field is a number from 01_99 and represents the slice identifier number. Each time we create a slice, we add it to the source_prefix_generator with its identifier. table/slice_name is a field that stores the table/slice name exactly as it is in our application. The table/slice name can change, but the table_sufix and slice_sufix should never change. action_bots_format_prefix is a field with an expression that takes only the table ID (it does not consider slices) since actions, bots, and format rules apply only to tables. view_prefix is a field that generates a usable prefix for views, since these can be based on slices. Fields with an empty slice_sufix cell are tables, and their view_prefix will always have the table suffix and 00 as the slice suffix. See the cases in the following example: 2.6. VIEW NAMING Our colleague suggested table sorting based on prefixes and view types; it was really interesting, so I decided to take his idea as inspiration for this new naming convention (though slightly modified). He starts with numbers, but I realized that starting view names with numbers in the editor while adding expressions doesn't automatically trigger the suggestion popup dialog. Whereas, if we start with letters, filtered suggestions automatically start appearing, which is more intuitive during development and increases typing speed. See it right here: The first part of the name structure always has the same length and is displayed very orderly, to the point where it eventually goes unnoticed, while the purpose becomes more recognizable.<view_type_code>_<view_prefix>_<view_purpose> What is the advantage of using prefixes (even numeric ones within the view_prefix) instead of full names? If the table name changes, the view name doesn't have to because the prefix is an ID, while the name can change. Everything becomes much simpler to visualize. Names are drastically shortened, which is more comfortable in the editor. Allows quick detection of unused or duplicate views. 2.7. SPECIAL CASES: DASHBOARD The only view type that doesn't follow the table-based naming format is the Dashboard view, as it can be composed of two or more tables. For these cases, we use a representative name in lowercase, following this format: db_<purpose> Rules: snake_case, lowercase. The purpose should be a clear and descriptive noun. Preferably, a maximum of 30 characters to avoid long and unwieldy names. 2.9. DISPLAY NAMES The name the user will see in the interface must be inserted within quotes in the Display Name field, as an expression, whether in views, actions, fields, etc. 3. FORMAT RULES 3.1. FORMAT RULE NAMING f_<table_prefix>_<purpose> Example: f_008_blank_children Indicates a format rule applied to the table with prefix 008, to handle rows without children. Rules: snake_case, lowercase. Maximum 23 characters. The purpose should be clear and descriptive. 4. BEHAVIOR ACTIONS 4.1 SYSTEM-GENERATED ACTIONS System-generated actions receive a default name. Some examples are: Add Delete Edit Compose Email (User ID) View Ref (TABLE) These names are consistent across all tables and should not be modified. 4.2. CUSTOM ACTIONS For actions we create manually, we will use the "source_prefix_generator" file.. First, I'll show the result, then I'll explain: As you can see, the actions are already organized by table in the editor UI (in the case of the image above, organized under the “items_types” table), but the naming convention ensures the first part of the name always has the same length and provides a better visualization of the action's purpose. Now, why is this convention necessary when they are already natively organized by table in the editor? Because AppSheet doesn't allow us to use the same name for actions in different tables. If we created an action named “update” in one table and then another with the same name in another table, AppSheet would automatically rename it to “update 2”, which creates naming inconsistencies. Note that this problem doesn't occur with system-generated actions, since AppSheet gives them the same name in all tables (i.e., there's no Add 1, Add 2, Add n). Therefore, until AppSheet allows manually created actions to share the same name if they are in different tables, this convention helps us maintain order and avoid inconsistencies in our apps. I have created a topic for AppSheet to implement this improvement; you can vote here so this limitation disappears in the future. When this happens, our convention will no longer be necessary, and development will be simpler. 4.3. ACTION CODE(action_code) There are four main sets of behavior actions in AppSheet: ACTION CODE Application a Data d External e Grouped g This code convention (action_code) facilitates the organization and quick reference of actions in AppSheet, improving clarity and efficiency in application development. Each set contains specific actions: 7 Application Actions 4 Data Actions 5 External Actions 1 Grouped Action 4.3.1. Application Actions (a) Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition. Copy this row and edit the copy → (a1): "clone" icon Edit this row → (a2):"edit" regular icon Export this view to a CSV file (not a row-level action)→ (a3): "fiie-csv" regular icon Go to another AppSheet app → (a4): "rocket"-regular icon IGo to another view within this app → (a5): "chevron-circle-right" black icon Import a CSV file for this view (not a row-level action) → (a6): "fiie-csv" black icon Open a form to add a new row to this table (not a row-level action) → (a7): "plus" regular icon 4.3.2. Data Actions (d) Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition. Add a new row to another table using values from this row → (d1): "layer-plus" light icon Delete this row → (d2): "trash-alt" solid icon Execute an action on a set of rows → (d3): "table" light icon Set the values of some columns in this row → (d4): "slider-h" regular icon 4.3.3. External Actions (e) Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition. Go to a website → (e1): "browser" regular icon Open a file → (e2): "folder-open" regular icon Start a phone call → (e3): "phone" regular icon Start an SMS message → (e4): "envelope" regular icon Start an email → (e5):"comment-alt-lines" regular icon 4.3.4. Grouped Action (g) Below are the actions of the "Application" set with their code and suggested icon for those with "hidden" condition. Execute a sequence of actions → (g1): "list-ol" regular icon 4.4. NAMING FOR ACTIONS <action_code>_<source_table_prefix>_<destination_table_prefix>_<action_purpose> If the action is applied to a single table, both the source and target tables will use the same prefix. Rules: snake_case, lowercase. The purpose should be a clear and descriptive noun. Preferably, maximum 30 characters to avoid long and unwieldy names. 5. BOTS 5.1. NAMING CONVENTION FOR BOTS bot_<table_prefix>_<purpose> Example:bot_018_adder Este bot pertenece a la tabla con prefijo 018 y su propósito es agregar filas. Rules: snake_case, lowercase. The purpose should be a clear and descriptive noun. Preferably, maximum 27 characters to avoid long and unwieldy names. 5.2. NAMING CONVENTION FOR EVENTS Events in AppSheet are triggered when one of these situations occurs: Event Type Code App Event app AppSheet database adb Scheduled Change (Time) sch Chat Application cha Google Forms gfr Gmail gml Event name format: event_<table_prefix>_<event_type_code>_<n_order_number> Example: event_008_app_1 Indicates it's an event on table 008, of type app (application event), with order index 1.If multiple similar events are created, the number is incremented (_2, _3, etc.) to avoid conflicts. 5.3. NAMING CONVENTION FOR STEPS In the rest of the editor, we use a coded nomenclature, but in this case, we'll use an intuitive one. Processes are organized as a sequence of logical steps whose purpose is to solve a problem (i.e., an algorithm).It's very interesting to see how steps look in a process when their nomenclature is clear and understandable. Here's a visual example:Process execute steps in sequence, which can include: Run a task Run a data action Branch on a condition Wait Call a process Return value(s) Rules: snake_case, lowercase. Short, clear, and descriptive purpose. Preferably, maximum 21 characters to avoid long and unwieldy names. Example: "generate_invoice" Process name for a process that generates an invoice. 5.4. BOTS - ICONS It is recommended to keep the default bot icon. The bot's purpose defines its function, but the icon helps identify it visually in the editor. This convention ensures order, clarity, and scalability in AppSheet application development.

(Es) Protocolo de Nomenclatura Estándar AppSheet

Haga clic en "Show more" para desplegar el protocolo:

INTRO

Querida comunidad, hoy les traigo un nuevo compendio (más corto pero conciso). No se trata de una actualización de la antigua versión , se trata de una reelaboración de lo que fue el AppSheet Standard Protocol. Son cimientos firmes para un trabajo sólido y consistente (sea que tengas experiencia previa o no).

Este manual surge de la necesidad de evitar el caos en el desarrollo de apps con AppSheet, estableciendo reglas claras para la organización y nomenclatura de elementos. No es un tutorial, sino un estándar para mejorar el rendimiento y la eficiencia en el trabajo individual o en equipos.

Este trabajo se ha limpiado para ofrecerles una experiencia simple. Sin más, comencemos.

¿QUÉ ES UN PROTOCOLO ESTÁNDAR?

Un protocolo estándar es un conjunto de reglas que eliminan el ruido mental a los desarrolladores, permitiéndoles enfocarse en construir en lugar de perder tiempo decidiendo nombres. Es como un "idioma" que se elige para proceder, basado en la experiencia. Sin un estándar, el caos reina en el trabajo en equipo y la organización personal. Adoptarlo mejora la claridad, eficiencia y profesionalismo, potenciando la creatividad al eliminar distracciones innecesarias.

1. DATOS

1.1. GOOGLE SHEETS - BASES DE DATOS

Cuando usamos Google Sheets como nuestra base de datos en AppSheet, se generan automáticamente carpetas en nuestro directorio de Google Drive, dentro de la carpeta 'appsheet/data'. Estas carpetas tienen un nombre predeterminado que coincide con el nombre de la aplicación creada, seguido de un guion y un número que actúa como identificador único de la aplicación. Este será el nombre que dejaremos en la carpeta ya que.

El id de app es único, rastreable y permanente CONTEXT("Appname") devuelve ese nombre.
Evitamos confusión entre nombre visible y nombre técnico.
Si alguien más trabaja en equipo, sabemos que el nombre real de la app es el App ID, no el título “de marketing”.
Permite relacionar sin ambigüedades: app ↔ carpeta ↔ base ↔ logs.
Es algo "feo" al principio pero es la forma más ordenada y estándar.
Se puede complementar esto con una hoja o base de datos con nombres de apps en las que se de de alta información al respecto.
Es sostenible a largo plazo.

Es importante entender la diferencia entre una spreadsheet (archivo) y una sheet (hoja de cálculo) en Google Sheets. La spreadsheet es la base de datos en sí misma, mientras que las sheets son las hojas dentro de la spreadsheet donde se crean las tablas de nuestra base de datos.

Si optamos por usar Google Sheets, se recomienda que las hojas no tengan columnas en blanco ni filas vacías, y que se realice un mantenimiento continuo eliminando cualquier fila vacía durante el uso de la aplicación, ya que al eliminar un registro desde AppSheet, se dejarán filas completas vacías en las tablas de la hoja de cálculo usada como base de datos. Puedes visitar este post donde se explica cómo crear un script en Google Apps Script para eliminar automáticamente las filas en blanco de tus bases de datos en Google Sheets.

Yo personalmente he creado este que estoy usando actualmente. Puedes usar el mío o crear el tuyo, pero en cualquier caso ten cuidado con agregar scripts que no conozcas en tus bases de datos:

function eliminarFilasVacias() {
  // Obtén la hoja activa
  var hoja = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  
  // Obtén el rango de la columna A
  var rango = hoja.getRange("A:A");
  var valores = rango.getValues();
  
  // Variable para contar las filas vacías
  var filasVacias = 0;
  
  // Recorre las filas de abajo hacia arriba (para evitar problemas al eliminar filas)
  for (var i = valores.length - 1; i >= 0; i--) {
    if (valores[i][0] === "" && filasVacias < 1) {
      // Si hay una fila vacía, deja esta fila
      filasVacias++;
    } else if (valores[i][0] === "") {
      // Si la fila está vacía y ya hay una fila vacía, elimina la fila
      hoja.deleteRow(i + 1); // +1 porque las filas en Apps Script son 1-indexed
    }
  }
}

1.2. ARCHIVOS PARA BASES DE DATOS

Google Sheets tiene un límite de 10 millones de celdas por hoja de cálculo actualmente. Consulta el siguiente enlace: Google Sheets Best Practices.

Si intentamos crear todas las tablas en hojas dentro de una única hoja de cálculo, podemos afectar el rendimiento y la organización de la información.

En este protocolo, se recomienda utilizar una hoja de cálculo separada para cada base de datos. De este modo, cada hoja tendrá su propio límite de 10 millones de celdas, y cada hoja de cálculo se convertirá en una base de datos independiente con alta capacidad. Esto proporciona mayor flexibilidad, mejora el rendimiento y facilita la organización de los datos.

1.3. NOMENCLATURA Y ORGANIZACIÓN

Todas las hojas de cálculo de cada aplicación o sección deben colocarse dentro de una carpeta contenedora con el mismo nombre que la aplicación o la sección (según se haya creado).

El nombre del archivo de Google Sheets, el nombre de la hoja de cálculo y el nombre de la tabla dentro de hoja de cálculo deben coincidir (los tres deben ser iguales).

Este nombre debe seguir estas reglas:

Escrito en minúsculas, en formato snake_case.
Plural y en inglés, independientemente del idioma del desarrollador.
Sin caracteres especiales. Puede contener números, pero no debe comenzar con ellos.
Debe expresar claramente el propósito de la tabla sin ambigüedades.

Ejemplo, si creamos una tabla llamada categories, esto no nos dice mucho, ya que podrían ser categorías de impuestos, categorías de artículos, etc. Es necesario que el nombre sea específico:
items_categories items_families items_types items_instances nutrients_categories nutrients_families nutrients_types

1.4 BASES DE DATOS

📌 Reglas:

snake_case, minúsculas, en singular (salvo casos especiales que se detallarán) y en inglés, independientemente del idioma del desarrollador.
Propósito claro y descriptivo.
Preferentemente, máximo 27 caracteres para evitar nombres largos y poco manejables.

Nombre de la carpeta contenedora de la base de datos en Google Drive:

<app_name>_<app_section> (la sección es opcional).

Nombre del archivo Google Sheets:

<table_name>
Nombre de la hoja de cálculo:

<table_name>

Nombre de la tabla dentro de la hoja de cálculo y en AppSheet:
<table_name>Nombre de slices:
<table_name>_<descriptor>

He solicitado una funcionalidad nueva para el editor; un casillero que permita agregar un número para que podamos organizar nuestras tablas en el editor (por índice y no por orden alfabético a los fines de independizar el nombre de las tablas de su organización en el editor. Puedes votar esta solicitud aquí.

1.5 RECOMENDACIONES ADICIONALES

Convertir en tabla: Se recomienda utilizar la opción "Crear tabla" en Google Sheets para poder aplicar filtros dentro de la base de datos.
Proteger encabezados: Se recomienda usar la función "Proteger rango" en Google Sheets para evitar la eliminación o modificación accidental de los encabezados de las tablas.
Congelar la fila del encabezado: Esto ayuda a mejorar la organización visual de los datos.
Longitud del nombre: Aunque no es obligatorio, es recomendable que el nombre tenga menos de 27 caracteres para evitar complicaciones al escribir expresiones y asegurar que los nombres se vean correctamente en el editor sin ocupar varias líneas.

Esto permitirá que la estructura de datos en Google Sheets funcione con muchas de las características de una base de datos tradicional.

1.6 NOMENCLATURA GENERAL DE CAMPOS

📌 Reglas:

snake_case, minúsculas, en singular (salvo casos especiales que se detallarán) y en inglés, independientemente del idioma del desarrollador.
Propósito claro y descriptivo.
Preferentemente, máximo 20 caracteres para evitar nombres largos y poco manejables.

Imagen de Tabla Ejemplo:

1.6.1. CAMPOS HABITUALES

Son campos que se repiten habitualmente en muchas tablas:

Nombre de campo	Propósito
Row ID	Si usan AppSheet DataBase, este campo es automático y no necesita ser creado. Es el id de fila. No es visible de manera predeterminada en la base. Tenga en cuenta que cuando se migra la aplicación a otra base de datos debe tener sumo cuidado al usar otro campo como id. Aunque se copia sin problemas al migrar a Google Sheets, regresar a la base de datos de AppSheet puede generar conflictos con campos duplicados. Editable If' destildado por defecto.
id	Si usan Google Sheets, campo obligatorio, clave principal de tabla, siempre se llama "id" en minúsculas. Puede usar: UNIQUEID("UUID"), UNIQUEID("packedUUID"), UNIQUEID(). En casos específicos, como tablas con contenido constante y de solo lectura, pueden usarse otros valores en el campo id, como valores elegidos manualmente siempre que no se repitan. Editable If' destildado.
_rowNumber	Automático: Este campo se crea automáticamente en todas las tablas, numerando las filas.
ia_<purpose>	Opcional: es un campo virtual de tipo texto, vacío (con una fórmula como esta: ""), utilizado para señalar las 'acciones, generalmente en línea'. Habrá tantos campos como acciones se necesiten.
created_at	Opcional: Este campo almacena la fecha y hora en la base de datos. Configurar en Google Sheet un formato YYYY-MM-DD hh:mm:ss. DateTime, initial value UTCNOW(), reset on edit of. No editable.
edited_at	Opcional: Este campo almacena la fecha y hora en la base de datos. Configurar en Google Sheet un formato YYYY-MM-DD hh:mm:ss. DateTime, initial value UTCNOW(), reset on edit on. Editable on.
created_by	Opcional: Es típicamente el correo electrónico del usuario que inicia sesión en la aplicación, por lo que se utiliza USEREMAIL() en el espacio de valor inicial, no editable y reset on edit desmarcado.
edited_by	Opcional: Es típicamente el correo electrónico del usuario que inicia sesión en la aplicación, por lo que se utiliza USEREMAIL() en el espacio de valor inicial, editable, reset on edit marcado.

1.6.2. CAMPOS FORÁNEOS

Ref:
<singular_table/slice_name>_id
Enum base Ref:
<singular_table/slice_name>_id
Enumlist base Ref:
<singular_table/slice_name>_ids

Suponiendo casos especiales en los que tenemos dos campos ref, enum de base type ref o enumlist de base type ref, que provienen de una misma tabla, en la tabla actual, no podemos nombrarlos iguales ya que generaría error. Para ello podemos solucionarlo del siguiente modo genérico:

Al primer campo ref proveniente de una tabla podemos llamarlo:

<singular_table/slice_name>_id

Al segundo campo ref proveniente de una tabla podemos llamarlo

<singular_table/slice_name>_<aditional_descriptor>_id/s

1.6.3. CAMPOS HEREDADOS

El caso más común de campo heredado es una clave foránea. Como vimos anteriormente se nombran <singular_table/slice_name>_id

Estos campos que se heredan en otras tablas tienen un nombre en su tabla origen; para campos diferentes a id heredado se tomará la siguiente convención:

<singular_table/slice_name>_<field_name>, así, si un campo se llama “nature” en la tabla “categories”, en la tabla “types” se llamará “category_nature” dejando en claro que es un campo heredado de la tabla “categories”.

2. VISTAS

2.1. VISTAS - RESULTADO EDITOR

Les dejo el resultado, después se los explico:

2.2. TIPOS DE VISTAS EN APPSHEET (CÓDIGO)

En AppSheet, las vistas funcionan como la interfaz de usuario. Actualmente, existen 11 tipos de vistas (hasta 2025), pero es se ha adelantado que es probable que se agreguen más en el futuro. Un ejemplo muy solicitado es la vista Gantt Chart, que al parecer está en proceso de estudio y desarrollo.

A continuación detallaré junto al tipo de vista, su código para la nomenclatura (en rojo) y el ícono que usaremos para cada vista ref (las vistas que se muestran al usuario directamente en el editor tendrán íconos que el desarrollador elija; solo hablamos de las vistas ref):

Dependientes de una tabla

Calendar (cl) icono "calendar-alt" regular
Deck (dk) ícono "list-alt" regular
Table (tb) ícono "table" regular
Gallery (gl) ícono "th-large" regular
Detail (dt) ícono "indent" regular
Map (mp) ícono "map-marker-alt" regular
Chart (ch) ícono "chart-pie" regular
Form (fr) ícono "edit" regular
OnBoard (ob) ícono "window-restore" regular
Card (cd) ícono "portrait" regular

Independientes de una tabla

Dashboard (db) ícono "layer-group" regular

2.3. ESTRUCTURA DEL EDITOR DE VISTAS

El editor de AppSheet organiza las vistas en cuatro secciones:

Primary Navigation
- Contiene las vistas del panel principal de la app (no hay demasiado por opinar aquí).
Menu Navigation
- Muestra las vistas accesibles desde el menú (no hay demasiado por opinar aquí).
System Generated
- Son vistas creadas automáticamente por AppSheet para cada tabla. No se recomienda usarlas directamente.
Referenced Views
- Un área desorganizada donde se almacenan todas las vistas referenciadas (Razón de ser de la convención de nomenclatura de vistas); véase a continuación.

2.4. REFERENCED VIEWS

Similar a una bolsa con basura (porque eso es lo que percibo), no tienen organización alguna, está todo “tirado en la misma bolsa”. Resulta un enorme tedio ver las vistas allí sin si quiera disponer de un ordenamiento por tabla o por tipo de vista. En fin debido a esto es que he modificado la convención que nos va a permitir tener un editor limpio, ordenado, intuitivo y, aunque un poco críptico, el "app editor" es accesible al equipo de trabajo que conocerá la convención con lo cual no es tan "críptico" y, a decir verdad, la convención solo sirve para brindar un orden mientras AppSheet no genere un ordenamiento nativo para esta sección. Dicho sea de paso puedes votar esta idea haciendo clic en el enlace para que tome relevancia. Una vez que AppSheet organice esta sección, esta nomenclatura perderá automáticamente su efecto y podremos disfrutar de un ordenamiento nativo sin tener que volver al legacy editor.

Para solucionar esto, propongo una convención de nombres que permitirá un editor limpio, ordenado e intuitivo, al menos hasta que AppSheet implemente un sistema de organización nativo.

2.5. MÉTODO DE ORGANIZACIÓN

Uso del archivo “source_prefix_generator”

Nuestro compañero @yasarcan propuso la creación de un archivo para documentar nombres de tabla en el viejo protocolo. Yo he tomado su idea como idea fuerza y he creado una app llamada appsheet_nomenclator .

Esta app sirve para:
✔ Generar prefijos estandarizados para nombrar vistas, acciones, bots y reglas de formatos, etc.
✔ Llevar un registro de cambios en las estructuras de la app.
✔ Facilitar la navegación dentro del editor.

Le sugiero que copie la app y la use para darle nombre a sus elementos.

2.6. NOMENCLATURA DE VISTAS

Nuestro compañero @Yahia_DAK sugirió un ordenamiento de tabla basado en prefijos y tipos de vista, realmente fue interesante así que decidí tomar su idea como idea fuerza para esta nueva nomenclatura (aunque un poco modificada). Él comienza con números pero me he dado cuenta que al comenzar con números en el editor mientras estamos agregando expresiones, el cuadro de diálogo no se genera automáticamente con el popup de sugerencias, en cambio si iniciamos con letras si, automáticmente comienzan a desplegarse sugerencias filtradas, lo cual es más intuitivo en el desarrollo y aumenta la velocidad de escritura.

Véanlo aquí mismo:

La primera parte de la estructura del nombre tiene siempre la misma longitud y se visualiza de forma muy ordenada al punto que termina pasando desapercibida mientras el propósito se hace más reconocible.

<view_type_code>_<view_prefix>_<view_purpose>

¿Cuál es la ventaja de usar prefijos numéricos en lugar de nombres completos?

Si el nombre de tabla cambia, el nombre de vista no tiene porque hacerlo porque el prefijo es un id mientras que el nombre puede cambiar.
Se hace todo mucho más simple de visualizar.
Los nombres se acortan abruptamente, lo cual es más cómodo en el editor.
Permite detectar vistas inutilizadas o duplicadas, rápidamente.

2.7. CASOS ESPECIALES: DASHBOARD

El único tipo de vista que no sigue el formato de nombres basado en tablas es la vista Dashboard, ya que puede estar compuesta por dos o más tablas.

Para estos casos, usamos un nombre representativo en minúsculas, siguiendo este formato:

db_<purpose>

📌 Reglas:

snake_case, minúsculas.
El propósito debe ser un sustantivo claro y descriptivo.
Preferentemente, máximo 30 caracteres para evitar nombres largos y poco manejables.

2.8. NOMBRES VISIBLES (Display Names)

El nombre que verá el usuario en la interfaz debe ser insertado dentro de comillas en el campo Display Name, como una expresión, ya sea en vistas, acciones, campos, etc.

3. REGLAS DE FORMATO

3.1. NOMENCLATURA REGLAS DE FORMATO:

f_<table_prefix>_<purpose>

Ejemplo: f_008_blank_children

Indica que es una regla de formato aplicada a la tabla con prefijo 008, para manejar filas sin hijos.

📌 Reglas:

snake_case, minúsculas.
Máximo 23 caracteres.
El propósito debe ser claro y descriptivo.

4. ACCIONES DE COMPORTAMIENTO

4.1 ACCIONES GENERADAS POR EL SISTEMA

Las acciones autogeneradas reciben un nombre por defecto. Algunos ejemplos son:

Add
Delete
Edit
Compose Email (User ID)
View Ref (TABLE)

Estos nombres son consistentes en todas las tablas y no deben ser modificados.

4.2. ACCIONES PERSONALIZADAS

Para las acciones que creamos manualmente, usaremos el archivo "source_prefix_generator".

Primero les muestro el resultado, seguidamente les explico:

Como pueden ver, las acciones ya están organizadas por tabla, en el caso de la imagen anterior, organizadas bajo la tabla “items_types”, lo que garantiza que la primera parte del nombre tenga siempre la misma longitud y proporcione una mejor visualización del propósito de la acción.

Ahora, ¿por qué es necesaria esta convención estando ya organizada de forma nativa por tabla?

Porque AppSheet no nos permite usar el mismo nombre para acciones en tablas diferentes. Si creásemos una acción llamada “update” en una tabla y luego otra con el mismo nombre en otra tabla, AppSheet la renombrará automáticamente como “update 2”, lo que genera inconsistencias en la nomenclatura. Nótese que este problema no ocurre con las acciones generadas por el sistema, ya que AppSheet les da el mismo nombre en todas las tablas; es decir, no existe Add 1, Add2, Add n.

Por eso, hasta que AppSheet permita que las acciones creadas manualmente puedan compartir el mismo nombre si están en tablas distintas, esta convención nos ayuda a mantener el orden y evitar inconsistencias en nuestras apps.

He creado un tópico para que AppSheet implemente esta mejora, puedes votar aquí para que esta limitación desaparezca en el futuro. Cuando esto ocurra, nuestra convención dejará de ser necesaria y el desarrollo será más simple.

4.3. CÓDIGO DE ACCIÓN (`action_code`)

Existen cuatro conjuntos principales de acciones de comportamiento en AppSheet:

ACCIONES	CÓDIGO
Application	a
Data	d
External	e
Grouped	g

Cada set contiene acciones específicas:

7 Application Actions
4 Data Actions
5 External Actions
1 Grouped Action

4.3.1. Acciones de Aplicación (`a`)

A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta"

Copiar esta fila y editarla → (a1): "clone" icon
Editar esta fila → (a2): "edit" regular icon
Exportar esta vista a un archivo CSV (no es una acción a nivel de fila) → (a3): "fiie-csv" regular icon
Ir a otra app de AppSheet → (a4): "rocket"-regular icon
Ir a otra vista dentro de esta app → (a5): "chevron-circle-right" black icon
Importar un archivo CSV para esta vista (no es una acción a nivel de fila) → (a6): "fiie-csv" black icon
Abrir un formulario para agregar una nueva fila a esta tabla (no es una acción a nivel de fila) → (a7): "plus" regular icon

4.3.2. Acciones de Datos (`d`)

A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta"

Agregar una nueva fila a otra tabla usando valores de esta fila → (d1): "layer-plus" light icon
Eliminar esta fila → (d2): "trash-alt" solid icon
Ejecutar una acción en un conjunto de filas → (d3): "table" light icon
Establecer valores en algunas columnas de esta fila → (d4): "slider-h" regular icon

4.3.3. Acciones Externas (`e`)

A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta"

Ir a un sitio web → (e1): "browser" regular icon
Abrir un archivo → (e2): "folder-open" regular icon
Iniciar una llamada telefónica → (e3): "phone" regular icon
Iniciar un mensaje de texto → (e4): "envelope" regular icon
Iniciar un correo electrónico → (e5): "comment-alt-lines" regular icon

4.3.4. Acción Agrupada (`g`)

A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta"

Ejecutar una secuencia de acciones → (g1): "list-ol" regular icon

Esta convención de código (action_code) facilita la organización y referencia rápida de las acciones en AppSheet, mejorando la claridad y eficiencia en el desarrollo de aplicaciones.

4.4. NOMENCLATURA PARA ACCIONES

<action_code>_<source_table_prefix>_<destination_table_prefix>_<action_purpose

Si la acción se aplica en una sola tabla, tanto la tabla origen como la tabla destino usará el mismo prefijo.

📌 Reglas:

snake_case, minúsculas.
El propósito debe ser un sustantivo claro y descriptivo.
Preferentemente, máximo 30 caracteres para evitar nombres largos y poco manejables.

5. BOTS

5.1. CONVENCIÓN DE NOMBRES PARA BOTS

bot_<table_prefix>_<purpose>

Ejemplo:bot_018_adder

Este bot pertenece a la tabla con prefijo 018 y su propósito es agregar filas.

📌 Reglas:

snake_case, minúsculas.
El propósito debe ser un sustantivo claro y descriptivo.
Preferentemente, máximo 27 caracteres para evitar nombres largos y poco manejables.

5.2. CONVENCIÓN DE NOMBRES PARA EVENTOS

Los eventos en AppSheet se generan cuando ocurre alguna de estas situaciones:

Tipo de Evento	Código
Evento en la aplicación	`app`
AppSheet database	`adb`
Cambio programado (Tiempo)	`sch`
Aplicación de Chat	`cha`
Google Forms	`gfr`
Gmail	`gml`

📌 Formato de nombre de eventos:

event_<table_prefix>_<event_type_code>_<n_order_number>

Ejemplo: event_008_app_1

Indica que es un evento en la tabla 008, de tipo app (evento en la aplicación), con un índice 1.
Si se crean múltiples eventos similares, se incrementa el número (_2, _3, etc.) para evitar conflictos.

5.3. CONVENCIÓN DE NOMBRES PARA PASOS (STEPS)

En el resto del editor usamos una nomenclatura codificada pero en este caso vamos a usar una nomenclatura intuitiva. Los steps se ordenan como lo que son, una secuencia de pasos lógicos ordenados cuya finalidad es resolver un problema (es decir, un algoritmo).
Es muy interesante ver cómo se ven los pasos de un proceso cuando su nomenclatura es clara y entendible. Aquí les dejo un ejemplo visual:

Los procesos ejecutan pasos (steps) en secuencia, que pueden incluir:

Ejecutar una tarea
Ejecutar una acción sobre los datos
Dividir la ejecución con una condición
Esperar
Llamar a un proceso
Devolver valores

📌 Reglas:

snake_case, minúsculas.
Propósito corto, claro y descriptivo.
Preferentemente, máximo 21 caracteres para evitar nombres largos y poco manejables.

Ejemplo: "generate_invoice"

Proceso que genera una factura.

5.4. BOTS - ÍCONOS

Se recomienda mantener el ícono del bot por defecto.
El propósito del bot define su función, pero el ícono ayuda a identificarlo visualmente en el editor.

Esta convención garantiza orden, claridad y escalabilidad en el desarrollo de aplicaciones en AppSheet.

INTRO Querida comunidad, hoy les traigo un nuevo compendio (más corto pero conciso). No se trata de una actualización de la antigua versión , se trata de una reelaboración de lo que fue el AppSheet Standard Protocol. Son cimientos firmes para un trabajo sólido y consistente (sea que tengas experiencia previa o no). Este manual surge de la necesidad de evitar el caos en el desarrollo de apps con AppSheet, estableciendo reglas claras para la organización y nomenclatura de elementos. No es un tutorial, sino un estándar para mejorar el rendimiento y la eficiencia en el trabajo individual o en equipos.Este trabajo se ha limpiado para ofrecerles una experiencia simple. Sin más, comencemos. ¿QUÉ ES UN PROTOCOLO ESTÁNDAR? Un protocolo estándar es un conjunto de reglas que eliminan el ruido mental a los desarrolladores, permitiéndoles enfocarse en construir en lugar de perder tiempo decidiendo nombres. Es como un "idioma" que se elige para proceder, basado en la experiencia. Sin un estándar, el caos reina en el trabajo en equipo y la organización personal. Adoptarlo mejora la claridad, eficiencia y profesionalismo, potenciando la creatividad al eliminar distracciones innecesarias. 1. DATOS 1.1. GOOGLE SHEETS - BASES DE DATOS Cuando usamos Google Sheets como nuestra base de datos en AppSheet, se generan automáticamente carpetas en nuestro directorio de Google Drive, dentro de la carpeta 'appsheet/data'. Estas carpetas tienen un nombre predeterminado que coincide con el nombre de la aplicación creada, seguido de un guion y un número que actúa como identificador único de la aplicación. Este será el nombre que dejaremos en la carpeta ya que. El id de app es único, rastreable y permanente CONTEXT("Appname") devuelve ese nombre. Evitamos confusión entre nombre visible y nombre técnico. Si alguien más trabaja en equipo, sabemos que el nombre real de la app es el App ID, no el título “de marketing”. Permite relacionar sin ambigüedades: app ↔ carpeta ↔ base ↔ logs. Es algo "feo" al principio pero es la forma más ordenada y estándar. Se puede complementar esto con una hoja o base de datos con nombres de apps en las que se de de alta información al respecto. Es sostenible a largo plazo. Es importante entender la diferencia entre una spreadsheet (archivo) y una sheet (hoja de cálculo) en Google Sheets. La spreadsheet es la base de datos en sí misma, mientras que las sheets son las hojas dentro de la spreadsheet donde se crean las tablas de nuestra base de datos. Si optamos por usar Google Sheets, se recomienda que las hojas no tengan columnas en blanco ni filas vacías, y que se realice un mantenimiento continuo eliminando cualquier fila vacía durante el uso de la aplicación, ya que al eliminar un registro desde AppSheet, se dejarán filas completas vacías en las tablas de la hoja de cálculo usada como base de datos. Puedes visitar este post donde se explica cómo crear un script en Google Apps Script para eliminar automáticamente las filas en blanco de tus bases de datos en Google Sheets.Yo personalmente he creado este que estoy usando actualmente. Puedes usar el mío o crear el tuyo, pero en cualquier caso ten cuidado con agregar scripts que no conozcas en tus bases de datos: function eliminarFilasVacias() { // Obtén la hoja activa var hoja = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet(); // Obtén el rango de la columna A var rango = hoja.getRange("A:A"); var valores = rango.getValues(); // Variable para contar las filas vacías var filasVacias = 0; // Recorre las filas de abajo hacia arriba (para evitar problemas al eliminar filas) for (var i = valores.length - 1; i >= 0; i--) { if (valores[i][0] === "" && filasVacias < 1) { // Si hay una fila vacía, deja esta fila filasVacias++; } else if (valores[i][0] === "") { // Si la fila está vacía y ya hay una fila vacía, elimina la fila hoja.deleteRow(i + 1); // +1 porque las filas en Apps Script son 1-indexed } } } 1.2. ARCHIVOS PARA BASES DE DATOS Google Sheets tiene un límite de 10 millones de celdas por hoja de cálculo actualmente. Consulta el siguiente enlace: Google Sheets Best Practices. Si intentamos crear todas las tablas en hojas dentro de una única hoja de cálculo, podemos afectar el rendimiento y la organización de la información. En este protocolo, se recomienda utilizar una hoja de cálculo separada para cada base de datos. De este modo, cada hoja tendrá su propio límite de 10 millones de celdas, y cada hoja de cálculo se convertirá en una base de datos independiente con alta capacidad. Esto proporciona mayor flexibilidad, mejora el rendimiento y facilita la organización de los datos. 1.3. NOMENCLATURA Y ORGANIZACIÓN Todas las hojas de cálculo de cada aplicación o sección deben colocarse dentro de una carpeta contenedora con el mismo nombre que la aplicación o la sección (según se haya creado). El nombre del archivo de Google Sheets, el nombre de la hoja de cálculo y el nombre de la tabla dentro de hoja de cálculo deben coincidir (los tres deben ser iguales). Este nombre debe seguir estas reglas: Escrito en minúsculas, en formato snake_case. Plural y en inglés, independientemente del idioma del desarrollador. Sin caracteres especiales. Puede contener números, pero no debe comenzar con ellos. Debe expresar claramente el propósito de la tabla sin ambigüedades. Ejemplo, si creamos una tabla llamada categories, esto no nos dice mucho, ya que podrían ser categorías de impuestos, categorías de artículos, etc. Es necesario que el nombre sea específico:items_categories items_families items_types items_instances nutrients_categories nutrients_families nutrients_types 1.4 BASES DE DATOS Reglas: snake_case, minúsculas, en singular (salvo casos especiales que se detallarán) y en inglés, independientemente del idioma del desarrollador. Propósito claro y descriptivo. Preferentemente, máximo 27 caracteres para evitar nombres largos y poco manejables. Nombre de la carpeta contenedora de la base de datos en Google Drive: <app_name>_<app_section> (la sección es opcional).Nombre del archivo Google Sheets: <table_name>Nombre de la hoja de cálculo:<table_name> Nombre de la tabla dentro de la hoja de cálculo y en AppSheet:<table_name>Nombre de slices:<table_name>_<descriptor>He solicitado una funcionalidad nueva para el editor; un casillero que permita agregar un número para que podamos organizar nuestras tablas en el editor (por índice y no por orden alfabético a los fines de independizar el nombre de las tablas de su organización en el editor. Puedes votar esta solicitud aquí. 1.5 RECOMENDACIONES ADICIONALES Convertir en tabla: Se recomienda utilizar la opción "Crear tabla" en Google Sheets para poder aplicar filtros dentro de la base de datos. Proteger encabezados: Se recomienda usar la función "Proteger rango" en Google Sheets para evitar la eliminación o modificación accidental de los encabezados de las tablas. Congelar la fila del encabezado: Esto ayuda a mejorar la organización visual de los datos. Longitud del nombre: Aunque no es obligatorio, es recomendable que el nombre tenga menos de 27 caracteres para evitar complicaciones al escribir expresiones y asegurar que los nombres se vean correctamente en el editor sin ocupar varias líneas. Esto permitirá que la estructura de datos en Google Sheets funcione con muchas de las características de una base de datos tradicional. 1.6 NOMENCLATURA GENERAL DE CAMPOS Reglas: snake_case, minúsculas, en singular (salvo casos especiales que se detallarán) y en inglés, independientemente del idioma del desarrollador. Propósito claro y descriptivo. Preferentemente, máximo 20 caracteres para evitar nombres largos y poco manejables. Imagen de Tabla Ejemplo: 1.6.1. CAMPOS HABITUALES Son campos que se repiten habitualmente en muchas tablas: Nombre de campo Propósito Row ID Si usan AppSheet DataBase, este campo es automático y no necesita ser creado. Es el id de fila. No es visible de manera predeterminada en la base. Tenga en cuenta que cuando se migra la aplicación a otra base de datos debe tener sumo cuidado al usar otro campo como id. Aunque se copia sin problemas al migrar a Google Sheets, regresar a la base de datos de AppSheet puede generar conflictos con campos duplicados.Editable If' destildado por defecto. id Si usan Google Sheets, campo obligatorio, clave principal de tabla, siempre se llama "id" en minúsculas. Puede usar: UNIQUEID("UUID"), UNIQUEID("packedUUID"), UNIQUEID(). En casos específicos, como tablas con contenido constante y de solo lectura, pueden usarse otros valores en el campo id, como valores elegidos manualmente siempre que no se repitan.Editable If' destildado. _rowNumber Automático: Este campo se crea automáticamente en todas las tablas, numerando las filas. ia_<purpose> Opcional: es un campo virtual de tipo texto, vacío (con una fórmula como esta: ""), utilizado para señalar las 'acciones, generalmente en línea'. Habrá tantos campos como acciones se necesiten. created_at Opcional: Este campo almacena la fecha y hora en la base de datos. Configurar en Google Sheet un formato YYYY-MM-DD hh:mm:ss.DateTime, initial value UTCNOW(), reset on edit of. No editable. edited_at Opcional: Este campo almacena la fecha y hora en la base de datos. Configurar en Google Sheet un formato YYYY-MM-DD hh:mm:ss.DateTime, initial value UTCNOW(), reset on edit on. Editable on. created_by Opcional: Es típicamente el correo electrónico del usuario que inicia sesión en la aplicación, por lo que se utiliza USEREMAIL() en el espacio de valor inicial, no editable y reset on edit desmarcado. edited_by Opcional: Es típicamente el correo electrónico del usuario que inicia sesión en la aplicación, por lo que se utiliza USEREMAIL() en el espacio de valor inicial, editable, reset on edit marcado. 1.6.2. CAMPOS FORÁNEOS Ref: <singular_table/slice_name>_id Enum base Ref: <singular_table/slice_name>_id Enumlist base Ref: <singular_table/slice_name>_ids Suponiendo casos especiales en los que tenemos dos campos ref, enum de base type ref o enumlist de base type ref, que provienen de una misma tabla, en la tabla actual, no podemos nombrarlos iguales ya que generaría error. Para ello podemos solucionarlo del siguiente modo genérico: Al primer campo ref proveniente de una tabla podemos llamarlo: <singular_table/slice_name>_id Al segundo campo ref proveniente de una tabla podemos llamarlo <singular_table/slice_name>_<aditional_descriptor>_id/s 1.6.3. CAMPOS HEREDADOS El caso más común de campo heredado es una clave foránea. Como vimos anteriormente se nombran <singular_table/slice_name>_id Estos campos que se heredan en otras tablas tienen un nombre en su tabla origen; para campos diferentes a id heredado se tomará la siguiente convención: <singular_table/slice_name>_<field_name>, así, si un campo se llama “nature” en la tabla “categories”, en la tabla “types” se llamará “category_nature” dejando en claro que es un campo heredado de la tabla “categories”. 2. VISTAS 2.1. VISTAS - RESULTADO EDITOR Les dejo el resultado, después se los explico: 2.2. TIPOS DE VISTAS EN APPSHEET (CÓDIGO) En AppSheet, las vistas funcionan como la interfaz de usuario. Actualmente, existen 11 tipos de vistas (hasta 2025), pero es se ha adelantado que es probable que se agreguen más en el futuro. Un ejemplo muy solicitado es la vista Gantt Chart, que al parecer está en proceso de estudio y desarrollo.A continuación detallaré junto al tipo de vista, su código para la nomenclatura (en rojo) y el ícono que usaremos para cada vista ref (las vistas que se muestran al usuario directamente en el editor tendrán íconos que el desarrollador elija; solo hablamos de las vistas ref):Dependientes de una tabla Calendar (cl) icono "calendar-alt" regular Deck (dk) ícono "list-alt" regular Table (tb) ícono "table" regular Gallery (gl) ícono "th-large" regular Detail (dt) ícono "indent" regular Map (mp) ícono "map-marker-alt" regular Chart (ch) ícono "chart-pie" regular Form (fr) ícono "edit" regular OnBoard (ob) ícono "window-restore" regular Card (cd) ícono "portrait" regular Independientes de una tabla Dashboard (db) ícono "layer-group" regular 2.3. ESTRUCTURA DEL EDITOR DE VISTAS El editor de AppSheet organiza las vistas en cuatro secciones: Primary Navigation Contiene las vistas del panel principal de la app (no hay demasiado por opinar aquí). Menu Navigation Muestra las vistas accesibles desde el menú (no hay demasiado por opinar aquí). System Generated Son vistas creadas automáticamente por AppSheet para cada tabla. No se recomienda usarlas directamente. Referenced Views Un área desorganizada donde se almacenan todas las vistas referenciadas (Razón de ser de la convención de nomenclatura de vistas); véase a continuación. 2.4. REFERENCED VIEWS Similar a una bolsa con basura (porque eso es lo que percibo), no tienen organización alguna, está todo “tirado en la misma bolsa”. Resulta un enorme tedio ver las vistas allí sin si quiera disponer de un ordenamiento por tabla o por tipo de vista. En fin debido a esto es que he modificado la convención que nos va a permitir tener un editor limpio, ordenado, intuitivo y, aunque un poco críptico, el "app editor" es accesible al equipo de trabajo que conocerá la convención con lo cual no es tan "críptico" y, a decir verdad, la convención solo sirve para brindar un orden mientras AppSheet no genere un ordenamiento nativo para esta sección. Dicho sea de paso puedes votar esta idea haciendo clic en el enlace para que tome relevancia. Una vez que AppSheet organice esta sección, esta nomenclatura perderá automáticamente su efecto y podremos disfrutar de un ordenamiento nativo sin tener que volver al legacy editor. Para solucionar esto, propongo una convención de nombres que permitirá un editor limpio, ordenado e intuitivo, al menos hasta que AppSheet implemente un sistema de organización nativo. 2.5. MÉTODO DE ORGANIZACIÓN Uso del archivo “source_prefix_generator” Nuestro compañero propuso la creación de un archivo para documentar nombres de tabla en el viejo protocolo. Yo he tomado su idea como idea fuerza y he creado una app llamada appsheet_nomenclator . Esta app sirve para:✔ Generar prefijos estandarizados para nombrar vistas, acciones, bots y reglas de formatos, etc.✔ Llevar un registro de cambios en las estructuras de la app.✔ Facilitar la navegación dentro del editor. Le sugiero que copie la app y la use para darle nombre a sus elementos. 2.6. NOMENCLATURA DE VISTAS Nuestro compañero sugirió un ordenamiento de tabla basado en prefijos y tipos de vista, realmente fue interesante así que decidí tomar su idea como idea fuerza para esta nueva nomenclatura (aunque un poco modificada). Él comienza con números pero me he dado cuenta que al comenzar con números en el editor mientras estamos agregando expresiones, el cuadro de diálogo no se genera automáticamente con el popup de sugerencias, en cambio si iniciamos con letras si, automáticmente comienzan a desplegarse sugerencias filtradas, lo cual es más intuitivo en el desarrollo y aumenta la velocidad de escritura. Véanlo aquí mismo: La primera parte de la estructura del nombre tiene siempre la misma longitud y se visualiza de forma muy ordenada al punto que termina pasando desapercibida mientras el propósito se hace más reconocible.<view_type_code>_<view_prefix>_<view_purpose> ¿Cuál es la ventaja de usar prefijos numéricos en lugar de nombres completos? Si el nombre de tabla cambia, el nombre de vista no tiene porque hacerlo porque el prefijo es un id mientras que el nombre puede cambiar. Se hace todo mucho más simple de visualizar. Los nombres se acortan abruptamente, lo cual es más cómodo en el editor. Permite detectar vistas inutilizadas o duplicadas, rápidamente. 2.7. CASOS ESPECIALES: DASHBOARD El único tipo de vista que no sigue el formato de nombres basado en tablas es la vista Dashboard, ya que puede estar compuesta por dos o más tablas. Para estos casos, usamos un nombre representativo en minúsculas, siguiendo este formato: db_<purpose> Reglas: snake_case, minúsculas. El propósito debe ser un sustantivo claro y descriptivo. Preferentemente, máximo 30 caracteres para evitar nombres largos y poco manejables. 2.8. NOMBRES VISIBLES (Display Names) El nombre que verá el usuario en la interfaz debe ser insertado dentro de comillas en el campo Display Name, como una expresión, ya sea en vistas, acciones, campos, etc. 3. REGLAS DE FORMATO 3.1. NOMENCLATURA REGLAS DE FORMATO: f_<table_prefix>_<purpose> Ejemplo: f_008_blank_children Indica que es una regla de formato aplicada a la tabla con prefijo 008, para manejar filas sin hijos. Reglas: snake_case, minúsculas. Máximo 23 caracteres. El propósito debe ser claro y descriptivo. 4. ACCIONES DE COMPORTAMIENTO 4.1 ACCIONES GENERADAS POR EL SISTEMA Las acciones autogeneradas reciben un nombre por defecto. Algunos ejemplos son: Add Delete Edit Compose Email (User ID) View Ref (TABLE) Estos nombres son consistentes en todas las tablas y no deben ser modificados. 4.2. ACCIONES PERSONALIZADAS Para las acciones que creamos manualmente, usaremos el archivo "source_prefix_generator". Primero les muestro el resultado, seguidamente les explico: Como pueden ver, las acciones ya están organizadas por tabla, en el caso de la imagen anterior, organizadas bajo la tabla “items_types”, lo que garantiza que la primera parte del nombre tenga siempre la misma longitud y proporcione una mejor visualización del propósito de la acción. Ahora, ¿por qué es necesaria esta convención estando ya organizada de forma nativa por tabla? Porque AppSheet no nos permite usar el mismo nombre para acciones en tablas diferentes. Si creásemos una acción llamada “update” en una tabla y luego otra con el mismo nombre en otra tabla, AppSheet la renombrará automáticamente como “update 2”, lo que genera inconsistencias en la nomenclatura. Nótese que este problema no ocurre con las acciones generadas por el sistema, ya que AppSheet les da el mismo nombre en todas las tablas; es decir, no existe Add 1, Add2, Add n. Por eso, hasta que AppSheet permita que las acciones creadas manualmente puedan compartir el mismo nombre si están en tablas distintas, esta convención nos ayuda a mantener el orden y evitar inconsistencias en nuestras apps. He creado un tópico para que AppSheet implemente esta mejora, puedes votar aquí para que esta limitación desaparezca en el futuro. Cuando esto ocurra, nuestra convención dejará de ser necesaria y el desarrollo será más simple. 4.3. CÓDIGO DE ACCIÓN (action_code) Existen cuatro conjuntos principales de acciones de comportamiento en AppSheet: ACCIONES CÓDIGO Application a Data d External e Grouped g Cada set contiene acciones específicas: 7 Application Actions 4 Data Actions 5 External Actions 1 Grouped Action 4.3.1. Acciones de Aplicación (a) A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta" Copiar esta fila y editarla → (a1): "clone" icon Editar esta fila → (a2): "edit" regular icon Exportar esta vista a un archivo CSV (no es una acción a nivel de fila) → (a3): "fiie-csv" regular icon Ir a otra app de AppSheet → (a4): "rocket"-regular icon Ir a otra vista dentro de esta app → (a5): "chevron-circle-right" black icon Importar un archivo CSV para esta vista (no es una acción a nivel de fila) → (a6): "fiie-csv" black icon Abrir un formulario para agregar una nueva fila a esta tabla (no es una acción a nivel de fila) → (a7): "plus" regular icon 4.3.2. Acciones de Datos (d) A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta" Agregar una nueva fila a otra tabla usando valores de esta fila → (d1): "layer-plus" light icon Eliminar esta fila → (d2): "trash-alt" solid icon Ejecutar una acción en un conjunto de filas → (d3): "table" light icon Establecer valores en algunas columnas de esta fila → (d4): "slider-h" regular icon 4.3.3. Acciones Externas (e) A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta" Ir a un sitio web → (e1): "browser" regular icon Abrir un archivo → (e2): "folder-open" regular icon Iniciar una llamada telefónica → (e3): "phone" regular icon Iniciar un mensaje de texto → (e4): "envelope" regular icon Iniciar un correo electrónico → (e5): "comment-alt-lines" regular icon 4.3.4. Acción Agrupada (g) A continuación las acciónes del set "Aplicación" con su código y su ícono sugerido para aquellas con condición "oculta" Ejecutar una secuencia de acciones → (g1): "list-ol" regular icon Esta convención de código (action_code) facilita la organización y referencia rápida de las acciones en AppSheet, mejorando la claridad y eficiencia en el desarrollo de aplicaciones. 4.4. NOMENCLATURA PARA ACCIONES <action_code>_<source_table_prefix>_<destination_table_prefix>_<action_purpose Si la acción se aplica en una sola tabla, tanto la tabla origen como la tabla destino usará el mismo prefijo. Reglas: snake_case, minúsculas. El propósito debe ser un sustantivo claro y descriptivo. Preferentemente, máximo 30 caracteres para evitar nombres largos y poco manejables. 5. BOTS 5.1. CONVENCIÓN DE NOMBRES PARA BOTS bot_<table_prefix>_<purpose> Ejemplo:bot_018_adder Este bot pertenece a la tabla con prefijo 018 y su propósito es agregar filas. Reglas: snake_case, minúsculas. El propósito debe ser un sustantivo claro y descriptivo. Preferentemente, máximo 27 caracteres para evitar nombres largos y poco manejables. 5.2. CONVENCIÓN DE NOMBRES PARA EVENTOS Los eventos en AppSheet se generan cuando ocurre alguna de estas situaciones: Tipo de Evento Código Evento en la aplicación app AppSheet database adb Cambio programado (Tiempo) sch Aplicación de Chat cha Google Forms gfr Gmail gml Formato de nombre de eventos: event_<table_prefix>_<event_type_code>_<n_order_number> Ejemplo: event_008_app_1 Indica que es un evento en la tabla 008, de tipo app (evento en la aplicación), con un índice 1.Si se crean múltiples eventos similares, se incrementa el número (_2, _3, etc.) para evitar conflictos. 5.3. CONVENCIÓN DE NOMBRES PARA PASOS (STEPS) En el resto del editor usamos una nomenclatura codificada pero en este caso vamos a usar una nomenclatura intuitiva. Los steps se ordenan como lo que son, una secuencia de pasos lógicos ordenados cuya finalidad es resolver un problema (es decir, un algoritmo). Es muy interesante ver cómo se ven los pasos de un proceso cuando su nomenclatura es clara y entendible. Aquí les dejo un ejemplo visual:Los procesos ejecutan pasos (steps) en secuencia, que pueden incluir: Ejecutar una tarea Ejecutar una acción sobre los datos Dividir la ejecución con una condición Esperar Llamar a un proceso Devolver valores Reglas: snake_case, minúsculas. Propósito corto, claro y descriptivo. Preferentemente, máximo 21 caracteres para evitar nombres largos y poco manejables. Ejemplo: "generate_invoice" Proceso que genera una factura. 5.4. BOTS - ÍCONOS Se recomienda mantener el ícono del bot por defecto. El propósito del bot define su función, pero el ícono ayuda a identificarlo visualmente en el editor. Esta convención garantiza orden, claridad y escalabilidad en el desarrollo de aplicaciones en AppSheet.

MultiTech

@Gustavo_Eduardo wrote:

Because “A” is the initial of “action”

🤓 Makes sense!

Gustavo_Eduardo

🙌

yasarcan

hi Did it happen?

(PII Removed by Staff)

Gustavo_Eduardo

I don't understand you

eldderri

@Gustavo_Eduardo ,

How about the number of tables allowed in Appsheet Database.I am now using Appsheet database in my app which may contain big data (more tha, 1000 records per month) and I am stuck at the limitation of 20 tables per database.I need to add some other tables .How to overcome this problem or shall I use Google sheets ? In case I use google sheet , shall I use separate spreadsheets?

Gustavo_Eduardo

Dear friend, I'm creating a post similar to this one but with a focus on performance. I understand you use the AppSheet database, and in my opinion, it works (up to a certain point) despite its limitations, but it's advantageous due to its benefits. So, as a piece of advice from me, I'd say use the database in certain cases, and for more complex tables with significantly more rows, use Google Sheets (if you don't have access to SQL or Postgres).

Let's get to what I do and what I believe is best. You can use the AppSheet database to manage users, interface views, and tables with few rows but that require more frequent synchronization. Google Sheets allows for a larger limit and isn't faster than the AppSheet database or SQL, but it's very flexible. My advice is not to be absolute in this case but rather to find the richness of all worlds. In fact, some databases on the market charge per query (imagine putting everything in the same database, even those tables that don't need much speed). You'd quickly go over budget.

And regarding huge apps (I would change the approach), instead of making one huge app, I would look for ways to create smaller apps with modules based on roles. But well, that's your decision. Both approaches will have their pros and cons, but when I publish what I'm doing, you'll see the benefits. Thanks for writing.

eldderri

In my case , I am making an app for three departments in my company and this app may be generalized through 3 companies.The app database tables may reach a number of 25 tables as each department has its different database structure.One of them may have a cloud source database.What do you suggest as database protocol in my case?

Gustavo_Eduardo

Basically—and unfortunately—this isn’t really a matter of suggestion or not when it comes to protocol. The database is something very personal, and in the end, it’s nothing more than a data warehouse.

If you ask me, I would create one database per department and one app per department. The department-specific tables of an app would be editable within that app and read-only for other departments. I’d also have a general database to store things like user management and interface data, for example.

But more than suggesting how to structure databases, this protocol is about suggesting nomenclature. In another post, I’ll go deeper into performance and architecture.

yasarcan

hi. I formulated the topic you described. I shared the excel link but I guess it was not allowed.

Gustavo_Eduardo

Sure, but I still don't understand. Could you explain a little more?

yasarcan

table name ; to define table names.

Gustavo_Eduardo

Ah, what I understand is that you created a table where you write the table names and they are stored there?

Gustavo_Eduardo

That's an excellent idea, I hadn't thought of it. If you allow me, of course, I'll mention you in the next update of the protocol (I'm gathering enough things to be able to do it). I'll add this idea as part of the protocol since it helps users avoid errors in nomenclature. I congratulate you on your work and I hope you'll continue to contribute your ideas since, from what I see, you've grasped the essence of this protocol. Surely you've benefited. Thanks again, my friend.

yasarcan

I'm glad I could explain. Sorry for my bad english. 🙂

Gustavo_Eduardo

Don't worry about your English. A tip: if you don't know how to explain something, explain it in your language and copy it into Gemini. Ask it to translate it, and then paste it into English. That way you won't have any problems! Best regards, and thanks again. Great contribution.

Gustavo_Eduardo

Followers of this post, I've read your comments and reworked the protocol. The day has arrived, and I've completed this enormous task. For now, I'm sharing two versions: English and Spanish. If you'd like an additional language, I'll see if I can translate it (it's up to you). This is the final version of the protocol using the current AppSheet editor. The previous version has been deprecated.

To view the content, you can click on the collapsible accordions.

ChristianLi

You're a legend @Gustavo_Eduardo !! 🙌

Gustavo_Eduardo

Chris! Thank you so much for your amazing comment. I've put a lot of effort into this and really wanted to share it with you all. Thanks a lot, my friend!! Whatever you need, just give me a shout.

Gustavo_Eduardo

Important Update to the Naming Protocol:

I’d like to share a small but meaningful improvement I’ve made in my development workflow.

👉 Previously, I used to manually rename the folders that AppSheet automatically creates inside appsheet/data in Google Drive.
I did this to align with my custom naming convention using snake_case.

🔄 However, after reviewing the implications and the value of the App ID, I’ve decided to leave the folder names as they are by default, like: AppName-123456.

Why?

That name includes the app’s unique and permanent ID, which matches CONTEXT("AppName").
It avoids confusion between the app’s visible name and its technical identifier.
It allows for clean mapping between app ↔ folder ↔ database ↔ logs.
It simplifies collaboration and auditability in team environments.
Even if it's not visually “pretty,” it’s standardized, clean, and sustainable in the long run.

📝 This change is now part of the AppSheet Naming Protocol, and it will be included in the full guide I’ll be sharing with the community.

Thanks to everyone who's been following this journey — we continue refining the details to build more solid, efficient, and professional apps. 🚀

yasarcan

thank you

Gustavo_Eduardo

you're welcome friend

Gustavo_Eduardo

Friends, I've updated the post for deleting blank rows. Please use it with extreme caution as I haven't tested it enough yet, but it's faster and more efficient than the last one I had because this one deletes everything in batch and always leaves one blank row (since if you use a table, you must have at least one row). Aquí también les dejo el link para que no tengan que buscarlo en el protocolo.

Gustavo_Eduardo

📱APPSHEET NAMING PROTOCOL APP

Friends, I'm sharing 01_appsheet_nomenclator, an app I created to help manage AppSheet apps—mainly focused on naming the components we create in our apps, following this naming protocol. You can copy it; here's the link.

I hope you find it useful.

I also want to let you know that I've made some updates to the protocol based on things I learned during the process—especially about the relationships between elements when building apps. For example, there are system bots and table bots, system events and table events, system processes and table processes. I've also corrected inconsistencies in the naming conventions for bot steps and process steps, which are not the same. The app will guide you through it.

The only thing you'll need to do is translate it, since I built it in Spanish—but the good news is that the database columns are already in English, just as described in the protocol.

In this case, since it is an example app, I have given it this name since I need the folder in my directory to be organized, but it is not a practice that I recommend in the protocol.

In a few days, I'll update the protocol, but don't worry. Basically, there's an issue with the previous naming convention that I've resolved in this case. When we work with many apps, it's normal for some applications to access a single database. This meant that with the old naming convention, the same source had to be named twice when it was actually just one. Now, the schema has been greatly simplified, and we no longer have to use that very basic source_prefix_generator we used in Google Sheets. This app also serves to manage system apps, which will save you enormous steps in production.

I also plan to create a functionality (but this is for the future, I'm not promising it now) that prevents creating two identical elements in the same context but with different names. Why? To avoid creating redundant elements and promote their reuse.

Without further ado, I hope this is helpful, and I'll be listening for any feedback to correct any errors (in all honesty, I haven't tested it extensively).

Gustavo_Eduardo

This protocol is, as many of you know, constantly evolving. Why? Because daily hands-on work keeps teaching me new things, which I document here—particularly regarding naming conventions. Today, it's time for a small but important update: renaming two columns and adding a new one.

user_id will be renamed to created_by to avoid ambiguity—especially in cases where the user might be an admin.
created_at keeps its name but will undergo a change in how it functions or is handled.
Two new columns, edited_by and edited_at, are being added with a clear purpose.

For details, please refer to the column table in the protocol.

yasarcan

Hi ,

I recently moved some tables from the application's database to a different email account for security reasons. To make this clear at a glance, I adjusted their naming convention.

Meta_o_.... (.....@otono.....)

......

Meta_df_.... (.....@dijitalfa.....)

maybe it will be useful to someone.

Gustavo_Eduardo

Please, my friend, expand, it is not well understood and this could be very useful.

yasarcan

Merhaba. Türkçe yazayım. Tüm tabloları a mailinin içinde barındırıyorum. Ancak kullanıcıların yetkilerini verdiğim tabloyu güvenlik için başka adrese taşıdım. bunu anlamak içinde hangi adrese taşıdıysam tablonun adına mailin harfini verdim. Bu sayede tasarım devam ederken kafam karışmıyor

Gustavo_Eduardo

Anlıyorum. Yani uygulamalarının, başka kullanıcıların hesaplarında barındırılan tabloları kullandığını söylüyorsun. Şahsen ben hiç bu şekilde çalışmadım.

Eğer bu metodoloji senin için işe yarıyor ve yönetimin için faydalıysa, bana geçerli bir çözüm gibi görünüyor! Ancak, uygulamam harici kaynaklardan besleniyorsa, bu kaynakların kendi orijinal yerlerinde barındırılmasını tercih ederim. Barındırma bana aitse (sahibi olarak), daha birleşik bir kontrol için tüm tabloları kendi kullanıcıma bağlı tutmayı tercih ederim.

yasarcan

Evet sorunsuz çalışıyor.

Gustavo_Eduardo

Önerinizi mevcut bağlamda görebilmemiz için bir ekran görüntüsü alabilirseniz çok iyi olur (lütfen e-posta alan adını kaldırın)!

yasarcan

Erp uygulamada görevlendirme df kısaltması ile "dijitalfabrika" mailine bağlı. Ama uygulama ve tüm veritabanları "otomasyona" bağlı

Gustavo_Eduardo

Harika, görüyorum ki adlandırma protokolünü etkilemiyor çünkü "snake_case" olarak yazılmış. Hatta protokolü değiştirmeye bile gerek yok çünkü "df" (senin durumunda) bir tablo "tanımlayıcısı". Bana göre biraz gizemli, çünkü sadece sen anlıyorsun, ama uygulamanın yöneticisi sen olduğun sürece bunda bir sakınca yok. Dünya genelindeki standart kurallar, özellikle veritabanı alanları için tanımlayıcı isimler önerir. Vurgulamak istediğim şey, ismin protokol dahilinde olduğudur.

Appsheet Standard Naming Protocol

(En) AppSheet Naming Standard Protocol

INTRO

1. DATA

1.1. GOOGLE SHEETS AS DATABASES

1.2. FILES FOR DATABASES

1.3. NAMING AND ORGANIZATION

1.4 DATABASES (Structure/Naming Summary)

1.5 ADDITIONAL RECOMMENDATIONS

1.6 GENERAL FIELD NAMING

1.6.1. COMMON FIELDS

1.6.2. FOREIGN KEY FIELDS

1.6.3. INHERITED FIELDS

2. VIEWS

2.1. VIEWS - EDITOR'S RESULT

2.2. VIEW TYPES IN APPSHEET (CODE)

2.3. VIEW EDITOR STRUCTURE

2.4. REFERENCED VIEWS

2.5. ORGANIZATION METHOD

2.6. VIEW NAMING

2.7. SPECIAL CASES: DASHBOARD

2.9. DISPLAY NAMES

3. FORMAT RULES

3.1. FORMAT RULE NAMING

4. BEHAVIOR ACTIONS

4.1 SYSTEM-GENERATED ACTIONS

4.2. CUSTOM ACTIONS

4.3. ACTION CODE(action_code)

4.3.1. Application Actions (a)

4.3.2. Data Actions (d)

4.3.3. External Actions (e)

4.3.4. Grouped Action (g)

4.4. NAMING FOR ACTIONS

5. BOTS

5.1. NAMING CONVENTION FOR BOTS

5.2. NAMING CONVENTION FOR EVENTS

5.3. NAMING CONVENTION FOR STEPS

5.4. BOTS - ICONS

(Es) Protocolo de Nomenclatura Estándar AppSheet

INTRO

¿QUÉ ES UN PROTOCOLO ESTÁNDAR?

1. DATOS

1.1. GOOGLE SHEETS - BASES DE DATOS

1.2. ARCHIVOS PARA BASES DE DATOS

1.3. NOMENCLATURA Y ORGANIZACIÓN

1.4 BASES DE DATOS

1.5 RECOMENDACIONES ADICIONALES

1.6 NOMENCLATURA GENERAL DE CAMPOS

1.6.1. CAMPOS HABITUALES

1.6.2. CAMPOS FORÁNEOS

1.6.3. CAMPOS HEREDADOS

2. VISTAS

2.1. VISTAS - RESULTADO EDITOR

2.2. TIPOS DE VISTAS EN APPSHEET (CÓDIGO)

2.3. ESTRUCTURA DEL EDITOR DE VISTAS

2.4. REFERENCED VIEWS

2.5. MÉTODO DE ORGANIZACIÓN

2.7. CASOS ESPECIALES: DASHBOARD

2.8. NOMBRES VISIBLES (Display Names)

3. REGLAS DE FORMATO

3.1. NOMENCLATURA REGLAS DE FORMATO:

4. ACCIONES DE COMPORTAMIENTO

4.1 ACCIONES GENERADAS POR EL SISTEMA

4.2. ACCIONES PERSONALIZADAS

4.3. CÓDIGO DE ACCIÓN (action_code)

4.3.1. Acciones de Aplicación (a)

4.3.2. Acciones de Datos (d)

4.3.3. Acciones Externas (e)

4.3.4. Acción Agrupada (g)

4.4. NOMENCLATURA PARA ACCIONES

5. BOTS

5.1. CONVENCIÓN DE NOMBRES PARA BOTS

5.2. CONVENCIÓN DE NOMBRES PARA EVENTOS

5.3. CONVENCIÓN DE NOMBRES PARA PASOS (STEPS)

5.4. BOTS - ÍCONOS

4.3. ACTION CODE(`action_code`)

4.3.1. Application Actions (`a`)

4.3.2. Data Actions (`d`)

4.3.3. External Actions (`e`)

4.3.4. Grouped Action (`g`)

4.3. CÓDIGO DE ACCIÓN (`action_code`)

4.3.1. Acciones de Aplicación (`a`)

4.3.2. Acciones de Datos (`d`)

4.3.3. Acciones Externas (`e`)

4.3.4. Acción Agrupada (`g`)