User roles and permissions in No-Code - Step-by-Step Execution

Concept Flow - User roles and permissions

Start

↓

Define Roles

↓

Assign Permissions to Roles

↓

Assign Roles to Users

↓

User Tries Action

↓

Check User's Role Permissions

Yes No↓

Allow

↓

Action

This flow shows how roles are defined with permissions, assigned to users, and then checked when a user tries to perform an action.

Execution Sample

No-Code

Roles = {"Admin": ["edit", "delete"], "Viewer": ["view"]}
Users = {"Alice": "Admin", "Bob": "Viewer"}
UserAction = "delete"
User = "Bob"
# Check if Bob's role allows 'delete'

This example checks if user Bob, who is a Viewer, can perform the 'delete' action.

Analysis Table

Step	User	User Role	Action Tried	Permission Check	Result
1	Bob	Viewer	delete	Is 'delete' in Viewer permissions? No	Deny action
2	Alice	Admin	delete	Is 'delete' in Admin permissions? Yes	Allow action
3	Bob	Viewer	view	Is 'view' in Viewer permissions? Yes	Allow action
4	Alice	Admin	edit	Is 'edit' in Admin permissions? Yes	Allow action
5	Bob	Viewer	edit	Is 'edit' in Viewer permissions? No	Deny action
6	End	-	-	-	No more actions to check

💡 All user actions checked against their role permissions; process ends.

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
User	-	Bob	Alice	Bob	Alice	Bob	-
User Role	-	Viewer	Admin	Viewer	Admin	Viewer	-
Action Tried	-	delete	delete	view	edit	edit	-
Permission Check	-	No	Yes	Yes	Yes	No	-
Result	-	Deny	Allow	Allow	Allow	Deny	-

Key Insights - 3 Insights

Why can't Bob perform the 'delete' action even though he is a user?

Because Bob's role is 'Viewer', which does not include the 'delete' permission as shown in execution_table step 1.

How does the system decide if an action is allowed or denied?

It checks if the action is listed in the permissions of the user's assigned role, as seen in the Permission Check column of the execution_table.

Can a user have multiple roles at the same time in this example?

No, each user has only one role assigned, simplifying permission checks as shown in the variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result when Bob tries the 'view' action at step 3?

A Deny action

B No action

C Allow action

D Error

💡 Hint

Check the 'Result' column at step 3 in the execution_table.

At which step does the permission check confirm that 'edit' is allowed for Alice?

A Step 4

B Step 5

C Step 2

D Step 1

💡 Hint

Look at the 'User' and 'Action Tried' columns to find when Alice tries 'edit'.

If Bob was assigned the 'Admin' role, what would be the result when he tries 'delete' at step 1?

A Deny action

B Allow action

C No action

D Error

💡 Hint

Refer to the permissions of 'Admin' role in the execution_sample and execution_table.

Concept Snapshot

User roles group permissions.
Permissions define allowed actions.
Users get assigned roles.
When a user acts, system checks role permissions.
If allowed, action proceeds; else denied.

Full Transcript

User roles and permissions work by grouping allowed actions into roles. Each user is assigned a role. When a user tries to do something, the system checks if that action is allowed by the user's role. If yes, the action is allowed; if not, it is denied. For example, a Viewer role may only have permission to view, while an Admin role can edit or delete. This system helps control who can do what in an application.