> 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/sfp/validating-a-change/controlling-validation-attributes-of-a-package/check-only-deployment-mode.md).

# Check-Only Deployment Mode

| Attribute        | Type      | Description                                                                                                                                                                                                           | Package Types Applicable                                                              |
| ---------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| checkOnlyAgainst | string\[] | Array of org aliases where this package should be validated using check-only (validate-only) deployment. When the target org matches an alias in this array, a check-only deployment is performed; otherwise skipped. | <ul><li>unlocked</li><li>org-dependent unlocked</li><li>source</li><li>diff</li></ul> |

Certain packages cannot be validated in pooled review environments (scratch orgs or sandboxes) - for example, Data Cloud packages that require specific provisioning, or integration-heavy packages that depend on connected apps and named credentials not available in pools.

The `checkOnlyAgainst` attribute allows these packages to be validated against persistent orgs using Salesforce's check-only deployment, which verifies deployability without committing changes to the target org.

{% hint style="info" %}
Check-only deployment itself happens only under `sfp validate org`. No other stage reads the attribute to change how a package is deployed.

The single-package-per-domain constraint below is a separate matter — it is enforced whenever the release config is loaded, so it also applies to deploy, release, prepare, sync, and domain commands.

To run a check-only deployment outside validation, use the `--check-only` flag on `sfp install`, which is a separate mechanism — see [Install without committing the change](/flxbl/sfp/installing-an-artifact/controlling-aspects-of-installation.md).
{% endhint %}

```json
{
  "packageDirectories": [
    {
      "package": "dc-connector",
      "path": "src/dc-connector",
      "type": "source",
      "checkOnlyAgainst": ["review"]
    }
  ]
}
```

When running `sfp validate org --targetorg datacloud-dev --releaseconfig config/dc-domain.yaml`, the package will be validated using check-only deployment against the specified org.

## Behavior

When using `sfp validate org` with a `--releaseconfig`:

* If `--targetorg` matches one of the aliases in `checkOnlyAgainst` → Check-only deployment
* If `--targetorg` does NOT match any alias → Package is skipped

The comparison is a literal string match against the value passed to `--targetorg`. Passing a username where the attribute lists an alias — or the reverse — does not match, and the package is silently skipped rather than validated.

## Requirements

### Release Config Required

Check-only deployment is applied only when `--releaseconfig` is provided.

### Single Package Per Domain

Domains containing a package with `checkOnlyAgainst` must have exactly one package. This avoids dependency ordering complexity.

The count is taken from the domain's resolved package list, and the check runs when the release config is loaded — so a domain that breaks this rule fails the command even on a run that does not touch the check-only package, and on commands other than validate.

### Org Authentication

The org alias in `--targetorg` must be pre-authenticated in your CI environment.


---

# 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/sfp/validating-a-change/controlling-validation-attributes-of-a-package/check-only-deployment-mode.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.