Removals

Goal: Remove things from a workspace safely, and know exactly what a Deploy will tear down.

When a removal takes effect

Before a delete, OpenX checks whether the record has anything running in Azure. What happens next depends on the answer:

The record	What a removal does
An access right, an access configuration or a job identity	It is removed like any other edit, with no confirm. Save to keep the change; there is nothing to Deploy
Has nothing running in Azure: never deployed, or a surface or warm query	A confirm says so, and the record is removed from the canvas. Save to keep the change; there is nothing to Deploy
Runs in your cloud (a deployed data connection, simulator, API source or workbench)	It stays on the canvas, greyed out, and waits for the next Deploy. Nothing in your cloud changes until then

Removing something yourself

1. Select the node on the canvas.
2. In the inspector, press the delete icon (tooltip Delete Node).
3. If nothing of the record runs in Azure (it was never deployed, or it is a surface or a warm query), a confirm opens with This was never deployed. It will be fully removed from the flow. (or Nothing of it is running in Azure. It will be fully removed from the flow.). Its title names the record, for example Remove data connection 'Line 3 sensors', and it lists anything that goes with it. Press Remove. An access right, access configuration or job identity has no confirm: it is removed as an edit.
4. If the record runs in your cloud, there is no confirm: it is marked for removal at once. The node stays on the canvas, greyed out, and its inspector shows what the removal will do and whether it still bills until Deploy, any delete settings its kind has, and one action, Restore.
5. Save. Deploy waits until your changes are saved.

The Deploy button counts what is waiting: Deploy · 1 removal, Deploy · 3 removals, and so on.

When nothing else describes it, the inspector of a waiting node says:

Waiting to be removed on the next Deploy. Nothing has been torn down yet: it still answers, still runs and still costs until then.

When other records are still attached

Most records that something else still points at - a surface that still holds nodes, a database a warm query still reads - are not refused for that. Where a confirm shows it, the warning names what is still attached, for example:

A surface cannot be removed while it still holds things. Remove what is listed first, or remove it together with the surface. Still attached (2): Line 3 sensors, Shift report

The records listed are not removed with it. Remove or disconnect them yourself, or keep them. (A line that reads Also removes N: ... is different: those records do go with it.)

Two are refused instead: a database container that a warm query or surface still reads, and an access configuration that people still hold access from. Disconnect or withdraw those first.

When a removal is refused

Some removals are always refused, because going ahead would break something or leave it running with nothing pointing at it. The refusal says why in one sentence. See A removal was refused for every reason and what to do.

Taking something off one surface

Taking a record off one surface removes only its place on that surface; the record stays in the workspace. It applies like any other edit, tears nothing down in your cloud, and is not counted on the Deploy button.

Removals proposed by Azi or an agent

Azi, or an agent connected over MCP, can propose a removal. It waits in Proposals like any other proposal, and only a person can accept it: a removal needs a person's confirmation, so even Greenfield never accepts one for you.

Accepting it opens a confirm with the button Accept removal. Its last line says when the removal takes effect:

• If it was built in the cloud, it stays until the next Deploy removes it; if it never was, it is removed when you accept.
• For a kind that runs nothing in Azure: It is removed when you accept. There is nothing to Deploy.
• For a record's place on one surface: This takes effect when you accept. There is nothing to Deploy.

Once accepted, a removal that waits for Deploy behaves like one you made yourself: greyed on the canvas, waiting, and restorable.

Restoring a removal

You can bring back anything that is waiting, at any point before Deploy:

• On the node: select it and press Restore in the inspector.
• In Proposals: the Waiting for Deploy (N) section lists every waiting removal, each with Restore. When more than one is waiting, Restore all (N) restores them in one step.

Save after restoring.

Deploying

Press Deploy in the top bar. Nothing runs yet: the Deploy window opens first, headed Review before you deploy, and says:

Everything below is what this deploy would do to your workspace. Nothing has happened yet.

Section	What it shows
New	Records that will be created in your cloud
Changed	Records whose deployed settings will change
Removing	Everything waiting to be removed, each with who staged it and how (for example from the canvas or from an accepted proposal)
In progress	A deploy that is already running, step by step

The window can also show Live now (deployed and left alone by this Deploy) and Not in this Deploy (proposals still waiting, which never count toward the Deploy). When the plan says where each record goes, New and Changed are grouped as Shared environment, Your private cloud and Workspace only.

A row in Removing asks How much of it goes: everything goes, or configuration only. A kind with delete settings of its own shows those instead. Until you save, the window reminds you: "Your handling choice is saved with your next Save, and takes effect on the deploy after that."

Press Deploy in the window to run it. You can close the window at any time; the deploy keeps running, and you can come back to it.

If the list changed

If something was staged or restored after you opened the review, the deploy stops before tearing anything down and shows you the fresh list, for example:

One removal is waiting for this deploy. Confirm the list below, then deploy again.

One deploy at a time

Only one deploy runs per workspace. While one is running, a Save (and so a Restore) and an accept are refused with a message that begins "A deploy is already running for workspace" and, when they are known, names the run, when it started and who started it. While a setup window is deploying its record, the message names that window instead: "The ... setup window is deploying for workspace". Wait for it to finish, then try again.

History

Recent activity in the Deploy window splits past work into Deployments and Saves; an accepted proposal is listed under Saves as Proposal accepted.

Who can do what

Any workspace member can accept a proposal; some changes (access, licences, connected-app requests) need a management right. The same holds for a Save. See Team & Access Rights for the rights by name.

Action	Who
Remove, Restore, Save, Accept	Any workspace member; some changes (access, licences, connected-app requests) need a management right
Deploy	People with Workspace.Deploy. Without it, the button reads Activate to Deploy

What cannot be removed today

Your landing zone. It holds the data archives of everything removed from the workspace, so it is refused with:

Your landing zone holds the data archives of everything removed from this workspace, so it outlives every other removal.

Data stores, IoT, communications and Provenance. Removing these kinds is not built yet, so a removal is refused rather than left running behind a record that is gone. Provenance is never deleted (retiring it is not built yet), and while a Provenance scope is under a locked immutability policy the workspace cannot be archived.

Provisioned databases and containers. A database or container that exists in its Cosmos account needs a copy of its data taken before it is removed, and that copy is not switched on yet. It is refused, and the record and its data stay where they are. A container that was never provisioned can be removed.

Some connection and simulator types. Only the types with a teardown can be removed today: an Azure IoT Hub data connection, and a simulator that runs in Azure.

Next steps

• What Save, accept and Deploy each do -> Save, accept and Deploy
• Understand a refusal -> A removal was refused
• The routes behind this page -> Removals API