Validador de Dependencia entre Campos
El validador Field Dependency (Admin Essentials) bloquea una transición de workflow cuando un campo objetivo está vacío mientras otro campo (el disparador) tiene un valor determinado. Es la forma natural de modelar relaciones del tipo "si pasa A entonces B es obligatorio" sin tener que volver obligatorio el campo en todos los casos.
Un mismo validador puede contener varias reglas independientes, cada una con su propio par disparador → requerido y, opcionalmente, su propio mensaje de error.
¿Cuándo usar este validador?
- Cuando la prioridad es Highest, exigir que el campo Assignee esté informado antes de cerrar.
- Cuando el tipo de issue es Bug, exigir que se rellene un campo personalizado "Severidad" o "Pasos para reproducir".
- Cuando una Resolution concreta se elige (por ejemplo Won't Do), exigir un comentario explicativo.
- Cuando un select de "Origen del ticket" toma un valor concreto (ej. Cliente VIP), exigir un responsable de seguimiento.
A diferencia del validador Fields Required, donde un campo se exige siempre en la transición, este validador solo lo exige cuando se cumple la condición, evitando bloqueos innecesarios.
Añadir el validador a una transición
-
En Jira, abra la configuración del workflow que desea editar:
- Para workflows asociados a un proyecto: Project settings → Workflows → Edit.
- Para workflows globales: Jira settings → Issues → Workflows → Edit.
-
Seleccione la transición que quiere proteger.
-
Abra la pestaña Validators.
-
Haga clic en Add validator.
-
En la lista de validadores disponibles, seleccione Field Dependency (Admin Essentials) y haga clic en Add.

-
Defina una o más reglas (siguiente sección) y guarde.
-
Publique el workflow para que los cambios entren en vigor.
Configurar las reglas
Al añadir o editar el validador se abre su panel de configuración (una Custom UI servida por Forge). Cada regla se configura como una fila independiente con el siguiente formato:
When field
<campo disparador>is<valor>then require<campo requerido>
Y debajo, opcionalmente, un Error message específico para esa regla.

Tipos de campo disparador admitidos
Esta versión del validador soporta como campo disparador los campos cuyo valor procede de una lista de opciones cerrada:
- System fields:
Priority,Issue Type. - Custom fields de tipo Single-select List o Radio Buttons.
Los valores disponibles se cargan automáticamente desde Jira cuando el usuario abre la lista "is".
Próximas versiones del validador ampliarán los tipos de campo disparador soportados (campos numéricos con operadores >=, <, etc., campos de texto). En esta versión los disparadores se limitan a campos con valores discretos.
Campo requerido
El campo requerido puede ser cualquier campo del catálogo de Jira (sistema o personalizado), incluyendo Assignee, Comment, Description, Labels, Fix Versions, etc. El validador comprueba que el campo tenga un valor distinto de vacío en el momento de ejecutar la transición.
Mensaje de error personalizado
Cada regla puede llevar su propio Error message. Si lo deja en blanco, el complemento muestra un mensaje por defecto del estilo "Assignee is required when Priority is Highest.".
Múltiples reglas
Puede añadir tantas reglas como necesite haciendo clic en + Add rule. Cada regla se evalúa de forma independiente y todas las que se cumplan a la vez deben superarse para que la transición se ejecute (las reglas se combinan en AND).
Comportamiento en tiempo de transición
Cuando un usuario intenta ejecutar la transición:
- Si ninguna regla se dispara (es decir, ningún campo disparador tiene el valor configurado), la transición se ejecuta con normalidad.
- Si una o más reglas se disparan y sus campos requeridos correspondientes están vacíos, la transición se aborta y Jira muestra los mensajes de error de cada regla incumplida. El issue permanece en el estado anterior.

Como con cualquier validador, recomendamos asociar a la transición una pantalla que contenga los campos requeridos. Así el usuario puede completar los campos durante la transición en lugar de descubrir el error al final.
Ejemplo: Assignee obligatorio cuando la prioridad es Highest
Suponga que el equipo desea garantizar que ningún issue de prioridad Highest avance a In Progress sin un responsable asignado.
- Edite la transición "Start Progress" del workflow.
- Añada el validador Field Dependency (Admin Essentials).
- Configure la regla:
- When field:
Priority - is:
Highest - then require:
Assignee
- When field:
- (Opcional) Error message: "Asigne un responsable antes de iniciar un issue de prioridad Highest."
- Guarde y publique el workflow.
A partir de ese momento:
- Un issue con prioridad Medium puede pasar a In Progress sin asignado.
- Un issue con prioridad Highest sin asignado se bloquea con el mensaje configurado.
Ejemplo: Comentario obligatorio según el tipo de issue
Si el equipo quiere que todos los Bugs lleven un comentario al pasar a Resolved:
- Edite la transición "Resolve" del workflow.
- Añada el validador Field Dependency (Admin Essentials).
- Configure la regla:
- When field:
Issue Type - is:
Bug - then require:
Comment
- When field:
- (Opcional) Error message: "Para resolver un bug, registre un comentario explicativo del cierre."
Otros tipos de issue (Story, Task, etc.) pasan sin requerir comentario.
Diferencias frente a "Fields Required"
| Aspecto | Fields Required | Field Dependency |
|---|---|---|
| Cuándo exige el campo | Siempre que se ejecute la transición | Solo cuando un campo disparador tiene un valor concreto |
| Reglas por validador | Una sola lista de campos exigidos | Múltiples reglas (cada una con su par disparador → requerido) |
| Mensaje personalizado | Uno solo, global | Uno por regla |
| Caso típico | "Para esta transición, siempre exige Resolution" | "Para esta transición, exige Resolution sólo cuando el tipo es Bug" |
Ambos validadores pueden coexistir en la misma transición. Si necesita una combinación, configure cada uno con su parte específica.