---
title: "Applicant Dashboard Summary View"
slug: applicant-dashboard-summary
section: Applicant Journey
status: stable
description: "Specification and documentation for the mini-dashboard and profile summary view on the applicant detail page"
last-updated: 2026-10-07
---

# Applicant Dashboard Summary View

Specification and documentation for the mini-dashboard and profile summary view on the applicant detail page

## Overview

The Applicant Dashboard Summary View is the at-a-glance status panel displayed at the top of every applicant detail page in the Globus Command Center. It aggregates the most operationally relevant information about an applicant's current state — journey position, readiness, blockers, and document status — into a compact, scannable layout. It is composed of two main components: the Profile Summary Panel and the Snapshot Cards Grid.

## Component Architecture

| Component | File | Purpose |
| --- | --- | --- |
| Applicant Summary briefing | applicant-profile/applicant-summary-briefing.tsx | Renders the structured briefing derived in shared/applicantProfileSummary.briefing.ts |
| Applicant workspace | applicant-profile/applicant-workspace.tsx | Renders the applicant profile workspace and mounts the briefing; consumes the ApplicantProfileSummary whose hero and snapshot cards are derived in shared/applicantProfileSummary.cards.ts |

## Data Sources

The summary view is assembled from four API endpoints, all scoped to the authenticated staff user's permissions:

| Endpoint | Data Provided |
| --- | --- |
| /api/applications/:id/journey-position | Current phase, stage, and journey position |
| /api/applications/:id/local-step-progress | Portal step completion percentages and missing fields |
| /api/applications/:id/eligibility-summary | Readiness state, active blockers, and rule outcomes |
| /api/documents/by-application/:applicationId | Document submission status (passport, DS-2019, etc.) |

## Displayed Fields

| Field | Source | Notes |
| --- | --- | --- |
| Journey Position | progress endpoint | Phase name and stage label |
| Readiness State | eligibility-summary endpoint | Colour-coded chip: green (on_track), red (blocked), yellow (paused), blue (addressed) |
| Active Blockers | eligibility-summary endpoint | List of failing rule names with applicant-facing messages |
| Missing Fields | local-step-progress endpoint | Incomplete portal steps with percentage completion |
| Passport Status | documents endpoint | Submitted / Approved / Expired / Missing |
| Program Dates | progress endpoint | Start and end dates; days until program start |

## Relationship to Queue Membership

The Snapshot Cards Grid also surfaces the applicant's current queue membership. Each queue the applicant belongs to is shown as a compact card with the queue name, entry reason, and time in queue. This is derived from the compliance_review_queue_items table and is consistent with the applicant's position in the staff-facing queue views. For the full queue architecture, see Applicant Processing Model .

> **Real-Time Updates**
>
> The summary view refreshes automatically when the applicant's readiness state changes or a new queue entry is created. Staff do not need to reload the page to see updated status.

## Summary Derivation Modules (Sep 2026)

Shipped Sep 14 2026 (Globus commit `bc6ceceac`, "Decompose Applicant Summary derivation"). The logic that turns the four data sources above into the summary was split out of one large shared module into two purpose-specific shared modules that both the applicant workspace and the **Next Best Action** component consume:

| Module | Owns |
| --- | --- |
| `shared/applicantProfileSummary.briefing.ts` | The structured Applicant Summary briefing — headline and one-sentence overview, processing-area chips, attention items, consolidated readiness blockers, prioritized recommended actions, and the summary-generation timestamp (see "Structured briefing" below). |
| `shared/applicantProfileSummary.cards.ts` | The hero and snapshot-card derivations — stage, readiness, compliance, placement, Market Ready, SEVIS and queue cards, plus the progress milestones. |
| `shared/applicantProfileSummary.logic.ts` | Thin composition layer that re-exports the two modules above. |

When the Market Ready gate carries `nativeGateProjections`, the Market Ready card is derived from them: the label is "Ready" when `nativeStatus` is `ready`, "Not Ready" when it is `blocked`, and "Awaiting" otherwise. The card's secondary text is "Retained market.exposure observations", and the projections are passed through on the card status.

On the Placement card, a stale terminal track is not proof of a current commitment; the current-placement evidence supplied by the profile context (`inputs.hasConfirmedPlacement`) is what may assert Hired.

On the SEVIS card, when `inputs.sevisReadiness?.ready` is set, the label is "Ready with override" if `inputs.sevisReadiness.overridden` is set and "Ready for SEVIS" otherwise. The card's secondary text is "Prerequisites met; batch checks still apply".

Because the derivation is shared code, staff UI and the next-best-action recommendation read the *same* derived summary and cannot disagree. No change to the displayed field contract in the table above was verified for this window; treat the refactor as a maintainability change, and the field table as still authoritative. The Command Center's freshness bar (see [Operations Command Center](/docs/operations-command-center)) was also extracted from the Applicant Summary briefing's header in the same window.

### Structured briefing

The Applicant Summary briefing is a compact, deterministic operational briefing (PR #2369, "Structure Applicant Summary briefing") that replaced the earlier paragraph-style summary. `buildApplicantProfileBriefing` returns:

| Part | Behavior |
| --- | --- |
| Headline / overview | Headline is `{first name}: {operational position}`. The overview is one sentence: the operational position (and stage) plus, in priority order, the count of outstanding evaluated blockers, else the count of areas needing staff attention, else "no active attention item is recorded" (when readiness is ready), else the current readiness label. If the operational position is unavailable it says so rather than guessing. |
| Processing areas | One chip per *applicable* processing track (applicability from application type and the program's applicable tracks; state from the journey track fields, status complete / in progress / not started), plus a "Visa / SEVIS" chip. If the journey track read is unavailable, the chips are suppressed rather than shown as fabricated "not started" states. |
| Attention items | Only non-zero items: compliance failures (critical), documents awaiting review, incomplete required workflow steps, and active queues (warnings). Each carries a count and a target tab. |
| Blockers | Consolidated and de-duplicated across Market Ready blockers and SEVIS gate blockers (matched on normalized rule identity, with gate names merged), linking to the Compliance tab. |
| Recommended actions | At most 3, in priority order: failed compliance (critical), documents awaiting review, expiring or expired documents (within 90 days; critical at 30 days or expired), missing required steps, queue SLA breaches. Each has a CTA label and a permission-aware target tab. |
| Timestamp | `generatedAt` / `lastUpdatedAt` come from an explicit summary-generation timestamp supplied by the caller (`inputs.summaryGeneratedAt`); the briefing does not invent one. |

When the briefing picks the first failed compliance check for the `compliance-failed` recommended action and for the compliance-failure attention item, it skips failed checks that are awaiting data and failed checks that `isNonBlockingReviewFailure` identifies as non-blocking review failures.