Ways to build
the pack.

The application pack has a fixed skeleton and a few free joints. The skeleton is set by dependencies; the joints are product choices. This page separates the two, gives four end-to-end flows, and benchmarks each decision so the choice is evidenced, not arbitrary.

Four dependencies are non-negotiable, whatever the flow: a client must exist before an account; an account must exist before an illustration (it describes it) or a transfer (it funds it); and the application can only be signed once its documents and figures are final. Everything else is a sequencing choice.

* Transfer is conditional — present only when the account is funded by a re-registration / in-specie transfer. Cash-funded (contribution) accounts skip it, and the illustration is based on the contribution. When present, it sits before the illustration so the figures reflect the incoming value.

The three joints that are actually open

The spine is fixed by dependency; the joints are fixed by regulation and one UX call. Only the entry point is genuinely free.

Where the user starts. All converge on the same signed application; they differ only in what's created vs. reused. (Detected up-front by a "who is this for?" chooser.)

This is really two questions hiding as one: when do you capture the transfer, and when do you initiate it. They have different answers.

"Creation" is ambiguous — it can mean drafting the records or activating the account. Split them and the answer is forced by regulation.

• Records are created as drafts during the flow — the client and account exist in a pending state so the illustration and pack have something to attach to.
• Documents & disclosures come before the client signs — the Key Features Document, illustration and application must be provided before commitment (disclose-before-sale). Non-negotiable.
• Activation happens after sign + approval — the account only goes live once the pack is signed and (for maker-checker models) approved.

Combining the entry points and the ordering decisions into four complete, buildable journeys. key = commit, reg = disclosure, ext = external rail.

Stripped to one line, the standard advised platforms converge on is entity-first, disclose-before-sign:

It is the standard because four rules hold almost everywhere, and only this order satisfies all of them at once:

• Client before account, account before everything. Create or select the client, then open the wrapper — nothing can be illustrated or funded without an account to attach to.
• Transfer authority lives inside the signed pack. Captured during the application (so the illustration reflects its value, as one consent), never a separate post-hoc form. The rail is initiated only after the client signs.
• Disclose before sale. The Key Features Document, illustration and application are shown before the client signs — regulatory, not optional. Documents always precede signature.
• Draft mid-flow, activate last. Records are created in a pending state; the account goes live only after sign (+ maker-checker approval where used).

Two flavours of the same standard

• Entity-first — start with the client. The advised / ops default (Flow A).
• Case-first — open the application shell first, then fill the entities inside it; the same order underneath. Your Figma / Imago maker-checker model (Flow B).

How the field actually sequences these three joints. The pattern is remarkably consistent: transfer authority inside the signed pack, disclosure before sign, and entry point varying by channel.