Build a Multi-Tenant #Supabase Project + #FlutterFlow Role based app

Summary: Multi-tenant Supabase + role-based FlutterFlow app (tutorial)

The video walks through building a multi-tenant “to-do” application using Supabase (with Row Level Security) and a front-end example built in FlutterFlow (using a prebuilt sample app). The core focus is on configuring the database schema and enforcing server-side access control so that users can only read/manipulate data belonging to their company/tenant, with additional role-based permissions (regular user vs. administrator).

---

What the app does (multi-tenant + roles)

• Each user belongs to a company.
• Users can perform CRUD on their own company’s to-dos only.
• There are roles:
  • user (regular permissions)
  • admin (can update/delete to-dos more broadly within the tenant)
• The tutorial emphasizes that security is enforced in Supabase (not only in the UI).

---

Backend setup in Supabase (3 tables + relationships)

Tables created

1. companies

   • id (primary key)
   • name

2. users (stored in the public schema)

   • id (UUID matching Supabase Auth user id)
   • email
   • company_id (foreign key to companies.id)
   • role (defaults to user, can be admin)

3. todos

   • id (primary key)
   • title
   • description
   • completed (boolean)
   • company_id (tenant isolation)
   • user_id (owner link)
   • created_at timestamp

Sample data + user seeding

• The creator adds:
  • two companies (Company A, Company B)
  • three users:
    • two users under Company A
    • one admin under Company A
    • another user under Company B to demonstrate separation
• Notes that user IDs from Supabase Auth (uid) are inserted into the users table to support joining.

---

Row Level Security (RLS) and policies (server-enforced)

RLS enabling

• Row Level Security is turned on for the todos table.
• After enabling RLS, the data becomes inaccessible until policies are defined.

Four policies for the todos table

The tutorial creates four policies corresponding to:

• SELECT (read visibility)
• INSERT (create to-dos)
• UPDATE (update to-dos)
• DELETE (delete to-dos)

Core access logic (multi-tenant isolation)

Each policy checks:

• Retrieve the requesting authenticated user id
• Look up that user in the users table
• Enforce visibility/mutation only when:
  • the request’s user and the target todos rows match the same company_id

Role-based logic (admin vs. user)

• For UPDATE and DELETE, the policy includes an OR condition:
  • regular users can modify their own to-dos (matched via user_id)
  • admins can modify other to-dos within the same company/tenant
• UPDATE policies also include a WITH CHECK-style constraint to ensure writes still comply with the policy.

---

Testing with a prebuilt FlutterFlow sample (“FlutterFlow app”)

A sample front-end app is provided (prebuilt) and cloned by the viewer. The app demonstrates the policies in action.

Supabase integration steps in FlutterFlow

• Retrieve:
  • Project URL
  • Anonymous public key
• Configure schema/API access in FlutterFlow (the video mentions disabling “Supabase V1” and using V2-oriented integration).

How login works (important for RLS)

Because users already exist in Supabase, the app:

1. signs in
2. queries the users table using the authenticated user id
3. stores the resulting company_id, role, and other user fields in App State

UI behavior and visibility depend on the stored role/user context.

---

CRUD functionality in the UI

The app implements the classic actions:

• Read: loads to-dos for display (filtering by completion status)
• Create: inserts a new to-do and sets:
  • company_id from app state
  • user_id from the authenticated user
• Update: marks to-dos as completed (refreshes list afterwards)
• Delete: deletes selected to-do rows, then refreshes

---

UI conditional visibility vs real security

• The UI hides certain icons/buttons based on:
  • role (admin)
  • whether the to-do belongs to the current user (user_id)
• The video explicitly demonstrates that even if UI hiding is removed, unauthorized operations still fail because RLS policies block access server-side.
• This proves the protection is not “just front-end”.

---

Demonstration outcomes (end-to-end)

In Supabase Test Mode + the front-end app:

• A regular user:
  • can create/update/delete only within the allowed scope
  • cannot manipulate other users’ to-dos in the same dataset
• An admin:
  • can see the tenant’s records
  • can update/delete more than regular users (per policy)
• Users from different companies:
  • see separate/empty results for other tenants
  • cannot manipulate other tenant data

---

Key takeaway emphasized

• Row Level Security + server-side policies are essential.
• The front-end (FlutterFlow) can improve UX (conditional visibility), but it must not be relied upon for security.

---

Main speakers / sources

• Speaker: Steve (“Digital Pro” / “Flood oflow Ambassador for Europe”; mentions Digital Pros and No Code Academy)
• Sources used in the demo: Supabase (Auth, database tables, RLS policies) and FlutterFlow (front-end CRUD + UI role-based visibility)