La respuesta corta
El número de procesos no lo elige usted. Un proceso es un disparador, luego un único nodo de filtro y luego acciones, y un filtro nunca puede ser hijo de una acción. Así que no se puede añadir una segunda condición independiente a un proceso que ya tiene una. Hay que traspasarla a otro proceso, que lleva su propio filtro.
El proceso invocado se ejecuta ante un cambio de registro o de forma manual, y el disparador manual es la opción que evita que se dispare por sí solo. Manual no significa que lo dispare un usuario; significa que no se dispara por sí solo, de modo que otro proceso puede invocar un proceso manual y una persona puede ejecutarlo. El mismo proceso es una subrutina en una cadena y una herramienta de reparación que alguien dispara a mano.
Así que lo que usted controla no es cuántos procesos tiene, sino si siguen siendo legibles: etiquete cada proceso y ponga a su nombre un prefijo de dominio, porque la plataforma muestra cuándo se ejecutó un proceso, pero no tiene ninguna vista documentada de qué lo invoca.
El problema de negocio
Un evento de negocio suele requerir comprobar varias cosas sin relación entre sí. Tome una cuenta que pasa de cliente potencial a cliente:
- Si faltan los datos del contacto principal, avise al propietario; de lo contrario, todos los correos automatizados posteriores no llegan a nadie.
- Si la región se escribió como abreviatura de dos letras, expándala, porque de lo contrario los informes por país se dividen en duplicados sin que nadie lo note.
- Rellene las fechas de renovación a partir del plazo del contrato, que es de doce o de veinticuatro meses.
No son alternativas. Una misma cuenta puede necesitar las tres, y no tienen nada que ver entre sí. El instinto es escribir un solo proceso para "la cuenta se convierte en cliente" que lo resuelva todo, y de ese instinto trata el §2.
El conjunto de automatizaciones del que se extrae este caso tiene 265 procesos repartidos en siete entidades, con 113 solo en una entidad. Esa cifra no es desorden ni una señal de alarma. Es lo que produce la forma del motor cuando un negocio tiene tantas reglas, y la pregunta interesante no es cómo tener menos, sino cómo mantener legibles cientos de ellos.
Por qué falla el enfoque obvio
Poner las tres comprobaciones en un solo proceso
Un proceso tiene un solo filtro, y el filtro es una única compuerta. Sus ramas son if / then / else: gana la primera rama que coincide y las demás nunca se evalúan.
Así que las tres comprobaciones anteriores, escritas como tres ramas de un mismo proceso, hacen que una cuenta que necesita las tres reciba solo la primera. Ni error, ni advertencia, ni informe de éxito parcial. Dos correcciones sencillamente no se producen, y el proceso parece haberse ejecutado.
Es el malentendido más caro que ofrece el motor de procesos, porque el diseño parece más ordenado y el fallo es invisible. Además empeora con el éxito: cuantos más casos cubre el proceso, más probable es que un registro coincida con varios y reciba uno.
Tampoco puede volver a filtrar a mitad de la cadena para sortearlo. Un filtro nunca puede ser hijo de una acción: la forma canónica es disparador, luego filtro y luego acciones, y el motor no acepta una segunda compuerta colgada al final del trabajo de la primera. Por tanto, las condiciones independientes no pueden expresarse en absoluto dentro de un único proceso. Es un hecho estructural, no una preferencia de estilo.
Nombres descriptivos
Nombrar un proceso según lo que hace (Enviar el correo de bienvenida, Actualizar la fecha de renovación) resulta claro el primer día e inútil en una lista de doscientos, porque la lista queda ordenada por verbo. Todo lo que empieza por Actualizar… acaba junto sin importar lo que toque, y los seis procesos de un mismo dominio se dispersan por el alfabeto. La lista se lee mucho más a menudo que cualquier nombre individual.
Documentarlo en una hoja de cálculo
Exacta el día en que se escribe, errónea al cabo de un mes, porque el conjunto cambia en la interfaz de administración y el documento no. Todo lo que se mantiene en paralelo a lo que describe acaba desviándose. Lo que perdura es lo que vive dentro del conjunto, y por eso el nombre tiene tanto peso.
La forma de un proceso y lo que se deriva de ella
Todo lo que contiene este blueprint se deriva de un único hecho estructural:
trigger → filter → actions
↑
exactly one, at the root.
A filter may never be a child of an action.Lo que significa que un proceso puede aplicar una condición independiente. Una segunda condición necesita un segundo proceso, y la forma de llegar a él es un nodo de disparo de proceso, que traspasa el control a otro proceso y lleva su propio filtro. La siguiente condición vive en el traspaso.
Fuente. Centro de ayuda de Coevera, Automatizer — triggering a process from another process, que presenta el mismo mecanismo como la forma prevista de construir: "more scaled-down processes … chained together into a unified workflow". El Process Manager que los enumera se documenta por separado.
Así que el ejemplo de cliente potencial a cliente no es un proceso. Es un detector más tres subprocesos:
| Proceso | Disparador | Su propio filtro |
|---|---|---|
| Detectar la transición | Actualización del registro en el campo de clasificación | Se ha convertido en cliente |
| Comprobación de datos de contacto | Manual (invocado) | Campos del contacto principal vacíos |
| Corrección de la región | Manual (invocado) | La región es un código de dos letras |
| Relleno de fechas de renovación | Manual (invocado) | El plazo es de 12 o 24 meses |
Cada subproceso evalúa su propia condición de forma independiente, así que una cuenta que necesita las tres correcciones recibe las tres. Esa es toda la razón por la que el conjunto tiene esta forma.
Dé a cada subproceso un filtro permisivo en la raíz, aunque el llamador ya haya decidido. No cuesta nada y aporta algo concreto: como los procesos manuales también puede ejecutarlos una persona, el subproceso puede invocarse en un contexto que nadie ha comprobado. Su propio filtro raíz es lo que lo hace seguro en ambos sentidos.
El tipo de disparador es un dato de primer orden
Hay cuatro tipos de disparador, y el tipo determina tanto cómo se llega a un proceso como la forma en que falla. Esto forma parte de cómo se piensa el conjunto de automatizaciones, no de algo que se descubre al abrir un proceso.
| Tipo | Se llega mediante | Cómo falla |
|---|---|---|
| Record | El cambio de un campo | En silencio. Si el campo deja de cambiar (una integración se detiene, una importación reescribe el mismo valor), nada se dispara y nada lo notifica. Imposible de distinguir de una semana tranquila. |
| Schedule | Una hora del día | Sin titubear. Se ejecuta puntualmente estén o no actualizados sus datos de entrada, así que actúa sobre datos obsoletos en lugar de no actuar. |
| Manual | Otro proceso que lo invoca, o una persona que lo ejecuta | Huérfano. Si el llamador se reescribe para dejar de invocarlo, ya no se llega al subproceso y nada lo indica. Su condición sigue siendo correcta; nada la consulta. |
| Online form | El envío de un formulario | Junto con el formulario. Fuera del alcance de este blueprint. |
La cifra que merece la pena medir en su propio conjunto de automatizaciones. En la entidad más cargada de este caso, con 113 procesos, el reparto es de 41 disparados por registro, 16 programados y 56 manuales.
Que la mitad de esa entidad sea manual no es un cajón de utilidades olvidadas. Es la capa de composición: los subprocesos que existen porque las condiciones independientes no pueden compartir un filtro. Un número alto de procesos manuales en un conjunto maduro es señal de que la descomposición se hizo correctamente.
Sí crea el único modo de fallo propio de este tipo. Un proceso disparado por registro que deja de dispararse al menos sigue figurando como vigilante de un campo; un subproceso huérfano parece idéntico a uno que funciona. Por eso el §7 sigue las cadenas de llamadas en lugar de limitarse a leer la lista.
Patrones que mantienen legible un conjunto de automatizaciones grande
Etiquete por dominio y ponga también el prefijo en el nombre
Los procesos admiten Tags, y el Process Manager filtra por etiqueta además de por propietario y estado (Automatizer — creating and running processes). Utilícelas. Pero la búsqueda de la lista compara nombres, una etiqueta solo aparece en una columna que usted decida añadir, y no hay carpetas ni una vista de dependencias documentada. Así que ponga también el dominio en el nombre, entre corchetes al principio:
[Contracts] Create the renewal record
[Contracts] Watch the renewal date for changes
[Hygiene] Normalise country and region codes
[Hygiene] Flag records whose status contradicts their dates
[Outreach] Send the scheduled check-inAsí, una lista plana se agrupa sola al ordenarla, una búsqueda de un dominio devuelve todo lo que lo toca, y añadir un proceso obliga a plantearse ¿a qué dominio pertenece?, que es lo que detecta un duplicado antes de que exista.
El conjunto examinado usa alrededor de una docena de prefijos; el mayor agrupa veinticinco procesos y el menor, dos. Esa distribución es en sí misma una herramienta de revisión: veinticinco miembros son un dominio que merece leerse en conjunto, y dos son o un caso límite real o un accidente de nomenclatura.
Una convención que no se hace cumplir se desvía. Dos de los prefijos de este conjunto son el singular y el plural de la misma palabra: doce procesos con una grafía, trece con la otra, todos relativos a la misma entidad. Ninguno es incorrecto; juntos hacen que la agrupación falle sin que se note, porque al ordenar quedan contiguos, pero al buscar uno se pierde el otro.
Anote la lista de prefijos como un conjunto cerrado y compruebe los procesos nuevos con ella. Es la gobernanza más barata posible, y lo primero que se deteriora.
Nombre la cadena, no solo el proceso
Como a los subprocesos se llega porque alguien los invoca y no porque vigilen algo, la única pista sobre quién invoca a quién es el nombre. Un prefijo compartido más un verbo coherente para el detector (el proceso que es dueño del evento) hacen que una cadena se pueda leer solo con la lista. Sin ello, seguir un evento de negocio significa abrir procesos hasta dar con el llamador.
Un subproceso sirve a la vez de subrutina y de herramienta de reparación
Como manual significa invocable y ejecutable, el subproceso que construyó para la cadena es también lo que ejecuta a mano cuando una fecha cambia, un registro se crea fuera de orden o una automatización estuvo desactivada durante una tarde. Es el mismo mecanismo que el gemelo manual del Blueprint 010 y la derivación reejecutable del Blueprint 009: no es un patrón distinto, sino el mismo visto desde otro ángulo. Constrúyalo una vez y cumple ambas funciones, siempre que conserve su propio filtro raíz.
Una última rama sin coincidencia que diga algo
Todo filtro que asigna un valor a un resultado debe terminar con una rama que coincida con todo lo que las anteriores no recogieron y cuya acción sea avisar a alguien. Con la semántica de gana la primera coincidencia, un valor no reconocido toma, si no, la rama de paso que exista y no produce ningún error. Es el seguro más barato disponible en un conjunto de este tamaño.
Límites y compromisos
La descomposición del §3 es obligatoria. Las consecuencias que siguen no lo son; se derivan de una segunda carencia: la plataforma informa de cuándo se ejecuta un proceso, no de cómo encaja el conjunto. El Process Manager tiene una columna Activity (24 hours) y estadísticas de ejecución de hasta 14 días, y cada proceso guarda un Activity Log de sus ejecuciones (Process Manager). Con las notificaciones activadas, el propietario recibe un aviso cuando se elimina o desactiva un proceso que sigue conectado a otro (triggering a process from another process). Lo que ninguna vista documentada muestra es qué invoca a un proceso concreto ni qué dejaría de alcanzarse sin él. Cuando a la mitad de los procesos de una entidad solo se llega porque alguien los invoca, ese grafo de llamadas ausente es lo que sale caro.
No se elimina nada, así que se renombra
Observado en este conjunto: cinco procesos llevan las palabras not used u obsolete en su propio nombre. Uno de ellos tiene una programación diaria y sigue ejecutándose.
No es descuido: es la respuesta racional a no poder demostrar que una eliminación es segura. Renombrar es reversible y no cuesta nada; eliminar podría romper algo que nadie sabe nombrar. Así, el conjunto acumula una capa de procesos documentados como muertos que no están desactivados.
La mitigación es una convención, no una herramienta: retirar significa primero desactivar, después renombrar y, por último, eliminar en una fecha que se escribe en el nombre. Un proceso marcado como no utilizado que sigue disparándose es peor que cualquiera de los dos estados por separado, porque el nombre le dice a la siguiente persona que ignore algo que está haciendo trabajo activamente.
Los duplicados se acumulan por año
Todo lo que lleva un año en su lógica tiende a copiarse cada enero en lugar de ampliarse, y la copia anterior nunca se retira. Este conjunto tiene varias familias así, en las que dos procesos hacen en gran medida el mismo trabajo sobre rangos de años distintos. Cada uno fue el cambio mínimo correcto en su momento; juntos son dos lugares que actualizar y una lotería sobre cuál se ejecutó realmente.
Los procesos programados coinciden, y nada le avisa
Las horas de programación se eligen de una en una, sin ver lo que ya está programado. En este conjunto, tres procesos diarios sin relación entre sí se ejecutan a la misma hora, y otros están separados por cinco y veinticinco minutos.
Programar a la misma hora no es un fallo en sí. Se convierte en uno cuando dos de ellos tocan los mismos registros, porque no hay garantía de orden entre ellos ni transacción que envuelva a ninguno, así que cuál gana no es algo que pueda deducirse de la configuración. Mantenga una única lista de horas programadas y sus responsables, y separe todo lo que comparta un conjunto de registros.
Un subproceso huérfano no se distingue de uno que funciona
Este es el modo de fallo que introduce el modelo de composición. A un subproceso solo se llega cuando alguien lo invoca. Desactive su llamador y el propietario puede recibir un aviso, si las notificaciones están activadas; reescriba el llamador para que deje de invocarlo y no se genera nada. En ambos casos el subproceso sigue pareciendo igual que cualquier otro proceso activado de la lista, con una actividad tan tranquila como la de una semana floja. Su filtro sigue siendo correcto. Nada lo consulta.
También es la única forma de proceso muerto cuya muerte se puede demostrar de verdad, porque la llamada está en la propia definición del llamador. Eso convierte el seguimiento de las cadenas de llamadas en la auditoría más valiosa del §7, y en la única manera de limpiar un conjunto de automatizaciones con certeza y no a base de valor.
Los procesos personales son una categoría real
Los conjuntos de este tamaño contienen procesos con las iniciales de alguien como prefijo: herramientas personales creadas para la rutina de una persona. Funcionan, se usan y son invisibles para todos los demás. Deles un prefijo compartido y ponga en el nombre lo que hacen, porque la alternativa es que se queden sin dueño el día en que esa persona cambie de puesto.
Lo que no hemos verificado
Las afirmaciones estructurales (un filtro en la raíz, un filtro nunca hijo de una acción, los cuatro tipos de disparador, el nodo de traspaso con su propio filtro) se han leído del esquema de la API y de definiciones de procesos extraídas de la interfaz de administración. El comportamiento de gana la primera coincidencia de las ramas de un filtro, así como las cifras del conjunto citadas a lo largo del texto, proceden de operar este despliegue.
No hemos probado la activación y desactivación masivas por patrón de nombre, ni si la plataforma ofrece una vista del grafo de llamadas; la documentación del Process Manager no describe ninguna de las dos. Las prácticas anteriores suponen que no existen, porque así se gestiona este conjunto en la práctica, pero que no se use no demuestra que no exista. Si está fijando convenciones para un espacio nuevo, revise la interfaz de administración actual antes de comprometerse a compensarlo a mano.
Verificación
Esta es la auditoría para un conjunto de automatizaciones que usted no construyó, y funciona desde fuera. Toda ella lee la lista de procesos en lugar de abrirlos uno por uno.
- Agrupe por prefijo de nombre y fíjese en lo que no tiene ninguno. Los procesos sin prefijo suelen ser los accidentes: añadidos con prisas y nunca revisados. Cuente también los prefijos distintos: más de unos quince significa que el esquema ha dejado de serlo.
- Busque el singular y el plural de un mismo prefijo, y el mismo dominio escrito de dos maneras. Es el fallo silencioso más común de una convención de nombres y se encuentra en treinta segundos.
- Agrupe los procesos programados por hora del día. Todo lo que comparte hora merece una revisión; todo lo que comparte hora y conjunto de registros merece corregirse.
- Busque en los nombres not used, obsolete, old, temp, copy e iniciales personales. Después compruebe si cada uno está realmente desactivado. La distancia entre "nombrado como muerto" y "desactivado" es donde esta auditoría demuestra su valor.
- Siga las cadenas de llamadas. Para cada proceso con disparador manual, averigüe qué lo invoca. Aquellos a los que nada invoca están realmente muertos, y es el único tipo de proceso muerto que se puede demostrar, porque la llamada vive en la definición del llamador y no en una inferencia. Hágalo antes que nada si ha heredado el conjunto.
- Compare el número de manuales con el de disparados por registro. Una proporción alta de manuales en un conjunto maduro es esperable y sana: es la capa de composición. Lo que importa es si cada uno tiene un llamador. Un número alto de manuales más huérfanos es la señal de que se reescribió una cadena y se dejaron atrás sus piezas.
- Compruebe la independencia de cada filtro con varias ramas. Cuando las ramas representan alternativas (un estado es uno de cuatro valores), un solo proceso es correcto. Cuando representan condiciones que podrían ser ciertas a la vez, la regla de gana la primera coincidencia hace que solo una llegue a aplicarse, y las demás deben extraerse a subprocesos. Esta es la auditoría que encuentra el error del §2 en un conjunto que construyó otra persona.
- Intente enunciar el propósito de cada proceso en una frase. Aquellos en los que no lo consigue son los que abarcan más de un asunto, y son los candidatos a dividirse, no porque estén rotos, sino porque son los que nadie se atreverá a cambiar más adelante.
Qué indicaría una regresión: un proceso nuevo sin prefijo, o con un prefijo que no está en la lista acordada; un proceso con disparador manual sin llamador; un filtro con varias ramas cuyas ramas son condiciones independientes y no alternativas; un proceso nombrado como retirado que sigue activado; dos procesos cuyos nombres solo difieren en un año; un proceso programado añadido a una hora en la que ya hay otro que toca los mismos registros.
Preguntas frecuentes
¿Cómo se mantiene sostenible un gran conjunto de automatizaciones del CRM?
Empiece por aceptar que el número no lo elige usted. Un proceso de Coevera es un disparador, luego un único nodo de filtro y luego acciones, y un filtro nunca puede ser hijo de una acción, así que no se puede añadir una segunda condición independiente a un proceso que ya tiene una. Hay que traspasarla a otro proceso que lleve su propio filtro. Por tanto, un evento de negocio que necesita tres correcciones sin relación entre sí son tres o cuatro procesos, por construcción. Lo que usted controla de verdad es la legibilidad: etiquete cada proceso por dominio y dele además un prefijo de dominio entre corchetes, porque el nombre es lo que busca la búsqueda de la lista de procesos; haga explícito el tipo de disparador, ya que cada tipo falla de una manera distinta; y dé a cada subproceso un filtro raíz permisivo para que se proteja a sí mismo si alguna vez se ejecuta por separado.
¿Por qué un evento de negocio necesita varios procesos del CRM en lugar de uno?
Porque un proceso tiene un solo filtro, y el filtro es una única compuerta IF-THEN-ELSE en la que gana la primera rama que coincide. Piense en una cuenta que pasa de cliente potencial a cliente y que necesita tres correcciones independientes: avisar al propietario si faltan los datos del contacto principal, expandir una abreviatura de región de dos letras al nombre completo para que los informes por país no se dividan, y rellenar las fechas de renovación a partir de un plazo de doce o veinticuatro meses. No son alternativas, son tres cosas que pueden ser ciertas a la vez. Si las pone en un solo proceso, solo se ejecuta la primera rama que coincide, así que un registro que necesita las tres recibe una. La solución es un proceso por cada condición independiente, invocado desde el proceso que detectó el evento.
¿Qué significa un disparador 'manual' en los procesos de Coevera?
Ambas cosas a la vez, y esa es la clave. Manual es uno de los cuatro tipos de disparador, junto con registro, programación y formulario en línea, y lo que realmente significa es que el proceso no se dispara por sí solo: por eso una persona puede ejecutarlo desde un registro y otro proceso puede invocarlo mediante un nodo de disparo de proceso. El mismo proceso sirve como subrutina en una cadena automatizada y como herramienta de reparación que alguien ejecuta a mano, sin construirlo dos veces. Por eso cerca de la mitad de los procesos de la entidad más cargada del conjunto examinado (56 de 113) tienen disparador manual, y por eso esa cifra indica una descomposición deliberada y no utilidades en desuso. También por eso cada subproceso debe conservar un filtro permisivo propio en la raíz: el llamador automatizado ya ha establecido el contexto, pero una persona que lo ejecuta de forma independiente no, y el filtro raíz es lo que hace que el mismo proceso sea seguro en ambos sentidos.
¿Cómo se auditan automatizaciones del CRM que no ha construido usted?
Trabaje a partir de la forma y no del contenido. Agrupe todos los procesos por prefijo de nombre y fíjese en los que no tienen ninguno, ya que los procesos sin prefijo suelen ser los que se añadieron con prisas. Compruebe si el mismo dominio aparece con dos grafías, que es el fallo silencioso más común de una convención de nombres. Agrupe los programados por hora del día y busque varios en la misma hora, sobre todo los que tocan los mismos registros, porque no hay ninguna garantía de orden entre ellos. Busque en los nombres not used, obsolete, old, temp e iniciales personales, y compruebe después si cada uno está realmente desactivado y no solo etiquetado. Y siga las cadenas de llamadas: un subproceso al que nada invoca está realmente muerto, que es la única forma de proceso muerto que se puede demostrar.