<h2>Introduction</h2>
An application of this sort needs solid permission systems to control user access. We could opt for a simple way out like RBAC, but that will be a very vague approach, cause one user may have over 10 documents, and sharing those documents will require the Owner delegating access and actions to either read or update the document.
Let’s say we use RBAC:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfs-jVJHidB4Nbduot5WVesBtS999s-I8Xt-U1fSB-xly9Q8RjU0fkAsJmWyvuOQJMtY1MdhywEwGUD8EowMSGPFGTgb0_OJAiNu9Y8ZLtjU7-PaImlCgjw0u5c0ILYQLSQ3s2FdQ?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
When User A shares a document with User B, the permission should be specific to that document. User A might want User B to edit one spreadsheet while only allowing read access to another. Traditional role-based systems would give User B the same level of access across all shared documents.
This is where Relationship-Based Access Control (ReBAC) becomes essential. Instead of assigning global roles, ReBAC grants permissions based on the relationship between a user and a specific resource. User A can make User B an editor of Spreadsheet X while keeping them as a viewer-only for Spreadsheet Y. Each permission is tied to the individual resource, not the user’s overall role in the system.
This granular control mirrors how real collaboration works - you trust different people with different levels of access to different documents based on context, not their job title.
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeJYQ6fe4ZWjEBEYRMMQlUBfvZzf8k-Ov63mS52Zx6-FiHpyO2DxJGKjkGtHT6hYkCPS8dQmrIhrF41DS2MzdmvyMdUy6xthPfTnk1HQlEhci0Vcuh9O8DOsr7h2KwC5ps9mf_i?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
<h2>What Will We Build?</h2>
In this article, we will create a collaborative spreadsheet application where users can create, share, and edit documents with permission controls. The app functions like Google Sheets, allowing multiple users to work on spreadsheets with different access levels.
Access Control Policies:
<ul>
<li>Owners can edit spreadsheets, manage sharing, and invite other users with specific permissions</li>
<li>Editors can modify cell content, apply formatting, and save changes, but assign roles to the document</li>
<li>Viewers can only read the spreadsheet content without making any modifications</li>
<li>Permissions are resource-specific - a user might edit one spreadsheet while only viewing another</li>
</ul>
Application Flow:
Users sign up and authenticate through Supabase
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdAmHtLxTIwMKs8vJcBp8DCUufMATsdmDiT72IC5U53tiTAZQYC2AR7yHvG8BqEqiIGUBxkDAbjvk_1BdttnDIwIA_8gKdImXgdLYolC6QcTrFmNCPjwVTcYLi2HAWh0jedJQIKeA?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
Authenticated users can create new spreadsheets (becoming the owner)
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXd7VyQ2Oq5aWQk3CDhtaREhpfGFI9fFj38_0nJ-FVCxm4MJdHs6-2Vi6yY2Ss2ECsJE6PagiTQ0bmQRPqvcLCytAbl6sIAMsKpJvfXlpe-H5LG6A76JtWh-EALmHJVbHuCa1aOHjg?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
The Spreadsheet:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeiVRyOwhjwBcQ98IYp-VMKUlGszbnjG631l-MaYnUpbPtm49qxYmxqkOUCJSSIl7IJubyBpZqFA7qjAjGq6JB7-kKrkcaZf4PcBBLg-lNM8ROBdPkUTL7g64cPmkwRwfGYdDZJVg?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
Owners can share spreadsheets by inviting users via their user ID, specifying either Editor or Viewer access:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcbl_CkL7majNLVfr3MSZ-BF78GyQjb_aVfuv1LipY2tWnKr6hWaweEusUXFbQtBZeleA5QD4tls8H7KlH-Ab57goaA4e6RMJp1t46hU06c9M5imRPJnPueXV9-al-3chbYMh1xWg?key=ty82Bl-S85ktPF__90pCMPJl" alt="">
Invited users see the shared spreadsheet in their dashboard with appropriate permissions. The interface adapts based on user permissions - read-only users see a locked interface while editors get full functionality
All changes are saved in real-time with permission checks on every action. The permission system ensures that users can only perform actions they’re authorized for on each specific spreadsheet, creating a secure collaborative environment.
<h2>Prerequisites and Tech Stack</h2>
In this article this are our basic requirements:
<ul>
<li>Node.js and npm installed</li>
<li>Basic knowledge of React and Next.js</li>
<li>Supabase account for database and authentication</li>
<li><a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> account for authorization management</li>
</ul>
Tech Stack:
<ul>
<li>Frontend: Next.js 15 with React 19 and Tailwind CSS</li>
<li>Database: Supabase (PostgreSQL)</li>
<li>Authentication: Supabase Auth</li>
<li>Authorization: <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> ReBAC</li>
<li>UI Components: Lucide React icons</li>
</ul>
To get started, feel free to clone this repo:
<pre><code>https://github.com/JoyIma/google-sheet-clone.git
</code></pre>
<h2>Database Schema</h2>
An application like this will obviously use a complex but effective database schema. Our database schema was built on Supabase (PostgreSQL), and it supports user management, spreadsheet storage, and permission tracking. I made these tables public
Core Tables: Profiles Table
<pre><code class="language-SQL"> CREATE TABLE profiles (
 id UUID REFERENCES auth.users(id) PRIMARY KEY,
 full_name TEXT,
 email TEXT UNIQUE NOT NULL,
 updated_at TIMESTAMP WITH TIME ZONE
 );
