¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único servicio de asistencia?

01El problema de negocio

Un fabricante vende a través de una red de distribuidores independientes. Esos distribuidores necesitan cosas del fabricante constantemente, y las solicitudes no tienen todas la misma forma:

• Una orden de compra que debe tramitarse con los precios acordados
• Una solicitud de presupuesto para una lista de piezas, con cantidades y una fecha límite de necesidad
• Una solicitud de producto nuevo: algo que no está en el catálogo y que requiere un estudio de viabilidad de ingeniería y la aprobación de seis departamentos internos antes de poder dar un precio
• Una solicitud de certificado de material para un lote de producción concreto, necesaria para el expediente de cumplimiento normativo de un cliente final
• Una consulta general o reclamación que no encaja en ninguna de las anteriores

Antes del proyecto, las cinco llegaban por correo electrónico y por teléfono a buzones compartidos. Nada tenía número de referencia, nadie podía responder a «¿dónde está mi solicitud?» sin preguntar a una persona, y no había forma de ver cuánto había tardado cualquier cosa.

Lo que pidió el negocio fue un único servicio de asistencia, con:

• una sola cola y una sola serie de números de referencia, para que cualquier solicitud pueda citarse en un correo;
• un único ciclo de vida de estados que todos entiendan, desde nuevo hasta resuelto;
• autoservicio para distribuidores: quien envía una solicitud ve las suyas y las de nadie más;
• un hilo de conversación por solicitud, con una separación estricta entre lo que ve el distribuidor y lo que queda como interno;
• un registro de auditoría de quién cambió qué y cuándo;
• y, solo para las solicitudes de productos nuevos, una aprobación formal de varios departamentos.

La tensión está por completo en la combinación. Se quiere uniformidad en la cola. Se requiere divergencia en el contenido: una solicitud de certificado necesita un número de lote y un número de colada, y no le sirve de nada una fecha de entrega; una solicitud de presupuesto necesita un conjunto repetible de líneas de piezas, algo que una consulta general nunca tiene.

02Por qué falla el enfoque obvio

Hay dos primeros instintos, y ambos se equivocan de una forma que obliga a reconstruir.

Primer instinto: una entidad más un desplegable «Request Type»

Es el reflejo habitual, porque un desplegable es lo más barato de crear. Falla en un punto concreto y estructural: un valor de desplegable no puede seleccionar un formulario.

Coevera asocia un diseño de formulario editable a cada CustomEntityType. No existe ningún mecanismo por el que el valor de un campo personalizado cambie el diseño. Así que con un desplegable se obtiene exactamente un formulario para los cinco tipos, que reúne los campos de todos ellos: en esta implementación son 42 campos, contados en el formulario unificado del espacio verificado el 2 de septiembre de 2026, de los que aproximadamente una docena se aplican a cada solicitud. A los distribuidores se les pide un número de lote en una orden de compra. No hay manera de que el formulario tenga sentido.

Dos consecuencias más, menos evidentes pero igual de dañinas:

• Mutabilidad. typeId se fija al crear el registro y es inmutable: lo impone la plataforma, sin necesidad de ninguna automatización de control. Un desplegable lo puede editar cualquiera con acceso al campo, de modo que una orden de compra puede convertirse sin avisar en una solicitud de certificado a mitad de su vida, invalidando todos los informes construidos sobre ella.
• Redundancia. Cada registro tendría entonces dos respuestas a la misma pregunta —su typeId real (que existe tanto si lo usa como si no) y su desplegable— sin nada que las mantenga de acuerdo.

Segundo instinto: cinco entidades personalizadas separadas

El reflejo contrario: si los cinco tipos son realmente distintos, modélelos por separado. Así se obtienen formularios limpios y se pierde todo lo que el negocio pidió realmente:

• Cinco secuencias de números de referencia en lugar de una serie compartida
• Ninguna cola única. «Muéstreme todo lo abierto para este distribuidor» se convierte en cinco vistas de lista que una persona tiene que fusionar mentalmente
• Cinco conjuntos de campos que mantener sincronizados. Estado, gravedad, remitente, objetivo de SLA y una docena más son comunes a todos los tipos; ahora existen cinco veces y divergen
• Ninguna conversión in situ. Una consulta general que resulta ser una solicitud de producto nuevo no puede convertirse en una: hay que volver a introducirla en otra entidad, con lo que pierde su historial y su número de referencia
• Cada informe es una unión de cinco fuentes, y cada tipo nuevo la convierte en una unión de seis

03Modelo de datos

Una entidad personalizada, Case, con cinco registros CustomEntityType por debajo. Dos entidades personalizadas de apoyo y tres extensiones de entidades integradas.

La entidad de caso y sus subtipos

