> 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/limiting-validation-by-domain.md).

# Limiting Validation by Domain

Validation processes often need to synchronize the provided organization by installing packages that differ from those already installed. This task can become particularly time-consuming for large projects with hundreds of packages, especially in monorepo setups with multiple independent domains.

## Using Release Configurations

To streamline the validation process and focus it on specific domains, you can use release configurations with the `--releaseconfig` flag. This approach limits the scope of validation to only the packages defined in your release configuration, significantly enhancing efficiency and reducing validation time.

### Basic Usage

```bash
sfp validate org -o ci \
                 -v devhub \
                 --mode thorough \
                 --releaseconfig=config/release-domain-sales.yml
```

In this example, validation is limited to packages defined in the `release-domain-sales.yml` configuration file. Only packages that:

1. Are listed in the release configuration AND
2. Have changes compared to what's installed in the org

will be validated.

### Multiple Domain Configurations

For projects with multiple independent domains, you can specify multiple release configurations:

```bash
sfp validate org -o ci \
                 -v devhub \
                 --mode thorough \
                 --releaseconfig config/release-sales.yml \
                 --releaseconfig config/release-service.yml
```

## Benefits of Domain-Limited Validation

1. **Faster Feedback**: Validate only the relevant packages for your team's domain
2. **Reduced Dependencies**: Avoid failures from unrelated packages in other domains
3. **Parallel Development**: Multiple teams can work independently without blocking each other
4. **Optimized CI/CD**: Shorter validation times mean more efficient pipeline execution

## Example Release Configuration

```yaml
# config/release-sales.yml
releaseName: sales
includeOnlyArtifacts:
  - sales-core
  - sales-ui
  - sales-integrations
  - opportunity-management
  - quote-management
```

`releaseName` is the domain name and `includeOnlyArtifacts` lists the packages in it. Use `excludeArtifacts` instead to list what to leave out — the two cannot be combined, and a config that sets both is rejected when it loads.

See [Release Config](/flxbl/sfp/development/defining-a-domain/release-config.md) for every attribute a release config accepts, including cross-domain dependencies and the properties carried into generated release definitions, and [Defining a domain](/flxbl/sfp/development/defining-a-domain.md) for how domains are structured.

## Combining with Other Options

### With Diff Check

```bash
sfp validate org -o ci \
                 -v devhub \
                 --diffcheck \
                 --releaseconfig=config/release.yml
```

### With Individual Mode

```bash
sfp validate org -o ci \
                 -v devhub \
                 --mode individual \
                 --releaseconfig=config/release.yml
```

### With Branch References

```bash
sfp validate org -o ci \
                 -v devhub \
                 --ref feature-branch \
                 --baseRef main \
                 --releaseconfig=config/release.yml
```

## Best Practices

**Give each domain its own release config.** One config per logical domain keeps validation scoped to the team that owns it. Start from [Release Config](/flxbl/sfp/development/defining-a-domain/release-config.md), which documents every attribute, and [Defining a domain](/flxbl/sfp/development/defining-a-domain.md), which covers how a domain is laid out in the repository.

**Declare cross-domain dependencies rather than duplicating packages.** Where a domain needs packages another domain owns, list the other domain under `dependencyOnDomains`. It resolves recursively, so you name the domain rather than tracking its package list as it changes. Copying package names between configs is what falls out of date.

**Keep the package list current.** A release config that has drifted from the repository silently narrows or widens what a pull request validates. `sfp releaseconfig probe -c config/` reads every release config in a directory, which is a quick way to check the set still loads and resolves.

**Pass the config explicitly in CI.** `--releaseconfig` is required, so each pipeline states the domain it validates. Where one pipeline covers several domains, pass the flag more than once rather than maintaining a combined config.


---

# 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/limiting-validation-by-domain.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.