The steps below need to be completed by the Google Workspace or Microsoft Azure Global Administrator.
Step 1 Confirm students use the school SSO system
You first need to confirm students use the same Single Sign-On (SSO) system as school staff. This is essential to providing student access.
Step 2 Add a Teacher role to the EdPotential application
If you do not have Teacher as a role in your EdPotential application in your Google Workspace or Microsoft Entra ID you will need to create this role.
In Google Workspace:
Click the SAML attribute mapping section in the EdPotential app settings
Under Group membership (optional), select the group(s) you would like to have access to EdPotential.
Set the App attribute value to mlepRole
Click Save.
In MicrosoftEntra ID:
In the Microsoft Entra admin centre, go to Enterprise applications and select the EdPotential SAML application
Click on Edit at the right of Attributes & Claims
Click on Add a group claim
In the Group Claims section that opens on the right select Groups assigned to the application
For the Source attribute select sAMAccountName
Click Save
Now that you've added the claim, you need to assign the group/s to the application
Go to Users and groups
Select Add user/group
Click on None selected and select the group/s to be added, typically Teachers (check senior leaders are in this group.)
We will then check that teachers can still log in by using the test account provided during onboarding. If this account is no longer active we will ask the Deputy Principal (DP) to log in.
Step 3: Add a Student role to the EdPotential application
Our next step is to differentiate between teachers and students in your SSO setup so that we can assign different permissions to the two groups.
Repeat Step 2, this time adding a role Student.
This group must only contain the students who are to have access. For example, if you are only wanting to provide access to Year 12 and Year 13 students, only these students (and a test student account, as explained in Step 5 below) should be in the Students group.
Step 4: Add Student ID as an attribute
You will need to add Student ID as an attribute. Here is how you can map that attribute so it’s sent as a claim to your application.
Identify where the Student ID is stored. Before you can send it, you need to know which field it lives in. In a school environment, it is typically in one of these three places:
EmployeeID: The most common field used for student/staff numbers
ExtensionAttribute1-15: Common if the school syncs from an on-premises Active Directory
ExternalID: Common if they use School Data Sync (SDS).
Add the Student ID Claim
Go to Single sign-on > Attributes & Claims > Edit
Click + Add new claim
Configure the claim:
Name: student_id (or whatever your app expects)
Namespace: (Leave this blank unless your app specifically requires a URI)
Source: Keep this as Attribute
Source attribute: Search for the field identified in the first step (e.g., user.employeeid or user.extensionattribute1).
Click Save.
Step 5: Add a test student account
As the next step of testing we need a test student account which has an account in KAMAR. This will enable us to check that a student only sees their own report when they log in.
One possibility is to share with us the account of a student who has left (with a new password), if that student still has an active account in KAMAR.
The test account will need to have the Student ID attribute set.
Please provide the full email address of the test account, as sometimes students are on a different domain.
We will test that this login gives access to only this student's report on EdPotential.
Step 6: Final testing (to be completed by the DP)
While we have tested access with a test student account, it's advisable we have one further check. We suggest the DP runs through this process with one student while they oversee so they can confirm everything works as expected.
To do so they will need to direct a student to log in at their EdPotential sign-in page. The student should only see their own report.