Loading
Because without one, the new pipeline, the reworked permissions and the untested import are all tried on live data, usually on a Friday, and usually while somebody is mid-quarter.
A sandbox is a separate copy of your workspace — configuration, and data if you want it — that can be refreshed from production on request and thrown away without consequence.
The sandbox has its own URL and its own API tokens, so an integration can be pointed at it. Refreshing pulls a current copy; nothing in it writes back to production, and outbound email is disabled by default.
A permissions rework that looked correct removed a whole team's access to renewals. It was found in the sandbox on a Tuesday, which is a considerably better day to find it than the following Monday.
It is not a backup, and it is not a staging environment that promotes changes automatically. Configuration proven in the sandbox is still applied to production deliberately.
Configuration, custom fields, automations, permissions and templates all copy across, and API tokens are separate so integration testing does not touch live records.
Only if you choose. It can be refreshed with configuration alone, which is often the right answer.
No, outbound is disabled by default — the mistake that makes sandboxes dangerous.
No. Applying to production is a deliberate act.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.