Evidence for an automated-report change should answer five questions: what changed, why it changed, who approved and performed it, how the result was tested, and how the prior state can be restored. The record does not need every screenshot a tool can produce. It needs a coherent chain from request to verified production result.
Preserve the change request and ownership
Record the report name, workspace, business owner, technical owner, request identifier, reason for the change, expected audience, risk level, approver, planned window, and completion time. Define the data cutoff and the decisions the report supports. If the change affects regulated, financial, safety, or personnel reporting, follow the organization’s specialized review and retention requirements.
Describe the old and new behavior in plain language. Include affected pages, calculations, filters, data sources, refresh schedules, subscriptions, exports, and permissions. Do not store passwords, tokens, or connection secrets in the ticket. Identify the approved credential owner or secret reference instead.
Keep version and deployment evidence
Save the prior and new report definitions or packages in the approved repository. Record version identifiers or hashes, dependency versions, configuration differences, and the deployment path. Microsoft’s Fabric deployment pipeline overview describes staged application lifecycle management, comparison of content in different stages, and deployment rules. Capture the comparison or equivalent diff that reviewers actually used.
Preserve the rollback package and concise restoration instructions beside the change record. A link to an undocumented old file is not a complete recovery plan. State which data or schema migrations cannot be reversed and what alternative recovery action applies.
Retain test evidence
Before deployment, record a small set of expected outputs: representative totals, row counts, date ranges, filters, calculations, permissions, refresh completion, and delivery behavior. Use a fixed data cutoff so reviewers can distinguish a change defect from newly arrived data. Save the test result, reviewer, time, and any accepted deviation.
After deployment, repeat the important controls in production or an approved production-like validation path. Record the first successful refresh, output comparison, subscription or export check, and monitoring period. When figures differ, document the reason rather than overwriting the baseline.
Link audit activity
Microsoft explains that Fabric user activities can be tracked with the audit log and that access depends on assigned audit roles. Reference or export the relevant deployment, edit, permission, refresh, export, and subscription events according to policy. An audit log is useful corroborating evidence, but it does not replace the change rationale, test result, or approval.
Keep a recipient-impact record when the report is distributed automatically. List the groups or channels affected, the first scheduled delivery under the new version, and the correction process if an error is later found. Avoid duplicating personal recipient data in unrestricted records.
Make the record durable and reviewable
Store evidence in an access-controlled system with retention, backup, and ownership. Use stable links and common export formats where practical. Periodically test that the prior package, instructions, comparison results, and audit references can still be opened by an authorized maintainer.
The minimum durable packet includes the approved request, ownership, old and new version identifiers, configuration diff, data-source and dependency inventory, test baseline, validation result, audit reference, deployment time, rollback materials, communications, and unresolved risks. Close the change only after production verification and assignment of any follow-up work.
Sources
- Overview of Fabric deployment pipelines — Microsoft
- Track user activities in Microsoft Fabric — Microsoft