If New table is missing or Dataverse says you do not have permission, buying another licence is not automatically the answer.
Creating a table sits behind several separate gates:
- you are working in the intended Power Platform environment;
- that environment has a Dataverse database;
- your account has the right product use rights;
- you can enter the environment;
- your Dataverse security role allows customisation and access to the required metadata tables.
Those gates are easy to blur because Power Apps shows them through one maker portal. Treating them as one problem leads to random role changes, unnecessary licences and too many System Administrators.
The two-minute diagnosis
Open Power Apps, check the environment selector in the top-right corner, and then use this table.
| What you see | Most likely gate |
|---|---|
| The intended environment is absent | Environment membership, tenant or environment security group |
| Environment is visible but Tables is absent or Dataverse is unavailable | No Dataverse database, wrong environment type or missing use rights |
| Tables are visible but New table is missing/blocked | Dataverse customisation role or metadata-table privileges |
| You can create a table but cannot read business rows | Data privileges, record ownership or sharing |
| You can edit in one environment but not another | Roles and databases are environment specific |
Do not test with a Global Administrator or System Administrator and assume an ordinary maker will behave the same way.
Layer 1: confirm the environment
An environment is a boundary for apps, flows, connections, security roles and—in environments that have one—the Dataverse database.
Before changing permissions, record:
- environment name and ID;
- tenant;
- environment type;
- whether it is linked to a Microsoft Entra security group;
- whether a Dataverse database exists;
- the exact affected user's account;
- the operation that fails.
If the user cannot see the environment, adding a Dataverse table privilege inside it cannot help. Resolve environment access first.
Also check that a Teams-based solution has not been confused with a normal Dataverse environment. Dataverse for Teams is tied to a Team and has different use, sharing and API boundaries. Microsoft says standalone use and direct API access can require an upgrade, and guests can run but not make or edit apps in that environment. Review Dataverse for Teams restrictions.
Layer 2: check whether Dataverse exists
An environment can exist without a Dataverse database.
In the current Power Platform admin centre, an authorised admin can select Manage > Environments, choose the environment and add Dataverse. Microsoft says the person creating the database needs to be an administrator in that environment with an appropriate licence. An environment has one Dataverse database. See Microsoft's current database-provisioning steps.
Provisioning a production database is an architecture and governance decision, not a harmless troubleshooting click. Confirm:
- region and environment purpose;
- security-group boundary;
- data-loss-prevention policy;
- owner and support route;
- backup, retention and lifecycle plan;
- whether the solution should live in a development, test or production environment.
If the database does not exist, do not grant more Dataverse roles and wait for a “sync.” There is nothing to customise yet.
Layer 3: separate Microsoft 365 rights from premium Power Apps rights
Some Microsoft 365 licences include limited Power Apps and Power Automate capabilities: makers can create and run apps with standard connectors in browser or mobile experiences. That does not grant blanket rights to premium connectors or custom apps using full Dataverse.
Microsoft also documents a limited Dataverse service plan bundled with certain Microsoft applications. It does not entitle a user to run standalone custom Power Apps or Power Automate flows that use Dataverse as a premium capability. Production and sandbox environments with full Dataverse need the appropriate Power Apps, Power Automate or Dynamics 365 entitlement for the actual user and scenario. Use Microsoft's current SKU and Microsoft 365 use-rights guidance.
Do not copy a price from an old article. Licensing changes. Record the product/SKU assigned to the affected user, then verify the current use rights in Microsoft documentation or with your licensing owner.
Developer Plan is not a production shortcut
Power Apps Developer Plan is useful for individual development and learning. It is not a shared production environment and does not licence other people to run a published business app. Use it to learn or build an isolated proof of concept, then deploy through your governed environment and licensing process.
Layer 4: understand the three different permission jobs
The words maker, customizer and data access describe different jobs.
Environment Maker
Environment Maker allows a user to create resources in an environment. It should not be treated as universal access to all Dataverse customisation and data.
System Customizer
Microsoft says anyone customising Dataverse needs at least the System Customizer security role. That role can customise the environment and has broad access to custom tables, but it does not automatically grant unrestricted access to all records in standard tables such as Account, Contact and Activity. Read the System Administrator/System Customizer boundary.
Metadata-table privileges
Microsoft's current table-designer prerequisites are more precise: creating and editing tables requires System Customizer and a system or custom role with Create, Read and Write privileges on the Entity metadata table. Check the current table-creation prerequisites.
Business-data privileges
Running an app and reading or changing rows uses table privileges such as:
- Create;
- Read;
- Write;
- Delete;
- Append;
- Append To;
- Assign;
- Share.
Each privilege also has a depth such as user, business unit or organisation. Roles are cumulative. See Dataverse security roles and privilege depth.
This is why a user can design a table but be unable to read another person's Account rows—or run an app but be unable to modify its schema.
A safe fix sequence
1. Reproduce with the affected user
Capture the exact environment and error. Ask the user to open Tables and attempt one harmless operation in a non-production environment.
2. Confirm use rights
Check the assigned licence and the app/connector/environment in scope. Do not assign a broad trial or premium SKU merely to make the error disappear without understanding the lasting requirement.
3. Confirm environment access
If the environment uses an Entra security group, confirm membership has taken effect. Ensure the account is not signed into another tenant or browser profile.
4. Inspect Dataverse roles
In Power Platform admin centre, select Manage > Environments > [environment] > Settings > Users + permissions > Users. Open the user and review assigned security roles.
For a person who must create tables, start with the documented System Customizer requirement in a development environment. If governance requires a custom role, test its metadata privileges carefully; a copied role is not automatically equivalent to the built-in role for every feature.
5. Grant the minimum business-data access separately
Do not use System Administrator as a substitute for app-specific data design. Give users a role that grants only the tables, operations and depths required by the app.
6. Test again as a non-admin
Sign out or use a clean browser session. Check these independently:
- environment appears;
- Tables opens;
- a test table can be created, if that is the role's job;
- the intended app can be opened;
- allowed rows can be read/created/updated;
- disallowed rows remain inaccessible.
7. Remove temporary access
If you temporarily granted a broad role for diagnosis, remove it after the controlled test. Record the permanent role, licence and owner.
Do not solve this with System Administrator
System Administrator has full permission to customise and administer the environment and access its data. It is useful for proving that the failure is permission related. It is a poor default fix for a normal maker or app user.
Use a time-bounded admin test if needed. Then design the actual role.
A handoff checklist for the admin
Send the admin facts, not “Power Apps is broken”:
User:
Tenant:
Environment name and ID:
Environment type:
Dataverse database present: Yes/No
Security group membership checked: Yes/No
Assigned Power Apps/Dynamics licence:
Required task: create table / edit schema / run app / read-write rows
Current Dataverse roles:
Exact error and UTC time:
Tested in clean browser session: Yes/No
That is enough to route the issue to licensing, platform administration or Dataverse security without guesswork.
Frequently asked questions
Is Environment Maker enough to create Dataverse tables?
Do not assume it is. Microsoft documents System Customizer plus the required Create, Read and Write privileges on the Entity metadata table for creating and editing tables.
Do Microsoft 365 licences include Dataverse?
Some include limited Dataverse use rights for specific Microsoft applications and standard Power Apps capabilities. They do not provide general rights to build and run standalone custom premium Dataverse apps.
Why can I create a table but not see its rows?
Schema customisation and business-data access are separate. The user's security roles also need appropriate privileges and access depth for the table's records.
Should I give the maker System Administrator?
Only as a tightly controlled diagnostic step if your governance permits it. The permanent fix should use the least privilege needed for customisation and data access.
Can I use Power Apps Developer Plan for a live team app?
No. Developer Plan is for an individual's development and learning environment, not a shared production licensing route.
For more buildable app patterns with the permission and licensing boundaries made explicit, join the Power Apps Builders Space.