Creating flows that run for other users when an item is created/modified should never really run with the credentials of the workflow developwer. You also should not own that flow. When you leave the organisation and your account gets removed and unlicensed, all these flows will break.
The recommended practice is to use a service account specifically for owning and running workflows. You can develop and test the flow with your credentials, but then it should be published by your IT department, using the service account credentials (which only IT should know). That account will never be removed from AD, so the workflows will stay alive when you leave, and IT has an overview of all workflows that do automation.
With that approach, it is also a lot easier to justify that the list item has an entry in its version history under the service account. This edit is done by the automated process, so it is a valid edit that needs to be in the audit trail.
- have your IT department set up a service account like PowerAutomate@yourcompany.com
- that account needs a license for Power Automate and SharePoint. Typically, the same license that you have in O365.
- ensure that the service account has sufficient permissions to read and edit the SharePoint sites/lists it needs to work with
- export the workflow and send the exported ZIP to your IT folks
- Using the service account credentials, IT imports the workflow, changes the connections from your account to the workflow account.
- Using the service account credentials, IT shares the workflow with you, so you can make edits without going through the export/import process each time.
The initial setup is a bit more work, but this approach is robust, sustainable, and provides the audit trail required.