If your component for users allows us to write an optional query that joins the user table and any other tables we need, we can fill the component with only the users we want displayed in it. In other words, if we have two areas, and the admin-type user is in Area A, we would want the component to only show users from Area A. If we build an Area table and a User-Area-Mapping table, we could easily select users in Area A to fill the component when the Area A admin is logged in.
But that would require that when the submit is done in your user component, it would also need to fire off an event with which we could do anything else needed for that new or modified or deleted user via a script. In this case, we would add or modify or delete the User-Area-Mapping table entry for that user.
The same goes with the roles, schedules and rosters. Each area would need their own roles, schedules and rosters that only they can add, modify, or delete. Again, if you allow joining other tables with your ‘internal’ tables to fill the component, and fire an event on submit, we can maintain Role-Area-Mapping, Schedule-Area-Mapping and Roster-Area-Mapping tables to handle the added complexity. If the component didn’t use a custom query to fill it, then it could show all users, roles, schedules, or rosters through a default query, as you have planned.
With these two capabilities, we could have as many levels of grouping as needed, with management at any or all levels of the hierarchy. You wouldn’t have to worry about anything over the user level. This would open Ignition up to handle as complex a scenario as needed, or just keep it simple, if complexity is not needed.