Qué lee y qué no.

Qué lee

Solo lo que necesita una evaluación, y siempre únicamente leyendo:

• Metadatos de soluciones y componentes: qué tablas, flujos, aplicaciones, plug-ins, roles y recursos web existen y cómo están configurados.
• El contenido de un archivo de solución exportado, cuando se proporciona uno.
• Uso e historial de ejecución, en la medida en que la conexión llegue: cuántas veces se ejecutó un flujo, cuántas falló, cuánto tardó un paso de plug-in.
• Los resultados del Power Apps checker de Microsoft, donde se haya ejecutado.

Qué descarta

Algunas cosas se leen de paso y no se conservan:

• Los secretos encontrados dentro de una definición se cuentan, nunca se almacenan y nunca se muestran. Un hallazgo dice que hay un secreto y dónde, no cuál es.
• Las credenciales de una conexión viven en Azure Key Vault y se referencian por nombre. La base de datos del producto no contiene ningún secreto.
• Los datos de negocio de las tablas no se leen. El producto cuenta filas; no las mira.

Qué se niega a hacer

No son ajustes. No hay configuración que active ninguno de ellos:

• Nunca escribe en un entorno de Power Platform, en ningún modo.
• Nunca publica en Azure DevOps, Jira o GitHub nada que nadie haya seleccionado, y nunca escribe en el entorno que ha leído.
• Nunca muestra el parque de un encargo a alguien a quien no se le ha concedido acceso a ese encargo.

Qué va en los documentos

Tres cosas salen del producto, y conviene saber exactamente qué hay en cada una:

• El libro. Nombres de componentes, nombres de soluciones, los hallazgos y su evidencia, las estimaciones y el backlog. Los nombres de componentes son la nomenclatura propia del cliente, así que trate el archivo como trataría su exportación de solución.
• El informe. El mismo material en forma de relato, más la lista de lo que no pudo comprobarse. Se nombran componentes allí donde un hallazgo trata de una cosa concreta.
• Los elementos de trabajo. Títulos, descripciones y criterios de aceptación, escritos en el propio proyecto de Azure DevOps, proyecto de Jira o repositorio de GitHub del cliente. Nada sale de su tenant que no estuviera ya dentro.

Eliminar un encargo

Eliminar un encargo elimina sus conexiones, sus ejecuciones, su inventario, sus hallazgos, sus estimaciones y su backlog, en una sola operación y sin papelera. Los elementos de trabajo ya publicados en el Azure DevOps, el Jira o el GitHub de un cliente son suyos y no se tocan.

Dónde se ejecuta

En Microsoft Azure, en una región elegida para el despliegue, en la propia suscripción de Capgemini. La base de datos solo es accesible para la identidad administrada del producto; no hay contraseña que filtrar, porque no hay contraseña. Lo único que sale de esa suscripción va al propio Power Apps checker de Microsoft, donde se analiza un archivo de solución en una región elegida en la conexión, y a Azure OpenAI, que estima hallazgos y lee descripciones cuando una ejecución puede usar un modelo. Ese despliegue está en la zona de datos de la UE y Microsoft no entrena modelos con lo que se le envía.

Cookies en este sitio

Este sitio público coloca una cookie, y solo si usa el interruptor de claro y oscuro: recuerda cuál eligió. No hay analítica, ni rastreo, ni script de terceros, ni fuente, imagen u hoja de estilos cargada desde ningún sitio que le vería llegar. Iniciar sesión coloca una cookie de sesión, y es la que le mantiene dentro.