Case 02
BoardFlow
Complex tenancy. Permissioned workflows. Fortnox-connected operations.
- Next.js
- TypeScript
- Supabase
- Postgres
- Fortnox API
Overview
BoardFlow is a production workflow system for consultants managing multiple client workspaces. The technically interesting part is not visual polish but the underlying data model: one consultant can belong to several organizations, each organization can manage many clients, consultants can be assigned to specific clients with separate roles, and end users only see the submissions tied to their client. Most of the application is built around making those relationships safe and usable across dashboards, API routes, and server actions without leaking data across tenants.
Contribution: Full-stack design and implementation — data model, Supabase auth/RLS flows, dashboard architecture, template system, and Fortnox integration
Agent surface
- Account-context switching backed by Supabase auth metadata, so one authenticated user can operate in different organization or client scopes
- Normalized relationship model across organizations, org consultants, client consultants, client users, templates, submissions, answers, and accounting mappings
- Fortnox OAuth integration with organization-level token storage, customer import, and per-client write approval before accounting actions are allowed
Supabase structure: real tenancy
The core problem in BoardFlow is relationship modeling. Access is derived from a chain of tables rather than a flat role enum: consultants belong to organizations through `org_consultants`, can then be assigned to individual clients through `client_consultants`, while client-side users are tracked separately in `client_users`. That structure lets the app support consultants working across several organizations and clients without collapsing everything into one ambiguous account type.
- Organization membership and client assignment are separate relationships with separate roles
- The frontend loads visible organizations, clients, and the active account from Supabase-backed context instead of hardcoding tenant assumptions
- Server actions and API routes rely on RLS-friendly queries and RPCs like `create_organization_with_context`, `create_client_with_context`, and `add_client_consultant_safe`
Client workflows sit on top of that model
Templates, submissions, answers, and accounting rules all inherit the same tenant boundaries. Consultants can assign templates to clients, create and review submissions, and inspect answer data with nested table rows and approval states. For table-based questions, accounting instructions are stored separately in `template_question_accounting`, which keeps the schema cleaner while still letting accounting behavior be attached to specific workflow steps.
- Client-template assignment is modeled explicitly through join tables rather than duplicating template records
- Submission answers support both simple values and hierarchical row data for more complex reporting flows
- Approval and feedback flows are persisted in the database so consultants and client users see different states of the same submission lifecycle
Fortnox integration is permissioned by design
Fortnox is integrated at the organization level through OAuth, with company metadata and customer lists pulled in during connection and stored in `org_integrations`. Imported customers can be turned into BoardFlow clients, but accounting writes are still gated per client through `can_write` and `fortnox_write_approved_at`. That extra permission layer matters because connecting an accounting system is easy; making sure the wrong client cannot be written to is the real engineering work.
- OAuth callback exchanges the code, fetches company info and customers, and stores tokens server-side
- Organizations can bulk-import Fortnox customers as clients without automatically enabling write access
- Accounting mappings live on template questions so actions like approval and payment events can later be tied to concrete bookkeeping behavior
Explore the other cases: Trappan.