Power Platform Integration Patterns: Dataflows for Simplicity, Azure for Power

Power Apps comes up in nearly every conversation I have about business systems right now. And as soon as it does, a dozen smaller questions follow: which database, which automation tool, and of course licensing.

Before any of those can be answered well, there are three older questions that have to come first:

1. What is the business use case?

2. How much data are we looking at, and what needs to happen to it?

3. Who are the users, and what do they expect?

The answers drive every decision a solution architect makes about where data lives, what the developers build, and how the system stays affordable and manageable. Let us break each one down using an example.

Question 1: What is the use case?

For this example I will use a rose distributor. Roses are a bit of a theme here at Nerdy Q, and like any product they move through a supply chain that has real problems to solve.

This company keeps its information in an Azure Data Lake, an Oracle database, and a collection of Excel sheets. That is an inexpensive way to store large volumes of invoices and records, but it is not friendly to query, track over time, or turn into dashboards. The data is cheap to keep and hard to use, and the result is roses spoiling in transit, slipping delivery times, and losses in the hundreds of thousands of dollars a year. The company wants to fix that with the Power Platform, in a system it calls the Smart Rose Allocation System, or SRAS.

The problem

The sales team needs current answers to four things:

• Which rose varieties are available, in transit, or close to spoiling

• Which varieties best suit a given event or retailer

• What customers typically buy together, such as red and white for weddings

• How each supplier is performing on delivery and quality grading

That information is spread across Oracle, the Data Lake, spreadsheets, and greenhouse sensors, with no single view. When marketing asked IT for a quick Power App to help match roses to clients, nobody had accounted for the data behind that request.

The proposed system

SRAS is a Power Platform solution that:

1. Connects to every source: Oracle for inventory, spreadsheets for customer notes, IoT sensors for temperature, the Data Lake, and the CRM.

2. Uses Azure Synapse to join, filter, and categorize the data, keeping only rose stock that is viable based on freshness and location.

3. Pushes that summarized data into Dataverse, where a Canvas app shows the sales team the best roses for each order.

4. Uses Power Automate to alert when freshness drops below a threshold, notify logistics to reallocate stock, and keep status in sync with Dynamics 365.

Put in one sentence, the use case is this:

We need a way to make sense of large, messy, relational and non-relational data, and serve only the relevant pieces to each type of user in near real time, without making them learn our schema.

That is the real lesson of the example, and it is not about roses. It is about large, complex data that has to be simplified for people; a clear separation between the data engine (Azure) and the user layer (Power Apps); a mix of scheduled (dataflows) and event-driven (flows) integration; and a user experience that does not punish people for how the database is designed.

Question 2: How much data, and what needs to happen to it?

Quantify it

In this example, the volumes look like this:

• Daily inventory updates from Oracle: about 500,000 rows across dozens of varieties and growing regions

• Greenhouse sensor logs: 10,000 to 30,000 entries a day for temperature, humidity, and spoilage predictions

• Customer preference data from the CRM and Excel: about 5,000 clients with custom notes

• Supplier and shipment logs: about 1,000 updates a day, stored in the Data Lake

That adds up to millions of rows a month, from several relational and non-relational sources, all of it time-sensitive.

Ask what the user actually needs

This is where many teams go wrong: they try to bring everything into Dataverse. The sales team does not need every sensor reading, every shipment record, or inventory history going back to 2015. They need a focused slice: what is fresh, what is available right now, and what fits each customer's preferences. That is perhaps 5 to 10 percent of the data.

Let the architecture filter the noise

What not to do:

• Load raw Oracle data straight into Dataverse through dataflows

• Normalize eighteen tables and expect a model-driven app to be fast

• Keep IoT logs in the Power Platform just in case

What to do instead:

• Use Azure Synapse to pre-process and aggregate only the roses that matter

• Score freshness, predict bloom windows, and sort by location there

• Push only the curated result, perhaps 20,000 records, into Dataverse each night

• Present it in a Canvas app that lets sales search by color, freshness, or season

The data is large, but the user layer only needs small data.

In practice that means Azure (Synapse or Databricks) handles volume, filtering, and enrichment; Dataverse holds just what users interact with; and Power Apps provides the experience without the performance problems. If the Power Platform is the boutique flower shop, Azure is the industrial greenhouse and logistics network behind it.

Question 3: Who are the users, and what do they expect?

This is the question most often skipped, and it matters more than the technology stack. If you design without knowing who touches the system, how often, and why, you end up optimizing for the wrong problem. In this example there are three groups:

• Order clerks need fast, filtered lists of active orders, stock availability, and suggested matches. They expect speed, simplicity, and a predictable flow, which is exactly what a model-driven app with the newer grid control, preview panels, and child tables does well. Copilot and agents can help here too, but only if this planning has been done first.

• Sales managers move between customers, buying history, supplier quality, and trends. They expect dashboards they can drill into, so a Canvas app over curated Dataverse data, or one embedded in a Power BI report, may serve them better.

• Analysts and operations staff need the whole picture: freshness trends, supplier delays, spoilage patterns, and revenue projections. They expect speed, scale, and flexibility, so they can skip Dataverse entirely and connect directly to Azure SQL, Synapse, or Oracle through Power BI or a Canvas app.

Canvas, model-driven, or both?

It is not an either-or decision. It depends on the role:

User Role	App Type	Reason
Front-line Clerks	Model-driven	Leverage structured data, automation rules, and new grid UX
Managers	Canvas or Embedded in Power BI	Optimized experience, data visualization, tailored UI
Analysts	Power BI + Direct Connect or Canvas	No movement, full depth, direct querying of live data

For more complex needs, Canvas apps can also be embedded inside model-driven forms or Power BI dashboards, which gives you a flexible interface over just-in-time data without rebuilding everything.

Does it need to be in Dataverse at all?

This is the architectural crossroads, and there are three reasonable answers:

• Full Dataverse: needed when you rely on automation, business rules, security roles, and row-level security, and suited to structured workflows shared across teams.

• Direct connection to Azure SQL or Oracle: no duplicated data and lower latency for real-time dashboards, which suits read-heavy roles such as managers and analysts.

• Hybrid, with premium licensing: frontline apps work from a curated seven-day view in Dataverse, advanced users connect directly to SQL or Oracle, and Canvas apps, Power BI, and flows bridge the layers.

How the example ends

The rose company's Dataverse now holds only seven days of active sales, open and pending orders, and the filtered, enriched rose stock relevant to that week. Clerks get a clean, fast model-driven app. Executives explore trends in Canvas apps inside Power BI, running live against Synapse. Power Automate handles the spoilage alerts. And no unnecessary record sits in Dataverse slowing things down.

Ultimately

If you design for the data, you get a database. If you design for the user, you get a solution.

The job is not to move all of the data. It is to move just enough of the right data to the right place for the right person. That is where the Power Platform earns its value, as long as you take the time to understand the problem and the people you are solving it for before you start building.

“A rose garden doesn’t bloom overnight—cultivate your architecture with care, and you won’t be pruning chaos later.”

If you are weighing Dataflows against Azure for your own data, that architecture decision is what Nerdy Q's services are for.