SharePoint List Forms: How to Keep Fields Read-Only and Use Power Automate to Fill Them

A very practical pattern in SharePoint Online is this one:

• the user fills only the business fields you want
• some columns stay read-only in the form
• Power Automate fills or updates those columns after creation or after a status change

This works well for columns such as:

• Requestor
• Submitted On
• Submitted By
• Review Owner
• Approval Snapshot
• helper columns used for governance or reporting

It also matches the actual behavior of modern SharePoint forms: form JSON and conditional formulas are mainly for form presentation and visibility, while Power Automate is the right tool to populate or update data after the item is created or modified. (Microsoft Learn)

Why this pattern is better than trying to force everything into the form

In modern SharePoint lists, you can configure the form and use conditional formulas to show or hide columns in the default form experience. That is useful for controlling the experience, but it is not the same thing as a full business-rules engine. Microsoft’s documentation for form configuration focuses on layout and predefined elements, while the SharePoint connector in Power Automate is designed to create and update list item values. (Microsoft Learn)

So the clean architecture is:

• SharePoint form controls what the user sees and edits
• Power Automate controls what the system fills in automatically

That separation is usually simpler, more supportable, and easier to document. (Microsoft Learn)

The target scenario

Let’s use a realistic example.

You have a list with these columns:

• Title
• Requestor (Person)
• Submit (Yes/No)
• SubmittedOn (Date/Time)
• SubmittedByEmail (Single line of text)
• Status (Choice)

And you want this behavior:

1. The user creates the item.
2. The user does not type Requestor, SubmittedOn, or SubmittedByEmail.
3. Those fields are treated as read-only in the form experience.
4. A Power Automate flow fills them automatically.
5. After Submit = Yes, some business fields also become non-editable in practice.

This is a very solid governance pattern for Microsoft Lists and SharePoint Online. (Microsoft Learn)

Part 1 — What “read-only” means in the native SharePoint form

This is the first concept to get right.

In the default modern SharePoint form, the platform officially supports conditional logic to show or hide columns in the form. Microsoft documents this through the form’s Edit columns experience and conditional formulas. (Microsoft Learn)

That means the most reliable native pattern is usually not “hard lock every field in place,” but instead:

• show a field only when it should be editable
• hide it when users should no longer interact with it
• optionally expose the value elsewhere for display or in the item view

So when people say “read-only” in native SharePoint forms, in practice they often mean one of these:

Pattern A — Hide the field from the form

The field still exists in the list, but users no longer see it in New/Edit.

Pattern B — Show the field only to some users or only in some states

For example, only show ReviewerComments when Status = In Review.

Pattern C — Let Power Automate own the field

The field exists, but users never type into it because the flow fills it.

That is the pattern this article recommends. (Microsoft Learn)

Part 2 — Best design principle: separate user fields from system fields

Do not make the form harder than it needs to be.

A cleaner design is to separate columns into two groups:

Editable business fields

These are fields the user should really fill out:

• Project Name
• Description
• Priority
• Required Date
• Category

System-controlled fields

These should be controlled by the process, not by the user:

• Requestor
• Submitted On
• Submitted By Email
• Flow Processed
• Locked After Submit
• Approval Stage Snapshot

This helps avoid accidental edits and keeps reporting more trustworthy. The SharePoint connector’s Create item and Update item actions are designed exactly for this kind of server-side update pattern. (Microsoft Learn)

Part 3 — Create the columns

For this pattern, create the following columns in your list.

Recommended columns

Site columns are supported in SharePoint Online, so you can create reusable columns at site level and add them to the list if you want consistency across solutions. (Microsoft Learn)

Part 4 — Hide or conditionally show fields in the native form

Now configure the list form.

Open the list, then:

1. Click New
2. Open the form menu
3. Choose Edit columns
4. For the columns you want to manage, apply conditional formulas as needed

Microsoft documents this form-level conditional formula experience for showing or hiding fields in list and library forms. (Microsoft Learn)

