---
title: "Data Flows"
slug: data-flows
section: Governance & Operations
status: stable
description: "The end-to-end data journey — from first lead capture through SEVIS submission and on-program operations"
last-updated: 2026-10-07
---

# Data Flows

The end-to-end data journey — from first lead capture through SEVIS submission and on-program operations

> **One Journey, One Direction**
>
> Data flows through the ecosystem in a single direction: portals write to Globus, Globus pushes to government and automation systems. Globus is the only system of record. This page traces that journey end-to-end so each handoff is described once, in context.

> **Two data concepts move through these phases**
>
> Throughout every phase below, Globus distinguishes applicant data (identity, biographical — follows the person across attempts) from application data (one attempt at one program in one season). The split is documented canonically in Applicant Data vs Application Data — including the field-level rule of thumb and the Partner Visibility Matrix that governs what each portal sees.

## End-to-End Overview

Every applicant’s data passes through seven phases. At each phase, a different system takes the lead — but Globus remains the authoritative record throughout.

## Phase 1 — Lead Capture

Applicants first appear as leads in HubSpot, captured through marketing pages, ads, or partner referral links. HubSpot owns pre-qualification data at this stage — contact info, program interest, eligibility pre-screen, and source/campaign attribution.

At conversion, HubSpot hands the lead off, through an n8n workflow, to the Globus onboarding provision endpoint (pre-qualified data and contact info), which creates the applicant, application and portal invite; the Applicant Portal only onboards against that record. From this point forward, HubSpot is no longer the system of record for the applicant.

## Phase 2 — Entry & Account Creation

Whether an applicant enters directly (via HubSpot) or is recruited by a partner, the same outcome occurs: Globus provisions the applicant and application with recruitment attribution (Partner ID, Brand, Program, Season) via the onboarding provision endpoint, and a Keycloak identity is created when the applicant redeems their invite. The portal is stateless — the application record lives in Globus, never in a portal database.

Attribution is locked at account creation and cannot be modified directly; it can only be changed through the audited reassignAttribution service (POST /api/admin/partners/applicants/:applicantId/reassign-attribution, which takes a reason). For the full entry mechanics, partner invite trigger, and attribution rules, see Direct vs Partner Entry.

## Phase 3 — Application & Compliance

The applicant completes their application through the Applicant Portal’s workflow engine. Data flows from the portal into Globus for validation, rules checking, and compliance enforcement.

What Globus Does With This Data

Validates against Rules Engine (Season override > Program default) / Runs eligibility checks and blocks unsafe transitions / Stores the canonical application record / Tracks status progression through workflow states / Triggers automation events via the Event Outbox
Partners can view stage progression for their own applicants but cannot edit compliance fields or override rules. For portal capability boundaries, see Portal Functional Boundaries.

## Phase 4 — Job Orders & Placement

Once an applicant is eligible for placement, the Host Portal and Partner Portal interact with Globus to match applicants to positions. Hosts create job orders (position descriptions with structured matching requirements, wage, and SEVIS classification); Globus reviews and approves them, activating capacity; partners view and reserve positions on approved job orders (time-bound holds that expire or convert to confirmed placements). All actions are audit-logged, season-aware, and permission-driven.

For the full Job Order + Reservation sequence, see Ecosystem Model.

## Phase 5 — SEVIS & Government

Globus is the only system that communicates with SEVIS. No portal, partner, or automation layer can directly interact with government systems. All SEVIS data submissions originate from Globus with sponsor-verified data.

> **Compliance Critical**
>
> SEVIS data submissions are legally binding. Only Globus — as the system of record and the designated sponsor authority — has the right to push data to SEVIS. This is not a technical choice; it is a regulatory requirement.

What Triggers a SEVIS Submission?

Applicant reaches SEVIS-eligible status in the workflow engine / Placement is confirmed and all compliance gates are passed / Program status changes (arrival, early termination, program extension, completion) / Sponsor staff initiates a manual amendment (audit-logged)
## Phase 6 — On-Program & Automation

Once a participant is active on-program, ongoing data flows are driven by check-ins, evaluations, and automated workflows. The n8n automation layer reads from Globus state changes and triggers side effects — it never writes back as an authority.

On-Program Data Sources

> **Automation Owns Nothing**
>
> n8n is a reaction layer. It reads events from Globus and triggers notifications, reports, and integrations. It never modifies authoritative data. For the full automation architecture, see n8n Automation Layer.

## Phase 7 — Closeout & Archival

When a participant completes or is terminated from the program, Globus records the final status, updates SEVIS, and archives the application record. Partners see a final milestone status only (completed / early termination). No further edits are possible.

Closeout Actions

Program completion or early termination recorded in Globus / SEVIS status updated (completed / terminated / no-show) / Application archived — immutable from this point forward / Partner sees final status milestone (read-only) / Host portal access to participant data ends / Audit trail sealed for compliance and legal record
## Event Flow Architecture

Every domain action in Globus that produces a state change follows a standardized event flow from action through to external delivery and side effects.

Domain Action → n8n Webhook Flow

### Event Types

Events emitted by Globus are organized by domain. Each event type triggers specific automation workflows, notifications, and integration actions.

| Domain | Event Types |
| --- | --- |
| domain | |

_(row above is a template, repeated for each data row)_

### Scheduled Background Scanners

Five background scanners (document_expiry, reservation_countdown, participant_digest, host_document_expiry, host_document_expiring_soon) run periodically to detect time-sensitive conditions and emit events that trigger notifications and automation workflows via notificationJobs.ts; in addition, the Reservation Expiry Sweeper is a state-and-capacity writer registered in the Batch Jobs catalog and is included here so the full set of periodic background work is in one place.

Staff can run a scanner on demand: `POST /api/admin/notification-jobs/:jobName/run`, or `POST /api/admin/notification-jobs/run` with body `jobName`, both requiring `notifications.manage`, run one of the five scanners immediately and return `scannedCount`, `emittedCount`, `skippedDedupe`, `errors` and `durationMs`; `GET /api/admin/notification-jobs` lists the valid names. An unknown or missing job name returns `400` with `error.code` `INVALID_JOB_NAME` and the valid names in `error.details.availableJobs`.

| Scanner | Trigger | Events Emitted |
| --- | --- | --- |
| scanner | trigger | |

_(row above is a template, repeated for each data row)_

> **Scanner Architecture**
>
> The Document Expiry scanner is implemented in notificationJobs.ts; the Reservation Countdown and Participant Digest scanners are implemented in hostDigestJobs.ts; all are registered from notificationJobs.ts. They run as periodic background tasks, scanning for approaching deadlines and emitting events through the standard eventEmitter flow so scanner-generated notifications follow the same delivery path as real-time domain events. The Reservation Expiry Sweeper is a separate process that writes reservation status, capacity counters, and audit rows directly — it does not emit notification events. Full job spec: Batch Jobs → reservation-expiry-sweeper .

## Data Ownership Rules

Every system in the ecosystem has a clear ownership boundary. Data created in one system is synced — not duplicated — into Globus as the canonical record.

> **One Record, One Owner**
>
> No data exists in two systems as an “authoritative copy.” Portals create data; Globus validates and stores the canonical version. If a portal and Globus disagree, Globus wins. This is by design, not by convention.