Twenty 2.26 en cámaras: socios, vistas y salida
Mini-caso para cámaras empresarias que necesitan socios, cuotas, contactos, vistas, API y una salida probada sin perder trazabilidad mensual.
Antes, la cámara guardaba socios en una planilla y reclamos en chats; después, cada contacto tuvo dueño, estado y próxima acción. En una entidad empresaria de San Martín, la tarea diaria era saber quién pagó, quién pidió gestión y qué dato podía salir a un reporte. Twenty 2.26.0 ofrece CRM self-hosted con objetos, vistas y API. Este caso muestra cómo probarlo.
Dónde aparece el socio partido
El socio partido aparece cuando una empresa figura activa en la planilla de cuotas, vencida en tesorería y pendiente en el chat de presidencia. Twenty publicó twenty/v2.26.0 el 31 de julio de 2026. La release menciona cambios en vistas del sistema, workflows, dashboard con formatos numéricos extendidos y correcciones de migración. Un socio con tres estados exige tres explicaciones. El dato global viene de Stack Overflow 2025 Work: muchas personas trabajan con más de una aplicación durante su semana laboral. En una cámara chica, esa mezcla aparece en contactos en hojas de cálculo, pagos en un sistema contable, reclamos en mensajería y reportes armados a mano. El caso usa un padrón de 1.200 socios, cinco comisiones internas y una tesorería de dos personas. En la mesa del tesorero hay un sello azul con la palabra "pagado"; el objeto tiene sentido porque marca una rutina que todavía compite con el sistema.
Cómo funciona por dentro
El flujo empieza cuando administración carga empresas, personas, categoría, cuota, comisión y responsable. Twenty recibe esos registros en objetos estándar o personalizados. La configuración de datos permite agregar campos y relaciones para unir socio, contacto, pago y gestión. PostgreSQL guarda registros, vistas, usuarios, permisos y eventos. La API entrega datos a reportes o integraciones con una clave limitada por rol. El backup copia base y configuración; una restauración abre el padrón con las mismas vistas. 1. Administración carga empresa, contacto, categoría y estado de cuota. 2. Tesorería agrega pago, vencimiento y comprobante. 3. Twenty valida campos, relaciones y vista visible para cada rol. 4. PostgreSQL guarda registros, usuarios, vistas y auditoría. 5. La API expone datos según clave y permiso. 6. Dirección consulta tablero de socios activos, vencidos y gestiones. 7. El backup restaura base y configuración antes de una importación grande. Los permisos separan carga, tesorería, lectura directiva y administración técnica. Secretaría puede editar contactos. Tesorería edita cuotas. Dirección lee vistas. Sistemas administra Docker, variables y respaldo. Si falla la base, el CRM pierde estado; si falla la API, el dato sigue consultable desde la interfaz.
Qué se instala o configura primero
La documentación de Docker Compose pide declarar variables en el servicio correcto y marca 2 GB de RAM como requisito mínimo. La guía de setup permite configurar email, storage, integraciones, workflows y límites desde el panel de administración. La guía de modelo de datos ordena objetos, campos y relaciones. Con dólar oficial vendedor a ARS 1.510, una instancia chica puede ubicarse entre USD 35 y USD 75 mensuales, entre ARS 52.850 y ARS 113.250, según disco y correo. Un piloto de 32 a 48 horas a USD 30/h queda entre USD 960 y USD 1.440, entre ARS 1.449.600 y ARS 2.174.400. Incluye instalación, padrón de muestra, roles, tres vistas, API y prueba de salida. Quedan fuera carga histórica completa y depuración legal del padrón. UMSA puede aplicar este circuito cuando una cámara necesita ordenar socios sin quedar encerrada en una licencia cerrada. El primer entregable verificable son 50 socios importados, dos roles, una vista de vencidos, una API key con alcance limitado y un archivo exportado que cuadre con el tablero.
Dónde se rompe y cómo probarlo
El primer riesgo es diseñar campos que luego no se pueden cambiar. La señal aparece cuando un campo de texto se usa para importes o fechas. La prueba crea cinco registros, filtra por vencimiento y rechaza cualquier dato que no permita ordenar correctamente. El segundo riesgo es abrir la API con permisos amplios. La documentación de API indica que cada workspace genera su esquema y que las claves pueden limitarse por rol. La prueba usa una clave de tesorería y verifica que no lea campos reservados de dirección. El tercer riesgo está en upgrades sin copia. La guía de upgrade pide respaldo de base antes del cambio. La prueba baja el servicio, restaura el backup en otra instancia y abre vistas, relaciones y API. El cuarto riesgo es importar socios duplicados. La señal es una empresa con dos contactos principales y cuota distinta. La prueba carga diez duplicados conocidos, revisa reglas de coincidencia y deja un reporte de fusiones pendientes. La cámara recién gana control cuando puede responder quién cambió un dato, cuándo lo hizo y cómo sale del sistema.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.