Data changes
Changes to production data get their own governed flow, with business and technical authorization kept apart.
Why a separate flow
A change to data is authorized by different people than a code release. Level 1 authorization decides whether the change should happen at all; DB authorization, by the database team, decides whether the script is safe to run. A Data Change keeps those two decisions separate.
The phases
New, Development, Code Review, Level 1 authorization, DB authorization, Database (where the database team runs the change), Applied and Done — plus Failed, for a change that could not be applied, and Cancelled.
Authorization
At each gate, the holders of that gate's permission record authorizations and rejections in the Authorizations tab — as many as needed while the change waits. It moves on only after the latest decision of the current cycle is an authorization, and every decision stays in its history.
- The “Analista Datos” role writes the change and requests authorization, but cannot authorize it.
- The “Administrador de Datos” role reviews, authorizes and applies it, but cannot create one.
- A workspace-wide authorization queue lists what is waiting and what has been authorized.
- A DB authorization can schedule an execution window; its card then shows whether the change was executed within it or late.
Board and reports
- Data changes have their own tab on the team board and on the workspace-wide change board.
- A report tab analyses authorization outcomes, rollbacks, schedule compliance and the components and applications each change touches.