Versión de fin de año

Esta versión incorpora un conjunto significativo de mejoras en la recepción de solicitudes, los flujos de trabajo, la gobernanza y el control de datos, diseñadas para reflejar mejor cómo operan las PMO y los equipos de proyecto en la práctica. El enfoque está en reducir la fricción en el punto de solicitud, fortalecer la gobernanza mediante una lógica de flujo de trabajo más clara, mejorar la colaboración y garantizar que los datos del proyecto y del portafolio se mantengan consistentes, controlados y auditables a medida que avanzan desde la recepción hasta la entrega.

En conjunto, estos cambios brindan a las PMO más confianza, más control y menos esfuerzo manual en todo el ciclo de vida del proyecto, desde la primera solicitud hasta la ejecución.

---

Esta versión introduce una serie de mejoras en los tableros de solicitudes comunitarias, que agilizan y clarifican la recepción de proyectos y la gestión de solicitudes, alineándolas mejor con los flujos de trabajo reales de las PMO. Ya sea que esté gestionando la recepción de proyectos, solicitudes de cambio o flujos de trabajo de gobernanza, estas actualizaciones reducen la fricción en la puerta de entrada y otorgan a las PMO mayor control sobre cómo ingresan las solicitudes al sistema.

Los tableros de solicitudes comunitarias ahora se pueden configurar para omitir el backlog y enviar las nuevas solicitudes directamente al flujo de trabajo.

Anteriormente, todas las solicitudes enviadas se colocaban en un backlog, lo que requería que un propietario o miembro del tablero las moviera manualmente al flujo de trabajo antes de que pudiera comenzar cualquier revisión o procesamiento. En muchos procesos de recepción, este paso del backlog añadía una fricción innecesaria, sobre todo cuando la primera columna del tablero ya representa la clasificación o revisión inicial.

Con esta versión, puede configurar un tablero de solicitudes comunitarias para que las nuevas solicitudes se creen directamente en la primera columna (la más a la izquierda). Esto permite que las solicitudes entren de inmediato en el flujo de trabajo y alinea el tablero de forma más cercana con la manera en que muchas PMO gestionan realmente sus procesos de recepción y revisión.

Esto resulta especialmente eficaz para la recepción de proyectos, las solicitudes de cambio o los flujos de trabajo de gobernanza en los que el backlog actuaba simplemente como un área de espera y no como un paso con verdadero significado.

Las PMO ahora tienen mayor control sobre cómo se presentan los tableros de solicitudes comunitarias a los solicitantes, lo que ayuda a mantener la experiencia de recepción enfocada e intuitiva.

Mediante la configuración Ocultar del widget de inicio en la definición del tablero, puede elegir si un tablero de solicitudes comunitarias debe aparecer en los dos puntos principales de descubrimiento de solicitudes de trabajo:

• el widget de solicitudes de trabajo de la página de Inicio, y

• la lista de tableros que se muestra cuando los usuarios seleccionan Crear → Solicitud de trabajo.

La opción Ocultar del widget de inicio le brinda un control preciso sobre cómo se muestran las solicitudes. Puede usarse para ocultar temporalmente un tablero, por ejemplo, mientras se diseña un proceso de recepción o se retira un flujo de trabajo antiguo. Un tablero también puede permanecer intencionalmente oculto mientras sigue en uso activo, con solicitudes generadas únicamente a través de su URL directa de solicitud de trabajo. Esto resulta útil cuando los envíos deben controlarse estrictamente, o incluirse en material de orientación de apoyo en lugar de hacerse ampliamente visibles.

En el caso de los tableros que permanecen visibles, ahora también puede asignarlos a categorías. Las categorías se muestran a los solicitantes al explorar los tableros de solicitudes de trabajo disponibles y ayudan a guiar a los usuarios hacia la vía de recepción correcta, como Recepción de proyectos, Solicitudes de cambio, Trabajo operativo o Revisiones de gobernanza.

Esta combinación de control de visibilidad y categorización facilita mucho la presentación de una experiencia de solicitud clara y con un propósito definido, incluso en organizaciones con múltiples canales de recepción.

Los tableros de solicitudes comunitarias ahora se pueden configurar explícitamente con un tipo de flujo de trabajo, lo que aclara cómo se pretende iniciar cada flujo de trabajo y cómo interactúa con los proyectos. Esto permite a las PMO diseñar procesos de recepción y gobernanza que se comporten correctamente, ya sea que las solicitudes se generen de forma independiente o en el contexto de un proyecto existente.

