Staff access and identity

Staff access in Skolar combines two things: the employee record and the user account that operates inside the tenant. A person can exist as an employee without necessarily having system access.

What this flow covers#

• granting access for the first time
• assigning one or more roles
• editing the email or roles of an existing account
• resetting passwords
• revoking access without deleting the employee
• impersonating a teacher or staff member for troubleshooting

Before granting access#

Check:

• that the employee record already exists and has the correct name
• whether the school uses an institutional email domain
• which role the person actually needs
• whether the email already belongs to a Skolar user in another school or tenant

How access is created#

When you grant access, Skolar:

1. validates whether you can assign the selected roles
2. builds the email using the tenant domain when applicable
3. checks whether that user already exists in Skolar
4. creates the account only if it does not exist yet
5. attaches roles to the current tenant and the correct employee
6. sends the access email or onboarding instructions based on role

If the user already existed in another school, Skolar reuses the account and does not send a new temporary password.

Editing roles and email#

When you edit access, the system replaces the role relationship for the current tenant and updates the email tied to the employee.

This matters because:

• access can change without editing the employee profile itself
• the wrong role mix can expose broader permissions than intended
• changing an owner can move ownership away from the previous user and downgrade them

Password reset#

Resetting the password creates a new temporary password and emails it to the user. Use it when:

• the person lost access
• the account is being recovered after inactivity
• there was an email or security change

If the real issue is an incorrect role, resetting the password will not fix it.

Revoking access or disabling staff#

Revoking access removes the ability to log in to the current tenant, but it does not necessarily erase the employee history.

Disabling an employee usually:

• revokes tenant access if it exists
• keeps operational history
• may be blocked if the teacher still has active courses

Impersonation#

Identity switching lets an admin temporarily sign in as the teacher to verify what they can actually see on their dashboard or inside their courses.

Use it only to:

• validate permissions or visible menus
• reproduce access problems
• confirm whether the issue is course setup or role configuration

It will not help if the employee still has no linked Skolar account.

Good practices#

• assign the minimum role set required
• do not share one account across multiple people
• document sensitive role changes in internal processes or comments
• check active courses before disabling a teacher
• use impersonation only for targeted troubleshooting

Common issues#

The employee exists but access cannot be created#

Check whether the email already belongs to an existing Skolar user or whether your own user is not allowed to assign the requested role.

The user can log in but cannot see the expected features#

Review the exact combination of tenant roles, not just whether the account exists.

The teacher cannot be disabled#

The usual cause is that they are still linked to active courses in the current school year.