RoboKind account structure & itinerancy example

In many school districts, there may be teachers who need to be able to teach robots4autism lessons using robots that may be at different school campuses.

Example:

  • School District Sample

    • Administrator (User Account)

    • Trainer (User Account)

    • Mobile Robot 1 (Robot)

    • Campus A (Organization)

      • Teacher 1

      • Teacher 2

      • Therapist (User Account)

      • Robot 2

    • Campus B (Organization)

      • Teacher 3

      • Teacher 4

      • Robot 3

Default Implementation:

  • Administrators or therapists who oversee or work with all of these campuses will be configured at the “School District Sample” level (Administrator 1, Trainer 2)

    • By Default, Administrator and Trainer users will be able to teach lessons on Mobile Robot 1 or using Avatar mode.

  • Teachers 1 & 2 & Therapist in Campus A will only be able to teach lessons on Robot 2.

  • Teachers 3 & 4 in Campus B will only be able to teach lessons on Robot 3.

With Itinerancy (hypothetical examples):

  • If the trainer user is expected to need to also teach lessons on both robot 2 in addition to robot 1, then robot 2 could be configured as “Standard + Itinerant” and the trainer user would also be set to Standard + Itinerant.

  • If the Therapist user occasionally visits and teachers lessons on Robot 3, then the therapist user and robot 3 would need to both be configured as Standard + Internet.

  • If teacher 2 moves to Campus B permanently, then their ability to teach lessons will automatically move from Robot 2 to Robot 3.

Additional considerations:

Related Documents:

RoboKind Central Organizational Structure Considerations & Itinerancy Support

RoboKind Central for Administrators and Managers

 

Related articles