8.3 FlexCard Architecture, Constituent 360 Layouts & Action Frameworks

8.3 FlexCard Architecture, Constituent 360 Layouts & Action Frameworks

Exam Focus: FlexCards form the visual presentation backbone of Salesforce Public Sector Solutions, delivering responsive, contextual micro-interfaces for both internal caseworkers in the Service Console and external citizens on Experience Cloud. On the AP-222 exam, candidates must master FlexCard states and conditional styling, flyout detail panels, nested child cards, multi-source data architectures (especially Integration Procedures), the declarative Action Framework, and high-performance caching strategies for high-volume citizen portals.

---

FlexCard Architecture & The Constituent 360 Vision

In public sector administration, caseworkers and citizens struggle with fragmented information systems. A social worker managing a child welfare case may have to click across 12 different database objects to view parent demographics, foster home certifications, recent home inspection visits, and open service requests. Similarly, a commercial restaurant owner logging into a citizen portal expects a unified dashboard summarizing all active health permits, liquor authorizations, upcoming fire inspection appointments, and outstanding municipal fees in a single glance.

FlexCards fulfill this Constituent 360 vision. A FlexCard is a modular, declarative UI component that summarizes contextual information and delivers actionable buttons tailored to specific user roles:

• Native LWC Compilation: Like OmniScripts, FlexCards compile directly into standard Lightning Web Components (LWC). They execute natively in the browser, adhere to Salesforce Lightning Design System (SLDS) styling rules, and deliver outstanding client-side rendering speed.
• Fluid 12-Column Responsive Layout: FlexCards leverage a 12-column responsive grid layout. Administrators can configure card elements to span 12 columns on mobile screens, 6 columns on tablets, and 4 columns on desktop monitors, ensuring seamless operation across field inspector smartphones and desktop caseworker consoles.
• Dual Deployment Footprint: A single FlexCard design can be deployed across internal and external workspaces:
  • Internal Service Console: Constituent Summary Header cards, Active Authorization cards, Recent Inspection Timelines, and Violation Warning sidebars.
  • External Experience Cloud Portals: Constituent "My Applications" hubs, "Renew Your License" cards, and "Upcoming Inspection Schedule" self-service widgets.

---

FlexCard States, Conditions, Flyouts & Child FlexCards

The power of FlexCards lies in their ability to dynamically alter their appearance, data display, and available actions based on real-time business data.

+-----------------------------------------------------------------------------------+
| FlexCard Multi-State Evaluation Engine                                            |
+-----------------------------------------------------------------------------------+
| Record Data Ingested: { Status: 'Revoked', ExpirationDate: '2026-08-15', ... }    |
|                                                                                   |
| [State 1 Check] Condition: Status == 'Revoked'                                   |
|   --> MATCH! Render Red Emergency Banner, Warning Icon, & "File Appeal" Action     |
|   --> (Engine halts evaluation; lower states are skipped)                         |
|                                                                                   |
| [State 2 Check] Condition: Status == 'Expiring Soon'                              |
|   --> (Skipped)                                                                   |
|                                                                                   |
| [State 3 Check] Condition: Status == 'Active'                                     |
|   --> (Skipped)                                                                   |
|                                                                                   |
| [Default State] Fallback state when no conditions evaluate to True                |
|   --> (Skipped)                                                                   |
+-----------------------------------------------------------------------------------+

1. The FlexCard State Machine

A single FlexCard can contain multiple States. Each State represents a distinct visual layout tailored to a specific operational lifecycle stage:

• Top-to-Bottom Evaluation: The FlexCard runtime evaluates state conditions sequentially from top to bottom. The first state whose condition evaluates to true is rendered. Once a state matches, the engine halts evaluation.
• State Conditions: Conditions evaluate incoming JSON attributes using standard operators (=, !=, >, <, LIKE).
• The Default / Blank State: Every FlexCard includes a Default State that renders when none of the conditional states match, ensuring the card never displays as a blank broken container.

Public Sector State Example: A FlexCard displaying a BusinessLicenseApplication:

