Google AppSheet

Google AppSheet permite crear aplicaciones y automatizaciones mediante herramientas sin código. Utiliza datos y reglas de trabajo para construir interfaces que pueden facilitar la consulta o recogida de información en procesos concretos.

En pocas palabras

Aplicaciones y programación

Web oficial

Contenido
  1. Qué es AppSheet
  2. Fundación, inversión y adquisición por Google
  3. Fuentes de datos y bases nativas
  4. Claves y relaciones entre registros
  5. Vistas, formularios y captura móvil
  6. Expresiones, cálculos y columnas virtuales
  7. Bots, procesos y seguimiento de ejecuciones
  8. Gemini: creación de apps e IA en procesos
  9. Identidad, filtros y gobierno de aplicaciones
  10. Rendimiento, versiones y despliegue
  11. Licencias, usuarios y coste de mantenimiento
  12. Adopción documentada y lectura de casos
  13. Aplicaciones en seguridad y salud en el trabajo
  14. Ejemplo desarrollado y comprobaciones
  15. Limitaciones y condiciones de uso
  16. Cómo elegir y complementar la herramienta
  17. Preguntas frecuentes
  18. Fichas relacionadas
  19. En el blog de Sabentis
  20. Fuentes y documentación

Volver a Herramientas

Qué es AppSheet

AppSheet es la plataforma de Google para crear aplicaciones y automatizaciones sin programación convencional. Combina datos estructurados, interfaces configurables y reglas de proceso. Se integra con Google Workspace y admite fuentes externas, por lo que su utilidad no se limita a convertir una hoja de Google en un formulario.

El enfoque es declarativo: el creador define los datos, las condiciones y el comportamiento deseado. Sigue siendo necesario diseñar el proceso. Una aplicación puede resultar sencilla de construir y difícil de mantener si mezcla datos maestros, solicitudes y resultados sin explicar qué representa cada registro.

Para valorar una propuesta, identificar primero la interacción que se quiere mejorar: consultar una información vigente, capturar una observación o pedir un material. Después se decide cómo se presenta, quién puede intervenir y qué evidencia confirma que el trabajo se ha completado.

Documentación de referencia: AppSheet product overview.

Fundación, inversión y adquisición por Google

AppSheet fue fundada en 2014 por Praveen Seshadri y Brian Sabino. NEA registra su primera inversión, de fase semilla, en 2015. El proyecto abordaba una necesidad habitual: aprovechar datos empresariales existentes para crear aplicaciones móviles sin encargar cada interfaz a un equipo de programación.

En mayo de 2018 AppSheet anunció Spec, una función para describir aplicaciones mediante lenguaje natural. Google anunció la adquisición el 14 de enero de 2020 y su incorporación a Google Cloud. La construcción asistida actual debe entenderse dentro de esta evolución, sin confundir Spec con las funciones presentes de Gemini.

Esta trayectoria explica dos rasgos del producto: su proximidad al modelo de hojas y tablas, y su ampliación hacia automatización y administración empresarial. Para seguir un tutorial antiguo conviene comprobar el editor, la licencia y la función concreta, porque las capturas y nombres pueden haber cambiado.

Documentación de referencia: AppSheet announces Spec, May 2018 · NEA investment record: AppSheet · Google acquires AppSheet, January 2020.

Fuentes de datos y bases nativas

AppSheet admite Google Sheets, Excel, bases SQL y servicios como Salesforce, además de sus propias bases de datos. Puede combinar tablas procedentes de distintas fuentes. La documentación diferencia conexiones disponibles de Integration Connectors en versión preliminar; una tabla incorporada desde Google Forms es de solo lectura.

Las bases nativas de AppSheet permiten organizar datos dentro del servicio sin preparar una hoja externa. La elección de almacenamiento debería considerar volumen, relaciones, responsables y otras aplicaciones que necesitan acceder a la misma información.

En un catálogo de materiales, separar la descripción del recurso de las solicitudes que lo utilizan. Evitar que una corrección de título borre el rastro de lo que se pidió. Identificar una fuente principal para cada dato reduce discrepancias entre aplicaciones auxiliares y el registro operativo reconocido.

