Short answer: In a property-management password recovery flow, resolve the external identity first, inspect its ownership and assurance second, and attach it only through an explicit, logged state transition. A recovery request should never become an account merge just because two records share an email address.
That decision rule matters because a tenant portal is a useful target for automated abuse. A stolen mailbox, a recycled phone number, or a typo in a landlord's spreadsheet can turn a convenient linking feature into unauthorized access to leases, payment history, and maintenance keys. The workflow below keeps the account-binding question separate from the reset-token question, so an auditor can reconstruct what happened without trusting a fuzzy match.
What should identity linking resolve, inspect, and attach safely?
Treat the operation as four states: received, resolved, inspected, and attached (or rejected). Each transition has an input, a decision, and an audit record. The external provider's subject identifier is the stable candidate; a display name or normalized email is evidence for review, not proof of sameness.
For a forgotten password, the user first proves control of a recovery channel that is already associated with the property account. Only then does the service resolve the identity assertion. The inspection step checks whether that identity is already attached, whether the target account has another usable sign-in method, and whether policy allows a new attachment. A failed match remains a failed match. Do not silently create a second tenant account and do not auto-merge on partial profile data.