Al definir un tablero, puede elegir entre tres tipos de flujo de trabajo:

• Flujo de trabajo genérico

  Se usa para solicitudes que no son inherentemente específicas de un proyecto, o en las que la solicitud no necesita vincularse a un proyecto en el momento de su envío. Algunos ejemplos habituales son las solicitudes operativas, las consultas generales o las ideas en etapa temprana.

  Los flujos de trabajo genéricos siempre se inician fuera del contexto de un proyecto y, cuando son visibles, se accede a ellos mediante la página de Inicio o el punto de entrada Crear → Solicitud de trabajo.

• Flujo de trabajo del proyecto

  Se usa para flujos de trabajo relacionados directamente con proyectos, como solicitudes de recepción de proyectos, solicitudes de cambio o aprobaciones a nivel de proyecto.

  

  La forma en que se puede iniciar un tablero de tipo Flujo de trabajo del proyecto depende de si está oculto de los puntos de descubrimiento principales:

  • Si el tablero no está oculto del widget de inicio, las solicitudes a este flujo de trabajo se inician desde la página de Inicio o el menú Crear → Solicitud de trabajo (es decir, como un punto de entrada estándar de solicitud de trabajo).

  • Si el tablero sí está oculto del widget de inicio, el flujo de trabajo pasa a ser contextual al proyecto y puede iniciarse desde dentro de un proyecto. En este modo, la configuración Categoría del Proyecto controla qué proyectos pueden iniciar una solicitud de flujo de trabajo:

    • Si se especifica una Categoría del Proyecto, solo los proyectos de esa categoría mostrarán el flujo de trabajo en el espacio de trabajo del proyecto.

    • Si no se especifica ninguna categoría, el flujo de trabajo está disponible desde el espacio de trabajo del proyecto para todos los proyectos.

    Cuando se inicia una solicitud desde un proyecto, las propiedades del proyecto que coinciden se sincronizan con la tarjeta, de modo que la solicitud hereda el contexto del proyecto correspondiente sin necesidad de volver a introducirlo manualmente.

• Flujo de trabajo Stage Gate

  Se usa específicamente para procesos de gobernanza vinculados a Stage Gates. Al seleccionarlo, el tablero puede asociarse con uno o más Stage Gates, garantizando que las aprobaciones, revisiones o acciones de apoyo se activen como parte del ciclo de vida del proyecto, en lugar de como solicitudes independientes.

  Cuando se crea una solicitud desde un Stage Gate, las propiedades del proyecto que coinciden se sincronizan automáticamente con la tarjeta, de modo que el flujo de trabajo hereda el contexto correcto del proyecto sin necesidad de volver a introducirlo manualmente. Esto mantiene las aprobaciones de Stage Gate estrechamente alineadas con los datos del proyecto que gobiernan y mejora la trazabilidad en las decisiones de gobernanza.

Al definir de antemano el tipo de flujo de trabajo, las PMO pueden garantizar que cada tablero se muestre en el lugar correcto, reduciendo la confusión y manteniendo los procesos impulsados por solicitudes estrechamente alineados con la gobernanza del portafolio.

---

Esta versión introduce mejoras en la forma en que se crean y preparan las solicitudes de trabajo antes de entrar en los flujos de trabajo formales. En conjunto, estos cambios permiten una elaboración de borradores más flexible, una mejor colaboración y solicitudes de mayor calidad.

Cuando un tablero de solicitudes comunitarias está configurado para omitir el backlog, los solicitantes ahora pueden trabajar en una solicitud a lo largo del tiempo en lugar de tener que completarlo todo de una sola vez.

Anteriormente, todos los campos obligatorios debían completarse antes de poder guardar una solicitud. Esto a menudo obligaba a los usuarios a apresurar los envíos o a abandonar las solicitudes por completo si aún no contaban con toda la información.

Con esta versión, las solicitudes ahora se pueden guardar en la primera columna (normalmente un estado de Borrador) aunque los campos obligatorios aún no se hayan completado. Esto permite a los usuarios iniciar una solicitud, guardarla como borrador, volver más tarde y continuar trabajando en ella a medida que se dispone de la información. Los campos obligatorios solo se exigen cuando la solicitud se envía formalmente al flujo de trabajo.

