Status · 2026-09-10 · IN PRODUCTION · Salesforce side deployed 2026-09-03 · Azure cutover 2026-09-09 · Production redeem proven both paths 2026-09-09 · Real messages carrying working links 2026-09-10 · Launch Mon 2026-09-14

Magic-Link Portal Login

One tap on a refill-reminder text and the patient lands on their My Home page already logged in — no date of birth to enter, no verification code to fetch. Email works differently since [D16] (2026-08-06): emailed links land on a date-of-birth step-up before the login runs, so the tap alone no longer completes it. Salesforce mints the link at dispatch time; Azure runs the bridge; SFMC renders it as a merge field. As of 2026-09-10 the whole journey is proven in production — the Salesforce side went live on 3 September, Azure was pointed at the real Salesforce on the 9th, a production link signed the test patient in on both paths that afternoon, and on the 10th a real text and a real email carried working links and each one signed them in. The safety switch is still on, so only test patients can receive a link. What remains is launch: the permission grant for every existing portal user on Friday, the go/no-go, and on Monday the journey switch, the safety switch off, and one real patient on one channel.

In production · proven end to end on both paths · launch Mon 14 Sep, one patient first Azure-led No SFMC-held secret One-click on SMS · DOB step-up on email 72-hour TTL Jun 2026 audit ✓ · Jul review found 4 (1 Critical) · §§1–2 shipped Aug 2026

Mon 14 Sep

Launch

One real patient, one channel; widening is a separate decision after

72 h

Link lifetime

Multi-use within window

~$250 / mo

Estimated run cost

Front Door Standard + EP1

NowWhere we are — 2026-09-10

Everything this plan describes is built and installed in the real systems, with the safety switch on so no real patient can receive a link yet. The go-live journeys stay off until launch morning by decision. The day-by-day record is magic-link-go-live-sequence.md; this page is the architecture.

✓ 2026-09-03

Salesforce side in production

Fifteen components by change set after a clean Full pass: the mint invocable, Magic_Link__c, the settings record, four flows including the SMS redaction, the credentials, both permsets. The bridge app was built by hand the same day with the real certificate — copying it across lands it with OAuth silently off.

✓ 2026-09-03

Production credential chain

A real mint for the test patient returned a link with a URL — credential, secret, Entra token, allowlist, callout, all in production, five days before it was needed. The ordinary-patient case produced no link and no error: the safety switch works.

✓ 2026-09-09

Azure pointed at production (G11)

Kyle: pause minting → advance the kill epoch → zero live links → five keys written and read back → sentinel → health green → minting resumed. Production only from here; the sandbox bridge is retired.

✓ 2026-09-09 · 09-10

Proven end to end in production

A production link signed the test patient in on both paths — text straight to /my-home, email through the redesigned date-of-birth page. Login History labels them Magic Link Bridge, so adoption is countable. On the 10th a real text and a real email carried working links and each signed them in.

✓ 2026-09-10

Production smoke (G13)

Fresh mint, byte-identical replay, revoked identity refused, on made-up identifiers. The fifteen-guess cap closed on evidence — hit live on the 3rd and the 9th; a made-up patient has no portal record and is bounced before a miss can count.

⏳ Fri 11 · Mon 14 Sep

Launch

Friday: the permission grant to every existing portal user (the step that must not be forgotten), the remaining test cases, and go/no-go. Monday: journey switch with the safety switch still on, verify no links for real patients, safety switch off, one real patient on one channel. Kyle's open gates — five untested alerts and the 2am plan sign-off — close by Friday or are accepted open.

WasWhere we were — 2026-07-08 (retained)

Azure platform built, deployed, security-hardened (2026-06-11), and re-verified live (2026-06-22). Auth proven end-to-end in the sandbox. Direction change 2026-07-08: the mint caller moves from SFMC to Salesforce core — the send path is no longer gated on the SFMC credential rotation; the new open work is the Salesforce-side mint caller (design + build).

