Power Apps model-driven form errors

A model-driven app's forms are generated from Dataverse table metadata rather than hand-built, so most of what goes wrong traces back to security, a business rule, or the business process flow acting on the record — not a bug in the form layout itself.

The record is unexpectedly read-only

Symptom. A user who should be able to edit a record finds every field locked, with no clear indication why.

Cause. Several independent things can each make a record read-only: the security role's write privilege at the relevant access level (User, Business Unit, Organization), the record's own state (an inactive, closed, or won record is read-only by design in most standard entities), or an active business process flow stage that locks fields until its own requirements are satisfied.

Fix. Check in this order: the record's status/state first (the simplest and most common cause), then the security role's privileges for that table at the right access level, then whether a business process flow stage is enforcing required fields before allowing further edits.

Prevention. When rolling out a new business process flow, document which stages lock which fields so "why is this read-only" doesn't become a recurring support question distinct from an actual security issue.

A business process flow gets stuck on a stage it shouldn't be on

Symptom. A record's business process flow shows the wrong current stage, or a user can't advance past a stage that looks complete.

Cause. A business process flow's stage is a value on the record itself, set by the flow's own logic and business rules tied to required fields on that stage — a required field left blank, a business rule that unexpectedly re-locks a field the flow depends on, or a workflow that changes the record's status outside the flow's own logic can all leave the stage out of sync with what a user expects.

Fix. Open the process flow directly on the record and check which required fields the current stage is actually waiting on (the flow surfaces this, though sometimes only after clicking into the stage), rather than assuming the stage indicator itself is wrong.

Prevention. Avoid changing a record's core status fields (like state or a custom stage-adjacent field) from a plugin, flow, or workflow that runs independently of the business process flow's own stage logic — that's the most common way a flow's displayed stage and a record's actual state drift apart.

A subgrid or lookup shows stale or missing related records

Symptom. A subgrid on a form, or a lookup search, doesn't show a related record that clearly exists.

Cause. Subgrids and lookups respect the viewer's security (row-level and field-level), so a record that exists but that the current user's security role or team membership doesn't grant visibility to will simply not appear — which looks identical, from the form, to the record genuinely not existing.

Fix. Confirm whether the missing record is visible to a system administrator (ruling out "it doesn't exist" or "it was deleted") before troubleshooting the subgrid's view or filter configuration — a security-model gap is a far more common cause than a broken view.

Prevention. When designing sharing and ownership for a new table, explicitly test visibility from a non-administrator user's account, since admin accounts bypass most of the row-level security that regular users hit.

A form script or business rule error appears only for some users, not others

Symptom. A JavaScript form customisation or business rule throws an error, but only for a subset of users, not everyone using the same form.

Cause. Form scripts commonly run different logic depending on the current user's security role, team membership, or a field value only some records have populated — a script that assumes a field is always populated (because it always was for the developer's test data) will fail specifically for users or records where that assumption doesn't hold.

Fix. Reproduce the error with the specific affected user's security context (or a record with the same field-population pattern) rather than the developer's own account, since form scripts frequently behave correctly under a broader security role that masks a narrower role's gap.

Prevention. Test form customisations against a representative non-administrator test user with a typical security role, not only against a system administrator account during development.

Where to go next

The parallel canvas-app failure modes are in Power Apps canvas app errors explained; the security model these forms sit on top of is in Dataverse security model; business rule and duplicate-detection specifics are in Dataverse duplicate detection and business rule errors.