Este comportamiento depende de la estructura del tablero:

• La primera columna representa las solicitudes en borrador o en curso.

• La segunda columna representa el punto en el que la solicitud está lista y entra en revisión o procesamiento formal.

Esto otorga a los solicitantes mucha más flexibilidad durante la recepción, mejora la calidad de los envíos y garantiza que las reglas de gobernanza se apliquen en el momento correcto, es decir, cuando una solicitud realmente pasa al flujo de trabajo.

Al iniciar una solicitud de trabajo, ahora se pueden agregar colaboradores mientras la solicitud aún está en Borrador. Esto permite que varias personas trabajen juntas para completar la solicitud antes de que entre en el flujo de trabajo formal.

Esto resulta especialmente útil en escenarios de recepción en los que se necesita reunir información de distintos roles, por ejemplo, combinando los detalles de entrega de un gerente de proyecto, la aportación financiera de un analista de la PMO o el contexto técnico de un experto en la materia, antes de que la solicitud esté lista para revisión.

Los colaboradores solo pueden editar la solicitud mientras permanezca en Borrador. Una vez que la solicitud se envía al flujo de trabajo, la tarjeta pasa a ser de solo lectura tanto para el solicitante como para los colaboradores, lo que garantiza que la información revisada y aprobada se mantenga estable a medida que avanza por las etapas de gobernanza o entrega.

---

Esta versión refuerza la relación bidireccional entre los tableros y los proyectos, garantizando que la información capturada mediante los flujos de trabajo se mantenga alineada con los datos del proyecto a los que se refiere. Ya sea que los proyectos se creen a partir de tableros o que las solicitudes se generen desde dentro de los proyectos, la sincronización ahora funciona en ambas direcciones para reducir la duplicación y mantener los registros consistentes.

Los tableros de pipeline de proyectos pueden definir columnas o estados específicos que activan la sincronización entre una tarjeta y un proyecto. Hasta ahora, esto se usaba principalmente para crear un nuevo proyecto: cuando una tarjeta se movía a una columna configurada, Fluid creaba el proyecto y copiaba las propiedades de la tarjeta que coincidían en el nuevo registro del proyecto.

La novedad de esta versión es que esas mismas columnas ahora se pueden configurar para sincronizar propiedades con el proyecto ya vinculado a la tarjeta, en lugar de crear un nuevo proyecto. Esto significa que, cuando una tarjeta se usa para impulsar un flujo de trabajo sobre un proyecto existente, cualquier información adicional o actualizada capturada en la tarjeta puede transferirse automáticamente al proyecto (cuando existan propiedades coincidentes). Esto resulta especialmente valioso para los flujos de trabajo de gobernanza y aprobación, en los que los datos del proyecto se van refinando progresivamente y deben reflejarse en el proyecto una vez que el flujo de trabajo alcanza un punto definido.

Además, al configurar una columna para sincronizar propiedades con un proyecto existente, también puede controlar cómo se gestiona el estado del proyecto. Seleccionar No cambiar garantiza que el estado del proyecto permanezca exactamente igual, mientras que elegir un estado específico le permite mover explícitamente el proyecto a un nuevo estado como parte del flujo de trabajo. Esto brinda a las PMO un control preciso sobre si un paso de gobernanza solo actualiza los datos del proyecto o también avanza su ciclo de vida.

La sincronización también se ha ampliado en la dirección opuesta para las solicitudes iniciadas desde un proyecto.

Cuando una solicitud se genera desde dentro de un proyecto, como una solicitud de cambio o un flujo de trabajo relacionado con un Stage Gate, las propiedades del proyecto ahora pueden sincronizarse de vuelta con la tarjeta, siempre que existan propiedades coincidentes en el tablero. Esto garantiza que las tarjetas que impulsan flujos de trabajo de proyectos reflejen siempre el contexto más reciente del proyecto, mejorando la trazabilidad y reduciendo el riesgo de incoherencias entre los datos del proyecto y las solicitudes asociadas a él.

En conjunto, estas mejoras brindan a las PMO una integración más estrecha entre la recepción, los flujos de trabajo de gobernanza y la ejecución de proyectos, favoreciendo una mejor calidad de los datos, pistas de auditoría más claras y menos esfuerzo manual a lo largo del ciclo de vida.

---

