Architectural Decision: Should Every Role Have Its Own Schema?

Context:

I'm working on a School ERP web application built using the MERN stack.
We have a "users" schema that acts as a base model for various roles like:

• Teachers
• Students
• Parents

Each of these role-specific users has its own schema containing relevant information, built on top of the base "users" schema, ensuring separation of concerns.

For example, the school owner is also a User, but they don’t require any additional information. In this case, the School schema simply contains a reference to the User who owns it.

My Dilemma:

Now, I’ve been asked to implement a new role: "Sub-Admins".

Here’s the catch:

• Sub-admins don’t need any additional fields.
• They can be documented using the existing "users" schema.
• The only thing that distinguishes them is a field that references the school(s) they are associated with.
• Each school can have multiple sub-admins.

My Questions :

So now I’m trying to decide:

1. Should I create a separate schema for sub-admins, just like I’ve done for teachers, students, and parents? Keeps the structure consistent -- Adds unnecessary complexity
2. Should I simply add a new reference field (e.g., subAdminSchool) directly to the "users" schema? Simple and direct -- Might introduce confusion, since other roles don’t store extra fields inside users

I've confirmed that the sub-admin role is unlikely to need additional fields in the near future.

Any advice, insights, or experiences would be highly appreciated. The coffee cups are piling up folks!! Thank you!!