</code></pre>
The profiles table extends Supabase’s built-in auth.users table with additional user information. It stores user display names and email addresses that we’ll sync with <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> for authorization. The id field directly references Supabase Auth’s user ID, creating a one-to-one relationship.
Sheets Table
<pre><code class="language-SQL"> CREATE TABLE sheets (
 id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
 name TEXT NOT NULL,
 user_id UUID REFERENCES auth.users(id) NOT NULL,
 cells JSONB DEFAULT &#x27;{}&#x27;::jsonb,
 created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
 updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
 );
</code></pre>
The sheets table stores our spreadsheet documents. Each sheet has:
<ul>
<li>A unique id that serves as both the database primary key and <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> resource instance identifier</li>
<li>A name for the spreadsheet title</li>
<li>A user_id linking to the sheet creator (automatically becomes the Owner in <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a>)</li>
<li>A cells JSONB field storing all spreadsheet data in a flexible key-value format</li>
<li>Timestamp fields for tracking creation and modification dates</li>
</ul>
Public Access Model
Since all sheets are publicly accessible to authenticated users, we’ve removed Row Level Security policies and permission tables. In order for this to work in Supabase, you will have to use the Service_Role_Key and not the Anon_Key:
<pre><code class="language-SQL"> CREATE POLICY &quot;Public read access to all sheets&quot;
 ON sheets FOR SELECT
 USING (true);
 
 CREATE POLICY &quot;Public write access to all sheets&quot;
 ON sheets FOR UPDATE
 USING (true);
</code></pre>
<ul>
<li>Any authenticated user can view any spreadsheet</li>
<li>Sheet creators maintain ownership privileges (managed through <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a>)</li>
<li>Sharing and editing permissions are handled entirely by <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a></li>
<li>Database-level access control is minimal, focusing on authentication rather than authorization.</li>
</ul>
Now let’s combine <a href="http://permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> authorization to get a full working collaborative spreadsheet.
<h2>The Implementation Guide</h2>
As I have said earlier, our application is half complete if we lack proper authorization implemented. We won’t be going deep into building our application, as you can just easily clone the application, but if you want a full on tutorial on how I built this, you can comment below, I will very be happy to break it down, to keep this article brief and not too long we will pay close attention to how best we can implement these authorizations.
We’ll build our collaborative spreadsheet application through four distinct phases: planning our authorization structure, configuring the schema in <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a>, setting up users and resources, and implementing permission enforcement. This approach ensures we have a solid foundation before writing any permission checks.
Planning Step
Before touching any code, we need to clearly define our authorization model. This planning phase prevents confusion later and ensures our permission system scales properly.
Resources
<ul>
<li>SheetDocument - Individual spreadsheet files that users create and collaborate on</li>
</ul>
Roles
<ul>
<li>Owner - Complete control over a specific spreadsheet</li>
<li>Editor - Can modify content</li>
<li>Viewer - Read-only access to spreadsheet content</li>
</ul>
Relationships
<ul>
<li>Users have role-based relationships to specific SheetDocument instances</li>
<li>Each relationship is scoped to individual spreadsheets (ReBAC model)</li>
<li>Multiple users can have different roles on the same spreadsheet</li>
<li>Users can have different roles across different spreadsheets</li>
</ul>
Authorization Policies in simpler terms
<ul>
<li>Sheet owners can share their spreadsheets and assign Editor or Viewer roles to other users.</li>
<li>Sheet editors can modify cell content, apply formatting, and save changes to sheets they have Editor access to.</li>
<li>Sheet viewers can only read spreadsheet content without making any changes.</li>
<li>Users can have different permission levels across spreadsheets - you might own Sheet A while only viewing Sheet B.</li>
<li>Permission changes take effect immediately across all active user sessions.</li>
<li>Users only see spreadsheets they have explicit permissions for in their dashboard.</li>
</ul>
To read more about this visit the full <a href="https://medium.com/@joyelijah2002/implementing-relationship-based-access-control-in-a-google-sheet-clone-71ce97af9b5e" target="_blank" rel="noopener nofollow">blog post</a>. Will love to hear your thought below.

joyelijah's public Squad

Explores implementing Relationship-Based Access Control (ReBAC) in a collaborative spreadsheet application similar to Google Sheets. ReBAC provides granular permissions where users can have different access levels (Owner, Editor, Viewer) for individual documents rather than global roles. The implementation uses Next.js, Supabase for database and authentication, and Permit.io for authorization management. The system allows document owners to share spreadsheets with specific permissions, enabling fine-grained control over who can view or edit each document.

Implementing Relationship-Based Access Control in a Google Sheet Clone