> 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/development/defining-a-domain.md).

# Defining a domain

A domain is defined by a release configuration. To define one, create a [release config](/flxbl/sfp/development/defining-a-domain/release-config.md) YAML file in your repository's **`config` directory**.

```
config/
  sales.yml
  service.yml
  core.yml
```

A simple release config can be defined as shown below

<pre class="language-yaml"><code class="lang-yaml">// Sample release config &#x3C;business_domain.yaml>
releaseName: <a data-footnote-ref href="#user-content-fn-1">&#x3C;business_domain>  </a> # --> The name of the domain
pool: <a data-footnote-ref href="#user-content-fn-2">&#x3C;sandbox/scratch org pools></a>
excludeAllPackageDependencies: true
includeOnlyArtifacts:   # --> Insert packages
  - <a data-footnote-ref href="#user-content-fn-3">&#x3C;pkg1></a>
releasedefinitionProperties:
  promotePackagesBeforeDeploymentToOrg: prod
</code></pre>

## Where release configs must live

sfp discovers domains by scanning the **`config` directory** at the root of your project. A release config placed anywhere else is not a domain: it does not appear in `sfp domain list`, and no command resolves it by name.

The scan is deliberately narrow:

* Only the **top level** of `config` is read. Files in subdirectories are not picked up.
* Only files ending in **`.yml`** or **`.yaml`** are considered.
* Each file is validated against the release config schema. **A file that fails validation is skipped without an error**, so a malformed config presents as a missing domain rather than as a failure.
* A config with no `releaseName` is skipped. `releaseName` is what makes a file a domain.

## The domain name comes from releaseName

The domain's name is the **`releaseName` inside the file**, not the file name. A file `config/sales-domain.yml` containing `releaseName: sales` defines a domain called `sales`, and that is the name commands expect.

Keeping the two aligned — `config/sales.yml` holding `releaseName: sales` — avoids the confusion, but only `releaseName` is authoritative.

## Referring to a domain

Commands that take `--releaseconfig` (also accepted as `--domain`) accept either form:

```bash
# By domain name — resolved from the config directory
sfp validate org -o ci -v devhub --domain sales

# By path to the config file
sfp validate org -o ci -v devhub --releaseconfig config/sales.yml
```

When a name matches no domain, sfp reports the names it did find:

```
'sales' is neither a release config file nor a domain in 'config' (available domains: core, service)
```

Seeing the wrong names there — or `none` — usually means the config sits outside `config`, uses a different extension, or failed schema validation.

`sfp domain list` shows the domains sfp can currently resolve, with the file each came from and how many packages it covers.

## Next steps

* [Release Config](/flxbl/sfp/development/defining-a-domain/release-config.md) — every attribute a release config accepts
* [Limiting Validation by Domain](/flxbl/sfp/validating-a-change/limiting-validation-by-domain.md) — scoping validation to a domain

[^1]: Replace with domain

[^2]: Pools of orgs where the change should be validated

[^3]: Insert your packages here


---

# 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/development/defining-a-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.