> 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/techniques/environment-management/pooling-sandboxes.md). # 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.
Pools in codev

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](https://docs.flxbl.io/codev/inspect/review-environments).
Review environment rules in codev

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](https://docs.flxbl.io/codev/pools/overview). 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. --- # 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/techniques/environment-management/pooling-sandboxes.md?ask=&goal= ``` `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.