Recommended visibility strategy

Always hide system-controlled fields from normal users

Hide these fields from manual entry:

• SubmittedOn
• SubmittedByEmail
• FlowProcessed

These are flow-owned fields.

Conditionally show fields only when needed

For example, show ReviewerComments only when status reaches a review stage.

For Requestor

You have two good options:

• hide it completely and let Flow fill it
• show it only for admins or special users

Example conditional formula

A common example is to show a field only when Submit = false.

=if([$Submit] == true, 'false', 'true')

This means:

• when Submit is true, the field is hidden
• when Submit is false, the field is shown

That formula style aligns with Microsoft’s documented list form conditional formula approach. (Microsoft Learn)

Example: show a field only for one specific user

=if([$CurrentUser.email] == 'user@contoso.com', 'true', 'false')

This can be useful for admin-only helper fields, though for most business scenarios I recommend keeping governance fields hidden and filled by Flow instead of manually exposing them. Microsoft documentation and related support discussions show this conditional-formula model for field visibility in the list form. (Microsoft Learn)

Part 5 — Build the Power Automate flow that fills the read-only fields

This is the core of the solution.

Use an automated cloud flow with the SharePoint connector.

Flow name

Populate read-only SharePoint fields

Trigger

When an item is created

This trigger is part of the SharePoint connector for Power Automate. (Microsoft Learn)

Step-by-step flow design

Step 1 — Create the trigger

Choose:

• Site Address
• List Name

Use the same SharePoint list where the form is used. The SharePoint connector documentation lists these triggers and actions for list items and files. (Microsoft Learn)

Step 2 — Add an Update item action

Use Update item.

Set:

• Site Address = same site
• List Name = same list
• Id = ID from trigger

Then populate the read-only fields.

Example mapping:

• Requestor = Created By Email or another mapped person identity
• SubmittedOn = utcNow()
• SubmittedByEmail = Created By Email
• FlowProcessed = Yes
• Status = Draft or Submitted

The SharePoint connector supports updating list item column values through Update item. (Microsoft Learn)

Important note for Person columns

Person columns are not plain text. In Power Automate and in APIs, they are handled differently from a simple single-line text field. Microsoft support discussions around SharePoint person fields note that these fields require proper user identity handling, and in some API cases you may need claims or lookup-style identity values. (Microsoft Learn)

In the normal SharePoint Power Automate connector experience, the easiest route is usually:

• use the person-related dynamic content exposed by the trigger
• or use the email value and let the connector resolve it if the action supports it in your environment
• test with a single-user Person column first

For many teams, a practical fallback is to store both:

• a real Requestor person field
• a SubmittedByEmail text snapshot

That gives you both usability and easy reporting. (Microsoft Learn)

Part 6 — Recommended production pattern

Here is the pattern I recommend most.

On create

Flow fills:

• Requestor
• SubmittedOn
• SubmittedByEmail
• FlowProcessed = Yes

On submit

A second flow or condition updates:

• Status = Submitted
• lock-related helper field such as Submit = Yes

In the form

Conditional formulas hide fields when the item is already submitted.

This gives you a stable and maintainable lifecycle:

• easy New form
• clean audit columns
• less manual error
• lighter UI logic

That combination of native form logic plus SharePoint connector actions is fully aligned with the documented capabilities of SharePoint forms and Power Automate. (Microsoft Learn)

Part 7 — Example architecture for “read-only after submit”

This is one of the best enterprise patterns.

Columns involved

• Submit = Yes/No
• Status = Choice
• Requestor = Person
• SubmittedOn = Date
• SubmittedByEmail = Text

Behavior

Before submit

User edits:

• Title
• Description
• Category
• Priority

After submit

Hide from the form:

• Title
• Description
• Category
• Priority

Or only hide selected fields, depending on your process.

Always flow-controlled

Never manually edit:

