Power Apps - History

What Power Apps actually is

Power Apps is Microsoft’s rapid application development layer for business applications. It sits above data sources such as SharePoint, Dataverse, SQL Server, Microsoft 365 services, and APIs/connectors, and lets you build browser/mobile apps without writing a conventional web stack. Microsoft currently divides Power Apps primarily into Canvas apps and model-driven apps. (Microsoft Learn)

For your scouting mission, you are in the Canvas app branch:

SharePoint Lists
       ↓
   Connectors
       ↓
   Canvas App
       ↓
Screens
       ↓
Containers
       ↓
Forms / Galleries / Controls
       ↓
    Power Fx

You already have the first two layers working.

Where did it come from?

It is not literally Oracle Forms reincarnated, but there is a recognizable lineage.

Microsoft had a collection of overlapping business-app tools over the years: Access, SharePoint custom forms, InfoPath, SharePoint Designer workflows, Dynamics CRM forms, plus Excel-style formulas. Power Apps arrived in the mid-2010s as Microsoft started consolidating much of that low-code business-application territory.

PowerApps reached general availability in 2016 alongside the original Common Data Service, which eventually became Dataverse. Even at launch, Microsoft was positioning it as a way to build apps directly over SharePoint and other business data. (Microsoft)

The InfoPath connection is particularly direct for a SharePoint person. Microsoft explicitly recommends Power Apps as a replacement technology for custom SharePoint forms that previously would have been built with InfoPath. InfoPath 2013 support ended July 14, 2026, and Microsoft has shifted those scenarios toward Power Apps, Power Automate, Lists and related tools. (Microsoft Support)

So mentally, I would place it roughly here:

Access / Oracle Forms thinking
          +
SharePoint Lists / InfoPath
          +
Excel formula language
          +
modern web/mobile UI
          ↓
      Power Apps

Not a historical family tree, but a very useful conceptual one.

Canvas versus model-driven

This distinction matters.

A Canvas app starts with the interface. You decide where things go, what controls appear, what data sources they talk to, and how they behave. Microsoft describes Canvas as giving you high control over the user experience and allowing connections to many external data sources. (Microsoft Learn)

A model-driven app starts with the data model in Dataverse. You define tables, relationships, forms, views and business processes, and Power Apps generates much more of the UI for you. Model-driven apps require Dataverse. (Microsoft Learn)

For what you are doing now:

Canvas is the correct choice.

You already have your data in SharePoint. You want a custom Centre-centric display. There is no reason to drag Dataverse onto the scout boat yet.

Your existing knowledge maps surprisingly well

Your database background is immediately useful.

You already understand:

table
record
column
primary-ish key
foreign key
one-to-many
query/filter

Power Apps merely changes some vocabulary:

database concept        Power Apps concept

table                   data source / table
row                     record
column                  field
SELECT ... WHERE        Filter()
SELECT one row          LookUp()
one current row         Form.Item
multiple rows           Gallery.Items
relationship            usually expressed in Power Fx

Your current app is basically:

CentreInfo
    1
    │ Centre Name
    │
    ∞
Contacts

The dropdown establishes the current master record. The Form presents that record. The Gallery queries the detail records.

Very old problem. Very new toolbar.

Your SharePoint background is probably the biggest advantage

You already understand that the list is not the view.

That distinction caught us briefly with Info versus Contacts, but once you recognized the old exports were views over underlying lists, the model became much clearer.

In Power Apps, you will increasingly stop thinking:

“I need the SharePoint Contacts view.”

and instead think:

“I need records from this list, filtered and presented as Contacts.”

For example:

Filter(
    Contacts,
    'Centre Name' = ddCentre.Selected.'Centre Name'
)

That is Power Apps taking over work that SharePoint views previously performed.

Microsoft supports Power Apps both as a customized SharePoint form and as a standalone app using SharePoint as its data source. You are effectively doing the latter. (Microsoft Learn)

Your Python-dev instincts need one adjustment

Power Fx is declarative, not primarily procedural.

This is perhaps the biggest conceptual adjustment.