• State 1 (Enforcement Hold): Triggered when HasUnresolvedViolations == true. Displays a prominent red warning banner, displays the code violation citation number, and disables the "Renew License" button.
• State 2 (Expiring Soon): Triggered when DaysUntilExpiration <= 30. Displays an amber warning badge, highlights the expiration date, and renders a prominent blue "Renew Now" OmniScript action button.
• State 3 (Active Good Standing): Triggered when Status == 'Active'. Displays a green "Good Standing" badge and renders a "Download Certificate" action.

2. Flyouts: Progressive Disclosure Without Page Reloads

A Flyout is an expandable detail panel that opens when a user interacts with a FlexCard action (such as clicking "View Inspection History" or "View Fee Breakdown").

• Rendering Modalities: Flyouts can render as a modal popup window, an inline accordion drawer that slides down within the card, or a side drawer.
• Flyout Content: A Flyout can host another child FlexCard, an embedded OmniScript, or a custom LWC.
• Operational Benefit: Flyouts eliminate context-switching. A caseworker reviewing a primary Account record can inspect 5 historical inspection visits and individual code violation details inside a flyout without leaving the constituent console or closing their primary workspace tab.

3. Nested Child FlexCards

FlexCards support hierarchical, parent-child architectures. When an Integration Procedure returns a parent object with a nested array of child records (e.g., an Account containing an array of ActiveLicenses), the parent FlexCard can embed a Child FlexCard:

• The parent card iterates over the child JSON array, rendering an instance of the Child FlexCard for each record in the list.
• The parent passes context and records down to the child card via the {records} context attribute.
• Child cards can fire events that notify the parent card when data changes, enabling synchronized UI updates.

---

FlexCard Data Sources: Architectural Patterns

FlexCards can retrieve data from a wide variety of backend sources. Choosing the appropriate data source is a primary architectural competency tested on the AP-222 exam.

---

The FlexCard Action Framework

A Constituent 360 card must be actionable, not merely informative. The FlexCard Action Framework provides a declarative configuration suite to attach interactive behaviors to buttons, icons, menu items, or entire card surfaces.

[FlexCard Action Types]
  ├── 1. OmniScript Action ───────► Launches Guided Intake (e.g., "Renew License")
  ├── 2. Navigate Action ─────────► Redirects to Record Page, URL, or App Page
  ├── 3. Event Action (PubSub) ───► Broadcasts Event to Sibling Cards / LWCs
  ├── 4. Card Action ─────────────► Toggles Flyout, Reloads Data, or Closes Card
  └── 5. Update Field Action ─────► Executes Instant Inline Record Field Updates

Action Types and Mechanics

1. OmniScript Action: The premier public sector action. Launches a targeted OmniScript modal or standalone flow, passing contextual parameters directly from the card record (e.g., ContextId={Id}&licenseType={Type}&renewalPeriod=2026).
2. Navigate Action: Seamlessly routes the user to standard Salesforce records, external government websites, Experience Cloud pages, or object list views.
3. Event Action (PubSub & DOM Events): Enables inter-component communication. When an intake worker clicks a specific citizen account card, the card fires an event via the PubSub event bus. Sibling FlexCards on the same console page (e.g., an Open Cases card and an Active Violations card) listen for the event and automatically refresh their data to match the selected citizen.
4. Card Action: Controls internal card state, such as opening or closing a Flyout panel, toggling between edit and view modes, or triggering a manual card data reload.
5. Update Field Action: Updates a record field directly in the database without opening an edit modal or navigating away, ideal for quick caseworker status toggles (e.g., marking a record as Reviewed).

---

High-Volume Citizen Portal Performance & OmniStudio Caching Strategies

Public sector portals face dramatic traffic spikes. When an agency opens annual commercial cannabis renewal windows, announces emergency disaster grant disbursements, or launches lottery-based pre-school enrollment, citizen portals experience 500% to 1,000% surges in concurrent constituent visits. Without an enterprise caching architecture, database governor limits are quickly breached, resulting in catastrophic service outages.

OmniStudio delivers a multi-tier caching architecture to safeguard high-volume portal performance:

