---
title: Finalization and the submission package
description: How your documents and forms are mapped to government portal slots, how the submission package is generated, and what you confirm before it is sealed.
product: Lexpoint — Individuals
audience: People managing their own Canadian immigration
doc_type: guide
canonical_url: https://docs.lexpoint.io/individuals/cases/finalization/
app_routes: https://my.lexpoint.io/app/cases/[case]/members/[member]/applications/[application]?tab=package, https://my.lexpoint.io/app/cases/[case]?tab=finalization
requires: An application whose documents and forms are complete
last_verified: 2026-09-04
keywords: submission package, government portal slots, portal upload slots, mapping documents, merge documents into one slot, table of contents, case index, confirm package, seal package, download case ZIP
license: Documentation © Lexpoint. Quote with attribution and a link to the canonical URL.
---
# Finalization and the submission package

Finalization turns a completed checklist into the files you upload to the portal you are filing in.
It
happens in two places: **Mapping**, per application, and **Packages**, for the case.

## Mapping

### Why mapping exists

The documents you gather in Lexpoint and the upload slots a government portal offers are not the
same list, and usually not the same length.

Which portal that is depends on what you are applying for: IRCC for federal applications, and a
province's own system — OINP, BC PNP, and the rest — for provincial ones. Each has its own slots and
its own limits, and none of them look like your checklist.

Say you are extending a work permit. Lexpoint asks you for four things:

- your current work permit
- a notice of assessment
- an employment letter
- a lease agreement

The portal, meanwhile, may offer a single additional slot — **Client Information**. Four documents,
one slot. That mismatch is normal, it is not specific to any one portal, and it is the problem
mapping solves.

**Mapping tells the assembler which of your documents belong together and which portal slot they
become.** Assign all four to Client Information and they are merged, in order, into one PDF that
fills that one slot. You upload one file to the portal, and everything is inside it.

### Doing it

Open an application and choose **Mapping** in the case tree, the last of the four workflow steps.
The heading on that screen reads *Match documents to IRCC portal upload slots*; the step works the
same way whichever portal your application is bound for.

The bar at the top counts **X of Y assigned** with a percentage; the case tree's Mapping glyph turns
to ✓ when every required item has a slot. Rows are split into a **Forms** section and a **Documents**
section.

| Control | What it does |
|---|---|
| **Auto-assign** | Assigns every item Lexpoint can match to its slot in one pass. Start here, then correct what it got wrong. |
| Slot selector on a row | Sets or changes the slot for that one item. |
| Drag handle | Reorders documents within a slot — see below. |
| **Initial** / **Request** | Scope chips. **Initial** is the original package; **Request** is a later post-submission ask. A picker appears when there has been more than one. |
| **Open Packages →** | Jumps to the case-level Packages screen. Generating and downloading happen there, not here. |

### Order is the order in the bundle

Where several documents share a slot, **the order you put them in is the order they appear in the
merged PDF.** Drag a row to move it. Whatever sits first in a slot is the first thing an officer sees
when they open that file, so put the document that establishes the point first — the work permit
before the lease.

### Leaving something out

**Anything you leave unassigned is not in the package.** That is the mechanism for excluding a
document: if you gathered something that should not be filed, or that belongs to a different
submission, leave its slot empty and it is simply not assembled.

Unassigned items still count against the **X of Y** bar, so a deliberately excluded document will
keep the counter short of complete. That is expected — the counter tracks what is assigned, not
whether you are finished.

```media
id: cases-mapping-workbench
type: screenshot
caption: The Mapping step of an application, with several documents assigned to one portal slot and the assigned counter at the top.
shot: /app/cases/[case]/members/[member]/applications/[application]?tab=package — most rows assigned, at least one slot holding several documents, both Forms and Documents sections visible. Demo account, light mode, 1440×900. Redact the principal name in the context bar and any filenames in the rows.
src: /media/individuals/cases-mapping-workbench.webp
```

:::note[On a full-representation case]
Mapping is read-only and reads *Your representative will prepare this application package.* There is
nothing for you to assign.
:::

## What the assembler builds

Once every application on the case is mapped, the package can be generated — and what comes out is
more than the files concatenated.

