Email workspaceWallet welcome
Source: App\Mail\WelcomeWallet, app/Mail/WelcomeWallet.php, resources/views/emails/wallet/welcome.blade.php. Referenced callers: WalletController::signup (:397) and WalletNGController::store (:141). These call send(new WelcomeWallet) to the wallet user after save, setupAccounts and SetUpSettings. The separate WalletCreatedMail is an internal signup alert already represented elsewhere.
Subject: Welcome to BuiltWallet (unchanged).
Suggested preheader: Welcome to Built Wallet. Your wallet is pending approval.
Portable values and source state
| Token | Existing source | Handling |
|---|---|---|
| {{wallet_url}} | Original fixed https://app.built.africa | Required validated original app-root destination, escaped in attributes. New label Open Built accurately describes it; it does not directly activate or approve a wallet. |
| {{preheader}} | Suggested existing welcome/pending context | Required escaped text. No deadline or approval guarantee. |
There is no source recipient-name, account number, bank details, status variable or approval URL. Do not add them. Default Built logo and optional {{logo_url}} override plus shared footer badges use [shared-footer](../shared-footer.md).
The source body says pending approval unconditionally. Both signup callers store status pending in production and approved elsewhere, then send the same body. This is an existing state mismatch: the draft preserves pending wording, and the non-production fixture documents it rather than inventing a second approved email. Decide whether to change that behavior in a separately authorized target-project change, not via a silent template condition.
The original “would be reviewed shortly” has no specified deadline; proposed copy says “It will be reviewed.” Capabilities remain: payments through invoices/payment links, vendor/data/airtime/utility bills, and virtual cards with transaction syncing. The original app-root Learn more link becomes Open Built. No new funding, activation, approval, availability or delivery promises are added.
Native integration
Preserve the existing user recipient and send() calls; Queueable alone is not a queued invocation. No explicit Mailable From/Reply-To override, PDF or business attachment exists; use native configured headers/transport without inventing a Reply-To. No per-email optional section or legacy duplicate link exists. Legacy maileclipse copies are not this referenced view.
Use the existing Mailable with a complete HTML Blade view and proposed text alternative. Portable {{placeholder_name}} tokens are not automatically Blade. Escape text and attributes, validate the exact approved app-root URL separately, and use one pass if replacing tokens. Keep previews' local inert URLs out of production. Logo and badges require approved HTTPS or actual CID assets; do not copy embedded preview controls/images as production policy.
Files: public/ready/wallet-welcome.html and .txt, previews/wallet-welcome-*.html/.txt. Three states cover the production pending body, documented non-production mismatch and long inert link robustness. No separate project-owned plain-text counterpart was found for this active view; the supplied text is proposed equivalent content. Browser checks are not Gmail/Outlook/iOS Mail, approval-state or production-delivery verification.