User Roles & Permissions
KC7 implements a role-based access control (RBAC) system with three primary roles, each with specific permissions and access levels.
Role Overview
Tenant Manager
Entire tenant
Full administrative access
Classroom Manager
Assigned classroom(s)
Classroom-level management
Student/Participant
Enrolled games
Game participation only
Tenant Manager Role
Permissions
Full Administrative Access:
Create, modify, and delete classrooms
Access all classrooms across tenant
Manage all users and roles
Assign Classroom Managers
View all analytics and data
Configure tenant-wide settings
Export data from any classroom or game
Manage billing and subscription (if applicable)
Tenant-Level Settings:
Branding and customization
Integration configuration
Security policies
Default classroom settings
Organizational metadata
Use Cases
Who should be Tenant Manager:
Primary organizational administrator
IT staff managing the platform
Program directors overseeing all activities
Senior instructors with full oversight
Anyone requiring complete access
When to assign:
Initial tenant setup (you're automatically Tenant Manager)
Adding co-administrators
Delegating full management responsibility
Disaster recovery contacts
Limitations
No technical limitations on access
Organizational policy may restrict usage
Recommended to limit to 2-5 trusted administrators
All actions are logged for audit purposes
Classroom Manager Role
Permissions
Classroom-Specific Access:
Manage assigned classroom(s) only
Create and configure games within classroom
Manage students enrolled in classroom
View classroom analytics
Export classroom data
Modify classroom settings
Generate classroom reports
Cannot Access:
Other classrooms in tenant
Tenant-wide settings
Other users' data outside assigned classrooms
Billing or subscription management
Cross-classroom analytics
Assignment
How to assign Classroom Manager:
Navigate to tenant Users tab or classroom Users tab
Select user (must already be in tenant)
Assign Classroom Manager role
Specify which classroom(s) they manage
Confirm assignment
Multiple Classroom Assignment:
Single user can manage multiple classrooms
Permissions are additive (access to all assigned classrooms)
Useful for instructors teaching multiple sections
Use Cases
Who should be Classroom Manager:
Instructors for specific courses
Department leads managing their team's training
Event coordinators for specific programs
Teaching assistants with delegated responsibility
Program managers for designated cohorts
When to assign:
Delegating classroom management
Distributing workload across team
Empowering instructors independently
Scaling program management
Limitations
Access Restrictions:
Cannot create new classrooms (Tenant Manager required)
Cannot access classrooms they're not assigned to
Cannot modify other users' roles
Cannot change tenant-wide settings
Best Practices:
Assign to specific classroom(s) based on responsibility
Review assignments each term/period
Remove access when responsibilities change
Document who manages which classrooms
Student/Participant Role
Permissions
Game Participation:
Access enrolled games
View personal progress and results
Submit answers and complete modules
View personal dashboard
Earn badges and achievements
Cannot Access:
Game management settings
Other participants' detailed data
Classroom management features
Analytics beyond personal performance
Administrative functions
Assignment
Automatic Assignment:
Default role when user joins classroom
No manual role assignment needed
Automatic when:
Using classroom join link
Manually added by manager
Auto-assigned via game settings
Use Cases
Who receives Student/Participant role:
Event participants
Course students
Training program attendees
Competition players
Anyone playing KC7 games
Data Access
What participants can see:
Own progress and scores
Own answer history
Personal completion status
Own badge achievements
Leaderboard (if enabled and they're included)
What participants cannot see:
Other participants' detailed answers
Classroom management data
Aggregate analytics
Manager communications
Administrative settings
Permission Matrix
Classroom Operations
Create classroom
✅
❌
❌
View classroom
✅ (all)
✅ (assigned)
❌
Edit classroom settings
✅ (all)
✅ (assigned)
❌
Delete classroom
✅
❌
❌
Customize appearance
✅ (all)
✅ (assigned)
❌
Game Operations
Create game
✅
✅ (in assigned classroom)
❌
Configure game settings
✅
✅ (in assigned classroom)
❌
Delete game
✅
✅ (in assigned classroom)
❌
Play game
✅
✅
✅ (if enrolled)
View game link
✅
✅ (in assigned classroom)
✅ (if enrolled)
User Management
Add participants
✅
✅ (to assigned classroom)
❌
Remove participants
✅
✅ (from assigned classroom)
❌
Assign Tenant Manager
✅
❌
❌
Assign Classroom Manager
✅
❌
❌
View user list
✅ (all)
✅ (assigned classroom)
❌
Analytics & Data
View classroom analytics
✅ (all)
✅ (assigned)
❌
View game analytics
✅ (all)
✅ (assigned)
❌
View individual progress
✅ (all)
✅ (assigned classroom)
✅ (own only)
Export data
✅ (all)
✅ (assigned classroom)
❌
Generate reports
✅ (all)
✅ (assigned classroom)
❌
Tenant Settings
Modify tenant settings
✅
❌
❌
Configure integrations
✅
❌
❌
Manage billing
✅
❌
❌
View audit logs
✅
❌
❌
Configure SSO
✅
❌
❌
Role Assignment Best Practices
Principle of Least Privilege
The principle of least privilege is a fundamental security concept stating that users should have only the minimum permissions required to fulfill their legitimate responsibilities, and no more. Applying this principle to KC7 role assignments reduces security risks, limits potential for accidental damage, and maintains clear accountability boundaries.
Start every role assignment decision from the Student role baseline. When someone needs access to KC7, the default assumption should be Student/Participant status. Only deviate from this baseline when you can articulate a specific, legitimate need for elevated permissions. This default-restrictive approach prevents permission creep where users accumulate unnecessary access over time.
Assign Classroom Manager role only to individuals who will actively manage classrooms - creating games, managing enrollments, reviewing analytics, or performing other administrative functions. Simply being an instructor or facilitator doesn't automatically warrant Classroom Manager status if their role is purely to guide participants through pre-configured content someone else created. The key question is: "Will this person need to modify classroom configuration or manage participants?" If the answer is no, Student role with enrollment in the relevant games is probably sufficient.
Reserve Tenant Manager role exclusively for full platform administrators who need unrestricted access across the entire organizational tenant. This might include IT staff responsible for the platform, senior program directors overseeing all activities, or individuals handling billing and organizational account management. Tenant Manager access is powerful - these users can delete classrooms, modify all permissions, access all data across every classroom - and this power should be carefully controlled. Most organizations should have 2-5 Tenant Managers at most, even if they have dozens of Classroom Managers.
The least privilege principle isn't just about security - it also reduces cognitive load and user error. When users have only the permissions they actually need, their interfaces are simpler, they're less likely to accidentally modify settings they shouldn't touch, and they can focus on their actual responsibilities without distraction from features they don't use.
Regular Audits
Role assignments that made sense when initially granted often become inappropriate over time as organizational responsibilities change, employees move to different positions, or programs wind down. Regular audits identify and correct these permission mismatches before they create security vulnerabilities or compliance issues.
In educational contexts, align audit frequency with your academic calendar. Review all role assignments at the end of each term or quarter, removing access for instructors who are no longer teaching, graduating teaching assistants who served as Classroom Managers, or updating permissions for instructors moving to different courses. This term-boundary audit ensures each new academic period starts with accurate permissions reflecting current responsibilities.
Staff changes trigger immediate audit requirements regardless of your regular schedule. When someone leaves your organization, terminates employment, or moves to a different role, their KC7 permissions should be reviewed within days, not waiting for the next scheduled audit. This prevents former employees from retaining access, ensures departing staff don't take sensitive data with them, and maintains clear accountability for who manages what.
Major organizational changes - restructuring, mergers, program discontinuations, or strategic shifts - warrant comprehensive audit cycles. These events often redistribute responsibilities across many people, making wholesale permission reviews necessary to realign access with new organizational realities. A restructuring that consolidates three departments into one might mean numerous Classroom Managers no longer need their access, or conversely, new managers might need permissions they previously lacked.
Corporate and enterprise environments should conduct formal annual audits at minimum, even if no known changes have occurred. Annual reviews catch permission drift that accumulates from small undocumented changes, verify that role documentation remains accurate, and demonstrate compliance diligence to auditors or regulators. Many organizations combine annual audits with fiscal year planning cycles, using the same period for budget planning and access control review.
Documentation
Undocumented role assignments create institutional knowledge gaps that cause problems when staff turn over or audits occur. Comprehensive role documentation answers critical questions about access control: why does this person have these permissions, who approved it, when should it be reviewed, and what business justification supports it.
Record who has what role at a granular level. Don't just document "John Smith is a Classroom Manager" - document which specific classrooms he manages, which other administrators also have access to those classrooms, and whether his access spans multiple organizational units. This granularity matters when you need to understand the full scope of someone's access or find all people who can manage a particular classroom.
Document why each role was assigned, capturing the business justification at the time of assignment. "Teaching assistant for CSCI 301 Spring 2024" provides much more context than just noting someone has Classroom Manager access. This justification documentation helps future administrators understand whether access should continue, helps during audits to demonstrate appropriate access control, and prevents the common problem of finding old permissions no one remembers the reason for.
Timestamp when each assignment occurred. Assignment dates help you identify stale permissions (someone assigned Classroom Manager three years ago but the class they managed has been discontinued), support audit trails showing access control history, and enable time-based rules like "review all assignments older than one year annually."
Include review dates in your documentation. When you assign a role, document when it should next be reviewed - perhaps at the end of the current academic term, when the project completes, or one year from assignment. These review dates prevent perpetual access that persists long after the legitimate need ends. Automated systems can then remind you when reviews are due rather than relying on memory.
Onboarding/Offboarding
Onboarding:
Effective onboarding establishes appropriate access from the beginning rather than requiring corrections later. A systematic onboarding process ensures new users get exactly the permissions they need without delays or security gaps.
Create user account: The first step is establishing the user's identity in KC7. Depending on your configuration, this might happen automatically through single sign-on integration with your institutional systems, through self-registration where the user creates their own account, or through administrative account creation where you create accounts on behalf of users. Verify the account uses a correct email address that the user actually monitors, as many system communications depend on email delivery.
Assign appropriate initial role: Most new users should start with Student/Participant role as their initial assignment. This follows the least privilege principle - start restrictive and elevate permissions only when specific needs emerge. Even users who will eventually need Classroom Manager or Tenant Manager access often benefit from starting as Students to learn the platform from a participant perspective before taking on administrative responsibilities. However, if you're onboarding someone directly into an administrative position, assign their management role during initial setup rather than creating a permission gap that leaves them unable to perform their job.
Add to relevant classrooms: Classroom membership determines what content users can access. During onboarding, enroll new users in classrooms they should immediately have access to. For participants, this means the courses or training programs they're attending. For instructors or managers, this means the classrooms they'll manage. Be specific and intentional about classroom assignments - adding someone to wrong classrooms creates confusion and potential privacy or data access issues.
Communicate access instructions: Even after all technical setup is complete, users need information to successfully access the platform. Send clear, specific instructions including: how to log in (URL and credentials), where to find their assigned games or classrooms, what they should do first, who to contact for help, and any deadlines or expectations. Many onboarding failures occur not because of permission problems but because users don't know how to use the access they have.
Offboarding:
Offboarding removes access for users who no longer need it due to program completion, employment termination, role changes, or other transitions. Thorough offboarding prevents security risks from orphaned accounts and maintains clean, accurate user lists.
Review all assigned roles: Before removing anything, understand the full scope of what the departing user can access. Check all role assignments across your tenant - they might be a Student in some classrooms, a Classroom Manager in others, and you need a complete picture before making changes. This review prevents partial offboarding where you remove some access but miss other permissions, leaving security gaps.
Remove from active classrooms: For users who no longer need access to ongoing content, remove their classroom memberships. This is particularly important for sensitive or confidential classrooms where you need tight control over who can access materials. However, consider whether the user needs continued access for reference or record-keeping purposes. A graduating student might legitimately need to review completed coursework for portfolio purposes, in which case you might leave them enrolled in archived classrooms while removing them from active ones.
Revoke manager permissions if applicable: Users with Classroom Manager or Tenant Manager roles require explicit permission revocation beyond just classroom removal. Change their role to Student or fully remove their access depending on whether they need any continued system access. Manager permission revocation is critical - even if you remove someone from all classrooms, residual manager permissions can sometimes allow unintended access to tenant-level features or data.
Preserve data for records: Before completing offboarding, ensure you've exported or preserved any data associated with the user that you're legally or operationally required to retain. This might include performance records, completion certificates, submitted work, or analytics data. Once you fully offboard a user, recovering their historical data can be difficult or impossible depending on your configuration. Export requirements vary by jurisdiction and organizational policy, but it's better to over-preserve during offboarding than discover later you deleted data you needed.
Optionally deactivate account: The final decision is whether to fully deactivate the user's account (preventing all login) or simply remove their classroom and role assignments while leaving the account active. Account deactivation makes sense for terminated employees, graduates who won't return, or other permanent separations. Leaving accounts active but depermissioned makes sense for temporary absences, users who might return, or situations where users need to maintain login access for non-KC7-specific reasons related to your organizational SSO setup. Consider your organization's account lifecycle policies and legal retention requirements when making this decision.
Changing User Roles
Promoting Users
Student → Classroom Manager:
Navigate to Users tab
Select student user
Change role to Classroom Manager
Assign specific classroom(s)
Notify user of new permissions
Classroom Manager → Tenant Manager:
Navigate to tenant-level Users tab
Select classroom manager
Change role to Tenant Manager
Confirm promotion
Document change for records
Demoting Users
Process:
Access user management
Select user
Change to lower role
Remove from unnecessary classrooms
Communicate change to user
Data preservation:
User's historical data preserved
Analytics remain accessible
Previous contributions retained
Special Scenarios
Guest Instructors
Temporary Classroom Managers:
Assign for specific term
Set calendar reminder to review
Remove access at end of engagement
Preserve classroom data
Teaching Assistants
Limited Classroom Manager privileges:
Can manage students
Can view analytics
May have restricted game management
External Evaluators
Read-only Classroom Manager variant:
View-only access to analytics
Cannot modify settings
Cannot manage participants
Export capabilities only
Note: Contact support if you need custom role configurations
Troubleshooting
User Can't Access Expected Features
Verify:
User's current role assignment
Classroom assignment if Classroom Manager
Role change has propagated (may take minutes)
User logged out and back in after role change
User Has Too Much Access
Solutions:
Review and adjust role
Verify no accidental Tenant Manager assignment
Check classroom assignments
Audit recent role changes
Role Changes Not Taking Effect
Common causes:
Browser caching old permissions
User hasn't logged out/in since change
Database propagation delay
Solutions:
Have user log out and log back in
Clear browser cache
Wait 5-10 minutes for propagation
Contact support if persists
Related Documentation
Managing Users - Adding and organizing users
Adding Co-Hosts - Inviting additional managers
Organizing Classrooms - Classroom structure and management
Managing Games - Game permissions and access
Last updated