You are used to:

contacts = [
    x for x in contacts
    if x.centre_name == selected_centre
]

Power Apps wants:

Filter(
    Contacts,
    'Centre Name' = ddCentre.Selected.'Centre Name'
)

You assign that expression to the Gallery's Items property.

Then when ddCentre.Selected changes, Power Apps reevaluates the expression.

That is why the Properties pane matters so much. Many controls are essentially little objects with formulas attached to properties:

Gallery
├── Items
├── Visible
├── X
├── Y
├── Width
├── Height
└── ...

You are not constantly issuing commands to the UI. You are declaring what each property should equal.

That has much more in common with spreadsheets, reactive UI frameworks and declarative GUI systems than with imperative Python.

Controls are your widgets

The useful Canvas controls for you initially are only a small set:

Dropdown / Combo box
Form
Gallery
Label
Button
Container
Text input

Ignore the zoo until you need it.

Your snapshot already has the important architecture:

Canvas App
└── Screen
    └── Canvas
        └── Vertical container
            ├── Centre dropdown
            ├── Centre/Info Form
            ├── Contacts Gallery
            └── Regions Gallery

The Form solves the one-record problem.

The Gallery solves the repeated-record problem.

The Container solves the layout problem.

That trio will probably account for most of your first app.

Forms are much more important than they looked yesterday

This is where your Oracle Forms experience comes roaring back.

A Power Apps Form has:

DataSource
Item
DefaultMode
OnSuccess
OnFailure

and contains Data Cards, normally one per field.

You can:

EditForm(frmCentre)

then:

SubmitForm(frmCentre)

or:

ResetForm(frmCentre)

The form handles much of the boring machinery: current record, field values, validation, submission and update behavior.

That is why manually placing ten labels and ten text boxes felt strangely primitive. You had bypassed the abstraction intended to do the work.

Galleries are basically repeaters

A Gallery receives a table expression:

Filter(
    Contacts,
    'Centre Name' = ddCentre.Selected.'Centre Name'
)

Then you design one item template:

Name
Role
Phone
Email

Power Apps repeats it for every matching record.

Think:

result set + row template

and galleries become completely unsurprising.

Containers are CSS layout managers wearing Microsoft clothing

They are not Docker. Tragically.

A vertical container says:

put my children one below another.

A horizontal container says:

put my children beside one another.

You can nest them.

That gets you away from this:

Y = 220
Y = 240
Y = 260

and toward:

Vertical container
├── header
├── Form
├── header
├── Gallery
└── footer

This is one of the areas where the Canvas designer has evolved. Microsoft now explicitly documents responsive app design using containers rather than relying entirely on fixed coordinates. (Microsoft Learn)

The thing I would learn early: delegation

This is the first Power Apps concept that is genuinely different enough that I would put a star beside it.

Suppose you write:

Filter(BigSharePointList, ...)

Ideally, Power Apps sends the filtering operation to SharePoint and asks SharePoint to return only the matching rows.

That is delegation.

But not every Power Fx operation can be translated into a query the remote data source understands. When an expression is non-delegable, Power Apps may retrieve only a limited portion of the source and process it locally.

On tiny demo lists, you may never notice.

On thousands of rows, it can produce something much nastier than a performance problem:

incorrectly incomplete results.

When Power Apps gives you a delegation warning, do not treat it as designer lint. Investigate it.

For your Centre/Contacts demo, straightforward SharePoint filtering on suitable columns should keep things relatively tame, but delegation should be in your vocabulary early.

Connections versus data sources

Another distinction worth making now:

Connection
   ↓
authentication/path to SharePoint

Data source
   ↓
specific list used by the app

A Canvas app may use many data sources through one or more connections.

So you can have:

SharePoint connection
├── CentreInfo
├── Contacts
└── Regions

and all three can appear on the same screen.

There is no data-source isolation requirement between sections of the Canvas.

Power Automate is beside Power Apps, not inside the same job

Eventually you will hit something like:

when a Centre is changed, email somebody, create a PDF, update another system, wait for approval, then notify Teams.