Esta versión refuerza la manera en que las decisiones impulsan el avance de los flujos de trabajo, brindando a las PMO un control más claro, una gobernanza más sólida y resultados más predecibles cuando las aprobaciones se integran en los flujos de trabajo del tablero.

Los flujos de trabajo han admitido desde hace tiempo la creación automática de decisiones cuando una tarjeta llega a una columna o estado específico. En esta versión, esa capacidad se amplía de modo que lo que sucede a continuación esté determinado directamente por el resultado de la decisión.

Ahora puede usar expresiones para controlar cómo se mueve una tarjeta una vez que una decisión se aprueba o se rechaza. Por ejemplo, una tarjeta puede moverse automáticamente a una columna Aprobado cuando se acepta, volver a Revisión adicional cuando se rechaza, o permanecer en la misma columna según el resultado. Esto permite que las decisiones de gobernanza dirijan activamente el flujo de trabajo, en lugar de limitarse a registrar una aprobación de forma aislada.

Este comportamiento se configura directamente a nivel de columna en el tablero. Al definir una columna, active las Reglas de flujo de trabajo de aprobación, especifique quiénes son los aprobadores de la decisión (mediante roles estáticos o dinámicos) y, a continuación, defina cómo debe moverse la tarjeta según el resultado de la decisión.

Esto significa que la lógica de aprobación, la responsabilidad y el avance del flujo de trabajo se definen todos en un mismo lugar, lo que deja claro cómo se traducen las decisiones de gobernanza en pasos concretos dentro del proceso.

En el caso de las decisiones iniciadas como parte de un flujo de trabajo, los resultados de aprobación ahora son definitivos. Una vez que un aprobador aprueba o rechaza una decisión, el estado no se puede cambiar.

Esto evita que las decisiones se reviertan después de tomadas, garantizando una pista de gobernanza clara y auditable. Si las circunstancias cambian y se requiere un resultado distinto, debe generarse y reasignarse una nueva decisión, en lugar de editar la original. Este comportamiento se aplica únicamente a las decisiones impulsadas por flujos de trabajo y no afecta a las decisiones creadas manualmente fuera de los flujos de trabajo.

Para reforzar esta claridad, las decisiones impulsadas por flujos de trabajo se han simplificado:

• Se ha eliminado la opción Condicional.

• El botón de acción ahora dice claramente Enviar, en lugar de Guardar.

• Los aprobadores solo pueden aprobar o rechazar la decisión.

Esto elimina la ambigüedad en los puntos de decisión y garantiza que las decisiones impulsadas por flujos de trabajo se comporten de forma consistente, lo que fortalece la gobernanza y la auditabilidad en los procesos de aprobación.

---

Esta versión amplía significativamente el papel de las propiedades personalizadas como mecanismo central de gobernanza y control de datos en toda la plataforma Fluid. Las PMO ahora cuentan con un control mucho más fino sobre quién puede ver y editar los datos, cómo se derivan y restringen los valores, cómo se capturan y gobiernan los documentos, y cómo se reutilizan las definiciones de propiedades entre tableros, proyectos y entornos.

En conjunto, estas mejoras fortalecen la consistencia de los datos entre la recepción y la entrega, reducen la configuración manual y los errores, y garantizan que la información crítica de proyectos y gobernanza se capture, proteja y reutilice de forma controlada y auditable a medida que el trabajo avanza de la solicitud a la ejecución.

Ahora puede definir un modo de visibilidad para cada propiedad personalizada, lo que le brinda un control preciso sobre quién puede verla y quién puede editarla.

Para cada propiedad personalizada, puede elegir uno de los siguientes modos de visibilidad:

• Editable por todos los usuarios
  La propiedad es visible para todos los usuarios y puede ser editada por cualquiera que tenga derechos de edición sobre el elemento. Por ejemplo, en Detalles del proyecto, un gerente de proyecto puede actualizar una propiedad configurada como Editable por todos los usuarios.
  Este modo es adecuado para información general del proyecto que se espera mantener de forma colaborativa, como notas de entrega o contexto de alto nivel.

• Oculta para usuarios no administradores
  La propiedad solo es visible y editable para los administradores del proyecto. Los usuarios no administradores no pueden verla en absoluto. Por ejemplo, en un proyecto, esta propiedad sería visible para un Administrador del proyecto, pero estaría completamente oculta para un gerente de proyecto que consulte los Detalles del proyecto.
  Esto resulta útil para campos internos de gobernanza, indicadores de control o datos que deben permanecer estrictamente dentro del equipo de la PMO o de administración.

