CreatiSoul
Agency OS · Design
CreatiSoul Agency OS · Architecture

How the system is laid out — the screens you'll navigate, the data behind them, and the stack that runs it.

Three views of the same machine. First the app sitemap — every section in the left rail and what lives under it. Then the entity-relationship diagram — how Company, Deal, Engagement, Invoice and the rest connect. Finally the tech structure — a custom Next.js front end talking to a Payload backend over Postgres, with a loose link out to the production platform.

10
top-level app sections
6 ✓ / 6
entities built / planned
3 tiers
Next UI · Payload · Postgres
4 roles
owner · admin · member · viewer
1
App sitemap & navigation
Built Planned

The left rail of the custom Warm front end (CRM-1b), shown as a tree. Each top-level section is a destination; the chips under it are its sub-pages / views. Built means a Payload collection already backs it (shipped in CRM-1a); Planned means designed but not yet built. The rail on the left mirrors what a team member sees; the pane on the right expands each node.

What lives under each section
Routes shown are illustrative. Sub-pages tagged ● built are backed by a live collection; ● planned are next.
Dashboard/Planned
My day · tasks & follow-ups Pipeline snapshot Revenue & overdue
Pipeline/pipelineBuilt
Deal board (drag across stages) Switch pipeline · New Business / Renewals Deal detail · value, MRR, owner
Companies/companiesBuilt
List · filter by lifecycle stage Account detail · contacts, deals, timeline Billing & GSTIN tab Engagements tab
Contacts/contactsBuilt
List · search across people Contact detail · company, role, activity
Leads (inbox)/leadsPlanned
Inbound inbox · website forms + manual Dedup & merge against existing Convert → Company + Deal
Engagements / Projects/engagementsPlanned
By service line · Website / Social / Meta / Google / SEO Engagement detail · deliverables & tasks Task board / list ↗ Open in platform (ads / social)
Invoices/invoicesPlanned
List · status & ageing (overdue) Invoice editor · GST / LUT lines Payments & reconciliation Reminders / dunning
Subscriptions/subscriptionsPlanned
Retainers · MRR per account Billing cycle & auto-invoice
Reports/reportsPlanned
Sales · win rate, pipeline value Revenue · MRR, collections, ageing Delivery health · tasks & overdue work
Settings/settingsBuilt
Team & roles (owner/admin/member/viewer) Pipelines & stages Service lines & tax / currency defaults Payment gateways · Razorpay / PayPal Platform link · app.csoul.cloud
2
Entity-relationship diagram
Built Planned

Company sits at the centre — the account everything hangs off. Lines show relationships with cardinality (1 → many). Solid lines are inside the CRM; the dashed plum line is the loose link out to the platform. Built entities already exist as Payload collections; planned ones are designed for later phases.

Contact Built
Person at a company · name, role, email, phone
N per Company
Activity Built
Timeline entry · type note / call / email / meeting / system
N on Company / Contact / Deal
Company Built
The account. lifecycleStage, isCustomer, billing + GSTIN, currency, platform-client link.
prospect → lead → qualified → customer → churned
Deal Built
status open/won/lost · oneOffValue/mrr · serviceLine · owner
N per Company
1 pipeline → N stages
Engagement Planned
Per service line · Website / Social / Meta / Google / SEO
N per Company
Invoice Planned
GST (CGST/SGST or IGST) / LUT export · multi-currency
N per Company
Subscription Planned
Recurring retainer · carries MRR · auto-generates Invoices each cycle
N per Company
Platform engine Live · external
app.csoul.cloud — campaigns → briefs → AI video / image. Meta-ads & social engagements link here instead of duplicating it.
loose link · brief out, creative back
CRM relationship (inside Payload) loose link out to platform N per X cardinality (1 → many)
3
Tech structure
single-tenant · RBAC

Three tiers, one database. The team mostly lives in the custom Next.js Warm front end; it reads and writes through Payload's access-controlled Local API (so role checks run server-side, not in the browser), and Payload persists everything to Postgres. Payload's own admin UI stays available for back-office edits. A single loose link reaches out to the production platform.

Presentation
Custom Next.js UI
The "Warm" front end · CRM-1b
  • Team's day-to-day app: boards, accounts, timeline
  • Server components call the Payload Local API directly
  • Renders only what the signed-in role may see
Payload Admin
Back-office · auto-generated
  • Built-in CMS-style admin for power edits & data fixes
  • Same collections, same access control
↓ both sit on the same backend
Application / API
Payload 3 backend
Headless · collections + hooks
  • Collections: Company, Contact, Deal, Pipeline, Stage, Activity (+ planned)
  • Access control enforces RBAC on every read/write
  • Hooks run automations — e.g. deal-won → customer
  • Exposes Local API (in-process), plus REST / GraphQL
↓ persists via Payload's Postgres adapter
Data
Postgres
Single source of truth
  • All CRM data in one relational database
  • Schema managed by Payload migrations
  • Separate from the platform's own data store
— own DB, distinct from the platform —

Roles & access (RBAC)

Owner
Full control + billing & org settings
Admin
Manage all records & team, no org-level danger
Member
Day-to-day: own deals, tasks, activities
Viewer
Read-only across the workspace

Enforced in Payload access functions — the Next UI and Admin both inherit the same rules. per-role field scope: confirm

Loose link to the platform

A Company stores a platform-client reference. An ads / social Engagement hands a brief to app.csoul.cloud and pulls finished creative back — no creative data is duplicated in the CRM.

Two separate apps, two databases, joined only at this link. link mechanism (deep-link vs API): confirm

Single-tenant by design: this CRM runs CreatiSoul's own agency, for internal users only — no client logins, no per-client data isolation to manage. That keeps the model simple: one workspace, one team, four roles.

Reading the architecture

This is the Architecture page — the app's information architecture, data model and stack. For the business context behind it see the Overview; for the flow a customer travels see Journey; for every stage of the boards see Pipelines; for operating procedures see SOPs; for the assist layer see AI.

Only the Built entities (Company / Contact / Deal / Pipeline / Stage / Activity, with the deal-won automation) exist today. Everything marked PROPOSED — confirm is an inference about your process or wiring and needs your sign-off before we build it.