User Views dependent upon Role

[phamalda]

Good day, BudiMates. Just wanted to run one more thing by you guys. I have a few tab options in our UI that are available to all users. However, we only need a couple of users that have the ability to edit the contents. I am looking to assign these accounts to the 'Editing User Role.' All other users should simply be able to view the underlying data. These would be under the 'App Viewer Role.'

All users currently go to the same screen and are able to modify these contents. For instance, the image below is under the Opportunities tab.

I have also set up a couple of Views from the primary table. One View is configured with Access: App Viewer Role. All of the columns are configured as Read-only

The other view has Access: Editing User Role. All of these columns are configured as Writable.

I have been reading through the Risk Management guidelines as well as those for Expense Approval. I am hoping to find a way to have those App Viewers Roles to see one view when they click Opportunities and the Editing User Roles see the view with which the data can be edited.

I'm sure that there's a way to do this in the Navigation for this screen using Handlebars...

I am still doing some digging on how to make this happen, but if anyone has any advice, I'd really appreciate the help. Thanks a ton.

[ConorWebb96]

Hey @phamalda,

There are a couple of ways to approach this.

Option 1: Duplicate tables with conditions

The most straightforward approach is duplicating the table and applying conditions to the component.

When a user with the Editing User role visits, they’ll see the table linked to their view, which lets them edit the data.

For users with the App Viewer role, you can apply conditions so that only the read-only version of the table shows.

The editing restrictions are still respected since the views handle permissions. Performance isn’t affected because the hidden table won’t render or make server calls.

Option 2: Navigate based on role.

Another approach is to use a navigation action. Here, you map role IDs (long and hard to manage) to friendly names. Then you navigate based on the user’s role. Below is some JS I've used to achieve this.

const roleMap = {
  [ $("Role.App Viewer Role") ]: "app-viewer",
  [ $("Role.Editing User Role") ]: "app-editor"
};

function getRoleName(id) {
  return roleMap[id] || "Unknown role";
}

return `employees/${getRoleName($("Current User.roleId"))}`

This example uses the employees table, but you can adjust it for your case. I've attached the app export here.

You can use preview to test and see the functionality in action.

I hope this helps and answers your question.

[phamalda]

Thank you so much for the quick response on this, @ConorWebb96. I really think that first option is going to get us where we need to be. I am still working on that. It takes us a bit to test everything. We are using SSO for all accounts, so I have to do some testing. Thanks again. I'll keep you guys posted. 👍

[phamalda]

Thank again for the quick response, @ConorWebb96. I am working on these Roles, permissions, etc. hopefully geared toward option 1 that you've mentioned above.

In the case of the Opportunities table, I have created a view with the same name. In the Columns section, I have set all attributes to Read-only.

I have assigned Access: App Viewer Role for this view. This is the first custom Role from the first image above. I have one use assigned that access. However, when that user logs in, he is still able to edit the values in that part of the UI. I am trying to determine if he is still getting the App User permissions or what I might have done wrong. Any ideas would be greatly appreciated.