How would you design an environment strategy for an org with two parallel projects, ongoing production support and a training requirement?

I assign environments by purpose and then attach a refresh calendar to each, because an environment strategy without refresh dates drifts into a set of orgs nobody trusts.

• Per-stream development — Developer or Developer Pro sandboxes, or scratch orgs where the metadata is genuinely in source, one per developer or per feature so work is isolated.
• Integration — one shared environment where both streams merge and the integration suite runs. This is the first place either stream sees the other's work.
• Staging / UAT — production-like configuration and representative data, used for user acceptance testing, performance and data-volume testing where required, and for a full deployment rehearsal including the manual steps.
• Training — refreshed to a known, stable state before each cohort, so the environment does not shift under a course mid-week.
• Hotfix — matching what is live in production right now rather than what is in test, so an urgent fix does not inherit the risk of the in-flight release.

The constraint I plan around first is the Full sandbox refresh interval, because it is the longest of the four sandbox types and it dictates what the release calendar can assume. If the cadence is shorter than the interval, staging either becomes a Partial Copy sandbox with a template, or it is kept aligned between refreshes by deploying to it exactly as I deploy to production.

I also decide the masking approach at design time. Any copy of production data into a lower environment is a data protection decision, and it has to run as part of the refresh process rather than as something someone remembers to do.