Depending on what you mean by "can and cannot do". If you don't what people to make changes to records if they are not an "admin", start with you data source and control access here first. If you want a different "User Experience" like different buttons / screens etc., you can work with an extra table in your data source. Something like this:
Table: UserPermissions
| UserEmail | IsAdmin | IsManager | ShowDebug | ShowStatistics |
| user1@domain.com | true | true | true | true |
| user2@domain.com | true | false | true | true |
| user4@domain.com | false | true | false | false |
Now on the OnStart of your app you can do this to get the permissions for that user:
If(
Not(
IsBlank(
LookUp(
UserPermissions,
UserEmail = User().Email
)
)
),
// A record found is either Admin or Manager or both.
Set(
varUserPermission,
{
IsAdminVal: IsAdmin,
IsManagerVal: IsManager,
ShowDebugVal: ShowDebug,
ShowStatisticsVal: ShowStatistics
}
),
// For non Admins or Managers
Set(
varUserPermission,
{
IsAdminVal: false,
IsManagerVal: false,
ShowDebugVal: false,
ShowStatisticsVal: false
}
)
For example if you have a container with labels somewhere on a screen with debug info, you could do this in the Visible property:
varUserPermission.ShowDebug
Now the debug info will only show if the user has permissions to see it. Same thing for a button that can redirect the user to a screen with statistics.
In this case there is no need for a password. If you don't want users to access your app in the first place. The best this is not sharing it with those users I guess.
This is just an basic example. It also al depend on what you really want to achieve and what your own permissions are at your environment.
The above is not tested and might not be the best solution. But just giving some examples that might get you a bit further. You can also have a look at Shane's video: https://www.youtube.com/watch?v=NqQGysNCac0
