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

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

Workflow (5-Phase Pattern)

Phase 1: Requirements Gathering

Before building, clarify these with the stakeholder:

Phase 2: Design & Layout

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

Card Layout Options

Data Source Configuration

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

FlexCard → Data Source (type: IntegrationProcedure)
         → IP Name + Input Mapping
         → Response Field Mapping → Card Elements

• Map IP response fields to card display elements using {datasource.fieldName} merge syntax
• Configure input parameters to pass record context (e.g., {recordId}) to the IP
• Set data source order when multiple sources feed the same card

Action Button Design

Conditional Visibility

• Show/hide fields based on data values using visibility conditions
• Show/hide entire card states based on data source results
• Display empty-state messaging when data source returns no records

Phase 3: Generation & Validation

Read references/data-binding-guide.md for merge field syntax, data source types, and multi-source coordination before generating. Read references/scoring-rubric.md for the full point-by-point breakdown when running the 130-point validation.

1. Generate the FlexCard definition JSON
2. Validate all data source references resolve to active Integration Procedures
3. Run the 130-point scoring rubric (see Scoring section below)
4. Verify merge field syntax matches IP response structure
5. Check accessibility attributes on all interactive elements

Phase 4: Deployment

1. Ensure all upstream Integration Procedures are deployed and active
2. Run a dry-run check: use the platform-metadata-deploy skill with --dry-run before committing
3. Deploy the FlexCard metadata (OmniUiCard) — sf project deploy start is safe to re-run; it upserts existing records
4. Activate the FlexCard in the target org
5. Embed the FlexCard in the target Lightning page, OmniScript, or parent FlexCard
6. If deploy fails: check error output for specific cause — common issues: upstream IP not deployed (Cannot find OmniIntegrationProcedure), missing namespace prefix (Entity not found), or FlexCard still in Draft status (activate before retrieving)

Phase 5: Testing

Test each FlexCard against multiple data scenarios:

Generation Guardrails

Avoid these patterns when generating FlexCard definitions:

Scoring Rubric (130 Points)

All FlexCards are validated against 7 categories. Thresholds: [PASS] 90+ (Deploy) | [VERIFY] 67-89 (Review) | [BLOCK] <67 (Block - fix required)

Read references/scoring-rubric.md for the full per-criterion breakdown of all 7 categories.

CLI Commands

Read scripts/flexcard-commands.sh for all FlexCard CLI commands (query, retrieve, deploy). Replace <org> with your org alias and <Name> with the FlexCard API name.

Data Source Binding

FlexCard Data Source Configuration

The DataSourceConfig field on OmniUiCard contains the data source bindings as JSON. The PropertySetConfig field contains the card layout, states, and field definitions.

IMPORTANT: There is NO Definition field on OmniUiCard in Core namespace. Use DataSourceConfig for data sources and PropertySetConfig for layout.

Read assets/omni-ui-card.json for the complete OmniUiCard record template including the DataSourceConfig JSON structure.

Data Source Types

Field Mapping from IP Response

Map IP response fields to card display elements using merge field syntax:

IP Response:                    FlexCard Merge Field:
─────────────                   ─────────────────────
{ "Name": "Acme Corp" }   →    {Name}
{ "Account": {            →    {Account.Name}
    "Name": "Acme Corp"
  }
}
{ "records": [             →    {records[0].Name}  (single)
    { "Name": "Acme" }          or iterate with Card List layout
  ]
}

Input Parameter Mapping

Pass context from the hosting page into the IP data source:

Cross-Skill Integration

Gotchas

FlexCard vs LWC Decision Guide

Dependencies

Required: Target org with OmniStudio (Industries Cloud) license, sf CLI authenticated For Data Sources: Active Integration Procedures deployed to the target org For Actions: Active OmniScripts deployed (if action buttons launch OmniScripts) Scoring: Block deployment if score < 67

Idempotency: sf project deploy start upserts metadata — safe to re-run without creating duplicates. Query first to confirm current state: see scripts/flexcard-commands.sh.

Namespace handling: In managed-package orgs, the metadata type may be prefixed (e.g., omnistudio__OmniUiCard). Check sfdx-project.json for the namespace. See scripts/flexcard-commands.sh for the namespaced deploy command.

Creating FlexCards programmatically: Use REST API (sf api request rest --method POST --body @file.json). Required fields: Name, VersionNumber, OmniUiCardType (e.g., Child). Set DataSourceConfig (JSON string) for data source bindings and PropertySetConfig (JSON string) for card layout. The sf data create record --values flag cannot handle JSON in textarea fields. Activate by updating IsActive=true after creation.

Output Expectations

Deliverables produced by this skill:

• FlexCard JSON definition (assets/omni-ui-card.json template) — OmniUiCard record ready for REST API creation or metadata deployment
• Data source binding block — DataSourceConfig JSON mapping Integration Procedure inputs and response fields to card elements
• Card layout config — PropertySetConfig JSON defining card states, field display, conditional visibility, and action buttons
• Validation report — 130-point score across 7 categories with deploy/review/block threshold result
• Deployment checklist — confirms upstream IPs are active, FlexCard is activated, and embedded in target Lightning page or parent FlexCard

External References

• OmniStudio FlexCards (Trailhead) — Official learning module for FlexCard fundamentals and guided setup
• OmniStudio Developer Guide — Technical reference for FlexCard metadata, data source configuration, and component properties
• Salesforce Industries Documentation — FlexCard configuration guide covering layout, states, and actions

Reference File Index

Pre-Delivery Checklist

• Upstream Integration Procedures exist and are active before FlexCard depends on them
• Orchestration order followed (FlexCard is last in the chain)