“User should update one SharePoint column, but I don’t want to give him edit permissions on the whole item, how to bypass that in PowerApps?”
When you build any solution, not only using Power Platform, you must consider permissions. Who can view / edit the data at which phase of the process? For example, when you build an approval process, the request should be locked – nobody can edit it once submitted. Yet sometimes you need more than just approve/reject response from the approvers, sometimes they need to add something to the request. To a request with a read only permissions… And you surely want to give them permissions to edit everything because of a single column.
While such solution can work if you disable the controls in PowerApps, they can still go to the SharePoint list and edit everything. No, you want to keep the read permissions, and bypass them only for that update.
Use Power Automate flow for the update
That’s a situation where you can benefit from the integration between PowerApps and Power Automate. While PowerApps use always the connections of the user, Power Automate can use a fixed connection, e.g. of some service account. Instead of using Patch(…) or SubmitForm(…) to save the changes, you can call a Power Automate flow.
Create a new flow with the PowerApps (V2) trigger and define all the inputs you want to update.
Follow with the ‘Update item’ action to use the inputs for the update…
…and respond back to PowerApps once finished.
Save the flow and go to the flow overview page.
Set it to use the service account
Now comes the most important part – telling the flow to use the service account instead of the user’s. Go to the ‘Run only users’ section and click ‘Edit’.
Open the dropdown in the ‘Connections Used’ section and replace the ‘Provided by run-only user’ selection with the specific account.
Save it. From now on the flow will always do the update under this specific account. It doesn’t matter whether the user running the PowerApp has permissions, the flow will always update it using the selected account.
Run the flow from the PowerApp
Now, with the flow properly configured, you can go to the PowerApp and connect it, e.g. to a button. Once a button is pressed (OnSelect) it’ll run the flow, pass the 5 parameters, and the flow will do the rest.
Summary
When working on a solution, permissions are always an important part. It’s something that should be considered on all levels, not only in the PowerApp, but also on the background data. If you block editing in PowerApp, but still let users edit it via SharePoint, it’s not a secure solution.
That’s why you should keep the access as strict as possible. Keep edit only if users should be able to edit everything, and read if not. And if there’s still a need for update, you can bypass the user permissions by combining the PowerApps with a flow.