How to allow users to use an app without giving them permission to edit the data source?

[Miho3]

Hi, people. I am trying to create a basic registration campus app.
If I create a registration (application) campus app in Power Apps and the data source is a List of SharePoint, it is necessary to grant editing rights on the List side to the registrant (applicant) who uses the app.

Even if the location of the data source is not visible from the app side, if the registrant (applicant) finds out the location (URL) of the List, he/she can directly edit (tamper) with the data.

Could you give me a solution to make it impossible to tamper?

[SudeepGhatakNZ]

If you build a PowerApp using the "Customise in PowerApps" option, it will force the users to use the PowerApp form whenever they open a record to modify it.

Do you have a standalone PowerApp in your case?

[Miho3]

Thanks for your reply. 

We are using Power Apps with Microsoft365 E3 license. Power Apps with Microsoft365 E3 may not be a standalone Power Apps...but is it available?

Using the "Customize in PowerApps" option means using Dataverse?

Sorry, I am a beginner. Could you give me more about how to use the "Customize in PowerApps" option?

[SudeepGhatakNZ]

You will find an option to customize the SharePoint list form in PowerApps using this option. Sorry it is called Customise Forms

[Miho3]

Oh, I have used this "Customize Form" button before.
We can easily create an apps from a List if we use it.

With that, can we let the users to use the app without user's edit permission on the List side?
I didn't know that. Thank you, anyway I will try it once.

[SudeepGhatakNZ]

Users will need access to the list in order to read and write anyway. 

What you can do is force them to use the PowerApps form instead of the default SP list form.

This way you can hide the fields you do not want your users to update (by excluding them from Powerapps form)

You will also need to turn off the Quick edit mode in the list.

Again, I think the goal here is to prevent the end users from making updates inadvertently.

Developers can still update SharePoint list items using the REST API. You can't prevent that.

[Miho3]

Thank you, @SudeepGhatakNZ 
To prevent the end users from making updates inadvertently, yes, that is what I want to know.
Moreover, I want to know how to prevent the end users from making updates intentionally.

We can't use PowerApps as an application system in our company unless we can guarantee the non-tampering of the data source. So, I had to verify this.

However, from what you are saying, the end user who use the app needs to be given the right to edit the data source(list), right?

[SudeepGhatakNZ · Accepted solution]

@Miho3 , yes that is correct.

Power apps is the front end, SharePoint is backend.

Users will need access to backend in order to read/write data.

The good thing is that SharePoint allows versioning, so there will be a trail of who updated what, when etc. Data can also be restored back (to an extent)

[Miho3]

@SudeepGhatakNZ , Thank you so much, I completely understand.

Before I asked the question here, I was wondering if what you told me was true.

The end users actually have read/write rights on SharePoint.
However, do we consider SharePoint is on the back end, so not within the reach of the end user?
That would be the point of controversy as to whether or not we would use PowerApps as our application system.

I think PowerApps is a useful tool, and I would like to learn more about it so that we can make better use of it in our company.　Thank you so much for your all responses.

[SudeepGhatakNZ]

Hi there,

SharePoint is a solution platform in itself and is suitable for simple use cases.

Behind SharePoint is a relational database, so it is not a backend in the true sense.

However, when you build an application using the Power platform, you are simply using SharePoint as a data store.

It is a backend system in that sense. If you want a more traditional backend (that cannot be tampered with), you should consider Dataverse. But again, that has its own licensing requirements.

I suggest that you involve a solution architect to go through the pros and cons of the two approaches because there could be other aspects that we haven't considered.