• Visible pero de solo lectura para usuarios no administradores
  La propiedad es visible para todos los usuarios, pero solo los administradores del proyecto pueden editarla. Por ejemplo, un gerente de proyecto verá la propiedad en la página de Detalles del proyecto, pero no podrá modificarla, mientras que un Administrador del proyecto sí podrá actualizar el valor.
  Esto es ideal para información controlada, como resultados de gobernanza, indicadores financieros o valores calculados que deben ser transparentes, pero protegidos frente a ediciones manuales.

• Visible y de solo lectura para todos los usuarios
  La propiedad es visible para todos y no puede ser editada por ningún usuario, ni siquiera por los administradores del proyecto.
  Este modo se usa normalmente cuando un flujo de trabajo o un proceso automatizado completa el valor de una propiedad. Por ejemplo, cuando los datos de aprobación de un proyecto se escriben como parte de un flujo de trabajo de recepción o de un Stage Gate, los valores deben permanecer bloqueados una vez aprobado el proyecto, garantizando que las decisiones de gobernanza capturadas durante el flujo de trabajo no puedan alterarse posteriormente.

Estos modos de visibilidad permiten a las PMO equilibrar transparencia y control, poniendo a disposición la información clave donde aporta valor, al mismo tiempo que protegen los datos críticos o sensibles frente a cambios no deseados.

Esta versión introduce las expresiones de lógica dinámica, que permiten que los datos ya capturados en Fluid impulsen cálculos, decisiones y comportamientos del flujo de trabajo de forma automática.

Las expresiones de lógica dinámica son pequeñas fórmulas que se evalúan en tiempo real contra el proyecto, el tablero o cualquier otra entidad. A medida que los valores cambian, la expresión se vuelve a evaluar automáticamente, garantizando que los resultados se mantengan consistentes sin intervención manual.

Formularios y captura de datos más inteligentes

Puede configurar propiedades personalizadas para que se rijan por expresiones, lo que permite calcular sus valores automáticamente a partir de otros datos introducidos en el formulario. Esto elimina la necesidad de actualizaciones manuales y garantiza que los valores se mantengan consistentes a medida que cambian las entradas.

Puede consultar la lista completa de expresiones y sintaxis compatibles en la documentación de Expresiones de lógica dinámica.

Por ejemplo:

• Un formulario de recepción de proyectos captura Costo estimado y Porcentaje de capitalización

• Un tercer campo, Monto capitalizado, se calcula automáticamente mediante una expresión

• A medida que el usuario actualiza cualquiera de las dos entradas, el valor calculado se actualiza al instante

Decisiones impulsadas por flujos de trabajo y movimiento de tarjetas

Las expresiones de lógica dinámica se pueden usar dentro de las reglas de decisión de flujo de trabajo para controlar qué sucede con una tarjeta una vez que se ha aprobado o rechazado una decisión de aprobación vinculada.

Cuando una tarjeta llega a una columna configurada para generar automáticamente una decisión de aprobación, puede definir reglas basadas en expresiones que determinen cómo debe moverse la tarjeta después de que la decisión se apruebe o se rechace. Esto permite que los resultados de aprobación impulsen el avance del flujo de trabajo de forma consistente y basada en datos.

Por ejemplo, cuando una decisión se aprueba, se puede evaluar una expresión para decidir el siguiente paso:

• Enviar la tarjeta a Revisión financiera si el presupuesto previsto supera un umbral definido

• Pasar directamente a Evaluación de beneficios para solicitudes de menor valor

Cuando una decisión se rechaza, la tarjeta puede dirigirse a un estado fijo, como Se requiere más información, garantizando que la solicitud regrese al punto correcto para su aclaración o corrección.

Esta lógica se define directamente en la columna del tablero mediante expresiones dinámicas. Las expresiones evalúan los datos ya capturados en la tarjeta, como el presupuesto, para determinar automáticamente el resultado adecuado.

Al combinar decisiones automatizadas con enrutamiento impulsado por expresiones, los flujos de trabajo pueden aplicar las reglas de gobernanza de manera consistente, reducir el criterio manual y garantizar que las solicitudes avancen por las etapas de revisión correctas según su contenido real, en lugar de un proceso único para todos los casos.

