Add or Update Text on SharePoint Pages with Power Automate

You have data in a list, spreadsheet or line-of-business system and want a flow to turn it into readable SharePoint pages.

The old shortcuts usually involve copying a page, replacing text inside raw CanvasContent1 JSON and hoping Microsoft never changes the internal shape. That can work until a page layout, web part or escaped character changes.

Microsoft Graph now provides a supported way to create modern site pages and create or update text web parts. It does not let Power Automate safely insert text into “any part” of any SharePoint page.

That distinction matters.

The short answer

Use Power Automate to orchestrate a controlled Microsoft Graph call:

1. resolve the target site and page;
2. identify a known text web part or create one in a known section/column;
3. send a Graph request using an approved Graph-capable connector;
4. validate the result;
5. publish only when the page passes your checks.

Microsoft Graph v1.0 documents:

• creating a site page;
• creating a text web part at a defined page position;
• updating an existing text web part;
• publishing the latest page version.

The documented create/update endpoints require Sites.ReadWrite.All for delegated or application access. That is a broad permission. Treat the connection, consent and flow as governed production automation.

Why “Send an HTTP request to SharePoint” is not enough

Power Automate's SharePoint connector includes Send an HTTP request to SharePoint.

Microsoft's guidance says this action supports SharePoint REST APIs. It does not call other Microsoft services such as Microsoft Graph.

For the Graph page endpoints in this article, use a connection method approved by your tenant. One documented route is a custom connector: Microsoft publishes a Power Automate custom-connector tutorial for Microsoft Graph.

Your organisation may use another governed Graph-capable action or service. Confirm:

• the connector is permitted by data policy;
• the flow owner and connection owner are durable service identities where appropriate;
• admin consent has been reviewed;
• the licence covers the chosen connector and run volume;
• secrets or certificates are stored and rotated properly;
• the target site set is approved.

Do not promise “no premium licence” from an article. Power Automate and connector entitlements can vary by tenant, plan and architecture.

Choose the right pattern

There are three common jobs.

Pattern A: create a complete new page

Use this when every input record becomes a page with a controlled layout.

The Graph request is:

POST https://graph.microsoft.com/v1.0/sites/{site-id}/pages
Content-Type: application/json

The body must include:

{
  "@odata.type": "#microsoft.graph.sitePage",
  "name": "supplier-onboarding.aspx",
  "title": "Supplier onboarding",
  "pageLayout": "article",
  "showComments": false,
  "showRecommendedPages": false,
  "canvasLayout": {
    "horizontalSections": [
      {
        "layout": "oneColumn",
        "id": "1",
        "emphasis": "none",
        "columns": [
          {
            "id": "1",
            "width": 12,
            "webparts": [
              {
                "id": "11111111-1111-1111-1111-111111111111",
                "innerHtml": "<p>Approved page text goes here.</p>"
              }
            ]
          }
        ]
      }
    ]
  }
}

Generate a real unique ID for each web-part instance. Use the current Microsoft example as the contract and reduce it to only the page features you need.

Microsoft supports text web parts plus a defined set of standard web parts. An unsupported web part causes the request to fail; Graph is not a route for cloning every possible hand-built page.

Pattern B: add a text web part to a known position

Use this when a controlled page exists and the flow should add a new text block to a known section and column.

For a horizontal section, the endpoint shape is:

POST https://graph.microsoft.com/v1.0/sites/{site-id}/pages/{page-id}/microsoft.graph.sitePage/canvasLayout/horizontalSections/{section-id}/columns/{column-id}/webparts
Content-Type: application/json

Body:

{
  "@odata.type": "#microsoft.graph.textWebPart",
  "innerHtml": "<p>Approved page text goes here.</p>"
}

The API also supports an optional index query parameter to specify the insertion position in the web-part collection.

This is precise placement inside a supported SharePoint page structure. It is not arbitrary placement anywhere in the rendered page.

Pattern C: update one known text web part

Use this when a page contains a designated automation-owned text web part.

PATCH https://graph.microsoft.com/v1.0/sites/{site-id}/pages/{page-id}/microsoft.graph.sitePage/webParts/{webpart-id}
Content-Type: application/json

Body:

{
  "@odata.type": "#microsoft.graph.textWebPart",
  "innerHtml": "<p>Replacement text for the controlled block.</p>"
}

Microsoft documents innerHtml as the content property of a textWebPart resource.

Updating the whole block is usually safer than trying to find and replace one phrase inside a large HTML string.

Design the page before the flow

Automation works better when the page has a contract.

Define:

• page naming convention;
• page title source;
• target section and column;
• whether the flow owns the whole page or one text block;
• what human editors may change;
• draft, approval and publication rules;
• how source records map to page IDs and web-part IDs;
• what happens when the source record is deleted or archived.

If people can freely rebuild the controlled section, its saved web-part ID may disappear. Either prevent that through ownership and process, or rediscover the page structure before each update and fail safely when the expected block is missing.

Build an idempotent flow

An idempotent flow can run twice without creating duplicate pages or duplicate paragraphs.

Store these values with the source record or in a mapping list:

