What happens to Databricks notebooks and jobs when a user's Microsoft account is deactivated?

[LincolnGarbin]

Hi everyone,

I recently joined a company where we use Databricks to process and transform data that is ultimately used in our Power BI reports and dashboards.

The person who has been training me is leaving the company. Our Databricks environment is integrated with Microsoft authentication, and his Databricks access is linked to his corporate Microsoft account and email address.

I assume that his corporate Microsoft account will eventually be deactivated or deleted when he leaves the company. I am therefore trying to understand what will happen to the Databricks resources he currently owns or has created.

He created several notebooks and other Databricks resources that I currently have access to. He also granted access to other users, and some of us have permissions to edit and manage these resources.

At the moment, when I go to the Databricks Workspace, I can find his user profile and access the notebooks he created. I can edit and work with them because I have the necessary permissions.

My concern is what will happen when his Microsoft account is deactivated.

Will the Databricks user associated with his Microsoft account also become inactive? If so, will the notebooks, jobs, and other resources he created continue to be available to users who already have access to them?

Could the deactivation of his Microsoft account affect our ability to access or manage these resources?

Are there any specific steps we should take before his corporate account is deactivated to ensure that the notebooks, jobs, and other Databricks resources continue to work properly?

Would it be better to clone or copy the notebooks to another user's workspace, or is there a recommended approach for handling Databricks resources when an employee leaves the company?

What is the best practice in this situation?

Thanks in advance for your help!

[GabFernandes · Accepted solution]

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.

[LincolnGarbin]

Thanks a lot! I really appreciate your guidance. I will follow the steps you suggested to reduce the chances of encountering any issues during this process and help ensure everything goes smoothly.