Change requests and review

Atlas keeps one record of your landscape. How a change reaches that record depends on the change management mode your workspace uses. An admin chooses the mode under Settings › Workspace › Change management.

Choose a mode

Simple is the default. It suits a team that wants to keep the landscape right without a formal approval step.

• People with a write role can edit directly. Use Undo where the action offers it.
• A change request is optional. Use one to group several related edits or to plan a change that takes effect later.
• The author can apply their own change request.

Review suits a team that wants to review changes before implementation. Reviewers act on each change request.

• The owner of an element and admins edit it directly. Others propose a change.
• A change request is submitted and then approved by the owner of the affected element or an admin. The author cannot approve their own, except an admin.
• For a relationship, such as a data object or capability linked to an application, the owner of either end counts as its owner. The same holds for an integration's middleware and data objects: the owner of the integration or of the IT component or data object at the other end.
• Approving and implementing are separate steps: a dated change waits until the owner implements it.

In both modes, AI agents and connectors submit proposals for a person to review. If you submitted a proposal yourself through MCP, use Atlas or ask another authorised reviewer to approve it.

A connector sync or a file import files one change request with one item per proposal, marked with its origin. Approving it adds the proposals to the catalog; rejecting it rejects them, and the next sync or import can propose them again. Populate shows each proposal with a link to its change request.

When to use a change request

Use a direct edit for corrections: an owner, a description, a classification, a wrong relationship.

Use a change request when several edits only make sense together, or when the change should be named and discussed as one thing, such as retiring an application or replacing its vendor. Give it a title that names the intent, such as "Retire Siebel CRM and move orders to Salesforce", and a description that says why.

Open Governance › Change requests and choose New change request. In the draft, add items: each item changes one field of an application (name, description, vendor or lifecycle stage) and can carry the day it takes effect. Proposals from AI agents, connectors and imports appear in the same list as submitted change requests.

Review the impact

On a change request, each existing application being changed has an Impact card. Read its affected applications and capabilities, owners to involve, sources and uncertainty reasons before deciding. Other changed elements are named separately. Unknown means an application has no recorded owner; Impact is unavailable right now means Atlas could not load the analysis, not that the change has no impact.

Edit inside an active change request

In the Atlas header, open Active change request and choose one of your own Draft or Revision requests. The selection stays active as you move between pages. A fact sheet shows a watermark and status chip so you can see that its supported inline edits add items to that request; the live record stays as it was until the request is applied or approved. Use the header selector to choose Editing live when you have finished. If a request leaves Draft or Revision, Atlas clears it and tells you. Only your own editable requests appear in the selector.

The fact sheet's Edit request action opens that request. Edits that the request cannot represent are not silently applied to the live record.

The lifecycle

In Simple mode the author can also apply a draft directly. The change request page shows only the actions you may take in your mode and role.

Planned changes

In Inbox, Waiting for review lists the newest submitted change requests. Planned changes due lists planned items dated today or earlier, with the oldest dates first. The card marks them Due today or Overdue. Select any row to open its change request.

An item can carry the day it takes effect. Leave the date empty to apply the change at approval. With a future date, approval records the decision but keeps the item out of the live record: it is planned. The Planned tab lists every planned item by date.

When the change has actually happened, the owner of the element or an admin (in Simple mode anyone with a write role) chooses Implement. Implementing confirms that the change still applies, so it is applied even if the element was edited after approval. A planned item whose date has passed is shown as overdue; Atlas never applies a plan because a date has passed. The change request is Implemented once every item is applied or explicitly rejected.

Conflicts

Each item remembers the version of the element it was written against. If someone changes that element afterwards, the change request shows a conflict, and it cannot be approved until the conflicting item is edited against the current version, or removed and added again.

Review individual items

A reviewer who can approve a submitted request or implement an approved request can reject an item without removing its record. Rejected items remain visible and are never applied. A conflict on a rejected item no longer holds up approval. The reviewer can edit an item�s JSON payload; Atlas checks it before saving and refuses the edit if the item or live target changed since the reviewer opened it. On a submitted request, the edited payload waits for approval. On an approved request, editing an open item applies it immediately.

Accept low-risk approves a submitted request, writes its decision record and applies update items. Structural creates remain open for implementation or rejection. Atlas reports how many items were applied and how many remain open. The same mode, ownership and self-approval rules apply as for ordinary approval.

What approval records

Approving a change request creates a decision record with its title, description, reviewer and every item, and marks it self-approved when the author decided it. Applied items appear in the history of the element they changed.

Relate a request to an initiative

Choose Related Initiative when creating a request to connect its concrete model edits to a larger effort. An editable request can belong to one initiative at a time. A draft can document an application in that initiative's scope; documentation coverage does not mean the work is approved, implemented or realised. See Initiatives.

Switching modes

Only an admin can switch. Change requests that are already submitted stay in the queue and are decided as before, and drafts stay drafts. Switching never changes history.

Compare a request with the live record

Open a change request to see its items with the Before value beside each proposed change. On an application fact sheet linked to that request, Compare with live shows each changed field as Before, Live and Proposed. A Conflict marker means the live value changed after the item was filed; review it before approving or applying the request. If Atlas cannot load the comparison, it says so instead of treating the fields as unchanged. See Workspace access and invitations for roles and reviewable changes for the AI client workflow.

Start with Governance in Atlas for help choosing a direct correction, a change request or a decision record.