For each slot that holds more than one document, the assembler prepends a **cover page and a table
of contents**, so an officer opening a merged bundle can see what is inside it and in what order.
Across the application it builds a **case index**. The result is a package in a consistent,
standard shape rather than a pile of PDFs named whatever they were named on your laptop.

You do not configure any of this. It is applied when the package is generated.

## Confirming what will be filed

On cases where your confirmation is required, Mapping gains a **Confirm slots** banner counting
**N/M confirmed**, and every row gains a **Confirm** column.

1. Select **Review →** on a row. The portal PDF opens in a viewer.
2. Read it. The footer says *Confirm only after you have reviewed this file.* The confirm button
   stays disabled until the file has loaded.
3. Select **Confirm**.

Where one portal PDF covers several of your requirements, the viewer says so — *One confirm covers N
Lexpoint items mapped to this portal PDF* — and one confirmation settles all of them.

### Confirm column statuses

| Chip | Meaning | What to do |
|---|---|---|
| **Confirmed** | You have confirmed this slot and its content has not changed since. | Nothing. |
| **Stale** | The content changed after you confirmed. | Select **Review again →**, then confirm. |
| **Needs confirm** | Not yet confirmed. | Select **Review →**, read the file, confirm. |
| **Regen needed** | The package has to be produced again before this can be confirmed. | Regenerate on the Packages screen. |
| **Package pending** | No package has been generated for this scope yet. | Generate it on the Packages screen first. |
| **Not in package** | A package exists but this slot is not in it. | Regenerate the package so the slot is included. |
| **No principal** | No principal account is linked to confirm against. | Raise it in the case conversation. |

Forms behave slightly differently: a form you already confirmed inside its own **Review & Confirm**
section shows as **Confirmed** here too, with a **Review & Confirm →** link back to the form when it
is not.

## Packages

Open **Packages** from the **Case** section of the case tree. This is where files are produced.

The header explains the two shapes: *Initial = one case package for all apps · ADR = per-application
tip.* One initial package covers the whole case; each later request produces its own package for the
application it concerns.

| Control | What it does |
|---|---|
| **Generate package** | Opens package settings, then produces the package. |
| **Application** selector | Appears when the case has more than one application. |
| **Stage** selector | Switches between the initial package and each later request. |

Under those, three cells stay visible:

| Cell | What it shows |
|---|---|
| **Initial assemble** | The case package's state, with **Download case ZIP →** once it exists. |
| **Your Drive** | A copy of that package in *your* Google Drive — not a firm folder. |
| **Document uploads** | Upload readiness across the case. |

**Your Drive** uses the Google account you connected under
[Settings → Integrations](/individuals/account/integrations/). It is a second destination for the
same package tree you can download as a ZIP.

| The cell reads | What to do |
|---|---|
| **Not connected** | **Connect Drive →** opens Google sign-in, then returns you here. |
| **No package yet** | Generate the package first. |
| **Ready** | **Save to Drive →** copies the package. |
| **Queued** or **N of M** | The copy is running. It continues if you leave the page. |
| **Saved** | **Open in Drive →** opens the copy in Google Drive. |
| **Failed** | The error is under the status. Try **Save to Drive →** again. |

If you work with a firm that mirrors files to *their* Drive, that is a different connection and a
different cell labelled **Google Drive**, with **Sync →**. Until their organization has connected
Google, that control's tooltip reads *Google Drive is not connected for your legal team yet.* That
is theirs to set up. On your own case Packages screen, the cell you use is **Your Drive**.

### Package settings

**Generate package** first opens a settings panel. Under **Continued pages** sit two checkboxes,
both ticked by default — **Additional employment history** and **Additional background history
(Schedule A)** — with the note *Unchecked items are left off the next package, contents, and case
index.* Confirming with **Generate package** starts the build.

```media
id: cases-packages-workbench
type: screenshot
caption: The case Packages screen, with the stage selector, the generate action, and the case bundle, Drive, and uploads cells.
shot: /app/cases/[case]?tab=finalization — a case with at least one generated package. Demo account, light mode, 1440×900. Redact the principal name in the context bar and the applicant name on the stage workspace card.
src: /media/individuals/cases-packages-workbench.webp
```

