Excel, SharePoint or Dataverse
for Power Apps?

Work out what you need before choosing a tool.

A weekly report prepared by one person has different needs from an app that a whole team updates throughout the day. Write down what each record represents, who owns it and what happens when an update is late or wrong. Use those answers to compare the tools.

The table below gives you a starting point. The following sections explain what to check and link to Microsoft’s documentation.

On narrow screens, scroll this table sideways. Keyboard users can focus the table region and use the arrow keys.

Decide who and what will update the workbook.

The Excel Online (Business) connector works with workbook files in supported Microsoft cloud document libraries. Its table operations are different from simply opening a worksheet. Microsoft explicitly warns that concurrent changes to one file from different clients, including manual edits and connector operations, are unsupported and can produce conflicts or inconsistent data.

Microsoft reference: Excel Online (Business) connector and limitations.

A workbook may suit a small trial or a report when someone looks after the file, headings and updates. Before using it for a shared app, check whether people, desktop Excel and automated processes would try to change it at the same time.

Ask the file owner

• Is there one agreed workbook, and who may rename columns or change its structure?
• Will people, the app and an automation all modify it?
• Which identifier finds the intended record after sorting or renaming?
• How will the person running the app spot a failed or delayed update?

Even a small workbook needs these checks. Write down how people will use it before deciding what to include in the trial.

Consider SharePoint for a team's list of work.

Microsoft’s SharePoint connector lets Power Apps work with lists. Its documentation covers supported field types, connections, conditional access and delegation limits. Delegation means the source processes a query. When it cannot, the app may show incomplete results that look correct in a small demo.

Microsoft reference: SharePoint connector, Power Apps support and delegation notes.

Consider a list for individual requests, tasks or updates when someone can look after SharePoint. If you need several lists, draw the links between them first. Decide who maintains each link and what happens when a linked record changes.

Test the searches and permissions people will use

Choose a known record beyond the first few items, then try the searches and filters people will use. Repeat with a normal user's account. Also decide what should happen if two people edit the same item before either refreshes.

Check the searches, field types and permissions you need. Row count alone does not tell you whether a list will work.

Consider Dataverse when records need to stay linked.

Dataverse stores data in standard or custom tables, with a defined type for each field. It supports links between records, business rules and access based on user roles. Consider it when your app needs several kinds of connected records and consistent rules about who can use them.

Microsoft reference: What is Microsoft Dataverse?

For example, an organization, its engagements, the work within each engagement and the status history are different records. Decide which relationships are required, who can change them and whether the same rules should apply across multiple screens or apps.

Plan who will manage the environment, change the app and approve data access. Decide how to check permissions, simultaneous updates, imports and backups, and how to hand the app over. A demo that works for its maker does not prove every user's access or the final running cost.

The same team can have three different starting points.

Quintera’s existing synthetic Dataverse demonstration uses that third structure. A focused Canvas app and management app update the same work item; a status change was saved, reloaded, checked in the other app and restored. This demonstrates the tested behavior, not that every organization needs the same design.

Explore the public synthetic companion. It is a browser illustration; a guided walkthrough of the private Power Apps can be requested through the project brief.

Check the actual users and components.

Microsoft’s licensing overview says the licenses you need depend on the products, features, data sources and environments you use. Some Microsoft 365 plans include limited Power Apps use; this is not the same as a standalone premium license. Seeing a Dataverse service plan in an account does not, by itself, mean you are licensed to run a standalone custom app.

Microsoft reference: Power Platform licensing overview and current guidance.

Before agreeing the design or fee, ask the organization’s license and access owner to confirm:

People

Who builds, runs and supports the app? Are users internal, guests or external?

Components

Which data sources, connectors, flows, environments and capacity needs are in the proposed design?

Access

Can each intended user perform the required actions with their own account, within the organization’s policies?

Cost and ownership

Which rights are already held, what needs to be acquired, and who owns ongoing administration and support?

Confirm the current license terms for your planned app. This guide gives no fixed license price. Licenses used for a personal demo do not tell you what another organization needs.

Use these questions to plan the project.

Keep the first pilot easy to judge.

Use approved sample data, someone to review the results and a short list of expected outcomes. Try finding, changing and reloading a record. Check invalid updates and permissions. Decide what would make you keep the design, change it or stop. Note what you have not tested.

If the process is still unclear, a workflow review can map it first. If the shared records and user tasks are already understood, Power Apps consulting can help you agree what to build and how to check it.