Documentación de referencia: Manage data sources · What is an AppSheet database?.

Claves y relaciones entre registros

Una clave identifica de forma única una fila y debe permanecer estable. AppSheet desaconseja utilizar el número de fila como identificador: al mover o eliminar registros puede cambiar. Las claves duplicadas pueden provocar que una actualización actúe sobre una fila incorrecta.

Esta cuestión resulta decisiva al pasar de una hoja informal a una aplicación compartida. El nombre de un centro puede corregirse, pero su identidad no debería cambiar con la ortografía. Las solicitudes deberían referenciar esa identidad y mostrar una etiqueta comprensible para la persona usuaria.

Antes de importar datos, revisar duplicados, valores vacíos y relaciones rotas. Un ejercicio útil consiste en renombrar un material de prueba y comprobar que las solicitudes anteriores siguen apuntando al mismo recurso. La calidad de la interfaz no compensa una identificación ambigua.

Documentación de referencia: What is a key?.

Vistas, formularios y captura móvil

El catálogo de vistas incluye tabla, ficha, formulario, calendario, mapa, gráfico y panel que reúne varias vistas. Los formularios pueden recoger texto, fotografías, ubicación y firmas. La captura NFC requiere un dispositivo móvil compatible; el botón de lectura no aparece en el navegador.

Elegir la vista según la pregunta de la persona. Un mapa ayuda a localizar centros; una tabla facilita comparar recursos; un formulario guía una petición. Una pantalla que intenta mostrar todo a la vez puede dificultar una tarea breve en campo.

En una campaña de SST, la fotografía debería tener una finalidad explicada y un contexto reconocible. Una imagen aislada no demuestra cuándo se resolvió una situación ni quién validó el resultado. Del mismo modo, un trazo capturado como firma no acredita por sí mismo la identidad ni la comprensión de un documento.

Documentación de referencia: View types · Form view type · Use NFC scanning.

Expresiones, cálculos y columnas virtuales

Las expresiones permiten consultar valores y referencias entre tablas. Una columna virtual calcula un resultado mediante una fórmula sin corresponder a una columna física de la fuente. Su cálculo puede tener un coste de rendimiento cuando se acumulan muchas columnas o expresiones complejas.

Conviene distinguir un dato capturado de una interpretación calculada. La fecha de solicitud es un hecho; la etiqueta «pendiente desde hace varios días» depende de una regla y del momento de consulta. Conservar esa diferencia ayuda a explicar por qué una vista cambia sin que se haya editado la solicitud.

Probar las reglas con casos normales, vacíos y límites. Para cantidades, acordar unidades y decimales. Para fechas, decidir qué ocurre al cambiar de día o de zona horaria. Esas decisiones deberían documentarse con ejemplos comprensibles, no quedar ocultas en una fórmula extensa.

Documentación de referencia: Column value expressions · Use virtual columns.

Bots, procesos y seguimiento de ejecuciones

Un bot vincula un evento con un proceso y sus tareas. Puede actualizar registros, emitir notificaciones o llamar a un servicio mediante webhook. El monitor permite revisar ejecuciones, errores y actividad; algunas funciones no se ejecutan plenamente con una cuenta gratuita aunque puedan configurarse.

Diseñar una automatización exige definir qué cuenta como cambio relevante. Si una solicitud se corrige tres veces, decidir si debe generar tres avisos o mantener una única conversación. El mensaje debería incluir un identificador y enlazar al registro autorizado para evitar copias contradictorias.

Una prueba debe seguir el recorrido completo: evento recibido, condición evaluada, acción ejecutada y resultado comprobado en destino. Un aviso enviado no significa que alguien lo haya leído. Para tareas que requieren respuesta, definir responsable, plazo y forma de registrar la resolución.

Documentación de referencia: Bots: The Essentials · Monitor your apps.

Gemini: creación de apps e IA en procesos

Gemini for App Creation propone tablas, columnas y una aplicación a partir de una descripción. Se incluye en licencias AppSheet de pago. Gemini in AppSheet Solutions añade tareas de extracción o clasificación a automatizaciones con Enterprise Plus y consumo de créditos. Son usos diferentes de la IA.

