Personalización: Campos y módulos
Flash se adapta a cada marca de dos maneras, ambas en una base de código compartida, nunca una bifurcación. Campos personalizados agregan tus propios datos al registro del miembro y se configuran a través de la versión 2 REST API. Módulos son funcionalidades opcionales que se activan por espacio de trabajo y son aplicadas por el servidor. Esta guía cubre ambas.
Los campos se declaran antes de configurarse.
Un propietario o administrador crea campos en Configuración → Campos Personalizados. Cada campo tiene una clave (su nombre de máquina, p. ej., cf_membership_no), un tipo y, para los tipos select, una lista de opciones. La clave y el tipo se fijan una vez creados. El campo API nunca crea campos; solo establece valores para los campos que ya existen y rechaza las claves desconocidas; la tabla de definición es la lista de permitidos.
Pase customAttributes al crear o actualizar
Tanto POST /api/v2/members (crear) como PATCH /api/v2/members/{id} (actualizar) aceptan un customAttributes object indexado por las claves de sus campos. Autentíquese con una clave Bearer fl_live_ que tenga el ámbito members:write.
curl -X POST https://flash.socialhub.ai/api/v2/members \
-H "Authorization: Bearer fl_live_..." \
-H "Content-Type: application/json" \
-d '{
"email": "ada@example.com",
"fullName": "Ada Lovelace",
"customAttributes": {
"cf_membership_no": "A-10023",
"cf_preferred_store": "flagship",
"cf_child_birthday": "2018-05-01"
}
}'Al actualizar, envía solo las claves que deseas cambiar. Al establecer una clave en null, se borra.
curl -X PATCH https://flash.socialhub.ai/api/v2/members/{id} \
-H "Authorization: Bearer fl_live_..." \
-H "Content-Type: application/json" \
-d '{ "customAttributes": { "cf_preferred_store": "airport" } }'Qué acepta cada tipo de campo
| Tipo | Ejemplo de valor JSON | Acepta |
|---|---|---|
text | "A-10023" | cadena |
number | 42 | number (o numérico string) |
date | "2018-05-01" | Fecha ISO (AAAA-MM-DD) |
boolean | true | verdadero / falso |
enum | "flagship" | una de las opciones del campo |
list | ["running","tennis"] | Subconjunto de las opciones del campo |
La validación es estricta: un valor debe coincidir con el tipo de su campo, un valor enum/list debe ser una de las opciones definidas y las claves desconocidas se rechazan con 400. Los campos para datos personales confidenciales (PII) aún no se aceptan; mantenga los atributos personalizados en valores comerciales no confidenciales.
Un único valor, utilizado en toda la plataforma.
Segmentos
Filtra los miembros por cualquier campo personalizado con operadores apropiados para el tipo (el mismo campo que configuraste en API).
Personalización del correo electrónico
Referencia el valor en la copia como {{cf_membership_no}} o {{member.cf_membership_no}}.
Lectura de miembros
Los valores personalizados se devuelven en el objeto miembro en customAttributes.
Funcionalidades opcionales, activadas por espacio de trabajo
Donde un campo personalizado agrega un valor , un módulo agrega una capacidad completa; por ejemplo, un módulo de tickets de servicio, citas o un registro de reparaciones. Los módulos están desactivados por defecto y se habilitan por espacio de trabajo. Cada espacio de trabajo ejecuta la misma base de código; que un módulo esté activado o desactivado es un dato (un derecho), nunca una compilación privada .
Aplicado por el servidor, en un solo lugar
Cada módulo tiene una clave estable (p. ej., tickets). La posibilidad de usarlo en un espacio de trabajo se activa mediante un interruptor único, que se verifica en un punto de control y se aplica en todos los lugares donde aparece el módulo: fail-closed: si el interruptor no está activado, la funcionalidad simplemente no está disponible.
API
Los puntos finales de un módulo deshabilitado rechazan llamadas con 403. El acceso nunca se deja al azar únicamente en la interfaz de usuario.
Navegación y páginas.
Las entradas y páginas del menú de un módulo solo aparecen cuando está habilitado para el espacio de trabajo y desaparecen limpiamente cuando se desactiva.
Inquilino aislado
Los permisos se aplican por espacio de trabajo. Los módulos y datos de una marca nunca son visibles para otra.
Cómo se introduce un nuevo módulo
Cuando una capacidad es realmente reutilizable, se construye una vez como un módulo: se registra en un catálogo de módulos bajo su clave, con sus propios datos, su propio API controlado por derechos y sus propias páginas. El primer espacio de trabajo que lo necesita lo construye; el siguiente simplemente acciona el interruptor. Este es el núcleo del modelo: las diferencias de los clientes se expresan como configuraciones, por lo que una actualización o solución llega a todos los espacios de trabajo a la vez.
- El módulo se registra en el catálogo con una clave estable y una descripción.
- Sus rutas de datos y API están protegidas por esa clave (cierre automático ante fallos).
- Su navegación y páginas se muestran solo cuando la tecla está habilitada.
- Un propietario lo activa para un espacio de trabajo; un segundo espacio de trabajo es un interruptor, no una reconstrucción.
Activar o desactivar módulos
Los propietarios del espacio de trabajo administran los módulos desde Configuración → Módulos. Cada cambio tiene efecto inmediatamente en API y en la interfaz de usuario.
Regla de decisión: usar la configuración primero; Añade un campo personalizado cuando necesites almacenar un valor; crea un módulo cuando una funcionalidad sea realmente reutilizable y nunca bifurques el producto para un solo cliente.
¿Necesita un tipo de registro completamente nuevo, no sólo un campo adicional? Consulte Objetos personalizados: cree su propio objeto comercial sin código, luego busque registros y segméntelos. Para mantener sincronizado el resto de su pila, consulte Conectores y notificaciones.