✓ Live

Azure platform

Function App, Front Door + WAF, SQL, Key Vault, mint / redeem / health — all deployed to prod. Re-verified 2026-06-22: Running, HTTPS-only, SCM + FTP basic-auth disabled.

✓ Proven

End-to-end auth (sandbox)

Mint → redeem → JWT-Bearer / singleaccess bridge. SF LoginHistory 4/4 success from NAT IP 135.119.140.149, zero failures (2026-05-26).

✅ Closed 2026-08-18

Storefront render

The May gap was missing commerce data in the sandbox, nothing else: once the store was stood up, a logged-in test patient lands on the portal home page and the refill wizard opens. Proven 2026-08-18.

⏳ Not started

Salesforce-prod go-live

Stand up the prod ECA + cert bind + consumer key, revert 3 App Config endpoints + bump the sentinel, prod smoke test. Not gated. See §8.

⏳ Not started · new

Salesforce mint caller (2026-07-08)

Direction change: Salesforce core mints via invocable + Named Credential; SFMC becomes merge-field-only. Replaces the AMPScript mint wiring outright — no longer gated on the credential rotation. Design + build pending (see §8).

Deferred

CDC / cache-miss fallback

Patient-Portal-V2 is the active priority (Kyle, 2026-06-11). Portal-user freshness gap accepted until the send path ships.

Security audit — 9 findings fixed + deployed 2026-06-11 · PR #215

One live exposure + eight landmines. Adversarially verified; build + 11 tests green. State tags: live deployed to prod · repo / decided shipped in code or a recorded decision.

SCM/Kudu basic-auth disabled live

The one live exposure — internet-reachable basic-auth on the JWT-signing app. Disabled on scm + ftp (live + Bicep); config-zip still deploys via AAD. Re-verified allow=false 2026-06-22.

usp_CreateMagicLink idempotency revive live

Re-mint of the same (contactId, idempotencyKey) after expiry/auto-revoke no longer hits a UNIQUE(ShortCodeHash) 500 — the proc now matches in any state and revives the row; 2627/2601 → THROW 50409.

Pepper-rotation replay safety live

Proc returns HashPepperVersion; mint regenerates the short URL with the row's stored pepper version on replay. Rotation no longer breaks live links. Unit tests added.

/healthz WAF rate-limit + pepper cache live

20/min/IP rule added to both Front Door WAF policies + pepper provider cached, closing a Key-Vault-throttle DoS on the shared platform vault. Applied surgically.

Scanner gating decision decided

Keep recording ScannerSuspected for observability; do not gate the bridge — correct for 72h multi-use links (a false positive would block a real patient). No behavioral change.

Go-live App Config revert needs a sentinel bump doc

Refresh watches only MagicLink:Settings:Sentinel; reverting the endpoint values alone won't propagate. Runbook now says bump the sentinel (or restart) at cutover.

Bicep endpoint-key de-seeding repo

A redeploy had silently reverted the 3 Salesforce env-pointer keys to prod defaults. They're now operator-managed App Config (removed from Bicep-seeded keys).

ADF SyncControl bookkeeping repo

Sync_SFDC_PortalUser_Full now records SetSyncInProgress / UpdateSyncSuccess + an idempotent bootstrap row (activates with Phase 2 portal-user sync).

SfmcTokenValidator OIDC caching repo

The OIDC ConfigurationManager is cached per metadata address (it was rebuilt per request) — the validator is a DI singleton.

⇄Direction change — who asks for the link

Committed 2026-07-08 (plan.md revision 11; authoritative decision record in the doc-integration enhancement plan §6): the mint request originates from Salesforce core, not the Marketing Cloud journey. Azure is unchanged — it still generates, stores, redeems, and bridges the link; only the prompter changes. Nothing gets unwound: the SFMC mint wiring was never built and its Entra secret was never handed to Marketing Cloud.

Superseded · never built

SFMC-initiated mint