+-----------------------------------------------------------------------------------+
| Multi-Tier OmniStudio Caching Architecture                                        |
+-----------------------------------------------------------------------------------+
| [Tier 1: Client-Side Browser Cache]                                               |
| • Compiled FlexCard LWC metadata & static layout assets cached in browser         |
| • Eliminates redundant component definition requests across page views           |
+-----------------------------------------------------------------------------------+
| [Tier 2: Platform Cache - Session Cache]                                          |
| • Caches user-specific session data (e.g., constituent's pre-calculated profile)   |
| • Persists across the user's active portal session; isolated to individual user  |
+-----------------------------------------------------------------------------------+
| [Tier 3: Platform Cache - Org Cache]                                              |
| • Caches non-user-specific global public data (statutory fee schedules, codes)   |
| • Shared across all 100,000+ portal visitors; bypasses SOQL and CPU limits       |
+-----------------------------------------------------------------------------------+
| [Tier 4: Server Database Layer (PSS Standard Objects)]                            |
| • BusinessLicenseApplication, RegulatoryAuthorizationType, Account               |
+-----------------------------------------------------------------------------------+

Configuring Integration Procedure Caching

Because Integration Procedures serve as the primary data source for FlexCards, architects configure caching directly within the IP settings:

• Cache Results: Toggles caching for the entire Integration Procedure response.
• Cache Type:
  • Select Session Cache for constituent-specific data (e.g., active applications belonging to the logged-in citizen).
  • Select Org Cache for universal agency data shared across all constituents (e.g., standard fee matrices, licensing code glossaries, municipal office locations).
• Cache Timeout (TTL): Specifies the time-to-live in minutes or seconds (e.g., setting TTL to 120 minutes for statutory code definitions, or 5 minutes for active application status). When subsequent requests arrive within the TTL window, the Integration Procedure returns the cached response directly from memory, consuming 0 SOQL queries and near-zero server CPU time.

---

FlexCards vs. Standard Lightning Record Pages: Public Sector Decision Matrix

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: Comprehensive Constituent 360 Console for Case Managers

A county child and family services agency implements the Public Sector Service Console for 200 child welfare caseworkers. When a caseworker opens a Person Account representing a primary guardian, they must immediately see a top summary card showing guardian contact info, open safety cases, an emergency red alert banner if an active protective order exists, and a button to launch an emergency home visit OmniScript.

How should the Lead Architect design this solution using FlexCards?

• Create a Constituent 360 Header FlexCard positioned at the top of the Person Account Lightning Record Page.
• Configure an Integration Procedure as the data source that queries the Account, related Case records, and protective orders via AccountContactRelation.
• Define two visual States in the FlexCard:
  • State 1 (Safety Warning): Condition HasActiveProtectiveOrder == true. Styled with a high-visibility SLDS red banner, displaying the order number and emergency contact numbers.
  • Default State: Renders standard guardian contact info and open case counts.
• Add an Action Framework button configured as an OmniScript Action that launches the EmergencyHomeVisit OmniScript, passing ContextId={recordId} and guardianName={Name} as input parameters.

Scenario 2: High-Volume Citizen Portal with Cached Integration Procedures

A state commercial licensing department experiences massive traffic spikes on July 1st, when 50,000 commercial transport companies renew their annual fleet permits. The portal home page features a FlexCard displaying active permits, statutory renewal fee tables, and current road restriction notices. During the previous renewal cycle, the portal crashed due to SOQL query governor limit exhaustion on the Account and RegulatoryAuthorizationType objects.

What architectural modifications must the consultant implement to prevent outages?

• Set the FlexCard data source to an Integration Procedure that separates constituent-specific data from static agency information.
• For universal regulatory fee tables and road restriction notices, configure an Integration Procedure step that stores and reads data from the Platform Cache (Org Cache) with a 24-hour TTL, completely eliminating database queries for static data.
• For the active fleet permit list, enable Platform Cache (Session Cache) with a 15-minute TTL, ensuring that repeated page refreshes by the constituent do not generate repeated SOQL queries against BusinessLicense or RegulatoryAuthorizationType.
• Configure the "Renew Permit" button as a FlexCard OmniScript Action, passing the cached permit ID directly into the intake OmniScript.