A production solution's cloud flows run their Dataverse actions through a connection reference that uses the personal account of a developer who is leaving the company next month. When the account is disabled, the flows will start failing. Which identity should the connection reference use going forward?

Connections created with personal accounts inherit the lifecycle of the person: when the account is disabled, its password changes, or multifactor policies require interaction, connections that depend on it fail. A Dataverse connection using service principal authentication signs in with an app registration's credentials and maps to an application user, which has its own security role and is not tied to employment changes. This decouples production automation from individuals and makes the identity's privileges explicit and auditable. Switching to another developer's personal account repeats the same risk with a different person and also attributes system changes to someone who did not make them. Keeping a departing employee's account active, even if marked non-interactive, leaves an ex-employee's credentials in use, which violates offboarding practice and still relies on a user account's password and policies. Using a Global Administrator account grants far more privilege than the flows need, concentrating risk in one credential and violating least privilege, and it is still a personal account that can be disabled or rotated. Exam caveat: the service principal's credentials, a secret or certificate, must be renewed before expiry, so track the expiry date and alert on it. Operational check: after switching, disable a test copy of the old user in a non-production environment and confirm the flows continue to run.