Hi!

This is a very common scenario when dealing with identity integration between Microsoft Entra ID (Azure AD) and Databricks.

Here is a breakdown of what happens when a corporate account is deactivated, followed by the best practices to ensure zero downtime or loss of access.

1. What Happens Upon Account Deactivation?
User Authentication & Identity: Once the user is deactivated in Entra ID (and synced via SCIM to Databricks), they will no longer be able to log in. Their user identity in Databricks becomes inactive/disabled.

Workspace Notebooks & Folders: They will NOT be deleted. The user's personal workspace directory (/Workspace/Users/user@company.com/) and all notebooks inside it remain in the workspace. Anyone with existing permissions (like Can Edit or Can Manage) can continue accessing and editing them.

Permissions & Access Control: ACLs (Access Control Lists) on shared objects remain intact.

2. The Hidden Risk: Databricks Jobs, Workflows, and Connections
While notebooks won't disappear, automated scheduled jobs/workflows can fail if they were created by the departing user.

Job Ownership: If a scheduled Databricks Job is configured with "Run as: Departing User", the job execution will fail as soon as the user is deactivated.

PAT Tokens & Connections: Any external API, JDBC/ODBC connection, or Power BI refresh using a Personal Access Token (PAT) generated by that user will immediately break.

Storage Access: If data access relies on the user's personal identity or credentials rather than a Unity Catalog Storage Credential or Service Principal, downstream Power BI reports will lose access.

3. Recommended Best Practices Before Offboarding
To ensure a seamless transition, here are the steps you should follow:

Step 1: Move Notebooks out of Personal User Directories
Notebooks stored under /Workspace/Users/user@company.com/ can feel "orphaned" over time.

Best Practice: Move production/shared notebooks to a Shared Folder (/Workspace/Shared/) or, even better, convert them into a Databricks Git Folder / Repo linked to your company’s Git repository (GitHub, Azure DevOps, Bitbucket).

Step 2: Transfer Job Ownership / Use Service Principals
Audit all scheduled Workflows/Jobs owned by the departing user.

For Production Jobs: Change the job owner and set the execution identity ("Run as") to a Service Principal rather than an individual employee's user account. This prevents jobs from breaking during future team transitions.

For Dev/Stage Jobs: At minimum, transfer ownership to yourself or another active admin (Job Details -> Ownership -> Edit).

Step 3: Audit Power BI Connections
Check your Power BI datasets/reports. If the connection to Databricks uses a Personal Access Token (PAT) or the user's OAuth credentials, update the data source settings in Power BI to use a Service Principal or a generic System Account with appropriate Unity Catalog / Warehouse permissions.

Summary Checklist:
Move critical notebooks to /Workspace/Shared/ or a Git Folder.

Reassign ownership of all Databricks Jobs/Workflows.

Configure production jobs and Power BI connections to use a Service Principal.

Transfer ownership of any Delta Live Tables (DLT) or Databricks SQL Dashboards/Alerts.

Hope this helps clear up your concerns and guides your transition! Let us know if you need help with the specific steps for transferring job ownership.