Review draft · Fictional records only. Keep employee, payroll, identity and health data out of this preview.
Skip to main content
Shield Health 360Shield operations

Support for your next step

Support route preview
Workspace Shield staffEmployer Cedar & Stone LogisticsCase S360-1048Plan period 2027 · fictional

Who owns this request?

The assigned case owner handles implementation blockers. Access issues go to the Hub access administrator.

No message is sent from this preview
The support service and named production contacts are not connected. This drawer shows the context that would accompany your request.
View sign-in and recovery
Menu
Shield 360 Hub · Product system

One system. Clear next actions.

Reusable patterns for case operations, employer onboarding, and employee decisions. Preview-only behavior is labeled; production integrations remain separate.

01 / Identity & tokens

Shield Health 360 · original logo
Navy
Brand
Action
Canvas

Satoshi · confident headings

Inter · readable labels and precise numbers

4 px spacing base · 46 px actions · 48 px fields · 13/14/15/16/20/26/34 px type · tabular numerals

02 / Actions & states

Census review and plan approval are required.
Hover, focus, pressed, and loading use the same action component.
Draft savedAwaiting approvalProvider rejectedNo decision

03 / Fields & validation

Enter a complete email address.
Permission denied
You can view this plan. Ask the case owner to request a configuration change.
Temporarily unavailable
The provider response is unavailable. Your recorded decision is unchanged.

04 / Dialogs & evidence

Keyboard focus stays inside an open dialog. Escape closes it and returns focus to the trigger. Draft fields stay in place.

  1. ✓ Discovery
  2. 02 Census
  3. 03 Plan setup
  4. 04 Education
  5. 05 Enrollment
Employee education guide
PDF · version 1.2 · sample

05 / Usage rules

01Desktop first for Shield staff and employers. Mobile first for employee enrollment; support both devices for every role.
02One primary next action per screen. Put its reason, owner, and deadline next to it.
03Every status has a text label. Saved, approved, activated, and reconciled are different states.
04Keep employer and plan context visible. Employee identifiers never authenticate a person.
05Use a 1,328 px workspace, 1,088 px employee decision grid and 720 px reading column. Mobile gutters are 20 px.
06Convert rosters to cards below 1,100 px. Preserve name, decision, activation, and required action.
07Never fabricate savings. Missing plan amounts remain visibly unavailable.
08Use original Shield assets. Semantic states and product tokens are provisional until brand review.

Interface states · 15B

These are visual state fixtures. Changing a state does not save a record, change permissions or connect a service.

Review your benefits

Next owner You · enrollment supportPlan period Not available in this state

No offering is available to review

Enrollment support must confirm your employer’s current enrollment window.

Confirm this sample action?

No production action
This dialog demonstrates explicit confirmation, cancellation, and focus management.

Case evidence

Census
Version 2 · format review pending
Plan configuration
Draft · approval pending
Source
Fictional demo records
Preserve evidence
Record versions, actor, timestamp, and next owner. Do not substitute a green badge for approval evidence.

Hub architecture · three workspaces

Target hostname: hub.shieldhealth360.com. After authentication, the private application must resolve authorized memberships and return to a permitted unfinished task. The Framer role previews do not authenticate anyone.

Shield staff

/shield/cases
Cases → case detail → task / evidence

Navigation: Cases; discovery; review; implementation; outreach; launch; enrollment support

Empty state: No assignment → operations lead; create case only with permission

Employer admin

/
Overview → next responsibility → review / submit

Navigation: Information; census; proposal; implementation; education; launch; employees

Empty state: No linked case → Shield contact; preserve supplied details

Employee

/employee/dashboard
Employer context → information → benefits → decision → receipt

Navigation: Enrollment; education; care access; recovery; help

Empty state: No open enrollment → existing receipts and support remain reachable

Workspace recovery and absence states

These are state examples. Retry returns to the example; it does not call a service or change a record.

No enrollment is open for you

You can still retrieve an existing receipt and get help. Enrollment support can check your employer and dates.

Support for your next step

Support route preview
Workspace EmployeeEmployer Not disclosed in this stateCase Not disclosedPlan period 2027 · fictional

Who owns this request?

Enrollment support helps with access, benefit explanations, receipts and correction requests.

No message is sent from this preview
The support service and named production contacts are not connected. This drawer shows the context that would accompany your request.
View sign-in and recovery

Retrieve your recorded decision

The secure application must find receipts by authenticated identity and employment, including prior plan periods. It must not disclose them from an employee ID alone.

Authentication and private receipt lookup are not connected.

Page, drawer or dialog?

Full page
Use for enrollment, long forms, proposal review and signed decisions. Keep context, progress, consequences and support visible.
Drawer
Use for a case blocker, evidence or support while preserving list filters and position. Do not put a full signing journey in a drawer.
Dialog
Use for a short, attributable confirmation or employer-context choice. State the scope and consequence; return focus on close.
Action feedback
Saving is pending; saved means the record exists; approved, transmitted and activated are separate statuses. State previews never claim persistence.

Implementation boundary

Responsive layouts, queues, case creation, employer onboarding, versioned corrections, proposal review, readiness and recovery examples are implemented as synthetic browser demonstrations.

Production authentication, scoped memberships, account recovery, durable server records, private documents and support delivery require the secure application. Browser-saved drafts and role fixtures are simulations, not server permissions.

The new staff and employer Hub journeys share browser-saved synthetic cases. The employee home and earlier workflow demonstrations retain their separate fixtures; this does not establish cross-module production integration.