Las propiedades personalizadas de tipo Persona ahora se pueden configurar con expresiones de búsqueda para controlar quién puede seleccionarse para la propiedad.

Cuando se define una expresión de búsqueda, los usuarios siguen seleccionando manualmente a una persona, pero la lista de personas disponibles se filtra automáticamente según los criterios configurados. Esto evita que los usuarios seleccionen a alguien fuera de las reglas definidas, a la vez que mantiene explícita la elección final.

En el ejemplo que se muestra a continuación, se ha creado una propiedad personalizada Propietario de negocio como propiedad de tipo Persona y se ha configurado con un filtro de búsqueda:

• El Campo de búsqueda especifica qué propiedad del registro de usuario debe evaluarse (por ejemplo, Línea de negocio).

• El Valor de búsqueda usa una expresión que hace referencia a otra propiedad del elemento, en este ejemplo, la Business Line del proyecto.

• Como resultado, solo los usuarios cuya Línea de negocio coincida con la Business Line del proyecto estarán disponibles para su selección al completar el campo Propietario de negocio.

Esto significa que los usuarios no pueden asignar accidentalmente a alguien fuera del ámbito organizativo pertinente, a la vez que se conserva el control sobre la selección final.

Este enfoque resulta especialmente útil para aplicar reglas de propiedad, guiar la selección de aprobadores y garantizar una asignación de roles consistente en proyectos y flujos de trabajo.

Las propiedades personalizadas ahora admiten un nuevo tipo Documento, que permite capturar documentos como datos estructurados del proyecto en lugar de como archivos adjuntos generales.

Al crear una propiedad personalizada, ya sea para proyectos, tableros, cronogramas, tareas, impactos u otras entidades, ahora puede definir la propiedad como tipo Documento. Los usuarios pueden cargar uno o más documentos directamente en esa propiedad, dejando claro por qué existe el documento y con qué se relaciona.

Cuando se carga un documento mediante una propiedad de tipo Documento:

• el documento se muestra directamente junto al valor de la propiedad, y

• también se añade a la ubicación de documentos correspondiente para la entidad:

  • la sección Documentos para los espacios de trabajo de proyectos, o

  • la sección Adjuntos para elementos como tarjetas, tareas programadas o impactos.

Esto garantiza que los documentos sean visibles de forma contextual y, al mismo tiempo, accesibles de forma centralizada.

La aplicación se puede configurar para bloquear los documentos que se incorporan como parte de un flujo de trabajo, independientemente de cómo se hayan añadido a la tarjeta.

Esto se aplica a:

• los documentos cargados mediante una propiedad personalizada de tipo Documento, y

• los documentos cargados directamente en la sección Adjuntos de la tarjeta.

Cuando una tarjeta avanza por un flujo de trabajo y los documentos se sincronizan con un proyecto, esos documentos se copian en la sección Documentos del espacio de trabajo del proyecto. Una vez que se produce la sincronización y el bloqueo de documentos está habilitado, los documentos quedan completamente bloqueados en el proyecto.

Los documentos bloqueados:

• no se pueden eliminar, ni siquiera por los administradores del proyecto, y

• no se pueden editar ni reemplazar.

Tenga en cuenta que, mientras la tarjeta permanezca dentro del flujo de trabajo, los propietarios y miembros del tablero pueden seguir añadiendo o eliminando documentos según sea necesario. Sin embargo, una vez que el flujo de trabajo alcanza el punto en el que los documentos se sincronizan con el proyecto, esos documentos se conservan como parte del registro formal del proyecto.

Esto garantiza que los documentos aprobados o enviados mediante flujos de trabajo de gobernanza, como casos de negocio, aprobaciones o evidencia de cumplimiento, permanezcan inmutables una vez que forman parte del proyecto, proporcionando una sólida auditabilidad y protegiendo la integridad de las decisiones de gobernanza.

Las propiedades personalizadas ahora se pueden reutilizar más fácilmente entre tableros y proyectos, sin necesidad de duplicar configuraciones completas. Puede copiar propiedades directamente desde otro tablero, o exportarlas e importarlas mediante un archivo JSON, con control total sobre qué propiedades se aplican y cómo se combinan.

Desde la página Configuración del tablero o la página Administrar propiedades personalizadas de proyectos, ahora puede:

