Microsoft 365 checklist for IT

Before approving

1. Confirm the practice’s Microsoft directory and each nominated mailbox’s primary address. Shared and individual mailboxes are supported; groups and distribution lists are not.
2. Identify the administrator allowed to consent to delegated Exchange.Manage, and the Exchange administrator able to create Application RBAC scopes and assignments. Responsibilities may be split between two people.
3. No second mailbox is required. If the directory has another user or shared mailbox not already authorised for Refera, Refera uses it for a denial check. If not, Refera runs the single-mailbox check below. To use the denial check instead, add one unlicensed shared mailbox before connecting.
4. Check for conflicting resources or a parallel unscoped Entra Mail.Read application grant. Entra and Exchange grants are additive; a wider grant defeats mailbox isolation.
5. Use only the current Continue to Microsoft or Copy secure link action from the practice’s saved connection. Every link expires after 30 minutes.

Practice setup steps

The capture permission

Refera uses Exchange Online RBAC for Applications.

Boundary	Requirement
Resource	Exchange Online Application RBAC role Application Mail.Read, scoped to the exact selected mailbox. Each additional mailbox has its own scope, assignment and proof.
Identity	Refera’s certificate-backed application. Ongoing polling does not use a staff account or the administrator session.
Delegated setup	Fresh authorization code, PKCE and nonce; token scope and signed client/tenant identity are checked before Exchange work. Neither session requests offline_access; a response carrying a refresh token is rejected. No staff password or customer-created client secret is requested. Setup access tokens remain in process memory and are discarded after the step.
Organisation consent	Separate from mailbox access. A callback receipt does not independently prove the grant or authenticate the administrator. Tenant-wide consent may persist after the short session; expiry does not revoke that grant.
Folder	The Inbox is proved first. After connection, one selected folder limits polling inside that mailbox; the Microsoft permission remains mailbox-scoped.
Message handling	New mail only from the recorded activation boundary. Read-only polling cannot send, delete, move, mark as read or categorise messages.

The existing administrator reference names Exchange Administrator plus Exchange Online Organization Management, or equivalent authority able to assign Application RBAC permissions. Check the actual delegated authority with the organisation’s administrator. A publisher badge is separate from both this authority and the mailbox proof; never bypass an organisation policy that blocks consent.

Checks before capture

An approval URL is returned only when the complete controller is configured. A disabled or incomplete controller returns no URL and changes no Microsoft connection state; capture stays off.

Preflight gives Refera no access and changes nothing, with one exception: if Microsoft reports that your organisation has never turned on Exchange organisation customisation (IsDehydrated), Refera runs Enable-OrganizationCustomization once, in the signed-in administrator’s own session. This is Microsoft’s one-time prerequisite for creating any Exchange role assignment; it grants Refera nothing. That attempt then stops, and you try again after a few minutes. Preflight resolves the real mailbox, checks the enterprise application and existing scope/assignment, and counts any legacy Application Access Policy that could apply to Refera. It stops on a missing or unsupported mailbox, an alias needing confirmation, conflicting resources, a policy that could apply to Refera, or a permission check the signed-in administrator cannot run. For the single-mailbox check it also stops if Refera can already read the chosen mailbox, or if Refera already holds an Exchange permission this connection did not create. If Microsoft returns incomplete or unfamiliar permission details, Refera adds no inbox access and asks IT to check the role, permission and scope in Exchange Online. Refera could not tell whether it is this connection’s own permission or another one; contact Refera if the check keeps failing. When the single-mailbox check is not available for an attempt, a missing second mailbox still stops setup.

The single-mailbox check runs when the administrator who signs in can see no other user or shared mailbox that Refera could test against. The chosen mailbox must refuse Refera before any grant. After the assignment, Microsoft’s Exchange permission test (Test-ServicePrincipalAuthorization) must list only Refera’s own read access to the mailboxes this practice connected. The first successful read must then come within 45 minutes of the last refusal. Connections proved before 16 October 2026 used the earlier rule, a first read within 15 minutes of the last refusal, and their proofs stay valid.

After assignment, Refera allows up to 2 hours 15 minutes for Exchange RBAC propagation. Microsoft usually switches on access within 30 to 60 minutes. Refera makes no Microsoft Graph call for that connection for the first 33 minutes, then checks at least 31 minutes apart, with a final check before the limit, so its own checks do not keep Microsoft’s permission cache waiting. With a second mailbox, it proves the target is allowed, proves the unrelated mailbox is denied, and rechecks that denial immediately before sealing the exact connection evidence. With one mailbox, it reads the target until the first successful read, requires that read within 45 minutes of the last refusal, and seals the refusal before the grant, the permission-test result and the first read. Capture starts from the moment the Exchange step completed, so mail that arrived while Microsoft switched on access is collected, and the practice’s connection activates in the background without anyone opening a page. A missing denial, a late check or a policy block fails setup with capture off; IT then removes the named assignment. No setup-message delivery timer decides this connection state.

Real referrals remain subject to the separate practice and service checks, including source integrity, authenticated retrieval, restore, export and practice isolation. These are not replaced by a successful consent page, status email or mailbox read.

If assignment may have happened but completion fails, Setup cleanup required retains the exact non-secret enterprise-application, scope and assignment names. Capture stays off; the result must not be described as no permission or successful removal.

Directory lookup and several mailboxes

A separate short discovery sign-in can return up to 500 normalised user/shared mailbox entries: display name, primary address, recipient type, derived opaque mailbox ID, selection eligibility and a bounded refusal reason. No other directory field is exposed. Text typed into the search box does not authorise a different mailbox. The server-held list lasts only for the setup session and is not durably stored or logged. No mailbox contents are returned by discovery. Ongoing capture does not browse the directory.