La descripción inicial debería indicar una tarea, datos necesarios, personas que intervienen y resultado esperado. Una propuesta de tablas puede servir como borrador, pero no determina por sí misma una estructura adecuada ni los permisos correctos.

Para extraer información, conservar el documento de origen y comprobar campos críticos antes de utilizarlos. En SST, una clasificación automática puede facilitar una revisión posterior; no debería transformarse sin validación en una evaluación de riesgos o en autorización de una actividad. Registrar correcciones ayuda a reconocer errores repetidos del proceso.

Documentación de referencia: Use Gemini in AppSheet.

Identidad, filtros y gobierno de aplicaciones

AppSheet distingue autenticación, acceso a la aplicación, acceso a datos y auditoría. Los filtros de seguridad limitan los registros descargados; un slice organiza una selección después de descargarlos. Ocultar una vista no sustituye una política de acceso a la información.

Las políticas de organización pueden restringir fuentes externas, uso de bases AppSheet, API o funciones de IA. La configuración debería responder al contexto: un catálogo público de materiales tiene necesidades diferentes de una aplicación interna con datos de personas.

Probar al menos tres perfiles: administrador, usuario autorizado y usuario sin acceso. Comprobar tanto lo visible como las modificaciones permitidas. El procedimiento de baja debe contemplar dispositivos, cuentas y aplicaciones compartidas. La persona que mantiene el contenido no tiene por qué disponer de todos los permisos técnicos.

Documentación de referencia: Security: The Essentials · Scale using security filters · Predefined governance policy templates.

Rendimiento, versiones y despliegue

La capacidad de una app depende también de la fuente de datos, no únicamente de la infraestructura de AppSheet. Para una actualización importante, la documentación propone trabajar sobre una copia, probarla y realizar la comprobación de despliegue antes de sustituir la versión utilizada.

Medir con un volumen representativo: tiempo hasta poder consultar, espera al guardar y duración de la sincronización. Una demostración con diez filas no permite estimar el comportamiento de un catálogo con años de solicitudes. Incluir teléfonos y conexiones parecidos a los que se usarán en campo.

Documentar quién mantiene tablas, reglas y acceso. Antes de retirar una versión, comprobar qué usuarios continúan utilizándola y cómo conservar los registros necesarios. La continuidad depende también de que otra persona pueda comprender el diseño y resolver incidencias ordinarias.

Documentación de referencia: App performance: Core concepts · Upgrade an app.

Licencias, usuarios y coste de mantenimiento

El catálogo incluye Starter, Core, Enterprise Plus y Publisher Pro para acceso público. Algunas ediciones de Workspace incorporan Core. User Pass utiliza un fondo de licencias: cada usuario elegible consume una por aplicación utilizada y puede acceder a ella durante ese mes.

Calcular el alcance con usuarios reales, externos incluidos, y comprobar el nivel requerido por la aplicación. Un prototipo gratuito no demuestra que todas sus automatizaciones funcionen en producción ni que se pueda distribuir sin coste.

El coste operativo también incluye diseño, soporte, revisión de permisos, conservación de datos y adaptación a cambios. Comparar ese esfuerzo con mantener un formulario sencillo o utilizar una capacidad ya existente. La rapidez inicial es valiosa cuando conduce a una solución sostenible.

Documentación de referencia: How to choose a subscription · Allow app access with AppSheet User Pass.

Adopción documentada y lectura de casos

El caso de Globe Telecom publicado por Google describe un programa de creación interna que pasó de 59 aplicaciones durante un hackathon a 350, con usos como mantenimiento de estaciones y auditoría. Es un relato del proveedor sobre ese despliegue, no una estimación aplicable a cualquier organización.

Para valorar un caso, preguntar qué tarea se sustituyó, qué datos existían, cuánto acompañamiento recibió el equipo y cómo se midió el resultado. Una reducción de tiempo no describe por sí sola calidad, estabilidad o aceptación por las personas usuarias.

