One Hook Should Decide Who You Are and What You Can Do

HokaGue-Devs — Thu, 08 Oct 2026 09:00:01 +0000

Most Power Platform Code Apps I've reviewed eventually accumulate two, three,
sometimes five different places that each answer "what can this user do" -
slightly differently every time. One hook checks a role field. A screen
re-checks it with a different condition. A button disables itself based on a
third rule that nobody remembers writing.

By the time someone asks "can a Regional Manager delete a validated record,"
nobody can answer with certainty - because the answer isn't in one place.

The invariant

One hook answers "who am I, and what am I allowed to do." Everything else
derives from it.

function usePermissions(): { role: Role; can: (action: Action) => boolean } {
  // the ONLY place that resolves identity -> role -> capability
}

Every screen, every button, every guard calls this hook - never its own
re-implementation of the rule.

Adding a dimension without breaking the invariant

The moment you need a second dimension - say, permissions that also depend on
which business entity the user is acting in - the instinct is to wire the new
logic into the existing hook. Don't. Compose a second hook on top of the
first one.

function usePermissionsForEntity(entityId: string) {
  const base = usePermissions();
  // combines base.role with entity-specific rules
  // never calls back into itself - no cycle
}

Wiring the first hook to depend on the second (instead of composing on top)
is how you get a circular dependency that only shows up once the app is big
enough to hurt.

Why this is worth protecting

One audit point. "What can a Regional Manager do" has exactly one place to read, not five to reconcile.
Safe to extend. A new dimension (entity, project, region - whatever your domain needs next) is a new layer on top, never a rewrite of the foundation.
Impossible to accidentally diverge. A button and a screen can't disagree about what's allowed if they both call the same function.

I work on Power Platform / Dataverse architecture (Code Apps, permission
models, approval workflows). Happy to discuss your project's architecture if
you're scoping something similar.

The Power Apps Code App Licensing Trap Nobody Tells You About

HokaGue-Devs — Wed, 07 Oct 2026 19:55:01 +0000

If you're building a Power Apps Code App (React + TypeScript + Dataverse), there's
one requirement that can kill an otherwise finished project: every end user needs
a Power Apps Premium per-user license.

Not a per-app license. Not a free tier. A Premium license, per person, for
every single user who will open the app.

This sounds obvious once you say it out loud - but it's easy to miss during
scoping, especially when the business asks for "an app for everyone in the
company." I've seen this surface after an application was fully built,
tested, and approved by the business: the project was technically done, and
licensing is what put it on hold.

Why this matters more than it seems

Power Apps Code Apps run on Dataverse, and Dataverse access via a custom app isn't covered by the free/basic tiers most organizations already have for Microsoft 365.
The cost scales with headcount, not with app complexity. A simple five-screen app for 2,000 employees can be far more expensive to license than a complex app for 50 people.
Procurement and budget approval for licensing often takes longer than building the app itself.

What to do instead

Ask this question before writing the first line of code, not during UAT:

"Who exactly will use this app, and do they already hold a Power Apps
Premium license for another reason?"

If the answer is "everyone in the company" or "we don't know yet," that's your
signal to escalate licensing to a budget conversation immediately - not a
technical one. A project that's code-complete but licensing-blocked is a
worse outcome than a project that never started, because by then the
business has already committed expectations.

Takeaway

Technical excellence doesn't protect a project from a licensing model nobody
priced in. If you're scoping a Power Platform Code App, put the licensing
question in the very first round of requirements - right next to "how many
levels does the approval workflow have."

I work on Power Platform / Dataverse architecture (Code Apps, Power Automate,
approval workflows, multi-entity permission models). Happy to discuss your
project's architecture if you're scoping something similar.

DEV Community: HokaGue-Devs