DEV Community: HokaGue-Devs

A Bundle Budget Is a Product Requirement

HokaGue-Devs — Mon, 19 Oct 2026 09:15:48 +0000

A business application can be functionally correct and still fail its first impression because the initial JavaScript bundle is too large.

A performance budget makes the trade-off explicit: what loads immediately, what can be split, and what belongs behind a route or interaction. It also gives a team a measurable regression signal instead of relying on anecdotes.

Power Apps Code Apps deserve the same discipline as any web application. Bundle size, startup time, and data volume are part of the product quality users experience.

PowerPlatform #React #TypeScript #Performance #Architecture

Server-Side Filtering Is a Scaling Decision

HokaGue-Devs — Sat, 17 Oct 2026 09:00:00 +0000

A list that feels fast with a few hundred rows can become unusable once the data grows.

Loading everything into the browser and filtering locally increases memory use, exposes more data than necessary, and makes response time depend on the total table size.

Pagination, filtering, and sorting should happen at the server boundary when the volume justifies it. The UI should request the slice it needs and keep the query aligned with the user’s permissions.

Performance and security meet at the same boundary: retrieve only what the user is allowed to see and what the screen can actually display.

PowerPlatform #Dataverse #Performance #Architecture #LowCode

A Degraded Mode Is Better Than Silent Failure

HokaGue-Devs — Fri, 16 Oct 2026 18:00:00 +0000

When a connector or Power Automate flow is unavailable, the worst outcome is a screen that appears to have accepted the action.

A degraded mode should make the failure visible, preserve the user’s intent when possible, and provide a next step. It should distinguish “saved,” “queued,” and “not completed.”

The message is part of the business process. A user who believes a notification was sent will act differently from one who knows it is waiting for retry.

PowerPlatform #PowerAutomate #Dataverse #Reliability #LowCode

Reminders Need Escalation Rules

HokaGue-Devs — Fri, 16 Oct 2026 09:00:01 +0000

Sending one reminder does not solve a stalled approval. A useful reminder policy defines the delay, the recipient, the number of attempts, and the escalation path.

The threshold should be configurable rather than buried in a flow. The history should show when the reminder was sent and when responsibility moved to a substitute or higher level.

A process that can notify but cannot escalate still depends on someone noticing the notification.

PowerPlatform #PowerAutomate #Dataverse #Workflow #Architecture

Delegation Should Have an End Date

HokaGue-Devs — Thu, 15 Oct 2026 18:00:01 +0000

Absence handling often begins as a manual change to someone’s role. That creates a second problem: nobody remembers to undo it.

A proper delegation has a scope, a start date, an end date, and an audit entry. Permission resolution checks whether the delegation is active for the requested entity and workflow level.

The end date is not a convenience. It is the control that prevents a temporary replacement from becoming an invisible permanent privilege.

PowerPlatform #Dataverse #Security #Governance #Architecture

Build the “What Is Waiting for Me?” View First

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

A validator should not have to browse five lists to discover the one request waiting for a decision.

The most useful first screen is often not a dashboard full of decorative metrics. It is a focused view of the user’s pending actions, grouped by urgency and workflow level.

That view depends on correct role resolution, entity scoping, server-side filtering, and durable state. It is therefore a good architectural test: if “what awaits me” is difficult to compute, the permissions or workflow model may be too scattered.

Design the landing experience around the decision the user came to make.

PowerPlatform #PowerApps #Dataverse #UX #LowCode

A Data Health Screen Finds Problems Before Users Do

HokaGue-Devs — Wed, 14 Oct 2026 18:00:01 +0000

A user should not discover that a reference table is incomplete halfway through a business process.

If an entity has no responsible direction, a category has no type, or a validator is missing, the application should detect it at startup and explain the impact. Otherwise the user experiences a generic empty list or a failed notification and concludes that the application is broken.

A health screen turns silent data defects into actionable checks: what is missing, who can fix it, and which workflows are affected.

This is not an administration luxury. In data-driven applications, the quality of reference data determines whether the process can execute at all.

PowerPlatform #Dataverse #DataQuality #Governance #LowCode

Import and Export Need a Contract, Not Just a Button

HokaGue-Devs — Wed, 14 Oct 2026 09:00:01 +0000

