Removing email from sign-in altogether
Signing in to the assistant currently relies on a six-digit code emailed to each person, and that delivery has been unreliable — Microsoft 365 doesn't consistently trust automated code emails sent from outside the tenant. The clean fix removes email from sign-in altogether: a "Sign in with Microsoft" button, so everyone signs in to the assistant with the ICB account they already use every day. No code email, nothing to fish out of a folder, and anyone with a bookkeepers.org.uk account can be admitted without me setting them up individually. The emailed codes stay available as a fallback.
This app handles sign-in only. It confirms who is signing in (their name and ICB email address) and nothing else. It has no access to mailboxes, files, or anything in the tenant beyond that identity check.
Because user consent is disabled tenant-wide (correctly), this needs a small app registration with admin consent. Following the same naming convention as before:
- In Entra admin centre: App registrations → New registration. Name it as below, leave account type as "Accounts in this organizational directory only".
ICB_Agent-02
- Under Redirect URI, choose platform Web and paste:
https://acuzipngzwjktfgtpxzi.supabase.co/auth/v1/callback
This is the assistant's sign-in service endpoint. Register, then continue below. - On the new app: Certificates & secrets → New client secret. Description "Assistant sign-in", expiry 24 months. Copy the secret Value (it is only shown once).
- On API permissions, the default delegated
User.Readis all it needs. Click "Grant admin consent for ICB". This is the step only a Global Admin can do. - Send me the Application (client) ID (from the Overview page) plus the secret Value from step 3 — a Teams message to me is fine; delete it once I confirm receipt.
I wire it in from my side and the "Sign in with Microsoft" button appears for the whole team.
The exemptions mailbox
The exemptions work agreed last week has two pieces: a new structured application journey, and a working surface over the current backlog. Both need sight of the exemptions@bookkeepers.org.uk mailbox, mirroring the setup we did for professional.standards@. Two grants:
2a — My access to the mailbox
Give jordan.copeland@bookkeepers.org.uk Full Access (read and manage) on exemptions@bookkeepers.org.uk — Exchange admin centre → Recipients → the mailbox → Delegation → Read and manage, or in PowerShell:
Add-MailboxPermission `
-Identity exemptions@bookkeepers.org.uk `
-User jordan.copeland@bookkeepers.org.uk `
-AccessRights FullAccess `
-InheritanceType All
2b — Widen the assistant's mailbox scope
When we set up ICB_Agent-01 you locked its reach to exactly two mailboxes with a management scope — the restriction that means it cannot read anything else in the tenant. That restriction stays; we re-issue it with the exemptions mailbox added as a third:
Set-ManagementScope `
-Identity "ICB_Agent-01 Mailboxes" `
-RecipientRestrictionFilter "PrimarySmtpAddress -eq 'jordan.copeland@bookkeepers.org.uk' -or PrimarySmtpAddress -eq 'professional.standards@bookkeepers.org.uk' -or PrimarySmtpAddress -eq 'exemptions@bookkeepers.org.uk'"
Then confirm it took effect (should return Granted):
Test-ServicePrincipalAuthorization `
-Resource exemptions@bookkeepers.org.uk `
-Identity a65ce8ca-68c0-4da2-8909-53b12402f712
Connect-ExchangeOnline). If exemptions@ is an alias on another mailbox rather than its own shared mailbox, let me know and I'll adjust the filter.What happens next
Part 1: as soon as the app details reach me, I wire in the "Sign in with Microsoft" button and the team signs in with their ICB account. Part 2: with the mailbox grants in, the exemptions backlog surface can start reading real correspondence.
Neither item depends on the other, so do them in whichever order suits. Please let me know as each lands.
Jordan
Practice Standards Assistant · 7 July 2026