Defining a domain

A domain is defined by a release configuration. To define one, create a release config 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

// Sample release config <business_domain.yaml>
releaseName: <business_domain>   # --> The name of the domain
pool: <sandbox/scratch org pools>
excludeAllPackageDependencies: true
includeOnlyArtifacts:   # --> Insert packages
  - <pkg1>
releasedefinitionProperties:
  promotePackagesBeforeDeploymentToOrg: prod

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:

# 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 — every attribute a release config accepts
• Limiting Validation by Domain — scoping validation to a domain