### Actions on a stage

The buttons on the stage workspace depend on where that package is.

| Button | When it appears |
|---|---|
| **Map this request** | Nothing has been mapped for this request yet. |
| **Generate** | Mapping is done and no package exists. |
| **Retry** | The last generation failed. |
| **Download** | A package exists. |
| **Regenerate** | A package exists and you want it rebuilt from current content. |
| **Seal** | Everything requiring confirmation has been confirmed. |
| **Mapping** | Opens the Mapping step for that application. |

A line under the buttons tracks the confirmation gate: *N/M confirmed · Review & Confirm then Seal*,
then **Confirmed — ready to seal**, then **Sealed**.

### While a package is building

Generating takes over the whole window rather than leaving you watching a spinner on the Packages
screen. The page is headed with one row per application plus a final **Case package** row, each
carrying a state — **Not started**, **Queued**, **Processing**, **Building file**, **Assembling**,
**Building ZIP**, **Finalizing**, **Complete**, or **Unsuccessful**. An **Events** panel below it
narrates the run as it happens. With more than one application it says *Each application builds
independently — finish order may vary*, and on a quiet stretch a line reads *Still working — large
cases can take a minute*.

- **Continue working →** at the bottom leaves the screen. The build carries on without you.
- **Download** appears on the **Case package** row the moment the case ZIP is ready.
- When everything finishes the screen says **Complete** and counts you back to the case.
- If it fails it says **Not completed**, gives the reason, and offers **Return to case** — retry
  from Packages.

Saving a copy to **Your Drive** stays on Packages: the cell moves through **Queued** or **N of M**
until it reads **Saved**. A firm's **Google Drive** **Sync →**, when that cell is present, opens its
own full-screen progress screen and returns you to Packages when it is done.

```media
id: cases-package-generating
type: screenshot
caption: The full-screen package build, with a row per application, the case package row, and the running Events panel.
shot: /app/cases/[case]/package-generating — reached by selecting Generate package on a two-application case, captured mid-run so at least one row reads Complete and another is still building. Demo account, light mode, 1440×900. Redact the applicant names on the milestone rows and any names in the Events panel.
```

### Package states

| State | Meaning |
|---|---|
| **Queued** | Waiting to start. |
| **Generating** | Being built. |
| **Completed** | Ready to download. |
| **Submitted** | Filed. |
| **Failed** | Generation failed — use **Retry**. |
| **Stalled** | Generation has been running far longer than expected. Retry, and raise it in the case conversation if it recurs. |

:::caution[Sealing locks the package]
Once a package is sealed it is fixed for filing. Confirm each slot against the actual portal PDF
before you seal, not against what you remember uploading — the whole point of the step is that what
you attested to is what gets filed.
:::

:::note[On a full-representation case]
Packages is read-only and reads *Your representative will prepare and bundle the case package.*
:::

## Related

- [Case status](/individuals/cases/case-status/) — what the service on your case changes about this screen
- [Requirements and checklists](/individuals/cases/requirements/) — everything must be complete before mapping is useful
- [Applications and IRCC forms](/individuals/cases/applications-and-forms/) — confirming a form is a prerequisite here
- [Case timeline](/individuals/cases/timeline/) — package events appear there
- [Messages on a case](/individuals/cases/messages/) — where to ask about a slot you do not recognize
- [Integrations](/individuals/account/integrations/) — connect Drive so Your Drive can receive a copy

## Frequently asked questions

### What is the difference between Mapping and Packages?

Mapping is per application: which of your documents go into which portal upload slot, and in what order, given that a slot usually holds several of them. Packages is the case-level screen where the files are generated, downloaded, and sealed. Mapping decides what is merged with what; Packages produces the result.

### What does "One confirm covers N Lexpoint items" mean?

Several of your requirements can be combined into a single PDF for one portal slot. Confirming that portal PDF confirms all of the requirements behind it at once.

### I confirmed a slot and it now says Stale. Why?

The content behind that slot changed after you confirmed it. Review the portal PDF again and confirm again, so what you attested to is what will actually be filed.