Tailspin Toys: three environments, 14 unmanaged customizations in production

Three environments, three different jobs:

Environment	Type	Solution type	Who
Tailspin – Dev	Sandbox	Unmanaged	All 40 makers
Tailspin – Test	Sandbox	Managed	3 publishers + UAT users
Tailspin – Prod	Production	Managed	3 publishers + end users; makers get no direct access

Key points:

• Unmanaged in Dev only. Dev is where makers edit; unmanaged layers are how editing works. Test and Prod receive managed solutions so a clean uninstall/rollback path exists.
• Data isolation: Test must contain sample or anonymised data, never a copy of production. If a copy is truly needed, use a configuration-only copy or a data masking step - the requirement says test activity must not touch production data, and a live connection string is how that promise gets broken.
• One publisher per solution, and a custom prefix (e.g., ts_) set on the publisher, not left as default.
• Pipeline: Dev → export managed → import to Test → UAT sign-off → export the same artifact to Prod. Never rebuild between environments; the managed artifact that passed Test is the one that ships.
• The three publishers are the only users with the System Customizer/System Administrator security roles in Prod.

Treat production as the source of truth exactly once, then reverse the flow.

1. Baseline: in Prod, create a solution (e.g., TailspinCore), use Add Existing to include all apps, flows, tables, columns, and connection references. This pulls the existing unmanaged components into a solution container.
2. Export it unmanaged as a one-time baseline artifact. This is the only unmanaged export you will ever take from Prod.
3. Import that baseline into Dev. From that moment, Dev is the authoring environment and Prod is read-only for makers.
4. Republish as managed: export managed from Dev, import to Test, then to Prod. The managed solution now sits on top of the same components.
5. Remove the unmanaged layer in Prod for the components now governed by the managed solution (in the modern maker experience this is done per component; for a clean result, delete the residual unmanaged customizations after the managed import succeeds).
6. Verify: confirm apps and flows still resolve - flows reference connection references, not the maker's personal connections, so the publishers must bind the connection references in each environment during import.

Risk control for a six-week freeze: do the baseline export first, do a dry run of the managed import into a temporary sandbox if one can be freed, and schedule the Prod cutover in a maintenance window. Do not attempt steps 1–5 in the last week.

Segment connectors by business use, then block the exfiltration paths.

• Business: Microsoft Dataverse, SharePoint, Outlook (Office 365 Outlook), Approvals, SQL Server.
• Non-business: anything the review has not explicitly approved.
• Blocked: Outlook.com (the personal mailbox connector) and the social media connector.

Design notes that the exam likes:

• DLP policies are tenant-level and scoped to environments or environment groups. Put Dev, Test, and Prod in an environment group and apply the policy to all three, or a maker will simply build the leaking flow in Dev and it will still be there in Prod.
• A flow cannot mix connectors from different data groups, and Blocked connectors cannot be used at all. That is what actually stops order data reaching a personal mailbox - a naming convention or a code review would not.
• Existing flows are affected immediately: flows that use a now-blocked connector, or that combine Business and Non-business connectors, are suspended and their owners are notified. Do not apply the policy on a Friday: coordinate it with the release so the three legitimate flows are rewired to a business-approved mailbox connector first.
• Since the environment strategy already moves every authoring activity to Dev with the policy applied, new violations are caught at build time rather than at audit time.