RiverSync

Portal platform — prototypes and specifications

One shell, one design system, six federated web apps behind a single RiverSync ID. This page is the gateway to the whole design: the working prototypes, the product requirements (PRD set) and per-app requirements (APP set), the domain contexts (DDD set), the data model (ERD set), the data workflows (DWF set) and the process workflows (PWF set). The shared UX (sidebar, top bar, product switcher, tables, forms, badges) is reusable across all six — exactly what the Blazor implementation will mirror. Account and Field are prototyped first; the others reuse the same shell.

The six apps

account.riversync.comPrototype

Authentication, federation and tenant management for everyone. Sign-in → workspace picker, org profile, users & roles, partner/tenant invitations, billing & invoices, audit.

Sign in flow Organization Users Roles Partners Billing Invoices Sites Departments Audit log
Portaldevice monitoringportal.riversync.comPrototype

Customer device monitoring — fleet dashboard, devices, the live multi-stack device detail, alerts & alarms, maintenance and tickets (carrying the support & partner conversations) across every Frigo · Koelkast · Nevera unit. Clickable end-to-end with a prototype role switch.

Portal app Device telemetry (standalone)
Partnersresellers & distributorspartner.riversync.comPrototype

Subtype-specialized: a reseller registers deals and services the devices it covers; a distributor watches its resellers' funnel and supplies the channel. Switch subtype with the Tweaks "Partner type" toggle.

Overview Deals (reseller) Funnel (distributor) Resellers Distribution agreements Workload Covered devices Renewals Tier program
PipelineCRM & salespipeline.riversync.comPrototype

RiverSync sales — the CRM front of the funnel: a unified communications inbox centralizing web form, email, LINE, Instagram, Facebook and LinkedIn into one queue tied to each relationship, a centralized contact graph with relationship hierarchies and a blended activity timeline, the leads inbox across six sources, opportunities with comparable variants, and the deal funnel board. RiverSync-only (sales · admin). Realizes SPEC-APP-PIP (PIP-9…14) / master SAL-1…8.

Communications inbox Leads inbox Contacts Contact graph & timeline Opportunities Variant compare Deal funnel
AdminRiverSync consoleadmin.riversync.comPlanned

RiverSync oversight — tenants, provisioning, customer & partner support, maintenance operations, platform health.

Fieldon-site servicefield.riversync.comPrototype

RiverSync field engineers, on site: today's dispatch board, device check-in, preventive-maintenance runbooks, on-site incident resolution, parts, photo evidence and customer sign-off. Mobile & tablet first, offline-capable. RiverSync-only (engineer role).

Open the mobile app

Specifications — the documents behind the prototypes

Product requirementsSPEC-PRDLiving docs

The platform-wide model — tenancy, identity, authorization, partner agreements. The master defines the scope; the Federation spec consolidates identity, roles & access across all six apps, Maintenance defines the per-device agreement product, Sales defines the contact-graph-to-deal funnel, and Products defines the catalog & telemetry-schema taxonomy. On conflict the platform wins.

Master Federation Maintenance Sales Products
App requirementsSPEC-APPLiving docs

One requirement document per app, each inheriting the platform. Account · Portal · Partners · Pipeline · Admin · Field.

Master Account Portal Partners Pipeline Admin Field
Entity Relationship DiagramSPEC-ERD set · PostgresLiving docs

The structural mirror of the PRDs: master holds the domain map, DM integrity conditions and requirement traceability; one drill-down per app. All diagrams render from one central catalog.

Master Account Portal Products Partners Pipeline Admin Field
Domain-Driven DesignSPEC-DDD set · domain contextLiving docs

The domain context map: the bounded contexts that make up the platform and which app each one surfaces to. Services own the ERD without overlap, app BFFs sit behind one API gateway, with a full endpoint catalog and the event backbone. Master holds the context map and SVC rules; one drill-down per domain.

Master Federation Devices Maintenance Support Sales Billing Audit Field service
Data workflowsSPEC-DWF set · lifecycleLiving docs

The create / update / retire / archive lifecycle of every entity as a state machine — the states it moves through and, for each transition, who acts and which event, rule and process drive it. Master holds the lifecycle map and the DWF rules; one drill-down per bounded context.

Master Federation Devices Maintenance Support Field service Sales Billing Audit
Process workflowsSPEC-PWF set · behaviourLiving docs

The behavioural reading: fifteen business processes drawn as swimlanes over the model — who acts, in what order, and which event carries each hand-off. Every step traces to a requirement and rides a domain event; all render from one central catalog. Now organized into sub-hierarchies — Onboarding, Federation and Service operations — each a folder with its own overview manual. Master holds the process landscape, the actor model and the WF rules.

Master ▸ Onboarding overview Customer onboarding Partner onboarding Capability & enrollment ▸ Federation overview Sign-in Access Roles Permissions Sales Device classification Partner channel Reseller tier progression Reseller→distributor ▸ Service operations overview Maintenance Incidents Field visit Billing
Design specsSPEC-UX set · build-ready UILiving docs

Build-ready UI/UX specifications — layout grids, every panel and state, the data each surface renders, realtime contracts and full design-system mapping, written so an implementer needs no further decisions. First issue: the Pipeline unified communications inbox.

Communications (Pipeline)

Assumptions & decisions — tell me where I'm wrong

Tenant model
  • Three tenant types: riversync (RiverSync users), customer, partner — one org can hold partner + customer roles at once (see Partners, and the sign-in workspace picker).
  • The product switcher is membership-gated: customers see Account · Portal; partner members also see Partner; RiverSync users see Pipeline · Admin, and engineers also see Field (field.riversync.com, mobile/tablet on-site). Toggle this via Tweaks → "Signed in as" (Customer · Partner · RiverSync). As a partner, "Partner type" picks the org — Nera (reseller · Gold) or MegaWarehouse (distributor · Platinum) — and "Role" picks which member of the signed-in tenant you are (each tenant has its own role set).
Demo data
  • Customer tenant: Sanyodenki (Thailand) (cooling & servo manufacturer) — frigo / koelkast units at plants, warehouses and sales offices across four Thai regions.
  • Partner tenants: Nera (Thailand) — Gold tier, also a customer · Huawei (Thailand) — Authorized tier (invitation pending).
  • Per-user application access: every member holds a role per app (see User Detail → Application access, the Users “Apps” column, and the per-app matrix in Roles).
  • Identity providers: Google · Microsoft · LinkedIn · email & password. THB invoicing; org SSO via Microsoft Entra ID (matches your Azure AAD setup).
Design system
  • Everything runs on RiverSync DS v2 unchanged — tokens, shell, icons, rs-* kit. Light/dark + density work everywhere.
  • Mandatory: every app reference uses the canonical DS badges — both types: the App pill (rs-portalbadge, top bar · switcher · pickers) and the compact surface pill (rs-adminpill family, dense tables & inline references). One domain hue per portal; rule recorded in CLAUDE.md.
  • Proposed v2 additions for the 5-app story: 6-tile membership-gated launcher, "Your tenants" switcher in the profile menu, tenant-invitation pattern, sign-in workspace picker.
Next steps
  • Review Account; mark up anything to change.
  • Then: Portal (customer monitoring) on the same shell, followed by Partner — its scoped device view reuses Portal's screens with delegated-access framing.
  • Pipeline (kanban funnel, quotes) and Admin close the set.