---
title: "Portal Overview"
slug: portal-boundaries
section: Portals
status: stable
description: "The ecosystem separates **authority** (the BackOffice Portal / Globus Hub) from the user experiences delivered through the Host and Participant portals."
last-updated: 2026-10-07
---

# Portal Overview

The ecosystem separates **authority** (the BackOffice Portal / Globus Hub) from the user experiences delivered through the Host and Participant portals. This page is the implementation map; feature-level contracts remain in the linked portal pages.

> **Code-verified baseline**
>
> The implementation notes below are verified against the `development` branches on 2026-07-23. They describe what the current code mounts and composes; they do not turn a code route into an operational or compliance policy. Policy and lifecycle decisions remain governed by the BackOffice Portal / Globus Hub. [1] [2]

## Portal Map

| Portal | Primary users | Current implementation boundary | Canonical follow-up |
| --- | --- | --- | --- |
| **BackOffice Portal (BOP / Globus Hub)** | Sponsor and operations staff | React staff application with an Express service, PostgreSQL/Drizzle persistence, RBAC-gated staff routes, background workers, and portal-facing integration routes. [1] [2] | [Globus Portal API Reference](/docs/globus-portal-api) |
| **Host Portal (HPP)** | Host-company and camp users | React/Vite client plus Express API. The client uses Auth0 role claims; the current `/api/v2` facades use JWT middleware that requires `read:hostcompanyportal:basic`. [3] [4] [5] | [Host Portal Governance](/docs/host-governance) and [Host Portal Endpoint Reference](/docs/host-portal-endpoints) |
| **Participant Portal (PPPToo)** | Applicants and participants | React 18 + Vite SPA plus a **stateless NestJS BFF** (`/api/v1`). No database, no migrations, no seeding, no scheduled tasks — every read and write is proxied to the Hub via `globus-sdk`. [6] [7] [8] | [PPPToo — Participant Portal v2](/docs/pppto-architecture) and [Endpoint Reference](/docs/applicant-portal-endpoints) |

## BackOffice Portal (BOP / Globus Hub)

BOP is the staff-facing operational control plane and the authoritative integration hub for the ecosystem. Its client route registry exposes staff workflows for applicants, document review, programs and seasons, SEVIS, queues and reporting, finance, host companies, partners, job orders, matching, placements, housing, workflow and form management, agreements, notifications, access control, and rules/compliance workspaces. [1]

The current service is not a thin administrative shell. Its startup composition includes request correlation and structured error handling, database migration/seeding outside production, RBAC-route coverage checks, and workers for events, notifications, agreement and reservation timing, SLAs, references, season lifecycle, webhooks, n8n integration, and rules evaluation. [2] BOP therefore owns operational coordination and sponsor-side decision surfaces; the external portals should present and submit information through their appropriate bounded interfaces rather than independently decide eligibility, compliance, governance, or placement state.

| BOP responsibility group | Current code evidence | Relationship to external portals |
| --- | --- | --- |
| Staff operations and governance | Applicant, document-review, program, rules/compliance, RBAC, integration, and administration routes are mounted in the staff client. [1] | Provides operational oversight and sponsor-side control. |
| Portal-facing integration | The Hub publishes dedicated `/api/portal`, `/api/integrations`, and `/api/partner` surfaces documented separately. [9] | Supplies the contract consumed by portal services; external portal UIs are not the authority for sponsor decisions. |
| Identity and authorization | The repository contains Entra, local-session/password, API-key, user-management, and access-revocation modules, plus an RBAC gate-coverage audit. [2] [10] | Do not describe BOP as using only one identity provider; use the specific authentication contract for the route or service being integrated. |
| Workflow and form composition | The current package manifest includes `@alliance-strategies/form-engine-portable`; the client mounts workflow, step, phase, operational-form, reference-template, and agreement surfaces. [1] [11] | The shared form engine is a component dependency, not a replacement for BOP’s workflow/authority layer. |

## Host Portal (HPP)

The Host Portal is the host-company and camp experience. Its current client routes cover the dashboard; applications or reservations; jobs and job orders; talent pool and participants; business and camp views; housing; contacts and addresses; company, arrival, offer, transportation/safety, cultural-activity, document, resource, notification, settings, job-offer, job-approval, activity, and administrator-user-management workflows. [3] Some job-oriented routes are intentionally redirected when the selected program is **Camp**, which is a current UI behavior rather than a generic lifecycle rule. [3]

