> 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/concepts/package-installation.md).
# Package installation
When a release runs — or you deploy from your workspace — each artifact installs into the target org following rules that decide what is skipped, what is deployed, and which tests run. Knowing these rules explains the statuses a release shows: why a package reads **Skipped**, why an install deployed three components instead of three hundred, and why some packages run tests during installation while others do not.
A release installs its artifacts in dependency order — each artifact deciding what it deploys.
## Already installed versions are skipped
The org records which artifact versions are installed. If the version to install matches what the org already has, the package is **skipped** — installing the same release twice does nothing the second time. A package can opt out with the `alwaysDeploy` behaviour, and `skipIfAlreadyInstalled` is the release-level control.
## Only changed components deploy
When a **source** or **diff** package installs a new version over an older one, codev compares the two artifacts file by file and deploys **only the components whose contents changed** — the unchanged majority of a large package never enters the deployment. This is the **component checksum skip**: on by default, and strictly additive — whenever the previous artifact cannot be fetched or carries no checksums, the package falls back to a full deploy.
It can be turned off per run, per package (the `disableChecksumSkip` behaviour), or per project, environment, or target branch from codev's settings. The full mechanism, including its fallbacks: [Component checksum skip](https://docs.flxbl.io/flxbl/sfp/building-artifacts/configuring-installation-behaviour-of-a-package/component-checksum-skip).
## Tests during installation depend on the package type
| Package type | Apex tests during install | Coverage requirement |
| ---------------------- | ----------------------------------------- | ----------------------------------- |
| Unlocked | No — validated when the version was built | 75% at build |
| Org-dependent unlocked | No | None |
| Source | Yes — the package's own test classes run | 75% per class, or org-wide coverage |
| Diff | Yes | 75% per class, or org-wide coverage |
| Data | No — records load via the data engine | None |
This is why unlocked packages install faster than source packages carrying many tests: their validation happened once at build time. See [Optimized installation](https://docs.flxbl.io/flxbl/sfp/building-artifacts/configuring-installation-behaviour-of-a-package/optimized-installation).
For a **source** or **diff** package, the [component checksum skip](#only-changed-components-deploy) narrows the tests the same way it narrows the deploy: when only the changed components install, the tests relevant to those components run instead of the package's full suite. How installation behaviour weighs into the choice between types: [Choosing a package type](https://docs.flxbl.io/flxbl/techniques/development-practices/choosing-a-package-type).
## Behaviours are baked in at build
An artifact is immutable: its installation behaviours are recorded when the version is built, and changing one requires building a new version. The behaviours a package can declare include:
* **`skipDeployOnOrgs`** — skip this package on named orgs.
* **`alwaysDeploy`** — install even when the same version is already present.
* **Aliasfy** — deploy an environment-specific variant of the package's metadata per target org.
* **String replacements** — substitute values in the source per environment at install.
* **Pre/post deployment scripts** — run scripts around the install.
* **Reconciling profiles**, **picklist updates**, **field history tracking** — type-specific install helpers.
Each is a one-line property on the package; the full catalogue with examples: [Configuring installation behaviour of a package](https://docs.flxbl.io/flxbl/sfp/building-artifacts/configuring-installation-behaviour-of-a-package).
## Order
Artifacts install in **dependency order** — the order of packages in the project configuration, refined by each package's declared dependencies and the domain's release configuration. Full detail: [Dependency management](https://docs.flxbl.io/flxbl/sfp/concepts/dependency-management).
---
# 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/concepts/package-installation.md?ask=&goal=
```
`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.