Skip to content

Deleting items and understanding cascade impact

Almost everything you can create in DeltaVault, you can delete. The delete action lives on the item’s own surface, and when the item has dependents, DeltaVault shows you exactly what else will be removed before you confirm. This page explains how delete behaves across the whole catalog: where to find it, what a cascade preview tells you, when a delete is refused, and how to recover a delete you have not committed yet.

Delete lives where the item lives. You will find it in one of three places, depending on the surface:

  • On a detail page, as a Delete action in the page’s actions band.
  • In a tree or a grid, as a Delete item in the row’s context menu.
  • On a canvas, as a Delete option on the node’s menu.

Wherever you start from, a confirmation dialog handles the delete, so the experience is consistent across the product. Deleting several items at once confirms them together and sums their impact into a single preview, and some kinds, source tables among them, take that same grouped path even when you are deleting a single row.

When you delete something that has dependents, the confirmation dialog lists exactly what else will be removed before you confirm. The counts are computed from the same logic that performs the delete, so what you are shown cannot drift from what actually happens. For example:

  • Deleting a connection removes its catalogs, schemas, tables, and columns.
  • Deleting a workflow removes its steps and the artifacts it generated.
  • Deleting a business model or domain lists its member models, entities, attributes, and its project and workspace assignments.
  • Deleting a business entity lists its attributes and the source columns and tables that were mapped to them.

When an item has no dependents to remove, the dialog is a lightweight confirmation instead of a preview. Some administrative items (for example a team) are removed with a plain confirmation rather than a cascade preview, because there is no dependent catalog structure to summarize.

Some deletes are refused, with the reason shown, until you clear the dependency first. This protects you from silently breaking something else that still points at the item. For example:

  • A schedule that is still assigned to a workflow or a table ingestion cannot be deleted until you unassign it.
  • A workflow that another workflow uses as a sub-workflow cannot be deleted until that reference is removed.
  • A business attribute that is an entity’s business key, or a business entity still referenced by a relationship, is refused until you resolve the reference.
  • A project’s default workspace cannot be deleted while the project points at it. Choose a different default first.

When a delete is refused, the confirm button is disabled and the dialog names exactly what is in the way, so you know what to clear before trying again.

The confirmation dialog is the safety gate. There is no trash view and no separate restore screen, so read the dialog before you confirm: it tells you which of two cases you are in.

Some deletes can be undone for a short time. When that is true, the dialog says so in as many words: “You can undo this for a short time after deleting.” Take the offer while it stands.

Otherwise the dialog reads “This cannot be undone.” and it means it. There is still one way back, and it is the branch model: if you are working on a feature branch and have not committed yet, a delete is simply one of your uncommitted changes on that branch, so discarding the branch reverts it along with everything else you had not committed. Once you commit, the delete becomes part of your history, and the way to bring something back is to recreate it.

SurfaceHow the delete affordance appears
Detail pageA Delete action in the page’s actions band
Tree or gridA Delete item in the row’s context menu
CanvasA Delete option on the node’s menu
Multiple selectionA bulk delete that confirms the selected items together and sums their impact