ROM

365

Personal Account Automations

When using Power Automation to update/create an item the author and editor will corrupt the data due to automation connection being set to these fields. This can be corrected by following the action with another HTTP api action to update the fields with original data.

HTTP Request to SharePoint
Uri
_api/web/lists/getByTitle('<ListName>')/items(@{outputs('Create_item')?['body/ID']})/validateUpdateListItem

Body

{

"formValues": [

{ "FieldName": "Author", "FieldValue": "[{'Key':'i:0#.f|membership|@{triggerBody()?['Author/Email']}'}]" },

{ "FieldName": "Editor", "FieldValue": "[{'Key':'i:0#.f|membership|@{triggerBody()?['Author/Email']}'}]" }

],

"bNewDocumentUpdate": true

}

Using Azure App Registration for HTTP Requests

Since you already have an Azure App registered, you’ll need to authenticate your HTTP request using OAuth. Here’s how:

  1. Grant API Permissions
    • Ensure your app has SharePoint API permissions (Sites.Selected or Sites.FullControl).
    • You can configure this in Azure AD > App Registrations > API Permissions.
  2. Obtain an Access Token
    • Use the HTTP action in Power Automate to make a request to Azure AD for a token.
    • The request should be made to:https://login.microsoftonline.com/{tenant_id}/oauth2/token
    • The body should include:{ “grant_type”: “client_credentials”, “client_id”: “your-app-client-id”, “client_secret”: “your-app-client-secret”, “resource”: “https://graph.microsoft.com” }
    • This will return an access token that you can use in subsequent requests.
  3. Make the HTTP Request to SharePoint
  • Use the Send an HTTP Request to SharePoint action.
  • Include the Authorization header:Authorization: Bearer {access_token}
  • This ensures the request runs under the Azure App account instead of your personal account.
  • More details on OAuth authentication can be found here and here.

Personal Account Automation Send Email As

When using Power Automation to send email follow these steps.

Uri
POST 
https://login.microsoftonline.com/{TenantID}/oauth2/v2.0/token
 

{

"client_id": "YOUR_CLIENT_ID",

"client_secret": "YOUR_CLIENT_SECRET",

"grant_type": "client_credentials",

"scope": "https://graph.microsoft.com/.default"

}
HTTP Request to Outlook
Uri 

POST 

https://graph.microsoft.com/v1.0/users/@{triggerBody()?['Author/Email']}/sendMail

Headers
{
 "Authorization": "Bearer YOUR_ACCESS_TOKEN",
 "Content-Type": "application/json"
}

Body

{
 "message": {
   "subject": "Compliance Notification",
   "body": {
     "contentType": "HTML",
     "content": "Your compliance event has been logged successfully."
   },
   "toRecipients": [
     {
       "emailAddress": {
         "address": "recipient@example.com"
       }
     }
   ]
 }
}

Since Graph API requires an access token, set up a separate HTTP request to retrieve a token:

To pull the triggering user’s email, use:
@{triggerBody()?[‘Author/Email’]}

Alternatively consider sending emails from a shared mailbox:
POST https://graph.microsoft.com/v1.0/users/sharedmailbox@example.com/sendMail

The SharePoint Batch API is a powerful way to send multiple requests in a single call, making your Power Automate flows much faster and more efficient. Instead of updating items one by one, you can bundle multiple updates together, reducing execution time significantly.

How It Works

  • You send a single HTTP request to SharePoint with multiple operations inside it.
  • The request uses multipart/mixed formatting, meaning each operation is separated within the batch.
  • SharePoint processes all the updates at once, instead of handling them individually.

Example Batch Request

Here’s a basic structure of a batch request:

POST https://yoursharepointsite/_api/$batch 
Content-Type: multipart/mixed; boundary=batch_guid --batch_guid 
Content-Type: multipart/mixed; boundary=changeset_guid 

--changeset_guid 
Content-Type: application/http 
Content-Transfer-Encoding: binary 

POST https://yoursharepointsite/_api/web/lists/getbytitle('YourListName')/items(1) 
Content-Type: application/json;odata=verbose 

{
  "IsDeleted": false 
} 

--changeset_guid 
Content-Type: application/http 
Content-Transfer-Encoding: binary 

POST https://yoursharepointsite/_api/web/lists/getbytitle('YourListName')/items(2) 
Content-Type: application/json;odata=verbose 

{
  "IsDeleted": false 
} 

--changeset_guid-- 
--batch_guid--

This request updates two items in a single batch. You can add more items to the batch to process multiple updates at once.

Why Use Batch Processing?

✅ Faster Execution – Reduces the number of individual HTTP requests.
✅ Less API Overhead – SharePoint handles multiple updates in one go.
✅ Improved Performance – Especially useful for large lists with thousands of items.

Resources to Learn More

You can check out Microsoft’s official guide or this tutorial on writing batch API calls in Power Automate.

Would you like help setting up a batch request in your flow? 

Get Over 5000 Items From A SharePoint List In Power Automate

1. Why HTTP Requests Are Powerful Automations

✅ More Control – You can structure API calls exactly how you need them, unlike built-in actions.
✅ Batch Processing – Lets you update multiple records in one request, massively improving speed.
✅ Workarounds for Power Automate Limits – If a built-in action doesn’t support something (like updating Image columns), HTTP requests often do.
✅ Integration Beyond SharePoint – You can connect to APIs outside Microsoft, expanding what’s possible.

2. Key Components of a SharePoint HTTP Request

Every request follows this pattern:

Method: POST / GET / PATCH / DELETE
URL: _api/web/lists/getbytitle('YourListName')/items(ItemID)
Headers: Accept: application/json;odata=verbose
Body: JSON data containing the changes
  • Method: Defines the action (e.g., POST to create, PATCH to update).
  • URL: The SharePoint REST API endpoint you’re calling.
  • Headers: Ensures proper data formatting.
  • Body: The actual JSON payload containing updates.

3. Avoid Common Pitfalls

🚫 Forgetting Authentication – Some APIs require an authentication token.
🚫 Improper Data Types – Always make sure numbers, dates, and boolean values match SharePoint’s expected format.
🚫 Too Many Requests – If you’re looping through thousands of items, try batch updates instead of individual HTTP calls.
🚫 Incorrect Formatting – A missing {} or extra comma in JSON will break the request.

4. Debugging Tricks

🔎 Use “Compose” actions to preview API responses.
🔎 Check for errors in Power Automate’s “Flow Runs” history.
🔎 If something fails, test the request in Postman before embedding it in Power Automate.

Versioning and Approvals

Links

Restore a previous version of a SharePoint list item – OneDrive dev center | Microsoft Learn

🔧 1. Anomepani’s REST API Code Examples

This one’s a treasure trove of raw REST calls, including restoreVersion. It demonstrates how to structure headers, utilize digest tokens, and manage versioning with precision. Great for validating your syntax and comparing against working examples.

📘 2. Microsoft’s SP-Dev Docs: Working with Lists and Items

This is the canonical reference for SharePoint REST structure. While it doesn’t explicitly documents restoreVersion, it confirms the URI patterns you’re using and helps validate your approach to list item operations.

🧠 3. Zplume’s Gist: FlowNinja Wisdom

This one’s mythic—John Liu’s style of debugging and Flow resilience. It delves into retry logic, digests quirks, and explains how to handle versioning edge cases. If your flow is retrying or failing silently, this gist helps you build guardrails.

REST Endpoint Details

In SharePoint, each list item can have multiple versions if versioning is enabled on the list. You can restore a previous version using the REST API. Specifically, your query is about the endpoint:

POST /_api/web/lists/getbytitle('LocationsAll')/items(27)/versions(8)/restoreversion

Here’s what you need to know:

1. REST Endpoint Details

  • lists/getbytitle('LocationsAll'): Accesses the list named LocationsAll.
  • items(27): Refers to the list item with ID 27.
  • versions(8): Refers to version number 8 of the item.
  • restoreversion: Action to restore that specific version.

2. Making the POST Request

You can restore a version via a POST request, but you must include the proper headers:

POST /_api/web/lists/getbytitle('LocationsAll')/items(27)/versions(8)/restoreversion HTTP/1.1
Accept: "application/json;odata=verbose"
Content-Type: "application/json;odata=verbose"
X-RequestDigest: "{FormDigestValue}"
IF-MATCH: "*"
  • X-RequestDigest: Required for authentication in SharePoint online or on-premises forms.
  • IF-MATCH: "*" ensures that the version is restored regardless of the current list item ETag.

No request body is needed for this endpoint—the POST itself triggers the restore.

3. Example Using JavaScript (Fetch API)

// Fetch Form Digest Value from SharePoint
const formDigestValue = document.getElementById("__REQUESTDIGEST").value;

fetch("/_api/web/lists/getbytitle('LocationsAll')/items(27)/versions(8)/restoreversion", {
    method: "POST",
    headers: {
        "Accept": "application/json;odata=verbose",
        "Content-Type": "application/json;odata=verbose",
        "X-RequestDigest": formDigestValue,
        "IF-MATCH": "*"
    }
})
.then(response => {
    if(response.ok) return response.json();
    else throw new Error("Failed to restore version");
})
.then(data => console.log("Version restored successfully", data))
.catch(error => console.error(error));

4. Important Considerations

Restoring a version does not delete other versions; it creates a new version identical to the restored one.

Ensure versioning is enabled on the LocationsAll list; otherwise, versions will not exist.

Make sure the user has permissions to restore versions (generally, Contribute or higher).

X-RequestDigest

In SharePoint, the X-RequestDigest header is required for POST, PUT, DELETE, or any data-modifying REST API calls. This value, also known as the Form Digest Value, is used for anti-forgery and authentication purposes. Here’s how to find and use it:

1. From the Page DOM (Classic SharePoint Pages)

On most SharePoint pages, the form digest value is embedded as a hidden input field called __REQUESTDIGEST. You can access it directly if you are executing JavaScript on the page:

// Fetch the Form Digest Value from the current page
const formDigestValue = document.getElementById("__REQUESTDIGEST").value;

console.log("X-RequestDigest:", formDigestValue);
  • This works for scripts running inside SharePoint pages (like a Script Editor Web Part or SPFx web part).
  • Use formDigestValue as the value for your X-RequestDigest header when making a POST request.

2. Requesting the Form Digest via REST API

If you are working outside the page context or with external scripts, you can request the digest from SharePoint using the following endpoint:

POST /_api/contextinfo
Accept: "application/json;odata=verbose"

Example using Fetch API:

fetch("/_api/contextinfo", {
    method: "POST",
    headers: {
        "Accept": "application/json;odata=verbose"
    }
})
.then(response => response.json())
.then(data => {
    const formDigestValue = data.d.GetContextWebInformation.FormDigestValue;
    console.log("X-RequestDigest:", formDigestValue);
})
.catch(error => console.error(error));
  • /_api/contextinfo returns contextual information about the current site, including the FormDigestValue.
  • This digest is valid for 30 minutes by default.

3. Usage in REST API Call

Once you have the X-RequestDigest, include it in the headers of your POST request:

fetch("/_api/web/lists/getbytitle('LocationsAll')/items(27)/versions(8)/restoreversion", {
    method: "POST",
    headers: {
        "Accept": "application/json;odata=verbose",
        "Content-Type": "application/json;odata=verbose",
        "X-RequestDigest": formDigestValue,    // Use the value obtained above
        "IF-MATCH": "*"
    }
})
.then(response => response.json())
.then(data => console.log("Version restored", data))
.catch(error => console.error(error));

Summary

  • The X-RequestDigest is mandatory for operations that change data in SharePoint.
  • Obtaining the value can be done:
    • Directly from the page DOM using __REQUESTDIGEST.
    • Via /api/contextinfo POST request in scripts or external clients.
  • It expires roughly every 30 minutes, so it may need to be refreshed for long-running scripts.

This ensures your SharePoint REST API triggers, such as restoring a version, are correctly authenticated and secure.