• Copiar propiedades personalizadas de otro tablero
  Seleccione un tablero existente del que desee copiar las propiedades. Una vez seleccionado, se muestra la lista de propiedades disponibles para copiar, lo que le permite desmarcar cualquier propiedad que no desee incluir. Esto le brinda un control preciso sobre qué definiciones de propiedades se copian en el tablero o proyecto de destino. A continuación, decida si desea:

  • Reemplazar todas las propiedades existentes en el destino por las seleccionadas, o

  • Fusionar las propiedades, añadiendo solo aquellas que aún no existan y dejando sin cambios las definiciones existentes.

• Exportar propiedades personalizadas a un archivo JSON
  Exporte las definiciones de propiedades personalizadas como un archivo JSON para poder reutilizarlas en otro lugar. Esto se usa normalmente para mantener alineadas las propiedades del tablero y del proyecto, reutilizar definiciones de propiedades sin duplicar tableros completos y trasladar la configuración de forma segura entre entornos, como al promover cambios de un entorno de pruebas a producción.

• Importar propiedades personalizadas desde un archivo JSON
  Cargue un archivo JSON exportado previamente y revise la lista de propiedades que contiene. Antes de aplicar la importación, puede seleccionar o deseleccionar propiedades individuales y elegir si desea reemplazarlas o fusionarlas con las existentes.

En todos los casos, las propiedades copiadas o importadas conservan su estructura, tipo de dato y configuración, lo que permite una captura de datos consistente entre tableros y proyectos, reduciendo la configuración manual y el riesgo de desalineación.

---

Esta versión introduce nuevas funcionalidades que brindan a las PMO mayor control sobre cómo se comportan los Stage Gates a lo largo del ciclo de vida del proyecto. En conjunto, estas mejoras permiten que la gobernanza sea tanto más estricta cuando es necesario como más flexible cuando corresponde, garantizando que los proyectos se gobiernen de forma consistente sin dejar de reflejar las condiciones reales de entrega y las reglas del portafolio.

Esta versión refuerza la gobernanza a nivel de fase al permitir que la progresión de fases del proyecto se controle explícitamente mediante la finalización de los Stage Gates.

Cuando se aplica una metodología a un proyecto y se definen fases con puertas asociadas, ahora puede exigir una regla que impida que el proyecto avance a la siguiente fase hasta que se hayan completado todas las puertas de la fase actual. Esta configuración se aplica a nivel de aplicación y la establece el Administrador del proyecto, garantizando un comportamiento consistente en todos los proyectos que usan metodologías gobernadas.

El comportamiento está diseñado para ser práctico y no disruptivo:

• Si un proyecto intenta avanzar pero una o más puertas siguen pendientes, el proyecto permanece en la fase más temprana con puertas incompletas.

• Cuando las puertas están completas, el proyecto puede avanzar de forma natural a la siguiente fase conforme a sus fechas planificadas.

• Si un proyecto ha superado su fecha de finalización o no aplica ninguna fase válida, la fase actual se borra en consecuencia.

Esto garantiza que los puntos de control de gobernanza realmente controlen el flujo de entrega, reduciendo el riesgo de cambios de fase prematuros y manteniendo un modelo de progresión razonable para los proyectos activos.

Los Stage Gates ahora se pueden mostrar u ocultar condicionalmente mediante expresiones basadas en propiedades del proyecto.

Esto significa que las PMO pueden definir reglas que determinen si una puerta es aplicable a un proyecto. Por ejemplo, una puerta podría ser visible solo para proyectos por encima de un determinado umbral de presupuesto, para tipos de proyecto específicos, o para iniciativas dentro de un portafolio o área de negocio en particular.

En el ejemplo anterior, la puerta Aprobación arquitectónica solo será obligatoria para proyectos en los que el impacto del cambio sea Alto o Medio.

Mediante el uso de expresiones vinculadas a los datos del proyecto, los marcos de gobernanza pueden hacerse más adaptables sin duplicar metodologías ni crear puertas innecesarias para proyectos en los que no aplican. Esto ayuda a reducir el ruido en los flujos de entrega, a la vez que garantiza que se aplique el nivel de gobernanza adecuado a los proyectos correctos.

Tenga en cuenta que las expresiones de Stage Gate dependen de una funcionalidad específica. La instancia de la aplicación debe estar configurada para habilitar esta capacidad antes de que se puedan definir y usar expresiones en los Stage Gates.

