Cómo funciona el no-code (objetos, campos y metadatos)
Por qué puedes adaptar el CRM por tu cuenta, sin programar, y cómo pensar esa flexibilidad.
En muchos sistemas, cambiar un registro exige un programador y una nueva versión. Aquí no. Los objetos, campos y valores se tratan como configuración: cuando creas o modificas un campo, el sistema pasa a mostrarlo, validarlo e incluirlo en los formularios, listas, el tablero y la exportación automáticamente.
Qué significa esto en la práctica
- ¿Necesitas guardar el identificador fiscal de las empresas? Crea un campo "Identificador fiscal" y aparece al instante.
- ¿Tu embudo tiene etapas distintas? Edita los valores del campo Etapa con tus propias fases.
- ¿Quieres un objeto nuevo, como "Contratos" o "Inmuebles"? Modélalo como objeto personalizado.
- ¿Cambió el equipo? Crea un perfil de acceso nuevo y define lo que ve, objeto por objeto.
Cómo pensar el modelado
- Enumera las "fichas" que usa tu negocio (objetos).
- Para cada ficha, enumera los datos que necesitas guardar (campos).
- Identifica los campos de elección (listas) y sus valores (p. ej. Etapa, Estado, Sector).
- Define quién accede a qué (perfiles).
Listas dependientes: las opciones de una lista cambian según otra
Una lista de selección puede depender de otra lista del mismo objeto. Ejemplo: en Tipo eliges "Producto" o "Servicio" y en Subtipo solo aparecen las opciones que tienen sentido para esa elección. Para configurarlo, abre el campo hijo en Configuración → Objetos y campos, elige la lista padre en "Depende de" y, en la tabla que aparece, marca para cada opción del padre qué opciones del hijo quedan disponibles. Una opción del padre sin marcas mantiene la lista completa.
La lista dependiente solo aparece en la ficha después de que la lista padre tenga una opción elegida; hasta entonces permanece oculta.
En la ficha, al cambiar la opción del padre, el hijo muestra solo las opciones permitidas y se limpia si la elección anterior dejó de valer. El servidor aplica la misma regla en todas las entradas (ficha, importación, API, app), rechazando una opción conocida que la selección del padre no permite; los valores antiguos que ya no existen en la lista siguen aceptándose, como en cualquier lista.
Eliminar un campo también lo quita de los campos exigidos de todas las etapas de los embudos. Una etapa nunca exige un campo que ya no existe, así que eliminar un campo nunca impide que una oportunidad avance.