The Platform — Multi-Tenant ERP

Business context

The Platform brings employee, management, HR, and training operations into shared workspaces. Its business modules connect day-to-day administration with approvals, records, and public-facing integrations such as the Hamad Center website.

Platform capabilities

These capabilities describe the shared product; my contribution is outlined above.

Employees & departments

Employee profiles, invitations and registration, account lifecycle, reporting relationships, emergency contacts, documents, and employee reporting/import support. Departments group employees and projects; manager/direct-report relationships are a separate concern.

Leave & contracts

Requests, balances, types and policies, calendars and holidays, manager/HR review, administrative decisions, history, backdated leave, and permission-controlled exports. Contract dates and historical cycles support eligible carryover during changes and expiry reminders.

Projects & performance reviews

Project ownership, departments, statuses, priorities, milestones, and progress updates. Quarterly reviews connect self-reflection, manager assessment, work and growth evaluation, acknowledgement, and follow-up goals.

Training operations

Courses, instructors, categories and levels, schedules, applications, repeated intakes, capacity, payment-related workflows, applicant administration, and confirmation communications.

News publishing

Original rich-text articles and externally sourced posts from URLs or PDFs, with images, tags, drafts, publishing, updates, and unpublishing.

Shared workspace services

Workspace context, permissions, notifications, preferences, audit/reporting capabilities, and English/Arabic presentation with RTL support.

Architecture & business rules

The reviewed architecture is a feature-organized modular monolith: one Next.js application containing protected business modules and administration. Feature code is colocated with shared utilities, while query functions and mutation actions separate reading from changing data.

React provides forms, screens, tables, and interactions. Next.js server-side code coordinates requests, authorization, and business operations. Supabase supplies services, while PostgreSQL functions, constraints, triggers, and transactions enforce additional business rules. Modules can use different access patterns; there is no universal custom REST layer for all Supabase access.

External-service adapters connect payment providers and email; scheduled work continues workflows beyond a browser request. The conceptual flow below is a guide to the layers, not a production topology.

Tenancy & role-based permissions

Multiple workspaces share infrastructure, with tenant context on tenant-owned records. Resolving a workspace, authenticating a user, identifying an employee, confirming membership, and checking permission are distinct operations.

Tenant-scoped queries, role-based access control, and PostgreSQL Row-Level Security work at different layers. Roles determine permitted operations; RLS applies row-access rules in the database rather than merely hiding rows in the interface. Privileged service-role operations require their own authorization safeguards.

Supabase integrations

Auth, PostgreSQL/RPC & RLS

Authentication and database access work alongside SQL function calls and row-access policies. Transactional leave decisions coordinate request state, balances, and history.

Storage, Realtime & Edge Functions

Storage supports file assets, Realtime integrates in-app notifications, and Edge Functions support email delivery. Integration behavior depends on environment configuration and deployed functions.

Scheduled workflows with pg_cron

The reviewed source defines scheduled work for payment holds, course lifecycle transitions, contract reminders, and delivery retries. These describe implementation patterns, not a verification of current production schedules.

Work beyond the browser request

Payment-hold reconciliation

A scheduled database task uses pg_net to initiate an HTTP call so application code can verify payment outcomes before releasing expired course-seat holds.

Course lifecycle

A scheduled sweep archives started courses and applications in the current intake together, keeping the lifecycle aligned.

Contract reminders

A reminder workflow finds eligible contracts ending within seven days. A separate retry workflow handles eligible pending deliveries with durable duplicate prevention and bounded attempts.

Event-driven business rules

Contract rollover occurs when contract changes are saved. Employee balance initialization can be trigger-driven; these are separate from scheduled sweeps.

Engineering considerations

Consistent business state

Transactions coordinate leave decisions; idempotency and durable delivery records prevent duplicate effects when operations are retried.

Course payments

Course → iteration/intake → application → payment relationships keep repeated deliveries distinct. A gateway interface/factory supports MyFatoorah and Tap implementations. Webhooks signal a need to verify provider outcomes rather than acting as blindly trusted confirmations.

Connected workflows

Tenant-aware Jira connection and synchronization support links project workflows to external tooling. Internal administration also supplies functionality integrated into the Hamad Center website.