The decision that matters
Use separate, limited credentials and sanitized fixtures where possible. Ensure authentication callbacks and external webhooks target the correct environment. Prevent preview jobs from sending real customer messages by default. Restrict access when a preview contains non-public work, and define when temporary deployments and resources should be removed. A random-looking URL is not an access-control mechanism.
A practical scenario
A designer reviewing a customer portal needs realistic invoice layouts, not live customer invoices. A seeded test organization can provide useful examples without granting access to production records. If a preview must connect to a shared service, limit its permissions and make its environment visible so operators do not confuse a test action with a live one.
Before you ship
- Keep preview credentials distinct from production credentials.
- Use fixtures that exercise realistic edge cases.
- Check callback URLs and outbound notification behavior.
A useful next step
Add environment separation to the deployment template so each new preview starts safely. Review any exception that uses production data and document its scope. The goal is a useful review environment that does not quietly become another route into live systems.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.