We recently updated our risk register workflow in MC 2022.1 to add additional approval steps for high-severity risks. Since the change, we’re seeing confusion around risk matrix versioning - specifically when users view historical risk assessments.
The problem: When a risk assessment was completed under the old workflow, the risk matrix version at that time showed different severity thresholds. Now when users access those older assessments, they’re seeing the current matrix version applied, which changes the risk scoring context. This is causing audit confusion because the documented rationale doesn’t match what’s displayed.
Additionally, I’m concerned about workflow rollback impact if we need to revert. We had one instance where we tested rolling back the workflow, and it seemed to orphan some in-progress risk assessments. User permissions on risk artifacts also seem inconsistent - some users who could previously view historical assessments now get permission errors.
Has anyone dealt with risk matrix version control issues after workflow modifications? How do you maintain version integrity for historical records while updating current processes?
Quick addition on the permissions issue - check if your workflow change modified the record ownership model. In MC 2022.1, there’s a known behavior where workflow updates can reassign record owners if the approval chain changes. This affects downstream permissions because ownership determines base access rights. Navigate to the affected risk assessments and verify the Owner field hasn’t changed unexpectedly.
Let me address all three issues you’re facing comprehensively:
Risk Matrix Version Control:
The core issue is that MC 2022.1 requires explicit version control enablement for risk matrices. Navigate to Risk Management > Configuration > Matrix Settings and enable “Maintain Version History”. This creates immutable snapshots of your matrix configuration tied to each assessment record. For existing historical records, you’ll need to run a version reconciliation:
- Export all risk assessments with their creation dates
- Identify which matrix version was active during each assessment period
- Use the Data Import tool to update the matrix_version_reference field for historical records
This preserves audit integrity by ensuring each assessment displays with its original scoring context.
Workflow Rollback Impact:
Never rollback a workflow with in-progress records - this is a critical mistake. MC’s workflow engine maintains state through forward-only transitions. When you rollback, in-progress records become orphaned because their current state doesn’t exist in the reverted workflow definition. Instead, implement workflow versioning:
- Create Risk Register Workflow v2.0 as a new workflow
- Configure a migration path from v1.0 to v2.0 for in-progress records
- Use MC’s workflow migration utility (Admin > Workflow Management > Migration Tool) to transition active records
- Keep v1.0 active in read-only mode for historical record access
This approach maintains data integrity and provides a clear rollback path if needed - simply stop assigning new records to v2.0.
User Permissions on Risk Artifacts:
The permission errors stem from role mapping changes in your updated workflow. When you modify approval steps, MC doesn’t automatically extend permissions to users with historical access rights. Fix this by:
- Go to Admin > Security > Role Definitions
- Create a “Risk Assessment Viewer - Historical” role
- Grant read permissions to both old and new workflow states
- Add affected users to this role
- In Workflow Configuration, map this role to all workflow states (both current and legacy)
Additionally, check if your workflow change affected the record lifecycle. If you added approval steps, records may have transitioned to new lifecycle states that have different permission requirements. Verify that user groups have appropriate access to all lifecycle states in the risk assessment record type.
For ongoing audit readiness, implement these controls:
- Enable audit logging for all risk matrix configuration changes
- Create a validation report that cross-references assessment dates with active matrix versions
- Document your workflow versioning strategy in your quality management procedures
- Schedule quarterly reviews of permission mappings across workflow versions
This comprehensive approach addresses version control, prevents rollback issues, and maintains proper permissions across workflow iterations while ensuring audit trail integrity.
The audit confusion is a real concern. What we did was create a custom report that explicitly shows the risk matrix version ID alongside each assessment record. This gives auditors visibility into which scoring criteria were active at the time. You can pull this from the risk assessment metadata table - the matrix_version_ref field should be populated if version control is enabled. Also consider adding a read-only field to your risk assessment form that displays the matrix version number at time of creation.