---
title: "Applicant Portal — Completion & Departure"
slug: applicant-portal-completion
section: Applicant Journey
status: draft
description: "The portal-side surface for AP-12 — what the applicant sees, does, and submits during program close."
last-updated: 2026-10-07
---

# Applicant Portal — Completion & Departure

The portal-side surface for AP-12 — what the applicant sees, does, and submits during program close.

> **Scope**
>
> This page is the applicant-portal-side expression of Phase 8. It documents the surface the applicant sees during closeout — the trigger, the four-step flow, the post-completion state, and the portal’s role relative to SEVIS closure. It does not redefine the ecosystem-level lifecycle (see Applicant Lifecycle — Phase 8 ), and it does not design the staff-side closeout workflow or the exit survey questions themselves.

> **Status check (verified 2026-07-04) — portal flow NOT built; Globus infra to reuse IS live**
>
> AP-12 is PENDING SCOPING in the PRD, and none of the portal endpoints this page reuses exist yet: PPPToo's check-ins controller is read-only (GETs for recurring current-season/season and templates — no submission POST, no checkin_type=final) and the portal has no travel or completion controller. Present the "reuses the monthly check-in / travel-request endpoints" claims below as proposed. The Globus side has real infrastructure the build will lean on: server/routes/checkins/monthlyCheckins.ts, checkins/templates.ts, checkins/sevisCheckins.ts, and the DS-2019/SEVIS routes (server/routes/ds2019.ts). One PRD reconciliation to settle at scoping: PRD AP-12B names Step 4 Close-Out Confirmation, while this page's Step 4 is Exit Survey / Program Evaluation. The program.completed trigger event and closeout_active flag remain unconfirmed against any Globus event catalog.

## Scoping Status

> **Asana scoping ticket filed for the Applicant Portal team**
>
> A scoping ticket has been filed in the AP-12 project on Asana in the canonical house format: Applicant Portal: AP-12 program completion & departure — PRD scoping pass . The ticket carries the architectural rule, the four-step flow, the post-completion state, and the Gherkin acceptance criteria the new PRD section must satisfy. The consolidated PRD update brief for the AP team lives at docs/applicant-portal-prd-update-brief.md.

## Purpose & Scope

AP-12 is the closeout surface inside the Applicant Portal. It exists so the applicant has a single, guided place to confirm their departure, file their final check-in, register return-travel details, and complete a program evaluation — without the staff team having to chase any of those four artefacts manually.

Everything on this page is portal behavior. Globus owns the underlying state machine, the SEVIS closure submission, and the program.completed event. The portal consumes those signals; it does not produce them.

In scope

- Trigger that activates the closeout surface in the portal
- Four applicant-facing steps and the data each collects
- What gets pushed to Globus per step (endpoint reuse, payload shape)
- Post-completion read-only archive view
- Portal’s role relative to SEVIS closure
Out of scope

- Designing the actual exit-survey questions
- Defining new Globus events — consumes whatever Globus emits today
- Staff-side closeout workflows and queues
- Re-engagement / alumni flows after completion
- SEVIS submission mechanics (see SEVIS & Government)
## Trigger — When the Surface Appears

The closeout surface is hidden until Globus tells the portal to show it. The portal does not compute “is this applicant near the end of their program” on its own — that decision belongs to Globus and is delivered as an event consumed by the portal.

| Aspect | Detail |
| --- | --- |
| Source | A Globus-emitted lifecycle event. Exact event name and payload TBD — to be confirmed against the Globus event catalog before implementation. Working assumption: an event tied to the program end date entering the configured closeout window (e.g., 14 days out). |
| Portal behavior on receive | The portal flips a closeout_active flag on the application view, surfaces a new “Program Completion” nav entry, and renders the four-step flow described below. |
| Idempotency | Re-receiving the same trigger event is a no-op. The portal does not reset already-submitted steps. |
| Deactivation | The closeout surface is replaced by the post-completion state when program.completed fires for the application. See Post-Completion Portal State. |

## In-Portal Completion Flow

The flow is rendered as four numbered steps. Steps unlock sequentially — the applicant cannot skip ahead — with the exception of Step 4 (exit survey), whose required-vs-optional status is currently a TBD (see Open Questions ). All four steps reuse existing Globus endpoints documented elsewhere; this page does not introduce new write surfaces.

## Post-Completion Portal State

When Globus fires program.completed for the application, the portal replaces the closeout surface with a read-only archive view. The applicant’s portal account remains active but the application itself is frozen.

Still accessible (read-only)

- Application summary (program, dates, host placement)
- Submitted documents and uploaded itinerary
- Check-in history including the final check-in
- Submitted exit-survey response (the applicant’s own answers)
- DS-2019 / SEVIS status as reported by Globus
No longer present

- The four-step closeout flow (replaced by a single “Program completed” banner)
- The Travel Request entry point for this application
- The Monthly Check-In entry point for this application
- Any “action required” nudges — the application is terminal
> **Application-scoped, not account-scoped**
>
> The post-completion state is scoped to the application — one attempt at one program in one season — per the canonical boundary on Applicant Data vs Application Data . The applicant’s account remains active. If the applicant later starts a new application (a separate attempt), that application begins fresh in Phase 1 and is unaffected by the completed application’s archived state.

## SEVIS Closure Interaction

> **The portal does not own SEVIS closure**
>
> SEVIS closure is owned by Globus and submitted to the government via the SEVIS service layer. The portal only reflects the SEVIS status that Globus reports. The portal never calls SEVIS, never waits on a SEVIS response, and never blocks an applicant action on SEVIS state.

- The applicant’s portal view shows the SEVIS status string verbatim from Globus (e.g., Active, Completed, Terminated) on the application summary card.
- The four closeout steps do not wait for SEVIS confirmation. The applicant can complete all four steps before Globus has submitted closure to SEVIS.
- If SEVIS closure fails on the Globus side, the portal continues to show the last known SEVIS status. Resolution is a staff-side concern, not a portal-side concern.
- For the actual SEVIS closure mechanics — reason codes, batch submission, certificate auth, J-2 cascade — see the dedicated reference page.
Cross-link: SEVIS & Government — Termination Processing .

## Open Questions / TBD

The following questions are unresolved as of this draft. Each one is logged here so future scoping has a single home and PRD authors do not need to re-derive them from scratch.

## Cross-References

- Applicant Lifecycle — Phase 8 (Completion) : the ecosystem-level definition of completion, including states (Completed, Early Termination, No Show), gate-out, and actors.
- Applicant Lifecycle — Program Completion Flow : the staff-side closeout view that this portal surface feeds into.
- SEVIS & Government — Termination Processing : the SEVIS closure mechanics this portal surface deliberately does not own.
- Applicant Lifecycle — Monthly Check-In System : the check-in pipeline that Step 2 (final check-in) reuses with checkin_type=final.
- Applicant Lifecycle — Travel Request Flow : the travel-request pipeline that Step 3 (return travel) reuses with travel_type=return.