How the connection will work.
edSI’s planned standard connection uses one Microsoft application registered and managed by the edSI platform. Each college authorizes that application in its own Microsoft tenant. The college keeps control of its Microsoft accounts and tenant policies.
Your college
Confirms its tenant, nominates administrators, approves the connection and reviews staff and student access.
edSI
Maintains the shared application, configures the sign-in endpoints, validates identities and enforces each college’s approved memberships.
App registration is normally a one-time edSI platform task. New colleges normally approve the shared app in their own tenant. A dedicated college-managed registration is a separate deployment option that must be agreed with edSI before creating it.
What your college needs.
| Prepare | What to check |
|---|---|
| Microsoft tenant ID | The directory identifier for the Microsoft 365 tenant used by your college. Find it in Microsoft Entra ID’s overview or properties. |
| Primary college administrator | The Microsoft work/school sign-in username (UPN) for the person who should administer your edSI college. Confirm whether their email address is also their sign-in username. |
| College email domains | The verified domains used by your staff and students. Record any different staff and student domains. |
| Approved account roster | Who is an administrator, staff member, finance officer, instructor or student. Include student-record and cohort assignments. |
| Microsoft tenant administrator | A person authorized to review the enterprise application and grant the required organizational consent. Your edSI administrator and Microsoft tenant administrator can be different people. |
Your setup steps.
- 01Prepare now
Confirm your Microsoft tenant and administrator.
Open the Microsoft Entra admin center and select your college’s directory. Confirm that the proposed primary edSI administrator is an active work/school account. Check its sign-in username, and confirm that staff and students belong to the intended tenant.
Have your Microsoft tenant administrator available for consent and any tenant-policy changes.
- 02Prepare now
Gather your tenant and account details.
Record the tenant ID, primary administrator username and staff/student email domains. In the standard shared-app connection, edSI supplies the application client ID. A new college does not normally create its own app registration or generate application credentials.
Keep these non-secret details ready for the activation process. A dedicated Microsoft connection form will accompany the sign-in integration.
- 03Prepare now
Review staff and student access.
Prepare the approved account roster. Choose a primary college administrator, assign staff responsibilities, and match students to their existing college records. Review instructor cohort assignments.
Microsoft verifies identity; edSI’s college memberships determine the records and actions each person can access.
- 05At activation
Verify and link existing accounts.
edSI will verify the Microsoft tenant and user identifiers and link the approved accounts to your college memberships. The requested primary administrator must complete verified sign-in before that Microsoft identity receives administrator access.
Existing student records and permissions need reviewed account linking. A matching email address alone does not establish an authorized account link.
- 06At activation
Test a small group, then launch.
Test the primary administrator, one staff member and one student. Check college selection, assigned access, sign-out and your Microsoft MFA policies. Confirm that an unapproved account and a user from another college cannot access your records.
Approve the rollout after these checks pass, with a tested administrator recovery route before changing the college’s login method.
Keep credentials in the right place.
For the standard shared connection
Your college supplies its tenant details and consent. edSI manages its application credential. No college Microsoft password, client secret or private certificate key belongs in a general support message, document or connection-metadata field.
The sign-in implementation will request the basic identity scopes openid, profile and email. Account creation, directory writes and licence management have separate permission requirements. Consent to sign in does not by itself enable those operations.
For a separately agreed college-managed application, edSI will provide the exact application configuration and callback URL. Its production credential must be installed through secure server settings; Microsoft recommends certificate credentials over client secrets for production.
Sign-in is the first connection.
| Connection | Purpose | Current pilot status |
|---|---|---|
| Microsoft sign-in | Verify staff and student identities using work/school accounts. | Preparation only; implementation pending. |
| Microsoft account provisioning | Create accounts and assign approved Microsoft 365 licences. | Not enabled; separate permissions and testing required. |
| Moodle synchronization | Import reviewed records and synchronize approved cohort/course memberships. | Metadata and mapping planning only; live sync pending. |
If Moodle already uses Microsoft sign-in, keep that integration in service during edSI preparation. edSI’s connection is configured separately, using the intended college tenant and reviewed account links.
A few useful answers.
Do we need to create a Microsoft app registration?
Normally, no. In the planned shared-app model, edSI manages its application registration and your Microsoft administrator authorizes it in your college tenant. The original app-registration instructions apply to edSI’s platform setup, or a dedicated connection agreed in advance.
Where do we get the application client ID?
edSI will supply the shared application’s client ID as part of the verified activation process. Your own tenant ID identifies your college. Do not create or paste a different application’s client ID to try to enable login.
Can everyone with our email domain access college records?
A domain identifies an email address, not a permission. Each person needs an approved college membership and role; a student also needs the correct student-record link. Microsoft sign-in will not automatically grant administrator privileges.
Can our Microsoft administrator differ from our edSI administrator?
Yes. The person granting Microsoft tenant consent can be different from the person managing edSI. Record the primary edSI administrator’s work/school username and verify their identity during account linking.
Can we enable Microsoft login today by saving tenant details?
No. New trials use a temporary username and password. Connection metadata is preparation only. edSI will provide the verified consent and callback configuration when the authentication deployment is ready.
What if our college needs its own application registration?
Discuss a dedicated connection with edSI before registering the app. For a college-only deployment, organizational single-tenant registration may be appropriate. Redirect URLs, account types, credentials and ownership must match that specific deployment.
Microsoft references.
Ready for the next step?
Gather your tenant ID, administrator username, email domains and approved account roster. Keep them ready for the verified activation process.
Return to college setupNew trials use a username and password. Configure institutional identity during implementation.