Pooling Sandboxes

A flxbl project uses two kinds of environment pool, for two different jobs. Scratch orgs are lightweight and ephemeral, which makes them ideal for day-to-day development. Sandbox pools give you production-like environments — realistic data volumes and the full organizational complexity of your org — which is what you need when a change has to be validated against conditions that mirror production. codev manages both, so you pick the pool that fits the work rather than the other way round.

Sandbox and scratch org pools in codev, with instance counts and availability

When to reach for a sandbox pool

Scratch orgs are fast to provision and install packages cleanly, so they suit feature development and unit testing for an individual developer. They do not, however, reflect the data and configuration of your production org.

A sandbox pool does. Because each environment starts from production metadata and configuration, it is the right place for acceptance testing, compliance and security validation, and any review that has to happen under production-like conditions. The trade-off is cost and time: sandboxes take longer to provision, and a developer sandbox holds roughly 200 MB of test data (larger licenses are available). For most teams that trade-off is worth making only where it earns its keep — review environments.

Review environments

The main use of a sandbox pool is review environments. codev assigns a pooled sandbox to each pull request, so a change is validated against a production-like org before it merges rather than after.

That gives a reviewer three things. Deployment validation — the change is actually deployed against production-like metadata, so deployment conflicts and dependency problems surface early. Testing — impacted Apex tests and end-to-end scenarios run against the production metadata structure with representative data. Acceptance — the environment is a shared place for business stakeholders to review and give feedback before the change reaches the trunk.

codev handles assignment and the environment's lifecycle through assignment rules that map a branch (or branch pattern) and domain to a pool. See codev review environments.

Review environment assignment rules mapping branch patterns and domains to a pool

Test data

Pooled sandboxes are built from snapshot sandboxes that carry curated test data, working within the developer-sandbox limit. A good snapshot holds the essential data for functional and end-to-end testing, representative permission and sharing scenarios, and the integration endpoints a change might touch — enough to exercise a real business process without exceeding the storage limit.

Keep snapshots current so pools stay useful: refresh them on a cycle aligned with production, use anonymized production extracts where compliance requires it, and generate synthetic data for scenarios real data does not cover.

Pool lifecycle

Sandbox pools originate from snapshot sandboxes. A snapshot of the main branch reflects the latest validated trunk and feeds standard review pools; a separate production snapshot mirrors live state for hotfix validation.

Two Salesforce platform constraints shape how these pools behave. A sandbox expires after 24 hours, and the platform creates only about four sandboxes concurrently, with a 24-hour minimum before a deleted one can be recreated. codev works within those limits: it leases an environment to a pull request for its validity window (with optional extensions), expires it automatically, and replenishes the pool on a schedule — usually a full recreation during a low-usage window. Running on Hyperforce improves creation and operation times.

Operating the pools

codev provisions, monitors, expires, and replenishes pools automatically. You set the minimum pool depth and codev keeps it topped up; because creation is slow, size pools to your peak review demand and keep a small buffer. Domain filtering limits how much each snapshot installs, which keeps provisioning times down. codev's pool monitoring surfaces depth, allocation success, creation times, and failures — see codev pools.

A full pool recreation needs a few hours of planned downtime because of the sequential creation and concurrency limits, so schedule it in a low-usage window and keep a manual recreation path for emergencies.

How it fits together

Use scratch org pools for development and sandbox pools for review and acceptance. codev review environments assign a pooled sandbox to each pull request and manage its lifecycle; codev pools maintain the inventory; sfp-pro is the engine underneath.