> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/ci-cd/component-cleanup.md).

# Component Cleanup

{% hint style="warning" %}
Component Cleanup is in **Beta**.
{% endhint %}

When you remove a component from a package — delete an Apex class, drop a field — it disappears from your source, but it does not automatically disappear from the orgs it was already deployed to. Salesforce only removes metadata when you ship a destructive change. Component Cleanup keeps track of these left-behind components so they do not quietly accumulate in your orgs.

<figure><img src="/files/69yhSTLlEgwbIp0fDXAc" alt="The Component Cleanup page"><figcaption><p>Component Cleanup — components dropped from packages, tracked per branch, with their status in each org</p></figcaption></figure>

## How components are tracked

Every build compares a package's current source against the last version codev published on that branch. Anything that was in the previous version but is gone now is a **dropped component**, and codev records it in a per-branch ledger with the package it came from, its type and name, and when it was first seen.

Because the ledger is per branch, a component dropped on `main` is tracked separately from the same component on a release branch — each branch reflects its own state.

## Statuses

Each entry has a status that reflects what happened to the dropped component:

* **Pending cleanup** — removed from the package with no destructive change issued, so it may still be sitting in your orgs. These are the ones to act on.
* **Moved** — the component now lives in a different package in the same repository. Nothing to clean up; it just moved.
* **Handled** — a destructive change now covers it, so it will be removed from orgs on the next deployment.
* **Restored** — the component was added back to its package on the branch; the drop was undone.
* **Dismissed** — you reviewed it and chose to leave it. It stays on record, and you can undo a dismissal later, but it is off the pending count.
* **Owned elsewhere** — another repository that deploys into the same org now ships this component, so it is not yours to clean up. codev re-checks this and reopens the entry if that repository stops shipping it.

## Verifying against orgs

A status tells you what your source says; **Org Status** tells you what is actually in your orgs. Press **Verify now** (it also runs on a schedule) and codev checks each registered environment on the branch for the component, briefly locking each environment while it looks. The result shows as **present in N/M environments**, **absent**, or **not verified**. When a component is confirmed absent from every registered environment, codev drops the entry — there is nothing left to clean up.

## Cleaning up

Component Cleanup tracks and verifies; it does not delete metadata for you. To actually remove a pending component from your orgs, issue a destructive change for it in the package — codev then marks the entry **Handled**. If a left-behind component is harmless and you would rather leave it, **Dismiss** the entry.

## Component Cleanup and Environment Drift

Both surface "things in the org that are not in source," but they answer different questions. Component Cleanup is narrow and intentional: it tracks components **you removed from a package**, per branch, from the moment they are dropped. [Environment Drift](/flxbl/codev/environments/environment-drift.md) is broad: it compares an environment's whole state against source and flags **any** difference — manual edits, missing components, configuration drift — per environment. Use Component Cleanup to manage deliberate removals; use Environment Drift to catch unexpected divergence.

## Related

* [Environment Drift](/flxbl/codev/environments/environment-drift.md)
* [Builds](/flxbl/codev/ci-cd/overview.md)
* [Releases](/flxbl/codev/ci-cd/overview-3.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/ci-cd/component-cleanup.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
