Create a pull request from your Git provider
Databricks notebooks support real-time co-authoring where multiple users edit, run, and comment on the same notebook simultaneously with live cursor tracking and instant sync. Combined with workspace permissions, revision history, comments, and Git integration via Repos, notebooks become a full collaboration platform. Use these features to pair-program, review work inline, and maintain a shared analytical workspace.
- Understand how real-time co-authoring works and what users can see
- Configure notebook permissions for team collaboration
- Use comments, revision history, and Git repos for structured collaboration
Who this is for: Teams who collaborate on data analysis, pipeline development, or shared notebooks and want to maximise productivity through real-time editing.
Part of the Databricks Notebooks section of the Databricks tutorial series.
Architecture / Concept Overview: Create a pull request from your Git provider
Real-time co-authoring uses the Databricks control plane to synchronise cell content, cursor positions, and execution state across all connected users. Each user sees live updates as others type, and cell execution results are visible to everyone attached. The notebook server handles conflict resolution, so simultaneous edits to different cells merge seamlessly and edits to the same cell follow last-write-wins semantics.
*The control plane synchronises edits from all connected users to a shared notebook state.*
*Collaboration features layer from live editing through comments, revision history, and Git integration.*
*Notebook permissions cascade from View to Run to Edit to Manage.*
Key Terms
- Co-Authoring
- Simultaneous editing of a notebook by multiple users with real-time synchronisation.
- Revision History
- Automatic snapshots of notebook content at regular intervals for auditing and rollback.
- Inline Comment
- A comment attached to specific text within a cell for contextual feedback.
- Repos
- Git integration that syncs notebooks with external repositories for version control and code review.
- Workspace Permissions
- Access controls that determine who can view, run, edit, or manage a notebook.
Prerequisites and Setup
- A Databricks workspace with multiple user accounts
- Notebooks stored in workspace folders or Repos
- Team members with appropriate permission levels
- A Git provider (GitHub, GitLab, Azure DevOps) for Repos integration
Step-by-Step Implementation
Configuration Reference
| Permission Level | View | Run Cells | Edit Cells | Manage Permissions |
|---|---|---|---|---|
| Can View | Yes | No | No | No |
| Can Run | Yes | Yes | No | No |
| Can Edit | Yes | Yes | Yes | No |
| Can Manage | Yes | Yes | Yes | Yes |
Monitoring, Cost, and Security Considerations
Monitoring
Track who is currently connected to a notebook via the avatar indicators in the notebook header. Revision history logs all changes with timestamps and user identities. Git commit history provides an additional audit trail.
Cost Optimisation
- Co-authoring lets multiple users share a single cluster, reducing the total number of clusters needed.
- Use "Can Run" permission for users who only need to execute, not edit, to prevent accidental changes.
- Review and clean up shared notebooks regularly to avoid sprawl.
Security and Governance
- Notebook permissions are independent of Unity Catalog data permissions — a user can edit a notebook without having access to the data it queries.
- Revision history is immutable and provides an audit trail.
- Repos add Git-level access controls (branch protection, required reviewers) on top of workspace permissions.
- Avoid storing credentials in notebooks; use Databricks secrets.
Common Pitfalls and Recommended Patterns
- Editing the same cell simultaneously: last-write-wins, so coordinate on shared cells using comments.
- Granting "Can Edit" too broadly: use "Can Run" for analysts who only need to execute preset analyses.
- Not using Repos for production notebooks: workspace revision history is helpful but Git provides proper branching and review.
- Losing work by overwriting co-author edits: use revision history to recover and coordinate via comments.
- Sharing notebooks via workspace folders with no structure: organise by team and project with consistent naming.
- Skipping inline comments: they are the fastest way to give contextual feedback without a meeting.
Frequently Asked Questions
Can I see who is currently editing the notebook?
Yes. Active collaborators appear as avatars in the notebook header. Each user's cursor is visible with a name label.
Does co-authoring work on serverless compute?
Yes. Co-authoring is a notebook UI feature independent of compute type. Multiple users can edit and run cells on the same serverless session.
How often is revision history saved?
Revision history is saved automatically at regular intervals and on explicit saves. You can also create named checkpoints for important milestones.
Can I prevent certain users from running cells?
Yes. Set their permission to "Can View" — they can see the notebook but cannot execute any cells.