Three sections on one page: users, roles and departments.
Inviting and creating are two routes
You can create the account yourself and set a password, or send an invitation so the person chooses their own. Either way, you set the role.
Someone invited but who has not yet accepted appears in the list but cannot sign in.
Deactivating replaces deleting
Deactivating a user stops them signing in while leaving their history — the documents they created, the tickets they answered — untouched.
If deletion is genuinely required (a personal-data erasure request, say), that is a separate action performed on that user's own page, and it cannot be undone.
A role with users cannot be deleted
Deleting a role that still has users attached is refused. Nothing is reassigned automatically, and nobody silently loses their access.
To remove a role, move its users to the right role yourself first. That way the decision about what each of them can do afterwards is yours rather than the system's.
System roles cannot be deleted even when empty.
The other route is to disable the role. Unlike deleting, that goes through — and it moves its users to the default role, so all of them lose their access at once. If that is not what you meant, reassign them yourself first.
The permission matrix edits the role, not the person
The permission table in the roles section acts on the role itself. Clearing a tick removes that permission from everyone holding it.
For an exception for one person, use that user's own per-user permissions — which only add, never subtract.
A department grants nothing
Departments organise people and are used in places such as ticket assignment. Belonging to one neither adds nor removes any permission; only the role does that.