This Functionality Requires the Application to Have Insights
Insights is a product suite by ArborXR, and managing the Headset Login Policy is one of its features. For Insights features to work for your ArborXR organization, the applications you use must have Insights installed into them by the content developer. Click here to learn more about Insights.
How Headset Login Policies Support Authentication of Users
If you navigate within Insights to 'Data Policies', you'll find the options for configuring your headset login policy.
Currently, this is a global setting that all insights-supported applications will enforce when a headset is launched. Once you select one of these, every time an Insights application is launched on one of the headsets in your organization, the user will be prompted to input. Once they do, all data recorded for that session will be attributed to that users respective input.
There are 4 options to choose from, which we'll go over in detail below.
LMS Integrations
If you've created an LMS connection already, then you'll be able to select it when choosing LMS Integrations.
Once selected, when a user opens an insights-supported application, they'll see an input prompt for a PIN or QR Code. This is generated via the LMS:
This is an example from a popular supported LMS, Moodle, of what the learner might see before putting on the headset.
Once they enter the PIN, or on supported headsets, scan the QR code, the user will begin their experience. After the experience is complete, all data from it will be tied to that specific user.
Email Domain
For the Email Domain option, you will input the expected email domain that all users will have, and confirm.
Once confirmed, when a user opens an insights-supported application, they'll see an input prompt for their email, with the domain prefilled for ease-of-use.
Once they enter the email, the user will begin their experience. After the experience is complete, all data from it will be tied to that specific user.
This is a form of trust-based authentication, meaning that we cannot vet that they entered a correct or valid email. The data will be tied to whatever they inputted for that particular experience.
Name/ID/Custom
Finally, we provide a fully customizable input you can request as the user's identifier. This could be anything from a Learner ID, Student Number, First Name, etc.
Once confirmed, when a user opens an insights-supported application, they'll see an input prompt for whatever you enter here.
So for example, if I have 8 learners, and I assign each of them a 4-digit number that I tell them they must input, and call it their Learner ID, I would set this field to Learner ID.
Then, once they enter the number in the headset, the user will begin their experience. After the experience is complete, all data from it will be tied to that specific input.
This is a form of trust-based authentication, meaning that we cannot vet that they entered a correct or valid input. The data will be tied to whatever they inputted for that particular experience.