AMPScript fetches an Entra token, then HTTPPost2 to mint at render time
Entra client secret copied into an SFMC-side store
Eligibility exported to DE columns + journey decision splits
Send path gated on the SFMC credential rotation (Risk #3)

Committed 2026-07-08

Salesforce-core-initiated mint

Apex invocable behind a Named Credential mints at reminder-dispatch time
Secret lives in a Salesforce External Credential — no SFMC-held secret
The data extension carries the pre-minted shortUrl; SFMC renders a merge field
Magic-link path no longer gated on the rotation

Why

Credential surface — no Entra secret handed to a third platform; SFMC credential hygiene is the exact live problem that was gating go-live.
Gate colocation — every "should this patient get a link" input is a Salesforce fact (portal user, consent, suppression); since 2026-08-24 the mint invocable itself refuses any call that omits an eligibility verdict — the flow's checks are pre-filters, not the authority.
Attribution — the idempotency key becomes a Salesforce-native identity (e.g. the reminder Id), making every minted link joinable to the reminder that caused it.
A simpler journey — pure merge-field render; no token handling or API error path inside SFMC.

New Salesforce-side design work it creates

[D2] closed 2026-08-17. Callout fan-out for reminder batches — Apex caps callouts at 100 per transaction. No fan-out shape is needed: the send already runs on a scheduled path with maxBatchSize 2, so mint runs synchronously there. That batch size must not be raised.
[D3] closed 2026-08-07. TTL vs dispatch→send lag — the 72h clock now starts at dispatch-time mint; measured entry→send is minutes, so mint-at-entry stands with no TTL change.
[D4] built in ClaudeTest 2026-08-17 (PR #131). Where the minted URL lives — a dedicated Magic_Link__c object, not a field on Refill_Reminder__c. URL stored as Text rather than URL (a clickable field would authenticate the clicker as the patient, with no symptom), blanked about an hour after mint; read-only "Magic Link: View All" permission set gates who can see it.
[D22] decided 2026-08-17 — DEFERRED TO v2 on 2026-08-25 [D22-am]. The minted URL also rests in Marketing Cloud's two reminder entry tables, which have had no cleanup rule since their 2024 creation. Both were to get 30-day record retention. That is now a v2 item: retention was never what bounds a live link — the 72-hour expiry is — so what it removes is the archive of already-dead links, and the expensive half is deciding the fate of ~20 months of accumulated reminder rows, which is a data-retention question this project should not settle as a side effect. Accepted risk: dead URLs accumulate until v2.
[D15] closed 2026-08-18 — the last open decision. What a patient with no portal account receives: the plain refill reminder they already get today, with no link. The alternative — sending an account-activation link — turned out to be impossible rather than merely unattractive: there is no patient-facing sign-up path, so a portal account must already exist before anyone can log in for the first time, and there is no activation link in existence to send. The mint step becomes a simple check for a portal account: has one, gets a magic link; doesn't, gets today's reminder untouched. No new message and no new build.
Fail open — a mint failure never blocks the reminder (blank URL → plain reminder, error logged).
Entra + Azure config — register MagicLink-Salesforce-Client, allowlist its appId (config-only on Azure), build the External + Named Credential; retire the never-distributed SFMC client.

§1The feature, in one paragraph

When a refill-reminder text or email goes out, the message carries a short URL. The patient taps it once and lands on their My Home page in the Salesforce portal already logged in — no date of birth to enter, no verification code to fetch. What it replaces: the normal portal login is email address + date of birth, then a one-time code sent to that address. There is no password at any point, so nothing here is "skipping a password" — a phrasing that has appeared in several documents and is wrong. On the email channel, [D16] (2026-08-06) adds a date-of-birth step-up before the login runs, so there the tap alone no longer completes it. Three systems each do one thing: Salesforce decides who gets reminded and asks Azure for the link at dispatch time (the 2026-07-08 direction change); Azure generates the link, holds the signing key, and runs the OAuth handshake at click time; SFMC renders the pre-minted URL as a merge field and delivers the message. Salesforce then establishes the session and serves My Home.

The bulk of the build lives in the existing AdvancedRx Azure VNet — the same one that already hosts eFax, the e-script integration, and the patient-matcher service. The Salesforce footprint stays small; §4 lists exactly what's required there.

§2How the bridge works

Salesforce asks for the link and fires the journey event; SFMC renders and delivers the message; Azure mints, holds the signing key, and runs the OAuth handshake at click time; Salesforce establishes the session and serves My Home. The refill wizard is not opened by the link.

Decide + Mint

Salesforce

Reminder flow mints via
invocable + Named Credential

→

Send

SFMC

Merge-field render
SMS or email

→

Bridge

Azure Function

Mint · Sign JWT · Exchange
VNet · Key Vault · SQL

→

Session

Salesforce

singleaccess
→ My Home

Step by step

Salesforce decides it's time to remind

Salesforce owns the timing, patient, and channel: a Refill_Reminder__c scheduled-path flow fires at the record's Send_Date_Time__c, and JBSystemFlow_Refill_Reminder_c (a Salesforce flow, not SFMC) fires the bulk event that enters the SFMC journey. Under the 2026-07-08 direction it also mints the link before firing that event — SFMC's job from here is render + deliver.

Salesforce asks Azure for a link

An @InvocableMethod Apex action behind a Named Credential (Entra client credentials as MagicLink-Salesforce-Client) POSTs to the machine-only mint host https://mint.advancedrx.dev/api/magic-links with the patient's Contact Id and portal User Id (read directly from Contact.Portal_User__c), channel, retPath, and an idempotency key (the reminder Id).

Azure mints + stores

Generates a random 128-bit seed and derives the 20-character code from it with a Key Vault pepper; stores the keyed hash of the code, the pepper version and the seed in SQL with a 72-hour TTL — a live code can be recovered only with both the database and the pepper. Returns { shortUrl, expiresAtUtc } to Salesforce.

SFMC renders + sends the message

The pre-minted shortUrl rides the journey-event payload into the data extension and the template renders it as a merge field — no AMPScript API call. The message goes out with the patient-facing link https://login.advancedrx.net/r/K7QXM3PVN9RW2HTDL4GA (illustrative — twenty characters, A–Z without I and O, digits 2–9; a separate host from the machine-only mint endpoint). Blank URL (mint failed) → the plain reminder still sends — fail-open.

Patient taps the link

Browser hits Azure (one tap on SMS, no interstitial; emailed links stop at the [D16] date-of-birth step-up first — see §5). Azure looks up the hashed code, resolves the stored User Id → Salesforce username via the local cache.

Azure signs the Salesforce JWT

ECA private key never leaves Key Vault — CryptographyClient.SignAsync handles the signature in-vault.

JWT Bearer → access token → frontdoor

Azure POSTs the assertion to Salesforce's token endpoint, gets an access token, swaps it at /singleaccess for a one-time-use redirect URL.

Patient lands logged in

302 redirect to the Salesforce frontdoor URI on the text path; on the email path the date-of-birth submit returns a 200 handoff page that forwards to it. Salesforce establishes the session and serves My Home. End-to-end latency has not been measured.

§3Why Azure

AdvancedRx already operates a HIPAA-compliant Azure VNet for eFax, e-script, and patient-matcher. Reusing it for magic-link gives wins that are hard to get inside Salesforce.

Public ingress hardening — Azure Front Door + WAF + per-IP rate limiting at the edge. Salesforce can't easily do this.
Key Vault-backed signing — the ECA private key signs in-place; it never leaves the vault.
Sub-millisecond SQL — hash lookups at click time without governor limits or Apex CPU caps.
Contact cache already in place — Azure resolves Contact → Salesforce username locally; no round-trip to Salesforce at click time.
Reduced attack surface — no community-reachable Apex endpoint is required for this feature; the link-mint surface lives on Azure behind WAF + private auth.
Real observability — App Insights for ops telemetry, scrubbed PHI-clean.

§4Salesforce-side surface

The bridge-side footprint is small and proven: the ECA, cert binding, and demo patient were all verified in the sandbox 2026-05-26; production go-live repeats it against the prod org (§8). The 2026-07-08 direction change added one new delivery — the mint caller, built 2026-08-19 and eligibility-gated 2026-08-24:

External Client App — the trust record

Holds the Azure-Key-Vault-generated public signing cert, the OAuth scopes Azure can request, the AdminApprovedPreAuthorized permitted-users policy bound via SetupEntityAccess to a small permset, and IP relaxation (Bypass; clicks come from arbitrary patient IPs). Five metadata files: ECA, OAuth Settings, Global OAuth Settings, Configurable Policies, Certificate. Cert binding: the Key Vault keypair must exist first (Phase 1); then the public cert is bound to the ECA inline as base64 in GlobalOauthSettings.<certificate>, deployed via the metadata API — no JKS, no Setup-UI import. Salesforce holds the public cert only; Azure signs with the non-exportable Key Vault key. (Bound + verified in ClaudeTest 2026-05-26.) Full procedure in cert-rotation-runbook.md. Once created, the ECA's consumer key is handed back to Azure as App Config MagicLink:Salesforce:EcaClientId — Azure redeem is non-functional until that's set.

+0 or 1

Permission set for the ADF integration user (if needed)

Azure's nightly ADF job extends to mirror portal User records alongside the existing Contact cache. If the integration user already has User-read access, no change. If not, one small permset grants it. To confirm pre-build.

Mint caller — new under the 2026-07-08 direction change

BUILT: External Credential (Entra client credentials as MagicLink-Salesforce-Client) + Named Credential Magic_Link_Mint + MagicLinkMintInvocable (13/13 tests). The contract requires an eligibility verdict (2026-08-24): calls without one are refused and logged (RefusedNoVerdict); an ineligible patient is skipped quietly (SkippedIneligible). Since revision 23, Magic_Link__c is the mint-attempt record — every outcome upserts a row carrying Mint_Status__c, with the URL written on Minted only, so a new channel needs no new fields and one query covers every lane. The URL stays FLS-gated to Magic_Link_View_All and auto-blanked ~1 h per [D4]. Fails open per [D2-am] to B2B_Custom_Exception__c; batch of 2 is the [D2] tripwire. Remaining: the reminder-flow wiring itself — no longer [D22]-gated, since D22 was deferred to v2 on 2026-08-25 [D22-am].

Explicitly not in scope on the Salesforce side: community-reachable endpoints, Custom Objects, Big Objects, LWC, public Experience Cloud routes, CMDT allowlists, AMPScript of any kind (the 2026-07-08 direction change removed the last SFMC API call). Apex + a Named Credential are now in scope — the one addition the direction change brought onto the Salesforce side.

§5Key design decisions

Three calls shape the architecture. Each was evaluated explicitly against alternatives; each is reversible if practice proves the trade wrong.

5.1 — Time-based expiry vs event-based

The link can either expire on a clock (time-based) or be killed the moment the patient submits a refill (event-based via a Salesforce → Azure webhook). Event-based gives tighter kill precision but requires Apex callout wiring, a Named Credential, an Azure endpoint, and tests on both sides.

✓ Chosen

Time only — 72-hour TTL

Link expires by clock, not by event. Bounded blast radius (refills of existing prescriptions to saved address only) accepted. Keeps the Salesforce-side surface to a single metadata record.

Deferred

Webhook on completion

Tighter kill precision (seconds, not hours). Engineering cost: one Apex class + Named Credential + Azure endpoint + trigger-event wiring + tests on both sides.

5.2 — One-click vs interstitial

Strictest posture: a "Tap to continue" interstitial page that blocks link scanners from triggering Salesforce sessions inside their sandboxes. Industry norm (Slack, Substack, Medium): one click, accept that scanners briefly hold ephemeral sessions.

✓ Chosen

One click — no interstitial

Matches Slack/Substack-grade UX. Scanner-induced sessions live only inside the scanner's ephemeral HTTP client and self-destruct. Audit log flags ScannerSuspected via UA signatures so triage stays clean.

Deferred

Explicit "Tap to continue"

Strictest scanner protection. One extra tap on the patient's side. Reversible to this design in a single-handler change if Salesforce-API volume from scanners proves material at rollout.

5.3 — Front Door tier: Standard vs Premium

Front Door Premium adds managed WAF rule sets, Bot Manager, and Private Link to origin — $295/mo more than Standard. For one narrow magic-link route, custom WAF rules + good function-side validation get most of the value.

✓ Chosen

Standard — ~$35/mo

Custom WAF rules + per-IP rate limiting + TLS + custom domain + edge logging. Sufficient for a single narrow public endpoint with strict input validation behind it.

Deferred

Premium — ~$330/mo

Worth it if/when we put other public Azure surfaces behind the same edge (storefront, outbound fax intake, future patient-facing endpoints). Then $295/mo delta amortizes across the platform.

§6Two pre-build spikes (gates)

The architecture depends on two things working that aren't documented for our exact configuration. Both spikes are small, parallelizable, and gating — neither requires a single line of production code.

✓ Spike A · Salesforce · PASSED

JWT Bearer + singleaccess for CCP Login

Proved the full handshake works for a Customer Community Plus Login license user. Minted a JWT locally, exchanged at the community token endpoint (returned access_token + community URL), POSTed to /singleaccess (returned frontdoor_uri JSON), followed the redirect chain (sid session cookie set, HTTP 200 on the storefront page).

Verified 2026-05-18 in ClaudeTest · three pre-auth gotchas captured in plan.md Phase 0 + a Phase 4 SetupEntityAccess wiring step. A subsequent Phase 4 metadata dry-run (same sandbox) surfaced three more execution details — cert binding requires an imported public cert; ECA enum values differ from legacy ConnectedApp; SetupEntityAccess.SetupEntityType is platform-inferred not writable. All folded into plan.md §6 Phase 0 so the production build doesn't re-derive them.

✓ Spike B · SFMC · SOFT-PASSED

Link wrapping + fragment behavior

Production SFMC self-send delivered both fragment (`/r#…`) and path (`/r/…`) URLs to Gmail with the href values completely unmodified — no wrapping through click.advancedrx.email. Caveat: SFMC Test Sends often skip click-tracking link wrapping; real journey/triggered-send wrapping behavior deferred to Phase 6a A/B rollout for definitive verification. V2 design accommodates either outcome.

Verified 2026-05-21 via production self-send · four execution gotchas + AdvancedRx SFMC infrastructure facts captured in plan.md.

§7Cost

Order-of-magnitude monthly estimate at expected refill-reminder volume. SQL adds are near-zero (reuses existing DB); Key Vault and App Insights are small even at scale.

Front Door Standard

Custom WAF rules + TLS + custom domain + edge logging

~$35

Function App EP1

Dedicated, always-warm, isolated blast radius from eFax

~$150–250

SQL · reuse existing

Two new tables on existing DB

~$0

Key Vault signing ops

Per-click sign call; volume-priced

~$5

App Insights

Sampled + scrubbed

~$5–25

Total · estimated

Realistic v1 range

~$200–315 / mo

§8What's next

Updated 2026-09-10. Everything below the next paragraph was written before production and is retained as the record of what the go-live steps were. All of it is now done except the permission grant to the existing cohort, which is Friday 11 September. What actually remains: the grant, QA-C cases C3–C5, go/no-go on the 11th, then on Monday the 14th the journey switch with the safety switch still on, the safety switch off, and one real patient on one channel. Kyle's alerts (five of six untested) and 2am-plan sign-off close by Friday or are formally accepted open. The live day-by-day is magic-link-go-live-sequence.md.

As written before production: the auth flow is proven end-to-end in the sandbox and the Azure plane was security-hardened on 2026-06-11. What remains is the Salesforce-prod go-live plus the one open storefront-render gap (prod-only data, not a flow defect).

✓ Proven in sandbox: Spike A (2026-05-18), Spike B soft-pass (2026-05-21), the full Azure plane (Function App, Front Door, SQL, Key Vault, mint + redeem + health), the ECA public-cert binding (PR #107), and — new on 2026-05-26 — the complete mint → redeem → JWT-bridge auth: Azure Bridge_Success ×2 and SF LoginHistory 4/4 successful logins all from the Azure NAT IP, zero impersonation. The JWT bridge is exonerated.
⚠ Storefront render — prod-only (open gap) — a redeemed link authenticates the patient but lands on the storefront login page, because "Advanced RX Store" is a B2B Commerce site and the sandbox has no WebStore / BuyerGroup / Buyer Account (that data lives only in prod; even admin impersonation bounces the same way). Decision: Option C — full storefront landing is verified in prod, not the sandbox. See plan §10 Risk #19.
Production go-live (can start now) — create the prod Magic_Link_Bridge ECA + permset + SetupEntityAccess, bind its public cert inline, and hand the consumer key to Azure. ⚠ SetupEntityAccess is NOT carried by source control — proven by test 2026-08-25: a clean five-component deploy into an empty sandbox produced 0 rows against ClaudeTest's 1. The post-deploy Apex insert (§7.6 step 3) is mandatory, the deploy stays green without it, and the only symptom is a patient seeing “the login link has expired” — so run the SetupEntityAccess verification query before any patient traffic. Consumer key goes to Azure as MagicLink:Salesforce:EcaClientId; Azure then reverts its 3 sandbox App Config values (TokenEndpoint, SingleAccessEndpoint, EcaClientId) back to prod and bumps MagicLink:Settings:Sentinel so running instances pick them up (audit finding #6). Watch-out: the ECA source has the sandbox org Id baked into orgScopedExternalApp — swap it for the prod org Id before deploy. Doesn't touch SFMC creds, so it's not gated. See §4 + plan §6 Phase 4.
Salesforce mint caller (new · not gated) — the 2026-07-08 direction change replaced the AMPScript mint wiring outright. Build: Entra app MagicLink-Salesforce-Client (+ allowlist its appId in Azure App Config — config-only on the Azure side), External + Named Credential, an @InvocableMethod mint action called from the reminder pipeline, and a home for the minted URL. Design open: batch fan-out vs the 100-callout cap, TTL vs dispatch→send lag, URL field FLS, fail-open. Salesforce reads the portal User Id directly from Contact.Portal_User__c at mint time — no data-extension hop (the 2026-05-26 audit facts carry over). No longer blocked on the SFMC credential rotation — that stays open for SFMC's own hygiene (MARISSA-HANDOFF.md §2 #2) but gates nothing magic-link.
SFMC template wiring (after the mint caller) — Phases 6a/6b as rewritten: the data extension carries the pre-minted MagicLinkUrl; SMS + OMM email templates render it as a merge field (blank → plain-reminder fallback). Send-classification check, one real-send URL-wrapping verification, then the 10% → 50% → 100% A/B rollout.
Risk acceptance per channel (SMS / email link-compromise vectors documented in §5 of the plan, Kyle as compliance counsel of record).

If the prod CCP Login + singleaccess exchange fails, an alternative Salesforce-only architecture is available as a fallback design record at ../magic-link-portal-login.md.

§9Verification basis

The architecture is reviewed against the existing Azure infrastructure repo and the live Salesforce + SFMC landscape.

Security hardening (2026-06-11, PR #215): a fresh-eyes audit fixed one live exposure (SCM basic-auth) + eight landmines — all 9 deployed live or in repo; adversarially verified, build + 11 tests green. Per-finding list under "Where we are now."

Live re-verify (2026-06-22): fn-magiclink-prod-east2 Running + HTTPS-only; SCM and FTP basic-publishing-credentials both allow=false (finding #1 confirmed live). App Config endpoint values are readable only from inside the VNet (jumpbox) — confirm / revert at go-live.

End-to-end auth (2026-05-26): the full mint → redeem → JWT-Bearer/singleaccess bridge was exercised in ClaudeTest against the demo portal user. Proof on both sides: Azure SQL Bridge_Success ×2 / RedeemCount=2 with zero failures, and Salesforce LoginHistory showing 4/4 successful logins, all from the Azure NAT IP 135.119.140.149 (2 Magic_Link_Bridge ECA token exchanges + 2 storefront session handoffs), with zero human/impersonation logins — the JWT bridge is fully exonerated. The only post-auth failure is the storefront render (prod-only commerce data; §8 + plan §10 Risk #19).

Azure side (as-built): the orchestration plane is BUILT and deployed (sandbox build) in advancedrx-document-integration. The mint contract in §7.1 is reconciled directly against the source (MintMagicLinkFunction.cs) — confirming mint requires both Contact Id and portal User Id, returns { shortUrl, expiresAtUtc }, and authenticates via Entra OAuth client credentials. Split hosts: machine-only mint.advancedrx.dev + patient login.advancedrx.net, both fronted by Azure Front Door. As-built facts in plan.md §4.6.

Salesforce side: aligns with storefront-data-audit.md (B2B storefront serving at https://advancedrx.net/vforcesite/ on the CCP Login license profile), integrations/sfmc.md (the existing refill-reminder send pipeline at JBSystemFlow_Refill_Reminder_c), and the in-progress SFMC credential rotation per MARISSA-HANDOFF.md §2 #2.

Spike A: CCP Login + JWT Bearer + singleaccess verified end-to-end in ClaudeTest 2026-05-18 — full handshake (token endpoint → singleaccess → frontdoor redirect → sid cookie set) confirmed for the CCP Login license.

Spike B: Production SFMC self-send 2026-05-21 delivered both fragment + path URLs to Gmail unmodified. Caveat: Test Sends often skip click-tracking link wrapping; real journey-send wrapping behavior verifies during Phase 6a A/B rollout. AdvancedRx SFMC infrastructure facts (sending stack 11, From domain hello@advancedrx.email, vanity click-tracking host click.advancedrx.email, dual-DKIM signed, DMARC pass) captured in plan.md §4.5.

Phase 4 metadata dry-run: the Salesforce-side metadata bundle (ECA, permset, post-deploy Apex) was authored and exercised end-to-end against the ClaudeTest sandbox on 2026-05-21 to validate the deployable shape before the production build. Three execution gotchas surfaced — cert binding requires an imported public cert (not a Salesforce-generated one); ECA policy enums differ from legacy ConnectedApp (AdminApprovedPreAuthorized + Bypass); SetupEntityAccess.SetupEntityType is platform-inferred, not writable via Apex. All three folded into plan.md §6 Phase 0 + §7.6 + the Phase 4 build steps so the production deploy doesn't re-derive them. The sandbox artifacts are throwaway; production deploy is still pending. Cert-import procedure: cert-rotation-runbook.md.

Direction change (2026-07-08): the mint caller moved from SFMC to Salesforce core — decision record in the doc-integration enhancement plan §6 and plan.md's Direction change section (revision 11). The Azure mint contract itself is unchanged and re-verified against MintMagicLinkFunction.cs (requires contactId + userId + channel + retPath + idempotencyKey; returns { shortUrl, expiresAtUtc }); the Azure-side change is allowlist-config-only. The SFMC mint wiring was never built and the MagicLink-SFMC-Client secret was never distributed, so nothing gets unwound.