Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceModulesChange Management

Change Management

The Change Management module governs controlled changes to systems, configurations, documents, forms, releases, and other records that have reached an approved, live, published, or otherwise controlled state.

It records the change request, impact, risk, testing, rollback, authorization, implementation, evidence, and post-implementation review posture. It does not perform the source change itself. DMS still owns document versions, Forms still owns form versions, and engineering systems still execute deployments.

When To Use It

Use Change Management when:

  • a framework, regulator, customer policy, or contract requires controlled change with approval, testing, rollback, and evidence;
  • a controlled document or published form should require authorization before it is reopened, revised, replaced, or structurally changed;
  • production configuration changes need a point-in-time governance record;
  • releases need a record of scope, schedule, rollback, and verification;
  • emergency changes need retrospective evidence and approval.

Do not use it as a ticketing queue or deployment system. It is the governance record around a change.

What You Manage

Current workspace surfaces include:

  • Change requests for proposed, approved, scheduled, implemented, closed, rejected, cancelled, and archived changes.
  • Configuration baselines for point-in-time baseline records.
  • Releases for grouped operational or technical releases linked to change requests where needed.

Change requests can store snapshots for change scope, impact, risk, testing, rollback, acceptance, emergency justification, authorization, implementation, evidence references, and post-implementation review.

Change Gates

Other Novantra modules can ask Change Management whether a controlled action is allowed. A change gate can return:

  • Not required when the source module policy does not require a change.
  • Required when a change request is needed but not linked yet.
  • Pending when a linked request exists but is not approved.
  • Authorized when a linked request is approved, scheduled, or implemented.
  • Blocked when the linked request is rejected, cancelled, closed before use, archived, or otherwise unsuitable for the action.

The source module still performs the actual action after authorization. Change Management records the authorization and evidence posture.

Change request lifecycle actions now evaluate the persisted review and lifecycle refs before material transitions. When a transition is approved, blocked, held for review, or closed without an applicable policy, the result is recorded as a workflow gate outcome and appears in Activity, work-management, posture, and audit-package descriptors. The gate result is evidence about the governance decision; it does not execute the operational deployment or document change.

Common Workflow

  1. Create a change request with the target record, change kind, and reason.
  2. Add impact, risk, rollback, testing, and evidence context.
  3. Submit the request.
  4. Approve or reject it according to your governance process.
  5. Schedule the implementation when needed.
  6. Mark the change implemented and capture the implementation evidence.
  7. Close the change after post-implementation review.

Every submitted write and final lifecycle outcome is captured in the workspace Audit Log. Change request detail pages also show the current lifecycle state and available actions.

  • Forms - published forms can require a governed change before structural changes.
  • DMS - approved or live document versions can require a governed change before revision.
  • Audit Packages - change evidence can be bundled for reviews and audits.
  • Secure Development - release and test gates can link to change requests.
  • Vulnerability Management
    • patch rollout evidence can link to change requests.
Last updated on
Party EngagementsVulnerability Management