Los 42 campos personalizados se crean una sola vez, en la entidad principal. Los cinco subtipos comparten ese único conjunto de campos; la definición del formulario de cada uno selecciona el subconjunto que le corresponde. Esta es la propiedad que hace rentable todo el patrón: 13 campos son comunes a los cinco tipos y se definen y mantienen exactamente una vez.

Allí donde se necesita una distinción por tipo —selección del formulario, disparadores de automatización, vistas guardadas, filtros de la API— el tipo se referencia directamente mediante typeId o type.name. Sin envoltorios, sin campo personalizado, sin lógica de sincronización.

Entidades de apoyo

La entidad Note es el mismo patrón aplicado una segunda vez, a menor escala: en lugar de un booleano personalizado «es interna», la visibilidad la determina typeId. Dos subtipos, ningún indicador que se pueda marcar mal, y la automatización filtra directamente por el tipo. El autor y la marca de tiempo proceden de los campos nativos de propietario y de creación: no hacen falta campos personalizados para ninguno de los dos.

Entidades integradas, ampliadas

04Configuración a nivel de campo

42 campos personalizados en Case, repartidos en 13 comunes más una parte específica de cada tipo:

La denominación de los campos sigue la convención de la propia plataforma: los campos personalizados llevan el prefijo cf_, los desplegables y los lookups llevan el sufijo _id porque se resuelven en UUID de opciones o de registros en lugar de en literales, y los lookups se nombran según la relación que expresan. Los nombres de campo de este blueprint están anonimizados; las formas, los tipos y las relaciones son los de la implementación real.

Permisos de campo por rol

Tres roles, y la separación de visibilidad se aplica a nivel de campo, no ocultando cosas en la interfaz: None, Read o Full por campo y por rol.

05Automatización y lógica

Nueve procesos de automatización, todos con ámbito de espacio. La regla que los organiza: un proceso por cometido, filtrado por typeId. Como los cinco subtipos comparten una entidad, cada proceso se define una sola vez y un nodo de filtro al principio del grafo lo restringe a los tipos a los que se aplica, en lugar de tener cinco copias casi idénticas.

Dos patrones que vale la pena reutilizar

La guarda de un solo disparo. Para registrar «quien lo aceptó primero» sin volver a registrarlo en cada actualización posterior, filtre por que el campo de destino esté vacío y asígnele el usuario que actúa. La condición hace que la escritura sea idempotente, sin un indicador aparte de «¿ya se ha ejecutado?».

La propiedad no cambia. El distribuidor que envió el caso sigue siendo el propietario del registro durante toda su vida; el analista interno se registra en un campo lookup aparte. El instinto es reasignar la propiedad al analista al aceptar el caso, pero la propiedad es lo que determina el acceso del distribuidor a su propio registro. Reasignarla eliminaría la visibilidad del remitente sobre su propia solicitud.

06Límites y compromisos

Los procesos de aprobación no pueden tener como destino una entidad personalizada

Solo uno de los cinco tipos —las solicitudes de productos nuevos— necesita aprobación formal, de seis departamentos. El patrón que funciona es un proxy sobre Quote:

1. Se crea un caso de solicitud de producto nuevo.
2. Un proceso genera un Quote vinculado bajo un tipo de presupuesto dedicado, reservado para aprobaciones.
3. El proceso de aprobación se ejecuta sobre ese Quote de forma nativa, con la interfaz de aprobación y el registro de auditoría estándar; el umbral, el bloqueo del registro y el rol aprobador se configuran como en cualquier presupuesto.
4. El Quote lleva un lookup de vuelta al caso; la plataforma mantiene automáticamente el vínculo inverso.
5. Al tomarse la decisión, un segundo proceso escribe el resultado de vuelta en el estado del caso.
6. Después, el Quote puede archivarse.

Por qué Quote y no Opportunity, si ambos pueden alojar una aprobación:

• Encaje semántico. Una solicitud de producto nuevo es una decisión de precio: «¿podemos fabricarlo y a qué precio?». Quote modela eso. Opportunity entendida como negocio es el enfoque equivocado.
• Sin contaminar el pipeline. Los proxies en Opportunity aparecerían en el pipeline de negocios y contaminarían las previsiones y los informes de ingresos. Un Quote queda en su propio tipo de presupuesto, fuera de la vista.
• El precio se registra de forma nativa. Las líneas del Quote son el precio propuesto, así que no hace falta ningún campo de precio personalizado en el caso.
• Caducidad integrada. Quote tiene una fecha de vencimiento nativa, útil para acotar en el tiempo una solicitud de aprobación.

Dos campos de resumen en el caso muestran el estado del proxy —estado de aprobación y motivo del rechazo—, derivados del Quote vinculado en lugar de almacenados. Para ellos no hace falta lógica de escritura de vuelta; la plataforma los actualiza cuando cambia el Quote.

