Allianz producer Copilot experience¶
Status: Implemented design plan | Last reviewed: 2026-10-09
Use this plan to implement the producer-service journey in Allianz1.svg through Allianz12.svg within the existing DevSDO Allianz app. Use native LWCs for the center workspace, catalogue components in the existing Agent Assist sidebar, and the existing wrap-up modal. It covers their shared conversation state, record operations and audio controls. Match the supplied design at its reference sizes, then adapt it to smaller viewports.
All twelve SVGs were rendered in Chromium and visually reviewed in order. Read-only DevSDO queries confirmed the installed Allianz wrappers, record pages and DCC wrap-up components, plus Clear Connect's native center and the maintained Takeda implementation of that pattern. The native implementation and release procedure are documented in Allianz producer workspace. Copilot 4870 was the existing illustration assistant selected for this journey; its independent two-assumption experience is retained. The sections below preserve the original reference audit and acceptance criteria.
Existing foundations¶
Keep the installed Agent Assist sidebar and wrap-up modal as the integration targets.
| Foundation | Verified starting point | Planned change |
|---|---|---|
| Allianz application | Existing console and three-column allianzRecordTemplate |
Adjust app-scoped layout, branding and record-page regions |
| Voice Call sidebar | Installed allianzAgentAssist, assistMode=Live Conversation, bound through VendorCallKey |
Load the producer catalogue composition and its live data |
| Case sidebar | Installed allianzCopilot, agent 4445, bound through Related_Conversation_Id__c |
Preserve specialist supervision; explicitly configure the producer-human-call experience where the new journey runs |
| Event bridge | Installed allianzMfeBase has copilot-event, external-event and sendCopilotEvent handling |
Add the required Allianz action consumers and result projection |
| Native center precedent | Clear Connect's multi-case page mounts four center LWCs; Takeda has a maintained native workspace and Apex controller | Build an Allianz native workspace using the same event/save pattern |
| Existing center embed | Installed allianzWorkspace; maintained shared workspace renderer |
Retain for existing uses; the designed center follows the native LWC approach |
| Wrap-up | Installed dccWrapUpLauncher, dccWrapUpModal, dccWrapUpScreen, dccSummaryNotes and footer |
Style/configure the existing flow and supply the Allianz summary, dispositions and tasks |
| Catalogue composition | Shared relatedSurfaces, context-only output and copilot_composed_layout |
Use these hooks for sidebar composition; native center state travels through host events |
| Audio enhancement | Existing RTC_AUDIO_CONFIG / RTC_AUDIO_STATUS connector path |
Connect the catalogue enable/disable action and actual runtime state |
The two retrieved Allianz record pages currently lead with a live transcript and record details. The Case page additionally includes a specialist request summary. Neither page definition contains the designed contract/scenario workspace. The wrap-up components are installed, but their presence alone does not prove the correct launcher and configuration are assigned to this Allianz journey.
The retrieved dccSummaryNotes uses an existing Flow/Apex summary interface. Map the Allianz post-call result into that interface, or extend its existing configurable summary content seam if necessary. Do not assume a catalogue renderer is already embedded inside that particular deployed summary component.
Source entry points:
- Allianz template and layout CSS.
- Case page, Voice Call page and metadata staging.
- Maintained Salesforce bridge, composed views and workspace renderer.
- Native workspace contract, LWC orchestration and Apex record operations.
Clear Connect precedent¶
The Salesforce app Clear Connect, developer name DCC_Patient_Service_Clear_Connect, assigns its multi-case record type to DCC_Patient_Service_Multi_Case_Page. Read-back of that page confirms this structure:
| Page region | Installed components |
|---|---|
| Center | dccMultiPatientInteractionDetails, dccMultiPatientInquirySummary, dccMultiPatientAppealForm, dccMultiPatientCaseSnapshot |
| Right | dccMultiPatientRightPanel, configured with agent 4465 |
| Left / wrap-up | Profile/context components and dccWrapUpLauncher, configured for TakedaMultiPatient |
This is the Salesforce Clear Connect app. The separately hosted ClearConnect PSP application uses React and the TrueServe SDK and is a different implementation.
The retrieved Clear Connect form itself implements the two-way Copilot integration. dccMultiPatientAppealForm receives catalog-action events such as appeal.open, accepts headless form_fields updates, preserves dirty fields and publishes appeal.progress. It saves through DCC_Multi_Patient_InquiryController.saveAppeal, then sends targeted form_context confirmation and the returned receipt. It also publishes record-scoped appeal.visibility messages: the sibling inquiry summary hides while the form is open and refreshes when successful submission restores the timeline. A failed post-save refresh is not reported as a failed save.
The right panel separately hosts dccMultiPatientAgentAssist and its Transcript tab. The native form therefore does not need to become a catalogue component to receive extracted values or react to a catalogue button.
The maintained Takeda workspace is the repository precedent for connecting a native center to Copilot. Its record page directly mounts takedaVoiceWorkspace. That parent renders native summary/form/snapshot children, subscribes to TrueServeCopilotEvent__c, handles catalogue actions, applies headless form extraction and preserves manually edited fields. It saves through Apex, returns targeted form_context confirmations, publishes progress events and refreshes record context. The installed native bundles were also retrieved read-only.
Prefer this architecture for Allianz because the center is a Salesforce record workspace with a persistent editable form. The LWC parent can control tab selection, form focus, validation, draft state and receipts directly, while Apex owns record permissions and transactional writes. It avoids an additional iframe/rendering boundary for those interactions.
The catalogue center remains a useful option when the same entire workspace must run across multiple host products. That portability is a tradeoff of choosing native LWCs here; reusable Copilot outputs and sidebar catalogue components remain independent of the Salesforce center.
Reference sequence¶
The screen numbers identify reference fixtures. Runtime transitions follow conversation facts and completed actions; they are not a timed slide sequence.
| Screen | Center workspace | Agent Assist / overlay | Required transition |
|---|---|---|---|
| 01 | Contract snapshot; three withdrawal scenarios; current case area below | Expanded transfer summary with handled/open items | Attach to the transferred conversation and load verified handoff context |
| 02 | Same snapshot and scenarios | Opening guidance; confirm contract, withdrawal amount and total-versus-net | Track confirmed versus missing details without losing the transfer summary |
| 03 | Same workspace | Comprehension guidance; speaking tips; Turn on English Enhancement / Not now | Show a relevant recommendation and handle the representative's action |
| 04 | Same workspace | Persistent enhancement toggle; activation message; Your Pace, 172 WPM example and 140 target | Wait for real enhancement state; display measured agent speech rate |
| 05 | Same workspace | Death-benefit impact breakdown and calculated result | Project trusted contract values and a versioned withdrawal calculation |
| 06 | Same workspace | Illustration setup; missing amount/frequency; start/defer actions | Create or resume an illustration draft and select its workspace |
| 07 | Illustration form, prefilled record data, five input groups, modeling assumptions; disabled submission | Listening/pending checklist synchronized with the form | Capture proposed values while preserving manual edits |
| 08 | Filled form, provenance badges, confirmed assumptions; enabled submission | Completed checklist and ready guidance | Validate the same draft revision and required confirmations in both views |
| 09 | Submission receipt above snapshot/scenarios | Submission acknowledgement and before-close details | Render the durable operation result and separate delivery state |
| 10 | Receipt remains visible | Pending signature on another contract | Show an authorized producer-book follow-up after the primary task |
| 11 | Receipt remains visible | Closing recap | Summarize actual outcomes, outstanding work and ownership |
| 12 | Underlying workspace retained under backdrop | Existing wrap-up modal: case fields, intents, editable summary, recommendations and footer actions | Load post-call evidence, retain edits, create selected tasks and complete the case |
The persistent left panel contains producer identity, authentication evidence, producer summary, producer details and agency details throughout. The application also needs functional case actions, status path, workspace tabs, More, Current Case / All Cases, and links such as Modify. Reference coverage for the unopened tabs is incomplete; reuse the existing record views until those interiors are specified.
Visual specification¶
Measured geometry¶
Measurements below come from the rendered SVG geometry, rather than estimates from a reduced screenshot. Use screen 01 as the canonical short desktop frame.
| Element | Reference measurement |
|---|---|
| Screens 01–05 | 1728 × 963 |
| Screens 06, 09–12 | 1738 × 968 export; application content begins 5 px from the left |
| Screen 07 | 1738 × 1138 |
| Screen 08 | 1738 × 1148 |
| Application navigation | Main rows end at y=50, y=90 and y=130 |
| Main content | Starts at y=146; 16 px outer horizontal margins in screen 01 |
| Three-column layout | Approximately 361.24 / 910.75 / 408.01 px, with 8 px gutters |
| Producer panel | x=16, y=146, width=361.24, height=754.09 |
| Producer summary inset | x=28, y=276, width=337.24, height=205.5 |
| Main summary container | x=385, y=350, width=911, height=497 |
| Contract snapshot | x=402, y=420, width=876.75, height=122 |
| Agent Assist container | x=1303.99, y=146, width=408.01, height=739 |
| Assist header | Approximately 60 px tall |
| Full-width rail controls | 20 px side padding; approximately 368 px wide |
| Transfer summary trigger | y=222; approximately 44 px tall |
| Guidance avatar | Approximately 40 px; message content begins 72 px inside the rail |
| Inset rail cards | Approximately 316 px wide |
| Composer | Bottom-aligned around y=819; separate send button |
| Wrap-up modal, screen 12 | x=407, y=241.27, width=923; overall height=513.48 |
| Modal identity block | Approximately 303.55 × 76.58 |
| Modal summary editor | Approximately 537.17 × 283.44 |
The current checked-in template uses 352 px / flexible / 372 px columns, 12 px gutters and 12 px padding. Those values are a concrete source of drift from the design.
Implement the measured desktop grid with a flexible center and explicit side widths at the reference size. Use container breakpoints for narrower consoles. Do not scale an entire desktop page down with a transform. The taller form references retain the short rail height; the center must scroll independently without hiding the form footer behind Salesforce's utility bar.
There are small export variations: screen 05 offsets the rail contents relative to screens 01–04, and screens 06 onward add an outer frame. Normalize the outer capture frame and record intentional internal deviations instead of shifting the app between states.
Tokens, assets and typography¶
Extract a shared Allianz token source and emit scoped styles for catalogue React components and the Salesforce components that need them. Shadow DOM and iframe boundaries require each renderer to receive the tokens; a single global CSS override will not reach all controls.
| Token family | Reference values / treatment |
|---|---|
| Brand / primary controls | #003781 |
| Dark text | #03234D |
| Page background | #F3F3F3 |
| Soft blue panels | #EEF3FA |
| Neutral borders | #E5E5E5, #C9C9C9 |
| Confirmed state | #2E844A, #1E6B3A, #F3FAF5 |
| Status path completion | Mint #ACF3E4 |
| Shapes | Large rounded workspace panels; smaller rounded cards; pill actions; fine dividers |
| Numbers | Consistent currency precision, right alignment and tabular digits |
| Icons | Reuse the supplied/installed Salesforce-style icons, Allianz logo and producer avatar |
All twelve exports outline their text as paths; none declares a text font family. The repository already contains Allianz Neo regular/bold assets, but that alone does not prove which font the designer used for every Salesforce label. Compare actual glyph shapes, line wrapping and baselines against the exports before fixing the font stack. Exact family/weight confirmation remains useful if that comparison is inconclusive.
Use reference text and frozen values in visual fixtures. Render actual text, inputs and buttons in the application. Extract reusable logos, avatar artwork and icons as assets where needed; do not use a full-screen SVG as the interactive UI. Initial visual estimates are 28 px for the case/owner titles, 18 px for the rail heading, 14–16 px for card text and 12 px for captions; verify these against the outlined glyph bounds.
Rendering and ownership¶
Use one composed catalogue entry point, tentatively ProducerAssist, in the existing sidebar. Use a native parent LWC, tentatively allianzProducerWorkspace, for the center. These names are proposed. Both consume the same business state through the existing host-event bridge; each owns its rendering and local interaction state.
| Area | Owner | Implementation approach |
|---|---|---|
| Salesforce global navigation and utility bar | Existing console | Configure supported branding, app navigation and density |
| Three-column page and case actions | Existing Allianz template / native record shell | Match dimensions; retain native action handlers and record identity |
| Producer/agency panel | Existing allianzCallerContext |
Extend data projection and restyle identity, summary, accordions and details |
| Contract/scenario/illustration workspace | Native allianzProducerWorkspace and child LWCs |
Own center tabs, contract/scenario presentation, editable illustration form and receipt; retain record/transcript access |
| Agent Assist | Existing allianzAgentAssist hosting ProducerAssist |
Use composed layout, persistent controls and one current guidance area |
| Record operations | Proposed AllianzProducerWorkspaceController |
Read authorized context; validate/persist drafts and return durable submission results |
| External operations | Native workspace plus small audio/host adapter | Handle validated catalogue commands using existing Salesforce/connector APIs |
| Wrap-up | Existing DCC launcher, modal, Flow and footer | Apply an Allianz configuration and summary adapter; preserve task/completion behavior |
Enable copilot_composed_layout only for the relevant Allianz sidebar surface configuration. It removes generic rail chrome so catalogue spacing, headings and controls can match the export. The native center does not depend on this flag.
Copilot workers can publish data into layout.region="context" for the sidebar to consume through A2UIRenderContext.relatedSurfaces. Form workers can emit headless form suggestions. The installed wrapper forwards raw events to TrueServeCopilotEvent__c, where the native workspace receives the relevant extraction. relatedSurfaces remains a React renderer API; it is not a direct LWC state bridge.
The native parent owns the current draft, dirty fields, active view and operation state. It publishes the resulting progress/confirmation snapshot back to Copilot, which drives the sidebar checklist. Persisted Salesforce/backend state owns saved drafts and receipts; neither view invents its own submission status. Do not run independent extraction for each visual copy of a field.
Use native children such as allianzContractSnapshot, allianzWithdrawalScenarios, allianzIllustrationForm and allianzSubmissionReceipt. Keep their state in the parent so changing a tab does not discard edits. Use app-scoped custom LWC markup/CSS where exact design control is needed, and native Salesforce controls where their behavior and supported styling fit.
A new coaching message must not reset the illustration form, move the composer or remount the entire rail. Keep transfer-summary expansion, enhancement state and active guidance as separate state.
Reusable component families¶
| Component family | Main inputs | Actions / states |
|---|---|---|
| Transfer summary | Reason, handled items, open items, verification and handoff evidence | Expand/collapse; preserve access across guidance changes |
| Guidance message | Heading, body, tone, related business item | Opening, coaching, calculation explanation, submitted, follow-up and recap variants |
| Confirmation/checklist | Stable field IDs, values, status and provenance | Pending, listening, suggested, confirmed, edited, invalid |
| Enhancement control | Requested and effective states, direction, availability | Enable, disable, pending, active, failed, unavailable |
| Speaking tips / pace | Tips; measured WPM, target, window, sample quality | Measuring, current, too fast, stale, unavailable |
| Financial breakdown | Typed amounts, calculation basis, timestamp and result | Loading, current estimate, invalidated input, unavailable |
| Illustration setup | Contract, scenario, missing prerequisites | Start/resume request; defer |
| Illustration form | Record context, five input groups, modeling assumptions, draft revision | Listen, edit, confirm, save draft, submit, retry, submitted |
| Submission receipt | Business reference, accepted time, assumptions, owner, delivery state | Submitted, processing delivery, delivered, delivery failed |
| Follow-up / before-close | Authorized related work, delivery route, ownership | Pending signature, reminder, task selection |
| Wrap-up content | Evidence-based summary, intents, recommendations, saved revision | Edit, regenerate with recovery, select tasks, save/complete through the existing modal |
The transfer/guidance/coaching/checklist families belong in the sidebar catalogue. The contract snapshot, scenario grid, illustration form and receipt belong in native center LWCs. Wrap-up content stays inside the existing DCC modal.
Reuse formatting conventions, schemas and suitable sidebar primitives from the producer catalogue. React components cannot be imported directly as LWCs. Its existing IllustrationRequest represents a smaller customer-facing assumptions interaction; keep that interaction separate from the five-input native representative form. The beneficiary catalogue serves a different journey and is not the producer component inventory.
Shared state and event contracts¶
Use one state model scoped to the current record and conversation:
| Namespace | Authoritative inputs |
|---|---|
producer / agency |
Authorized Salesforce record and context Flow |
verification |
Trusted authentication result, method and timestamp |
handoff |
Explicitly resolved transferred-call summary and evidence |
contract / scenarios |
Versioned contract lookup and deterministic calculations |
speech |
Original finalized agent STT plus audio timing |
enhancement |
Connector requested/effective status |
illustrationDraft |
Native parent owns the working draft; persisted typed values, confirmation/provenance and revision restore it |
submission / delivery |
Durable business operation and delivery receipts |
followUps |
Authorized related producer records and selected tasks |
wrapUp |
Persisted summary, human edits and completion status |
The same-conversation composition hook does not automatically import a preceding AI call. Resolve that relationship through the existing server/host handoff path, then publish the allowed transfer snapshot into the active human conversation. Likewise, keep internal conversation/workflow IDs separate from customer-facing business references.
Each editable field needs a value, provenance (record, heard, suggested, manual), confirmation status, update revision and relevant utterance ID. Model extraction cannot overwrite a newer manual edit. The form and checklist derive readiness from the same validated draft.
The native event loop follows the maintained workspace pattern:
- A catalogue action reaches the native workspace through the installed wrapper and LMS.
- The workspace selects the correct contract/draft and opens its native illustration form.
- Headless form suggestions update eligible fields. Match record, conversation, worker and form identity; ignore duplicates and stale revisions.
- Manual edits mark fields dirty and publish the current progress/confirmation snapshot. They remain authoritative over later extraction.
- Save/submit calls the Apex/controller boundary with the current values and expected revision. Preserve the draft on failure.
- On success, send targeted
form_contextconfirmation, publish the returned state/receipt and refresh the record context. The sidebar and existing wrap-up consume that same result.
Reuse the Takeda flow, with the explicit conversation/revision guards and typed Allianz fields described here. Its demonstration Task receipts are not a production illustration submission service.
Proposed action names below are contracts to add, not existing APIs:
| Action | Consumer and result |
|---|---|
accent.normalization.set |
Host adapter sends existing RTC_AUDIO_CONFIG; connector status updates the visible control |
illustration.open |
Open/resume the current record's draft in the existing workspace |
illustration.field.confirm |
Persist a targeted field value/confirmation at the expected revision |
illustration.progress |
Publish native draft values, provenance and readiness to synchronize the sidebar |
illustration.draft.save |
Persist the draft and return its saved revision |
illustration.submit |
Validate and submit once; return a durable reference and status |
followup.task.add |
Delegate to the existing Salesforce task action |
wrapup.open |
Delegate to the installed launcher for the current record |
speech.metrics.updated |
Feed measured speech data to interested Copilot workers and the view projection |
Use the deployed external-event / Lightning Message Service path for catalogue actions and existing sendCopilotEvent for host-to-worker events. Include a stable event/request ID, record identity and resolved conversation identity; include draft revision on draft mutations. Repeated submissions return the existing result. Emit separate operation results: API acceptance alone cannot mark enhancement active, an illustration submitted or a case complete.
The retrieved bridge already supports the event transport. The new work is the native workspace's action listeners, business operations and state projection. Use direct parent/child events within the center's LWC tree and LMS across the sidebar or utility-bar boundary. For connected utility-bar audio controls, do not rely on DOM bubbling across separate Salesforce component trees.
Feature-specific work¶
English Enhancement and pace¶
Preserve the design's English Enhancement label. For this producer-to-caller case, the enable button targets outbound agent audio through the existing accent-normalization profile. Preserve the configured provider, voice, grammar and unrelated audio settings.
The visible state must distinguish requested, starting, active, disabled, unsupported and failed. Render the screen 04 activation message only after effective connector state confirms the change. Not now dismisses the current recommendation without changing audio. The persistent toggle and utility-bar controls must stay synchronized.
Add WPM measurement; it is not an existing live metric. Count original final agent words once per utterance before transcript enhancement. Preserve provider word/segment start and end times, or measure per-channel speech intervals when those are unavailable. Current estimated transcript-publication timestamps do not supply accurate speech duration.
Calculate 60 × words / speaking_seconds over a configurable recent speech window. Define pause treatment and minimum sample duration explicitly. Keep raw-audio speaking pace separate from transformed audio playback rate. Represent missing timing, insufficient speech and stale data distinctly; silence is not a measured zero WPM.
Use 172 WPM and a target of 140 only in the screen-04 fixture. Configure the target and thresholds as product settings; the design is not evidence for a universal speaking-rate rule. Update the display deterministically without a model call per tick. Copilot can consume the metric to choose coaching text.
Financial context and follow-ups¶
Extend the context/lookup contract for producer affiliation, book of business, service pattern, contract owner, valuation date, charge schedule and death-benefit basis. Associate each displayed fact with its as-of time and source.
Calculate the scenario proceeds, free-withdrawal allowance and death-benefit reduction in a typed service/tool. Preserve the design's values in a synthetic fixture; establish the actual calculation and rounding contract before using it on changing data. Do not ask the language model to generate financial values for these tables.
The pending-signature card comes from an authorized lookup within this producer's book, with contract identity, request date, status and required action. It cannot be inferred merely because a closing recap is underway.
Illustration capture and submission¶
Model the five visible input groups as structured fields: recurring amount/frequency, start date, duration, allocation and future purchase payments. Keep prefilled record details and product modeling assumptions separate from captured inputs.
Use the existing targeted form/event mechanisms where their schema fits, following takedaVoiceWorkspace's headless extraction, dirty-field preservation and confirmation loop. Add the native Allianz form and its draft/submission operations. The current two-option customer illustration component does not implement this full request.
Server validation owns required fields, compatible assumptions and revision checks. Save Draft remains available before completion. Submit Request validates and saves the current visible draft with its submission operation; it does not require an earlier Save Draft click. It requires the validated confirmed state and cannot duplicate an existing request. Preserve the draft after an error and explain the failing field or operation inline.
After submission, project one result into the workspace receipt, sidebar guidance and wrap-up evidence. Track accepted submission, document generation and delivery separately. Navigate back to the summary with the receipt visible, retaining the submitted assumptions for review.
Existing wrap-up modal¶
Retain the installed launcher, record-focused opening behavior, Flow bindings, task creation and completion footer. Verify the active Flow/custom-label configuration used by the Allianz record before wiring the final journey.
Feed its existing summary interface a structured Allianz result containing editable narrative, case reason/status, producer intents and recommended actions. Preserve the modal's existing user-edit and regeneration behavior; a late result cannot silently replace edited notes. Show progress while a post-call result is still being produced.
Use app-scoped configuration/styles for the approximately 923 px modal, two-column body, compact controls, summary toolbar and footer. Bind Add Task and Mark as Complete to the existing action paths. Save the current edits and selected actions before reporting completion.
If the existing content seam needs a catalogue-hosting extension, add it inside this modal and preserve its Flow events. Do not introduce a second wrap-up launcher or a separate modal state store.
Implementation sequence¶
| Phase | Concrete output | Exit condition |
|---|---|---|
| 1. Reference fixtures and tokens | Twelve deterministic LWC/sidebar states, extracted assets, exact viewport manifest, scoped design tokens | Every reference can be rendered without live model variability |
| 2. Native app and sidebar layouts | Updated Allianz columns/context panel; native workspace/children; composed sidebar catalogue; modal styling fixture | Geometry, text wrapping and visual states match the exports |
| 3. Context and shared state | Producer/handoff/contracts projection, headless form schema, native working draft and two-way LMS state | One field update changes both checklist and workspace without resetting edits |
| 4. Live enhancement and WPM | Audio action adapter, connector feedback, timing preservation, speech metric producer | Real audio state and measured WPM drive screen 04 |
| 5. Illustration and follow-up actions | Draft persistence, confirmed submission receipt, delivery status, authorized pending work | Screens 06–11 run from durable operations and survive refresh |
| 6. Existing wrap-up integration | Allianz summary adapter/configuration and existing task/completion wiring | Screen 12 opens on the correct record and saves the human-reviewed result |
| 7. DevSDO acceptance | Reference-size screenshots, visual diffs and connected journey evidence | Visual and behavioral criteria below pass |
Complete the visual LWC and sidebar-catalogue fixtures before coupling them to real-time providers. That makes each design state inspectable while the state and business contracts are implemented. Keep the interactive data contract identical between fixtures and live adapters.
Select the producer-human-call binding explicitly during phase 3. The existing beneficiary Copilot, producer self-service voice agent and specialist supervisor are distinct runtime roles. Reusing the installed sidebar does not make those roles interchangeable.
Validation and pixel fidelity¶
Establish separate visual and functional checks.
- Render all twelve states at their original SVG dimensions, browser zoom 100% and a fixed device scale factor. Preserve source SVGs and record their hashes.
- Produce overlays and image diffs for the complete app, left panel, workspace, sidebar and modal. Compare component crops as well as the whole page so unchanged Salesforce chrome cannot conceal a poor card match.
- Target measured anchors and dimensions within 1 CSS px for owned components. Require the reference line breaks, icon sizes, padding, borders and colors. Calibrate image-diff tolerances for font antialiasing using a stable browser baseline rather than declaring an arbitrary global pass percentage.
- Freeze time, record values, avatar, viewport, animations, speech metric and component state for each visual fixture. Mask only genuinely external Salesforce chrome when needed, and list every mask. Do not mask the components under review.
- Exercise actual intermediate states: enhancement starting/failure/off; WPM measuring/stale; listening/proposed/confirmed/edited form fields; draft-save/submission failure; delivery pending; wrap-up loading and unsaved edits.
- Test desktop reflow at narrower console sizes and the long form at the short viewport. Keep the composer and required action controls reachable; avoid nested accidental scrollbars and utility-bar overlap.
- Check keyboard focus, accordion semantics, form labels, status announcements, toggle state, modal focus containment and focus return. Represent statuses with words/icons as well as color.
- Rehearse the full event journey in DevSDO with a bound conversation: host context → recommendation → audio acknowledgement → measured pace → form edits → persisted submission → wrap-up save. A static screenshot pass is not proof of those operations.
Pixel-level control is strongest inside catalogue components and custom Allianz LWC markup. Native Salesforce global chrome and shadowed base-control internals depend on supported styling hooks, platform rendering and browser fonts. Match those within the supported app configuration, and document residual differences rather than applying brittle cross-app DOM overrides.
Add focused tests for duplicate audio commands, requested-versus-effective state, WPM utterance deduplication/timing, manual-edit races, shared form readiness, idempotent submission and wrap-up edit preservation. Reuse existing SDK/bridge tests for transport behavior and native workspace regressions as the behavioral pattern. Compile native LWC templates/styles and validate Apex record operations as well as the sidebar catalogue.
Implementation documentation updates belong with the affected code: Allianz console, Copilots, A2UI, the Allianz user walkthrough, and relevant user-guide navigation. Regenerate catalogue/config schemas when their source contracts change.
Reference decisions to resolve¶
These are bounded design/data decisions; they do not prevent starting the visual fixtures.
| Observation | Planned treatment |
|---|---|
| Screen 08 shows an amber suggested start date while the checklist and header say ready | Keep provenance separate from confirmation. Require explicit confirmation of the suggested date; then render the appropriate confirmed state |
Screens 09–11 show SR-291640; screen 12's recommendation shows IFR-291640; existing demo code also distinguishes review references |
Use one returned submission reference for this request, with separately typed review IDs where applicable |
| Submission receipt says delivered, while the wrap-up summary says delivery awaits confirmation | Use one delivery-status source in all views; fixture variants can represent either state |
| Some early screens hide the transfer trigger, while later screens restore it | Keep the summary accessible; define expanded/collapsed/contextual visibility deliberately |
| Later status-path labels contain visibly distorted/inverted glyphs | Treat these as export artifacts; preserve the intended status labels and geometry |
| Snapshot dates and amounts differ from older demo scripts | Version a synthetic design fixture; live displays use the returned business facts |
| Verification reads “Face ID” with a precise timestamp | Show that only when the trusted authentication evidence supports that method/time |
| Unopened app tabs and error/loading views are not supplied | Reuse the app's current behavior and extend the reference styling; label these states as inferred in review |
| Exact font metadata is absent | Compare repository fonts to the outlined references and confirm the remaining mismatch before final visual sign-off |
Review evidence¶
Local review outputs are under .local-data/allianz-design-review/: twelve full-size PNGs, three contact sheets, a source-hash/dimension manifest, measured geometry and isolated read-only DevSDO source snapshots. The clear-connect/ subdirectory contains the Clear Connect application/page assignments and native component read-backs. These are review evidence, not deployment inputs.
The installed sources confirm the reuse boundaries above. No connected call, illustration submission, case completion, catalogue publication or Salesforce deployment was performed during this review.