Each mailbox has its own approval, folder, capture boundary, polling status and disconnect lifecycle. A current organisation receipt or discovery list may be reused for selection, but a delegated token, mailbox permission or proof is never reused for another mailbox. An exact directory/mailbox pair can belong to only one Refera workspace at a time; verified denial on disconnect releases the claim.

Folder changes reach the same mailbox’s poll configuration before the folder is treated as active. They need no new administrator consent and do not enable overlapping folders. Older connections keep their original record key and Inbox default until their own disconnect/relink lifecycle completes; they are not silently rewritten into mailbox slots.

New mail and connection health

A fixed capture from time, cursor and idempotent processing prevent reconnect from silently moving capture backwards. Refera does not sweep the existing inbox or import older mail. A historical import would be a separate, explicitly agreed and bounded job; connecting never starts one.

Connections records a successful inbox check only after sync finishes and the current mailbox/request binding is rechecked. After the 10-minute stale threshold it shows Inbox check delayed and retries. This health timestamp does not repeat the access proof, certify that permissions have not changed or prove individual message delivery.

Delayed-check and recovery emails contain metadata only. There is one warning attempt per affected active Owner/Admin, without repeated warnings during the same interruption. The original recipient set is frozen; recovery within 24 hours is notified only after every original warning was provider-accepted, and only to original recipients still holding the role. New or removed recipients do not receive that recovery. Recovery watches use one-way recipient hashes, not stored email addresses. Neither provider acceptance nor these emails proves delivery, missed mail or connection authority.

Disconnect and cleanup

1. An Owner or Admin requests Stop reading for the exact mailbox. A durable poller stop must be acknowledged; failure leaves the connection record unchanged.
2. A Microsoft administrator uses Copy instructions for IT to remove the named Exchange assignment and inspect the named resources. No delegated refresh token remains for unattended removal.
3. Refera proves the old target mailbox is denied. Until then, Revocation pending or Removal pending remains visible and reconnect is blocked.

Other mailbox slots continue independently. Records already held in Refera are not deleted by disconnect. Optional write/send assignments, if separately enabled in a future release, require their own removal and denial proof.

If the wrong organisation was approved, changing the organisation in Refera retires unfinished local setup; it does not revoke any Microsoft grant already made there. That organisation’s administrator must inspect and remove the unintended enterprise application or delegated consent as appropriate.

If a status email is quarantined

Use Microsoft quarantine to inspect Authentication-Results and X-Forefront-Antispam-Report, including SPF, DKIM, DMARC, SFV, CAT and BCL verdicts. Submit a false positive where appropriate; use a temporary allow entry only if Microsoft offers it through that submission. Do not use Advanced Delivery, a broad mail-flow bypass or an inbound connector for normal Refera mail. A missing or quarantined receipt does not prevent an otherwise verified connection.

Practice activation and source records

Versioned, Object-Locked source storage is deployed in AWS Sydney. Real referrals stay off until source integrity, authenticated retrieval, restore, export and practice-isolation checks pass.

Other connections and staff sign-in

Microsoft 365 is the current inbox connection. Gmail, IMAP, HealthLink, Medical-Objects and direct upload are unavailable; this checklist grants no authority to configure them. Do not redirect a HealthLink EDI mailbox or grant a watched-folder path. Its written partner assessment, applicable profile/conformance, synthetic interface testing, certificates, source lifecycle, live-network proof, monitoring and reviewed reversible cutover remain separate prerequisites.

Fax/scanner PDFs can arrive through the verified Microsoft inbox. Do not port or redirect an existing fax number during signup; use a patient-free test and a separately reviewed cutover if routing must change. Refera requests no EMR plug-in or database access.

Each staff member uses a passkey, or the email-link-plus-authenticator route, at every sign-in. Email proof alone opens only the account-security step at first sign-in, never referral records. Microsoft approval is separate from Refera sign-in. Sign-in details

Controls retained for unavailable Outlook drafting and sending

These are constraints for unavailable capabilities, not setup options or permission requests. Current Refera text is copy-ready only. Outlook draft creation and sending are not available to practices.

• Outlook drafts and sending are not available to practices. Separate mailbox-scoped grants would require Application Mail.ReadWrite and Application Mail.Send.

Neither follows from Mail.Read, and neither permits an unscoped Entra application grant. Each needs its own approval, target allowance, unrelated-mailbox denial and connection check.

• Owner approval: an Owner’s separate sending addendum requires recent passkey or TOTP proof and chooses the approving role: authorised staff, Owners/Admins, or Owner only. It grants no Microsoft access by itself.
• The separate test send is patient-free and restricted to the nominated mailbox. Real sending is limited to the fixed server-generated patient-booking email, with no attachments and explicit named-person approval for every send.
• The single-use operation binds tenant, referral, sender mailbox, recipient/subject/body hashes, empty attachments, staff identity/role, sealed draft approval, addendum and permission generation. It expires rather than becoming reusable authority.
• Uncertain outcomes: Graph 202 Accepted does not prove delivery, reading or booking; it confirms acceptance for processing only. A lost response is resolved using the original durable request. An ambiguous outcome stays Outcome unknown, is never automatically retried and requires checking Outlook Sent Items before another decision. Repeating accepted content needs a new sealed approval and explicit repeat-send confirmation.
• Refused or unknown outcomes have durable PII-free operational alerts through Slack and email. Accepted sends retain an audit record without routine success alerts.
• Disabling the addendum stops local sending immediately without stopping read-only capture. Microsoft removal required remains until the separate send assignment is removed and target denial is proved.

Administrative process-state only - Refera performs no clinical triage.