/omnistudio-flexcard-generate

name: omnistudio-flexcard-generate
description: "OmniStudio FlexCard creation and validation with 130-point scoring. Use when building at-a-glance UI cards, configuring data source bindings to Integration Procedures, or reviewing existing FlexCard definitions for accessibility and performance. TRIGGER when: user creates FlexCards, configures data sources, designs card layouts, or asks about OmniUiCard metadata. DO NOT TRIGGER when: building OmniScripts (use omnistudio-omniscript-generate), creating Integration Procedures (use omnistudio-integration-procedure-generate), or analyzing dependencies (use omnistudio-dependencies-analyze)."
metadata:
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"
  relatedSkills:
    - "experience-lwc-generate"
    - "omnistudio-datamapper-generate"
    - "omnistudio-dependencies-analyze"
    - "omnistudio-integration-procedure-generate"
    - "omnistudio-omniscript-generate"
    - "platform-metadata-deploy"
  version: "1.0"
  minApiVersion: "60.0"

omnistudio-flexcard-generate: OmniStudio FlexCard Creation and Validation

Expert OmniStudio engineer specializing in FlexCard UI components for Salesforce Industries. Generate production-ready FlexCard definitions that display at-a-glance information with declarative data binding, Integration Procedure data sources, conditional rendering, and proper SLDS (Salesforce Lightning Design System) styling. All FlexCards are validated against a **130-point scoring rubric** across 7 categories.

Scope

• **In scope**: Creating and validating OmniStudio FlexCard definitions (`OmniUiCard`); configuring Integration Procedure data sources; designing card layouts, states, and action buttons; scoring against the 130-point rubric; deployment and activation
• **Out of scope**: Building OmniScripts (use `omnistudio-omniscript-generate`), creating Integration Procedures (use `omnistudio-integration-procedure-generate`), mapping full dependency trees (use `omnistudio-dependencies-analyze`), deploying metadata to org (use `platform-metadata-deploy`)

---

Core Responsibilities

1. **FlexCard Authoring**: Design and build FlexCard definitions with proper layout, states, and field mappings 2. **Data Source Binding**: Configure Integration Procedure data sources with correct field mapping and error handling 3. **Test Generation**: Validate cards against multiple data states (populated, empty, error, multi-record) 4. **Documentation**: Produce deployment-ready documentation with data source lineage and action mappings

Document Map

| Need | Document | Description | |------|----------|-------------| | **Best practices** | [references/best-practices.md](references/best-practices.md) | Layout patterns, SLDS, accessibility, performance | | **Data binding** | [references/data-binding-guide.md](references/data-binding-guide.md) | IP sources, field mapping, conditional rendering |

---

CRITICAL: Orchestration Order

FlexCards sit at the presentation layer of the OmniStudio stack. Ensure upstream components exist before building a FlexCard that depends on them.

omnistudio-dependencies-analyze → omnistudio-datamapper-generate → omnistudio-integration-procedure-generate → omnistudio-omniscript-generate → omnistudio-flexcard-generate (you are here)

FlexCards consume data from Integration Procedures and can launch OmniScripts. Build the data layer first, then the presentation layer.

---

Key Insights

| Insight | Detail | |---------|--------| | **Configuration fields** | `OmniUiCard` uses `DataSourceConfig` for data source bindings and `PropertySetConfig` for card layout, states, and actions. There is NO `Definition` field on `OmniUiCard` in Core namespace. | | **Data source binding** | Data sources bind to Integration Procedures for live data; the IP must be active and deployed before the FlexCard can retrieve data | | **Child card embedding** | FlexCards can embed other FlexCards as child cards, enabling composite layouts with shared or independent data sources | | **OmniScript launching** | FlexCards can launch OmniScripts via action buttons, passing context data from the card's data source into the OmniScript's input | | **Designer virtual object** | The FlexCard Designer uses `OmniFlexCardView` as a virtual list object (`/lightning/o/OmniFlexCardView/home`), separate from the `OmniUiCard` sObject where card records are stored. Cards created via API may not appear in "Recently Viewed" until opened in the Designer. |

---

Workflow (5-Phase Pattern)

Phase 1: Requirements Gathering

Before building, clarify these with the stakeholder:

| Question | Why It Matters | |----------|---------------| | What is the card's purpose? | Determines layout type and data density | | Which data sources are needed? | Identifies required Integration Procedures | | What object context does it run in? | Determines record-level vs. list-level display | | What actions should the card expose? | Drives button/link configuration and OmniScript integration | | What layout best fits the use case? | Single card, list, tabbed, or flyout | | Are there conditional display rules? | Fields or sections that appear/hide based on data values |

Phase 2: Design & Layout

Read `references/best-practices.md` for layout patterns, SLDS compliance, accessibility requirements, and performance guidance before designing.

Card Layout Options

| Layout Type | Use Case | Description | |-------------|----------|-------------| | **Single Card** | Record summary | One card displaying fields from a single record | | **Card List** | Related records | Repeating cards bound to an array data source | | **Tabbed Card** | Multi-context | Multiple states displayed as tabs within one card | | **Flyout Card** | Detail on demand | Expandable detail panel triggered from a summary card |

Data Source Configuration

Each FlexCard data source connects to an Integration Procedure (or other source type) and maps response fields to display eleme