“Add import” is not a complete requirement. Users need to know which columns are accepted, which values are valid, what is mandatory, and what happens when one row fails.

A reliable import workflow starts by downloading a template, validates before writing, reports errors by row, and makes retries safe. Export should preserve enough structure to be useful without leaking fields the user is not authorized to see.

The template is not documentation stored somewhere else. It is part of the user experience and part of the contract between the application and its data.

A good test includes an empty file, a duplicate, an invalid reference, a partial failure, and a file produced by the export itself.

PowerPlatform #Dataverse #PowerApps #DataQuality #LowCode

Sensitive Financial Fields Need More Than Hidden Columns

HokaGue-Devs — Tue, 13 Oct 2026 18:00:01 +0000

A field hidden by the interface is still readable by an export, an API call, or a technical account. Visibility rules and encryption solve different problems.

For sensitive financial values, the threat model should cover storage, transport, exports, logs, and operational access. A UI that masks a number while the database stores it in clear text has improved presentation, not confidentiality.

A migration also needs a compatibility plan: introduce the protected field, read from the new field first, fall back to the legacy value during transition, and remove the clear field only after verification.

Security decisions are architectural when the data is financial or personal. They should not depend on whether the current screen happens to display the value.

PowerPlatform #Dataverse #Security #Compliance #Architecture

Bulk Operations Must Be Safe to Retry

HokaGue-Devs — Tue, 13 Oct 2026 12:51:31 +0000

A bulk operation that fails at item 437 is not exceptional. Networks break, sessions expire, and flows time out.

The dangerous design is a process that cannot be restarted safely. Run it again and it creates duplicates, sends duplicate notifications, or advances records twice.

Idempotence means the same operation can be applied again without changing the final result after the first successful application. In practice, that requires stable business keys, explicit processing states, and writes that can recognize work already completed.

The retry strategy should be designed before the first CSV import or mass transition. A progress log should distinguish pending, completed, and failed items, with enough detail to resume only what is necessary.

“Just run it again” is a safe instruction only when idempotence has been designed deliberately.

PowerPlatform #PowerAutomate #Dataverse #Integration #Architecture

Optimistic Locking Prevents Silent Overwrites

HokaGue-Devs — Mon, 12 Oct 2026 18:00:04 +0000

Two people open the same request. Person A edits the amount. Person B edits the comment and saves later. Without optimistic locking, B can overwrite A’s change with an older snapshot.

The application may report success while silently losing valid work. That is worse than an explicit conflict because nobody knows a decision was replaced.

A practical approach stores a version or row timestamp and sends it with the update. The server accepts the write only if the version is still current. Otherwise, the user receives a conflict message and can compare before deciding what to keep.

This is especially important for Dataverse-backed Code Apps where several screens, flows, and users can touch the same record.

Concurrency is not an edge case when a process is shared. It is the normal case waiting to happen.

PowerPlatform #Dataverse #React #Architecture #LowCode

Notify the Role, Never the Person

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

A validation workflow with four levels will, sooner or later, break this rule:
someone sends an email notification to a specific person instead of to
whoever currently holds the role. It looks harmless - "just email the
manager" - until that manager goes on leave, changes team, or the role gets
reassigned, and the notification keeps going to someone who no longer has
any say in the decision.

The invariant

Notifications target a role, never a person. The recipient is derived
from the role expected at the workflow level being notified - and every
holder of that role receives it.

function recipientsFor(level: WorkflowLevel, entityId: string): User[] {
  // resolves to "everyone currently holding the expected role for this level
  // and entity" - never a stored person reference
}

Why "just email the person" always comes back to bite

Roles change, hardcoded emails don't. The day someone leaves or switches teams, every notification still pointing at them silently stops reaching anyone who can act.
Delegation becomes possible for free. If the recipient is "whoever holds this role," adding a temporary delegate (someone on leave) is a one-line change to role resolution - not a hunt through every place an email address was hardcoded.
Auditability. "Who was supposed to be notified at level 3 last March" is answerable from role history, not from a snapshot of someone's inbox three resignations ago.

The practical rule of thumb

If your notification code reads a person's name, email, or user ID directly
from a record instead of asking "who currently holds the expected role here,"
that's the bug waiting for the next org change.

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