That is where Power Automate enters.

Think:

Power Apps     user interacts now
Power Automate process happens across systems

Power Automate is Microsoft's orchestration/workflow piece and uses the same broad connector ecosystem. (Microsoft Learn)

Don't reach for it merely because a button needs to save a record. SubmitForm() is perfectly capable of doing mundane work.

Dataverse can remain somebody else's problem for now

Dataverse is Microsoft's proper Power Platform application data store. It brings stronger relationships, security, business rules, server-side extensibility and application lifecycle capabilities than SharePoint Lists. (Microsoft Learn)

Eventually you may encounter a requirement where SharePoint starts protesting:

• complex relational data
• many interconnected entities
• row-level business security
• substantial business logic
• heavy transactional behavior
• larger enterprise Power Platform application suite

That is when Dataverse becomes worth discussing.

It is not a prerequisite to building useful Power Apps.

And Fabric stays on its battleship

Fabric is analytics/data engineering territory.

You currently have:

SharePoint
     ↓
Power Apps
     ↓
people doing work

Fabric becomes interesting when you have:

many systems
     ↓
pipelines / transformations
     ↓
historical consolidated data
     ↓
analytics / Power BI

Different mission.

Where your sysadmin instincts become important

Power Apps is not merely an editor. There is a platform underneath it:

Tenant
└── Environments
    ├── Apps
    ├── Connections
    ├── Flows
    ├── Dataverse (possibly)
    ├── security roles
    └── policies

That is the piece I suspect you will understand faster than many pure app makers.

You will eventually care about:

• who owns an app
• who owns a connection
• who can edit versus run
• dev/test/prod environments
• what happens when the developer leaves
• environment variables
• solutions
• DLP policies
• deployment
• service accounts
• licensing

Given that you have inherited an abandoned environment, ownership and application lifecycle management are not theoretical concerns.

For the POC, ignore most of it.

But before anything becomes operationally important, I would absolutely inspect how ownership and deployment are expected to work.

Power Apps is low-code, not no-engineering

This distinction may save your sanity.

The marketing surface says:

drag things around and describe what you want.

The engineering reality is still:

requirements
data model
relationships
UI structure
state
validation
error handling
security
performance
deployment
maintenance

Power Apps simply gives you prebuilt machinery for much of it.

The complexity hasn't vanished. It has been compressed into configuration, formulas and platform conventions.

That is why your BA, database and sysadmin experience may actually matter more than knowing Power Fx syntax.

Your likely learning order

I would learn only this much at first:

1. Canvas App
2. Screen
3. Containers
4. Controls
5. Data sources
6. Form + Data Cards
7. Gallery
8. Filter() / LookUp()
9. SubmitForm()
10. Power Fx properties
11. Delegation
12. Responsive layout

Then stop.

Do not presently wander into:

Dataverse
Solutions
PCF controls
custom connectors
Power Automate
Power Pages
Fabric
Copilot Studio
Dynamics 365

unless your POC actually asks for them.

The snapshot

For your notes, I think this is the useful conceptual picture:

POWER PLATFORM
│
├── Power Apps
│   │
│   ├── Canvas Apps     ← YOU ARE HERE
│   │   │
│   │   ├── Screens
│   │   │   └── Containers
│   │   │       └── Controls
│   │   │           ├── Forms    → one record
│   │   │           └── Galleries → many records
│   │   │
│   │   ├── Power Fx
│   │   │
│   │   └── Connectors
│   │       └── SharePoint
│   │           ├── CentreInfo
│   │           ├── Contacts
│   │           └── Regions
│   │
│   └── Model-driven Apps
│       └── Dataverse
│
├── Power Automate
│   └── workflows / orchestration
│
└── Dataverse
    └── Power Platform application database

That is enough territory for the scouting party.

And there is one particularly encouraging historical detail for this week: Microsoft itself describes Power Apps Studio as having a design experience somewhat like building a slide deck. (Microsoft Learn)

Which explains both its accessibility and why a database developer can spend two hours hunting for Properties while wondering who hid the actual development environment. 😆