• stable source key;
• SharePoint site ID;
• page ID;
• page name/URL;
• designated web-part ID;
• last source version or hash;
• last successful update UTC;
• publication state;
• last error.

Then use this decision:

No page mapping
└── Create page → save returned page ID and web-part ID

Existing page mapping
├── Source unchanged → do nothing
├── Source changed and web part exists → update it
└── Page/web part missing → stop for repair; do not silently create a duplicate

A flow that searches by title alone is fragile. Titles are editable and not guaranteed unique.

Microsoft Graph can list the site's pages, but once you have created a page, retain its returned ID rather than repeatedly guessing which title is the right one.

Prepare the text safely

innerHtml is HTML, not plain text.

Do not drop untrusted form submissions, imported HTML or user-supplied markup straight into the request. At minimum:

• convert plain text to safe HTML;
• encode <, >, & and quotes where needed;
• allow only the small set of markup the page design requires;
• reject scripts, event attributes, embedded forms and unknown URLs;
• keep links on approved protocols and domains;
• cap content length;
• retain the original source separately.

For a controlled source, assemble simple semantic markup:

<h2>What is changing</h2>
<p>Approved, encoded summary.</p>
<h2>What you need to do</h2>
<p>Approved, encoded action.</p>

Do not build JSON through long string concatenation if your connector can accept a structured object. Quoting, line breaks and HTML characters are where apparently successful flows produce broken pages.

Recommended flow shape

Use a child flow or solution-aware flow so connection references and environment values are controlled.

1. Trigger — a reviewed source item changes or an approved batch starts.
2. Get configuration — site ID, target page policy and publication mode from environment variables/configuration.
3. Validate source — required fields, content length, owner and approval state.
4. Resolve mapping — page ID and web-part ID for the stable source key.
5. Compose safe content — create the structured request body.
6. Create or update — call only the intended Graph endpoint.
7. Read back — retrieve the returned page/web-part state.
8. Human approval — when content or audience requires it.
9. Publish — call the page publish endpoint only after checks pass.
10. Record outcome — IDs, version/hash, UTC time and any error.

Use explicit run-after paths so a failed Graph call records the error and clears any “processing” flag. A successful HTTP status is not enough if the wrong page was updated.

Draft versus published pages

Creating or updating a page does not mean you should publish it immediately.

Use draft-first when:

• the source text is written by people outside the page-owning team;
• the page reaches a large or regulated audience;
• links or dates need human review;
• an update could replace manually maintained content;
• translation or accessibility review is required.

Microsoft's sitePage publish operation publishes the latest version and can check in a checked-out page. Put that call behind the correct approval rather than adding it automatically to every create/update branch.

Batch processing without made-up speed claims

There is no responsible universal promise such as “500 pages in 15 minutes.”

Throughput depends on:

• connector and licence;
• tenant and Graph throttling;
• page size and web-part count;
• approval design;
• concurrent flow settings;
• retries;
• source-system latency;
• SharePoint service health.

For a batch:

1. process a small pilot;
2. use controlled concurrency;
3. handle 429 and transient 5xx responses using the returned retry guidance;
4. checkpoint each source record;
5. make reruns idempotent;
6. stop when failure rate crosses an agreed threshold;
7. retain a rollback mapping;
8. compare created/updated counts with intended source counts.

Fast duplication is not success if pages are wrong or unreviewed.

Verification checklist

Test with a non-admin reader, not only the flow owner.

• The correct page was created or updated.
• The page URL and ID are stored against the correct source key.
• The designated text web part contains the expected encoded content.
• Existing manual web parts are unchanged.
• The page remains a draft until its approval condition is met.
• Published content is visible to the intended reader.
• A user without permission cannot open it.
• A second identical run creates no duplicate page or block.
• A removed web part causes a controlled failure rather than a new duplicate.
• The rollback process can identify the exact page version/change.

Frequently asked questions

Can Power Automate add text anywhere on a SharePoint page?

No. Microsoft Graph can create pages and create or update supported text web parts at defined positions. It does not support arbitrary DOM edits or every SharePoint web-part type.

Can Send an HTTP request to SharePoint call Microsoft Graph?

No. Microsoft says that SharePoint connector action supports SharePoint REST APIs, not other Microsoft services such as Graph. Use a tenant-approved Graph-capable connector or custom connector.

What permission does Graph require to update a SharePoint text web part?

The current Microsoft Graph documentation lists Sites.ReadWrite.All as the least-privileged delegated and application permission for the update operation. Treat consent and connection ownership as a formal governance decision.

Should the flow edit CanvasContent1 directly?

Avoid raw CanvasContent1 find-and-replace for a new design. Use the supported Graph sitePage and web-part resources so the automation owns a defined page object or text block.

How do I stop the flow creating duplicate pages?

Give every source record a stable key, store the returned page and web-part IDs, compare the source version/hash before updating and fail safely when the mapped object is missing.

If you are converting list data into governed pages rather than a pile of duplicates, join the Power Automate Builders Space. Bring the target page contract, connector route and a redacted failed request—not credentials or tokens.