HPP has an end-user authentication layer distinct from the service-to-service Host Proxy contract. The React client reads Auth0 namespaced role claims and protects ordinary surfaces with a user role, with user management requiring an administrator role. [3] Its Express JWT middleware validates Auth0-issued tokens and requires the `read:hostcompanyportal:basic` permission; the current identity and job-order v2 route modules explicitly apply that middleware. [4] [5] The Host Proxy API-key/header model remains the cross-service contract with the Hub, not a substitute description of browser-session authentication. [12]

| HPP capability area | Mounted client or API evidence | Authority boundary |
| --- | --- | --- |
| Host and camp administration | Company information, business, camp, contacts, addresses, profile, and user-management surfaces are mounted in the client. [3] | The Host Portal presents host data and requests changes; governance policies remain in the Hub. |
| Demand and placement work | Jobs, job orders, talent pool, reservations, participants, placements, offers, and approvals are represented by client routes and `/api/v2` facade domains. [3] [5] | The service mediates host work; placement and compliance authority are not delegated to the browser. |
| Operational information | Housing, arrivals, transportation/safety, cultural activities, documents, activities, resources, notifications, and settings are implemented as portal workflows. [3] [5] | The detailed lifecycle and document contracts remain in the Host Portal pages. |
| Backend composition | The Express server mounts documented `/api/v2` facade domains for dashboard, identity, reservations, participants, activity, talent pool, placements, hosts, profiles, users, notifications, positions, onboarding, job orders, and documents. [5] | Endpoint-level auth must be checked against the route module; do not reuse retired route or mock-service claims as the current reference. |

## Participant Portal (PPPToo)

`Alliance-Strategies/PPPToo` (`development`) is the source baseline for this page’s Participant Portal statements. The predecessor, `ParticipantPortalPrototype`, is **archived and read-only** — none of its Express service, Drizzle tooling, Redis dependency, migration/seeding paths, scheduled-tasks manager, or `BFF_TARGET` proxy applies to the live portal. [6] [7]

PPPToo is an npm-workspaces monorepo with two application workspaces (plus an `e2e/` test workspace): a React 18 + Vite SPA (`client/`) and a **stateless NestJS 11 BFF** (`server/`). The BFF has no database, no ORM, no migrations, no seeding and no background workers; every controller resolves against the Globus Hub through `@alliance-strategies/globus-sdk`, forwarding the applicant's Bearer as `X-Portal-Access-Token`. [6] [7]

The client mounts a flat set of nine authenticated pages — `/dashboard`, `/application`, `/documents`, `/check-ins`, `/profile`, `/settings`, `/travel`, `/notifications`, `/arrival-information` — behind a `RequireAuth` guard, plus three public entry routes (`/sign-in`, `/forgot-password`, `/onboarding`), a public referee route (`/reference/respond`), and three legal pages. [8]

> **PPPToo is a zero-persistence, two-workspace stateless build.**
>
> This is the inverse of the retired `ParticipantPortalPrototype` note that previously sat here. The BFF holds no local data; business authority lives in the Hub and the portal genuinely has no persistence tier of its own. [7]

| Participant capability area | Current code evidence | Authority boundary |
| --- | --- | --- |
| Participant experience | Nine authenticated pages plus public entry, referee, and legal routes. [8] | The portal guides and collects participant work; eligibility and governance decisions belong in the Hub. |
| Authentication and session flow | Bearer token in `sessionStorage` — **no cookies**. `RequireAuth` redirects to `/sign-in` when no token is present. Credentials are exchanged server-side against Keycloak by `POST /api/v1/auth/login`; a `passport-jwt` strategy validates request JWTs. `assertRealmInvariants()` fails the boot on Keycloak realm drift. [6] [8] | End-user session authentication must not be conflated with the Hub’s server-to-server API-key mechanisms. |
| Dynamic forms | The client pins `@alliance-strategies/form-engine-portable` to an exact version. Three routes (`POST /api/national-window/get`, `POST /api/national-window/list`, `POST /api/eligibility/calculate`) are excluded from the `api/v1` prefix because the compiled engine bundle calls those bare paths. [6] [7] | The form renderer is a delivery component; workflow definitions and enforcement remain centrally governed. |
| Documents and data operations | Documents stream through the BFF (`/applications/:id/documents*`, `/documents`, `/step-media/:mediaId/file`); `@google-cloud/storage` is a server dependency. [7] | Do not promise one universal direct-storage or signed-URL pattern without checking the current portal and Hub route contracts. |

