FieldOps es multi-tenant con aislamiento a nivel de base de datos. No es un filtro que alguien puede olvidar de poner en una consulta: es una política de la base de datos, y por debajo de ella no hay forma de que los datos de una organización aparezcan en otra. Sobre esa base van cinco roles, permisos por módulo, historial de cada cambio y observabilidad continua.
Muchas plataformas dicen ser multi-empresa y en el fondo guardan todo junto, separado por una columna que la aplicación tiene que recordar filtrar en cada consulta. Basta que alguien escriba un query sin ese filtro para que se mezcle la información de dos clientes.
En FieldOps la separación no depende de que la aplicación se acuerde: es una política de la base de datos. La organización a la que perteneces viaja con tu sesión y la base misma se encarga de que no puedas leer nada fuera de ella.
El rol responde a una pregunta simple: hasta dónde llega esta persona. No es una etiqueta decorativa — define qué ve, qué puede cambiar y de qué se hace responsable dentro de la organización.
| Rol | Alcance | Caso típico |
|---|---|---|
| SUPER_ADMIN | Opera la plataforma. No pertenece a ninguna organización cliente. | El equipo de Gestdat que mantiene la plataforma funcionando y habilita nuevas organizaciones. |
| ADMIN | Administra su organización: configuración, usuarios e integraciones. | El gerente de operaciones o el encargado de sistemas que define estados, campos, permisos y la conexión al ERP. |
| SUPERVISOR | Coordina el trabajo del equipo y ve el conjunto de la operación. | El jefe de terreno que reparte las actividades de la semana, revisa el avance y detecta lo que está trabado. |
| USER | Ejecuta: sus actividades, sus documentos, su chat. | El técnico, el ejecutivo o el analista que hace el trabajo, adjunta la evidencia y cierra lo que le toca. |
| VIEWER | Solo lectura. | El cliente externo que necesita ver cómo avanza su propio trabajo, sin entrar a la operación completa. |
El rol define hasta dónde llega alguien. El permiso por módulo define qué hace dentro de ese alcance.
En la práctica ningún equipo calza exacto con cinco cajones. Tienes un supervisor que además maneja el inventario, un usuario que no debería tocar los costos, un analista que solo necesita reportes. Por eso, sobre el rol, cada módulo se habilita por separado.
Es la pregunta que aparece siempre: "¿y cómo le muestro el avance a mi cliente sin mandarle un Excel cada viernes?". Para eso existe el rol VIEWER: acceso de solo lectura, acotado a lo que le corresponde, sin que tenga que instalar nada ni pedirle nada a tu equipo.
El VIEWER es una cuenta más de tu organización, con el mismo aislamiento que las demás. Le das visibilidad, no una llave. Y si mañana el proyecto termina, se desactiva y queda registrado quién lo hizo y cuándo.
La trazabilidad no es un módulo aparte que hay que acordarse de activar: es la forma en que la plataforma guarda las cosas. Cada cambio queda pegado a la entidad que cambió, y todo junto arma la línea de tiempo de la organización.
Cada actividad, documento, material o usuario lleva su propio historial: qué cambió, de qué valor a qué valor, quién lo cambió y a qué hora.
Todos esos historiales, consolidados en una sola línea de tiempo. Sirve para reconstruir qué pasó una semana determinada sin abrir veinte fichas.
Cada consulta al asistente queda guardada con su contexto: quién preguntó, qué respondió, sobre qué fuentes y si esa respuesta terminó convertida en una actividad.
Si vas a mostrarle la plataforma a tu equipo y a tus clientes, tiene sentido que se vea tuya. Cada organización configura su subdominio, su logo, sus colores y sus plantillas de correo — y eso aplica tanto en la vista interna que usa tu equipo como en la vista pública que llega a un cliente.
Que la plataforma funcione no se declara: se mide. Hay pruebas que recorren los flujos críticos de forma continua, monitoreo de errores agrupados y métricas de uso real. Cuando algo se rompe, lo sabemos antes de que nos escribas — y cuando algo no se usa, también lo sabemos.
Los errores se agrupan por causa, no por cantidad de veces que aparecieron. Así se corrige el problema de fondo y no el síntoma que más gritó.
Qué módulos se usan de verdad, cuáles nunca se abren y en qué paso la gente se traba. Es la base para decidir qué mejorar primero.
Revisión continua de la base de código para que la plataforma siga siendo mantenible a medida que crece, en vez de acumular deuda en silencio.
La telemetría alimenta recomendaciones priorizadas de qué conviene corregir o simplificar. Evidencia primero, decisión después.
La pregunta razonable cuando aparece una IA dentro de una plataforma es: ¿qué alcanza a leer y quién decidió eso? La respuesta corta es que el asistente hereda exactamente el aislamiento y los permisos de la persona que lo está usando. No hay una puerta lateral.
Acá te contamos cómo está construida la plataforma, no qué sellos colgamos en la pared. Si tu organización tiene requisitos específicos de seguridad o de manejo de datos, lo conversamos derecho en el diagnóstico y te decimos qué se puede y qué no.
Qué analiza el asistente, con qué fuentes responde y por qué siempre confirma una persona.
La unidad operacional que lleva el historial de cada cambio, responsable y evidencia.
Cómo entra la información de tus sistemas y con qué credenciales queda conectada cada organización.
Los módulos, los casos de uso y cómo se conectan entre sí en una sola vista.
Te mostramos el aislamiento, los roles que necesitaría tu equipo y qué vería un cliente externo si le abres el acceso de solo lectura.
