Environment Setup & Security Troubleshooting
Set up your development environment the right way. Learn how to manage Power Platform environments, configure Dataverse security roles for code components, and troubleshoot common security issues.
Your developer workspace
Think of environments like workbenches in a workshop.
You would not build a prototype on the same bench where finished products ship to customers. You have a development bench (experiment freely), a testing bench (check everything works), and a production bench (only finished items go here).
Power Platform environments work the same way. Each environment has its own Dataverse database, security roles, and configurations. As a developer, you need to know how to set up your dev environment, configure the right permissions for your code, and fix things when security blocks your work.
Environment strategy for developers
| Environment | Purpose | Who Has Access | Data |
|---|---|---|---|
| Development | Build and iterate on solutions | Developers, makers | Sample/test data only |
| Test / UAT | Validate before production | QA team, key users | Sanitised copy of production data |
| Production | Live system for end users | All licensed users | Real business data |
| Sandbox | Experimentation, training | Varies | Resettable, disposable |
Developer environment best practices
- One developer per dev environment when possible (avoids solution conflicts)
- Use developer environments (free, tied to your account) for personal experimentation
- Never develop directly in production â always build in dev, deploy via solutions
- Reset sandbox environments regularly to catch âworks on my machineâ issues
- Use the Power Platform CLI (pac) to manage environments from the command line
The pac CLI for environment management
The Power Platform CLI (pac) is a developerâs best friend. Key environment commands:
pac auth create --environment <url>â authenticate to an environmentpac auth listâ see all authenticated environmentspac org listâ list available environmentspac org select --environment <env-id>â switch active environmentpac solution export --path ./solution.zipâ export a solutionpac solution import --path ./solution.zipâ import a solution
The exam expects you to know these commands and when to use them.
Configuring security roles for code components
Each code component runs with a specific security identity. You must configure the right permissions for that identity.
| Component | Runs As | How to Configure Permissions |
|---|---|---|
| Plug-in | Calling user (default) or system user | Security role on the application user or calling userâs role |
| Cloud flow (automated) | Connection owner or service principal | Security role on the service principal / app user |
| PCF component | Current user (inherited from app) | Userâs security role must include access to data the component reads |
| Custom connector | Per-connection user identity | Connection ownerâs permissions determine API access |
| Client script | Current user | Runs in browser with current userâs Dataverse Web API permissions |
Least privilege in practice
Bad: Give the plug-inâs application user the System Administrator role (has access to everything).
Good: Create a custom security role with only the specific table/column permissions the plug-in needs:
- Read on Contact table (Organisation-level, because it reads any contact)
- Write on Account table (Organisation-level, because it updates any account)
- No permissions on any other table
Troubleshooting security issues
Common security problems developers encounter and how to diagnose them:
| Symptom | Likely Cause | How to Fix |
|---|---|---|
| Plug-in throws âaccess deniedâ | Application user lacks permissions on the target table | Add the required table privilege to the app userâs security role |
| Flow fails with âinsufficient permissionsâ | Connection reference mapped to a user without the right role | Map to a service principal with appropriate permissions |
| PCF component shows no data | Userâs security role does not include Read on the data table | Add Read permission to the userâs security role for that table |
| Custom connector fails in production | DLP policy blocks the connector group combination | Reclassify the custom connector in the production DLP policy |
| Canvas app shows âYou donât have permissionâ | User not assigned a security role in the target environment | Assign the appropriate security role in the admin centre |
Scenario: Kai troubleshoots a plug-in error
Kai Nakamura is a developer at LogiFlow. His new plug-in validates shipment data and creates an audit record in a Log table. It works perfectly in his dev environment but throws âSecLib::AccessCheckExâ errors in the test environment.
Diagnosis: The plug-in runs as an application user. In dev, that user has System Administrator (Kai was lazy). In test, it has a restricted role that does not include Create permission on the Log table.
Fix: Add Create permission on the Log table to the application userâs security role in the test environment. Then remove System Administrator from the dev environment too â develop with production-like permissions to catch these issues early.
Kai's automated cloud flow creates Shipment records in Dataverse. The flow works when Kai tests it manually but fails in production with 'The user does not have permission to create records.' The flow uses a connection reference. What should Kai investigate first?
đŹ Video coming soon
Next up: Solutions & Layers â understanding managed vs unmanaged solutions, dependencies, and environment variables.