En un piloto propio, elegir una interacción frecuente y limitada. Medir correcciones, peticiones incompletas y tiempo hasta su resolución, además del tiempo de captura. Comparar con el proceso anterior usando definiciones iguales y conservar ejemplos que permitan explicar los resultados.

Documentación de referencia: Globe Telecom customer case.

Aplicaciones en seguridad y salud en el trabajo

En SST puede apoyar la organización de actividades sencillas, como consultar recursos aprobados o recoger necesidades de materiales por centro. La utilidad depende de diseñar una tarea bien delimitada y de mantener una fuente de información clara, evitando que varias aplicaciones creen versiones distintas del mismo registro preventivo.

Un escenario propuesto por Sabentis es consultar materiales aprobados en un centro con conectividad intermitente y registrar solicitudes para revisión posterior. Otro es recoger preferencias de idioma y formato para organizar una campaña. También puede mostrar recursos vigentes por centro. En estos usos, conviene separar el estado local de una petición del estado confirmado por el equipo que la recibe, evitando expectativas de atención inmediata.

Ejemplo desarrollado y comprobaciones

Por ejemplo, una aplicación podría mostrar el catálogo vigente de materiales de una campaña y permitir solicitar ejemplares en un idioma concreto. Las solicitudes se revisarían antes de prepararse y quedarían vinculadas al material y centro correspondientes.

  1. Preparar un catálogo con identificador, título, idioma, versión y estado vigente; vincular las solicitudes a esos identificadores.
  2. Configurar quién consulta el catálogo y quién puede modificarlo, verificando acceso con usuarios de prueba.
  3. Abrir la aplicación con conexión y comprobar que se descargan los datos y, si se necesitan, los archivos.
  4. Desconectar el dispositivo, crear una solicitud y verificar que queda claramente pendiente de sincronizar.
  5. Reconectar y comprobar el registro en la fuente, su identificación y ausencia de duplicados.

Después, modificar un material en la fuente y comprobar cuándo se actualiza en el dispositivo. Probar también dos usuarios que actúan sobre un mismo registro. El resultado aceptable es conocer qué versión se consultó y si la petición llegó; no basta con que el formulario permita pulsar guardar. Las pruebas deben hacerse con datos ficticios y sin mezclar solicitudes de ensayo con pedidos reales.

Limitaciones y condiciones de uso

El enfoque sin código no elimina los riesgos de una configuración incorrecta. Deben probarse permisos, sincronización y reglas de datos, especialmente en uso móvil; no conviene atribuir a una aplicación creada rápidamente fiabilidad suficiente para autorizar trabajos o registrar decisiones clínicas.

El uso sin conexión requiere una primera apertura con conexión y configuración de caché para archivos. Guardar localmente y completar la sincronización son resultados distintos. Preparar y probar el dispositivo antes de utilizarlo en campo.

Documentación de referencia: Offline and Sync: The Essentials.

Cómo elegir y complementar la herramienta

Elegir AppSheet cuando se necesita una interfaz de consulta o captura sobre datos estructurados y hay responsables capaces de mantener sus reglas. Google Sheets puede servir de fuente en un proceso acotado, con control de edición; Power Apps ofrece otra opción del catálogo cuando predomina el ecosistema Microsoft. Comparar identidad, fuentes y sincronización, no solo rapidez de creación.

Antes de ampliar el uso, definir soporte, recuperación y retirada de versiones antiguas. Una aplicación auxiliar debe tener un propietario claro y una fuente reconocida; si cada centro mantiene su copia, la comodidad del formulario puede ocultar divergencias de contenido.

Preguntas frecuentes

¿Guardar sin conexión equivale a entregar la solicitud?

No. El cambio puede estar solo en el dispositivo hasta completar la sincronización.

¿Un slice protege información confidencial?

No por sí solo. Filtra la presentación de datos ya descargados; los controles de seguridad requieren otro diseño.

¿Ver un PDF significa que estará disponible offline?

No. Hay que configurar la caché compatible y probar la disponibilidad después de desconectar realmente el dispositivo.

Solicita una demo

Descubre todo lo que Sabentis puede hacer por tu organización.

Prueba Sabentis

request a demo
stars 5
GetApp Software Advice Capterra