## Document Management

Document handling spans the three portal experiences and the Hub, but the checked-in implementations are **not identical**. BOP mounts sponsor-side document review and administration; HPP mounts v2 company/application document facade domains; and PPPToo streams participant documents through its BFF to the Hub. [1] [5] [7] The shared rule is that portals should not independently make compliance or governance decisions from document status; implementation details such as upload, download, and storage adaptation must be taken from the portal-specific endpoint references. [9]

### Documentation Taxonomy

The categories below remain a useful cross-portal taxonomy. They are not a promise that every client displays the same category list or storage implementation.

| Category | Examples | Primary interaction context |
| --- | --- | --- |
| Identity | Passport, national ID, birth certificate | Participant intake and verification |
| Academic | Transcripts, diplomas, enrollment letters | Participant intake and eligibility review |
| Medical | Health certificate, vaccination records, insurance proof | Participant workflow and compliance review |
| Employment | Offer letter, job description, employer verification | Host/company and placement workflow |
| Compliance | Site-visit reports, housing inspections, safety certificates | Host/company operations and sponsor review |
| Agreement | Partner agreements, terms and conditions, NDAs | Partner/host and sponsor governance |
| Financial | Fee receipts, payment confirmations, refund documentation | Participant and sponsor finance workflow |
| Media | Profile photos, interview recordings, training videos | Participant and host experiences where enabled |

## Brand Theming Contract

A shared brand-theming contract remains the target integration model: portal implementations should obtain brand identity and presentation configuration through approved portal/Hub interfaces rather than create divergent sponsor-facing brand records. [9] PPPToo already follows it — `applyBrandTheme()` in `client/src/lib/brand.ts` writes CSS custom properties from the theme returned by `GET /api/v1/brands/:id/theme`, invoked from `usePortalContext`, `AuthBrand`, and `PublicShell`. There is no `BrandProvider`/`BrandStyleProvider` component pair. [8]

> **Implementation caution**
>
> This page defines the cross-portal contract, not a guarantee that every current branch exposes the same bootstrap response or has eliminated all legacy styling paths. Verify the exact route and returned schema in the relevant portal endpoint reference before building a consumer.

### Brand-Scope Resolution

Scope enforcement belongs to the Hub-side authority chain and staff RBAC model, while portal-specific UI behavior should use the context and permissions delivered through its own authenticated service boundary. BOP’s source has dedicated access-management surfaces and route-gate checks; HPP and PPPToo each implement their own user-session boundary. [1] [2] [3] [8]

## Boundary Principle

> **Portals present. BOP / Globus Hub decides.**
>
> A portal may render workflow guidance, collect submissions, manage its own client session, and adapt data for its audience. It should not become the final authority for eligibility, compliance, agreement status, placement governance, or sponsor operations. BOP owns the staff-side operational and integration authority; HPP and the Participant Portal supply scoped user experiences over that authority. [1] [2] [9]

## References

[1]: https://github.com/Alliance-Strategies/BackOfficePrototype/blob/development/client/src/App.tsx "BackOffice Portal development client route registry"
[2]: https://github.com/Alliance-Strategies/BackOfficePrototype/blob/development/server/index.ts "BackOffice Portal development server entry point"
[3]: https://github.com/Alliance-Strategies/HostPortalPrototype/blob/development/client/src/App.tsx "Host Portal development client route registry"
[4]: https://github.com/Alliance-Strategies/HostPortalPrototype/blob/development/server/middleware/jwt-auth.ts "Host Portal JWT middleware"
[5]: https://github.com/Alliance-Strategies/HostPortalPrototype/blob/development/server/routes-modular.ts "Host Portal modular v2 route registration"
[6]: https://github.com/Alliance-Strategies/PPPToo/blob/development/package.json "PPPToo root workspace manifest"
[7]: https://github.com/Alliance-Strategies/PPPToo/blob/development/server/src/main.ts "PPPToo BFF bootstrap"
[8]: https://github.com/Alliance-Strategies/PPPToo/blob/development/client/src/App.tsx "PPPToo client route registry and RequireAuth guard"
[9]: /docs/globus-portal-api "Globus Portal API Reference"
[10]: https://github.com/Alliance-Strategies/BackOfficePrototype/tree/development/server/auth "BackOffice Portal authentication modules"
[11]: /docs/form-engine-portable "Form Engine documentation"
[12]: /docs/integration-contract "Portal Integration Contract"