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?
Next up: Solutions & Layers — understanding managed vs unmanaged solutions, dependencies, and environment variables.