Create One Safe Place to Build
Diesen Beitrag auf Deutsch lesen
Design a governed Maker Environment with aligned DLP, intentional access, Dataverse controls, solutions, monitoring and a clear path to production.
TL;DR
A Maker Environment should offer a governed alternative to a restricted Default Environment. Align its DLP with production, grant access through a Security Group after basic training, enable 30-day Dataverse Audit retention, create apps and flows in solutions by default, monitor capacity, and migrate mature solutions to production.
Original by Michael Roth, on MichaelRoth42 Blog. Read the original · suggested by Michael Roth
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Complete the basic learning module and build in the Maker Environment, using solutions from the start so experiments can become portable and migration-ready.
- Admins/CoE: Align Maker Lab DLP with production, control entry through a Security Group, monitor usage and capacity, and split environments only when advanced connectors, high volume or serious Dataverse use justifies the overhead.
- Security/Compliance: Enable Dataverse Audit with 30-day retention to trace data changes, while recognizing that audit is retrospective evidence and does not prevent mistakes, restore data or replace backups.
- Leadership/Business: Provide a clear migration path for solutions that become important, because restricting the Default Environment without an alternative drives workarounds and frustration.
Frequently asked questions
Why should the DLP policy of a maker environment resemble production?
Because makers would otherwise build with capabilities that do not exist in production and be disappointed later.
How should access to a maker environment be granted?
Through competence, not automatically for everyone in the directory. A learning module of about 30 minutes comes first, then access through a security group managed by the governance team or IT.
When does it make sense to split a maker lab into several environments?
One general maker lab is the default. Splitting is justified when advanced cases need risky connectors, a business unit has consistently high maker volume, or makers build model-driven apps with real business logic.