Cuando está habilitada la configuración de la aplicación que impide avanzar a la siguiente fase hasta que se completen todas las puertas de la fase actual, ahora se aplica un control adicional dentro de la misma fase.

En este modo, un proyecto no puede completar una puerta de salida de una fase a menos que ya se hayan completado todas las puertas de entrada de esa fase. Esto garantiza que los proyectos no puedan omitir las aprobaciones de entrada requeridas y pasar directamente a las decisiones de salida de fase.

Este comportamiento refuerza la secuencia correcta de gobernanza al garantizar que:

• las verificaciones y aprobaciones de entrada se completen antes de que se tomen las decisiones de salida, y

• la finalización de una fase refleje una ruta de gobernanza plenamente conforme, y no solo una aprobación final.

Junto con el bloqueo de la progresión de fases y la visibilidad condicional de puertas, esto proporciona a las PMO un marco de Stage Gate robusto y consistente que aplica la gobernanza en el orden correcto, sin dejar de ofrecer flexibilidad donde las reglas se relajan de forma intencionada.

---

Esta versión amplía las notificaciones para mejorar la visibilidad en los flujos de trabajo y los eventos del ciclo de vida del proyecto, garantizando que las partes interesadas se mantengan informadas sin tener que vigilar activamente los tableros o paneles.

Se han introducido varias notificaciones nuevas para mejorar la transparencia en los procesos de recepción, solicitudes y decisiones.

Cuando una decisión se enruta a un Work Hub, ahora se notifica al propietario del Work Hub, lo que garantiza que las solicitudes de aprobación enviadas a los equipos tengan un responsable claro y se actúe sobre ellas.

Los solicitantes también reciben una notificación cada vez que cambia el estado de su solicitud de trabajo, manteniéndolos informados a medida que su solicitud avanza por las etapas de revisión, aprobación o rechazo.

Además, cuando se aprueba una solicitud de recepción y se crea un espacio de trabajo de proyecto, se envía una notificación tanto al Solicitante como al Gerente de proyecto. Esto confirma que el proceso de recepción se ha completado y señala claramente que el proyecto está listo para avanzar, cerrando el ciclo entre solicitud, aprobación e inicio del proyecto.

También se han añadido nuevas notificaciones para mejorar la visibilidad de los cambios clave en los proyectos.

Ahora se notifica a los gerentes de proyecto cuando:

• cambia el estado del proyecto, y

• se actualiza la asignación del Gerente de proyecto principal.

Estas notificaciones garantizan que los gerentes de proyecto se mantengan al tanto de las actualizaciones importantes de titularidad y ciclo de vida, reduciendo el riesgo de cambios no advertidos y mejorando la percepción diaria de la situación.

---

Esta versión introduce mayor flexibilidad en la forma en que se bloquean y gestionan los campos del proyecto, ayudando a las PMO a equilibrar el control de gobernanza con las necesidades diarias de entrega.

Los proyectos ya se pueden configurar para bloquear campos específicos, de modo que solo los administradores del proyecto puedan actualizarlos. Uno de estos campos es el campo PM principal, que a menudo está estrictamente gobernado en entornos regulados o controlados a nivel de portafolio.

Ahora se ha añadido una nueva opción Allow Primary PM Edits que funciona junto con esta configuración de bloqueo de campos. Esto permite a las organizaciones decidir si:

• todos los campos bloqueados deben permanecer restringidos únicamente a los administradores del proyecto, o

• el campo PM principal permanece editable, incluso cuando otros campos del proyecto están bloqueados.

Esto brinda a las PMO un control más fino sobre la gestión de la titularidad, por ejemplo, permitiendo que los traspasos de PM se realicen sin problemas y sin requerir la intervención de un administrador, sin dejar de proteger otros campos sensibles del proyecto.

---

La funcionalidad de edición masiva para tableros se ha mejorado para permitir establecer o actualizar el Solicitante en varias tarjetas de solicitud de trabajo a la vez.

Esto resulta especialmente útil en escenarios en los que las solicitudes se enviaron en nombre de otras personas, se importaron de forma masiva o requieren corrección después del envío.

Para actualizar solicitantes de forma masiva, exporte el archivo de edición masiva del tablero, complete la columna RequestedBy con el valor correspondiente para cada tarjeta y vuelva a cargar el archivo en Fluid.