Las notas integradas no podían expresar dos niveles de visibilidad

El requisito es un único hilo en el que algunas entradas son visibles para el distribuidor y otras son estrictamente internas. La funcionalidad de notas integrada no tiene dimensión de visibilidad, así que el hilo pasó a ser una entidad personalizada con dos subtipos. Un coste que conviene dejar explícito: el caso tiene por tanto notas integradas y un hilo de notas personalizado, y hay que mantener las integradas fuera de los formularios para evitar dos lugares donde escribir que compitan entre sí.

Los campos de texto libre no pueden alimentar listas de distribución

El campo de contactos a notificar empezó siendo un área de texto para escribir direcciones de correo. Se sustituyó por un lookup de selección múltiple a Contact, porque la automatización no puede extraer de forma fiable direcciones de un texto libre para construir una lista de destinatarios. Si hay que actuar sobre el valor de un campo, y no solo leerlo, tiene que ser una referencia tipada.

Otras restricciones encontradas en esta implementación

• Un campo tiene que estar en el formulario para funcionar. Los campos calculados y los campos rellenados por IA que no están en el diseño de formulario de un registro no hacen nada sin avisar: no se calculan y no dan error. Estar en el formulario es funcional, no estético.
• Las secuencias no pueden reiniciarse cada año. El contador de secuencia nativo se incrementa al crear el registro y no tiene reinicio anual. Se puede componer un año en el número como prefijo, pero el contador en sí avanza de forma continua.
• Los procesos con ámbito de espacio necesitan credenciales autenticadas por sesión. Las credenciales de API de acceso personal se rechazan al escribir procesos del espacio, aunque sí pueden leerlos.

Carencias conocidas de esta implementación

Se documentan en lugar de omitirse:

• La escritura de vuelta de la aprobación solo gestiona la rama aprobada. Un proxy rechazado deja el caso en su estado de trabajo sin propagación automática; hace falta un filtro paralelo para el resultado de rechazo.
• El proceso de notas de auditoría se dispara con cada actualización del caso y no solo con los cambios de estado; necesita una condición de campos modificados para dejar de generar ruido.
• Las fechas objetivo de SLA se fijan manualmente. Derivarlas de la gravedad se diseñó y se aplazó deliberadamente.

07Verificación

Los diseños con subtipos fallan en silencio: un formulario que se muestra, un proceso que informa de éxito y un discriminador conectado a lo que no es. Lo que se comprobó realmente:

• Inventario de campos releído por entidad. Cada campo se volvió a leer desde la API después de crearlo y se cotejó con la especificación por nombre de API, no por etiqueta. Tres campos habían salido con nombres distintos de la especificación, y uno no se había creado en absoluto sin que nada lo indicara; ninguna de las dos cosas era visible desde la interfaz.
• Número e identidad de los subtipos. Se confirmó que existen cinco subtipos bajo la entidad de caso y ningún sexto huérfano: la trampa del subtipo por defecto del §3 aparece exactamente aquí.
• Inmutabilidad del discriminador. Se intentó cambiar typeId en un registro existente y se confirmó que la plataforma lo rechaza.
• Acceso a campos por rol, probado con cada rol. No se leyó de la configuración: se inició sesión y se confirmó que los campos que deben ser invisibles para un distribuidor realmente no aparecen.
• Cada proceso confirmado como activado, y su grafo de nodos releído. Dos procesos estaban activados pero se detenían en nodos provisionales: informaban de éxito y no hacían nada. Esta es la comprobación que encontró la carencia en la escritura de vuelta de la aprobación.
• Un recorrido completo por subtipo en la interfaz: crear, avanzar por el ciclo de vida, confirmar que las notas y los correos llegan y confirmar que la vista del distribuidor muestra solo lo que debe.

Qué indicaría una regresión: casos que aparecen con un subtipo vacío o incorrecto; el campo de analista asignado que cambia después de la primera aceptación; notas escritas como internas que llegan a un distribuidor; solicitudes de productos nuevos sin proxy de aprobación vinculado.

Blueprints relacionados

• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? — la decisión de ubicación que aplica este blueprint: campo, subtipo, registro relacionado o entidad nueva.
• Blueprint 004 — ¿Cómo evita que se envíen presupuestos y descuentos antes de que alguien los apruebe? — el proceso de aprobación que este blueprint sortea con un Quote proxy, y lo que bloquea realmente la barrera del umbral.
• Blueprint 006 — ¿Cómo configura una numeración de documentos que resista la producción? — la serie única de números de referencia sobre la que funciona la cola, y lo que le hace un registro eliminado.
• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — un proceso por cometido, que es lo que mantiene legible un año después la automatización filtrada por typeId.