• Requestor
• SubmittedOn
• SubmittedByEmail

This pattern relies on SharePoint’s form-visibility logic rather than trying to turn every field into a fully managed custom control. (Microsoft Learn)

Part 8 — Example formulas

Hide a field after submit

=if([$Submit] == true, 'false', 'true')

Show a field only when status is Draft

=if([$Status] == 'Draft', 'true', 'false')

Show a field only for one admin email

=if([$CurrentUser.email] == 'admin@contoso.com', 'true', 'false')

These are examples of the conditional formula style documented for list form visibility. (Microsoft Learn)

Part 9 — What not to do

Do not rely on column formatting to change the stored value

Microsoft’s column-formatting documentation is very clear: formatting changes the display, not the data. It does not update list item values. (Microsoft Learn)

Do not overload the form with process-owned fields

If a field is truly process-owned, let the flow write it.

Do not mix audit intent and business intent

Author and Created By are audit fields. Requestor is a business field. Keep them separate.

Do not assume a Person column behaves like a text field

Person fields need more care in flows and APIs. Test them early. (Microsoft Learn)

Part 10 — When to use Power Apps instead

This article is focused on native SharePoint forms plus Power Automate.

But if you need:

• true card-level edit/view mode
• dynamic defaults before save
• custom validation
• richer user-specific rules
• a polished custom UX

then customize the list form with Power Apps. Microsoft documents SharePoint form integration and form behavior in Power Apps, including Edit form and Display form controls. (Microsoft Learn)

So the decision is simple:

• Native form + Flow = best for lightweight governance
• Power Apps form = best for advanced UX and true client-side control

Part 11 — Full implementation walkthrough

Step 1 — Create the list columns

Create:

• Requestor (Person)
• SubmittedOn (Date and Time)
• SubmittedByEmail (Text)
• Submit (Yes/No)
• FlowProcessed (Yes/No)
• Status (Choice)

Step 2 — Configure the form

Use Edit columns and conditional formulas to:

• hide SubmittedOn
• hide SubmittedByEmail
• hide FlowProcessed
• optionally hide Requestor
• hide business fields after Submit = true

Step 3 — Build Flow 1

Trigger: When an item is created

Action: Update item

Fill:

• SubmittedOn = utcNow()
• SubmittedByEmail = Created By Email
• FlowProcessed = Yes
• Requestor = creator identity or mapped person
• Status = Draft

Step 4 — Build Flow 2

Trigger: When an item is created or modified

Condition:

• if Submit = true
• and optionally if FlowProcessed = Yes

Action:

• update Status = Submitted
• update any process columns needed
• optionally send notification

Step 5 — Retest the form

Validate these scenarios:

• new item
• edit before submit
• edit after submit
• flow re-run behavior
• Person field resolution

These steps use capabilities documented across SharePoint form configuration, conditional formulas, and the SharePoint Power Automate connector. (Microsoft Learn)

Part 12 — Recommended baseline for your SharePoint solutions

For internal request forms, I recommend this baseline:

Use the form for

• collecting user-entered business data
• hiding irrelevant fields
• simplifying the input experience

Use Power Automate for

• stamping identity
• stamping timestamps
• assigning process status
• enforcing consistency
• filling helper and reporting columns

Use Power Apps only when needed

• true interactive locking
• custom people picker defaults
• complex branching UX

This keeps the solution stable and easy to support over time. (Microsoft Learn)

Final conclusion

If your goal is to have “read-only fields in the SharePoint form that are automatically populated,” the best practical design is not to fight the native form engine.

Instead:

• hide or conditionally show those fields in the native form
• let Power Automate populate them with Create item / Update item
• reserve Power Apps for cases where you need true client-side edit control

That is the cleanest modern SharePoint Online approach, and it aligns with Microsoft’s documented model for form configuration and connector-based data updates. (Microsoft Learn)

Summary table — implementation steps

Summary table — technical guidance

Summary table — Microsoft references