omnistudio-flexcard-generate

Name: omnistudio-flexcard-generate
Author: forcedotcom

744stars272forks

How to install omnistudio-flexcard-generate?

forcedotcom/sf-skills/omnistudio-flexcard-generate

$npx -y skills add forcedotcom/sf-skills --skill omnistudio-flexcard-generate

Installs into the current project.

Summary

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 FlexCar

Files · 1

View on GitHub

SKILL.md

1	# omnistudio-flexcard-generate: OmniStudio FlexCard Creation and Validation
2
3	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.
4
5	## Scope
6
7	- 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
8	- 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`)
9
10	---
11
12	## Core Responsibilities
13
14	1. FlexCard Authoring: Design and build FlexCard definitions with proper layout, states, and field mappings
15	2. Data Source Binding: Configure Integration Procedure data sources with correct field mapping and error handling
16	3. Test Generation: Validate cards against multiple data states (populated, empty, error, multi-record)
17	4. Documentation: Produce deployment-ready documentation with data source lineage and action mappings
18
19	## Document Map
20
21	\| Need \| Document \| Description \|
22	\|------\|----------\|-------------\|
23	\| Best practices \| [references/best-practices.md](references/best-practices.md) \| Layout patterns, SLDS, accessibility, performance \|
24	\| Data binding \| [references/data-binding-guide.md](references/data-binding-guide.md) \| IP sources, field mapping, conditional rendering \|
25
26	---
27
28	## CRITICAL: Orchestration Order
29
30	FlexCards sit at the presentation layer of the OmniStudio stack. Ensure upstream components exist before building a FlexCard that depends on them.
31
32	```text
33	omnistudio-dependencies-analyze → omnistudio-datamapper-generate → omnistudio-integration-procedure-generate → omnistudio-omniscript-generate → omnistudio-flexcard-generate (you are here)
34	```
35
36	FlexCards consume data from Integration Procedures and can launch OmniScripts. Build the data layer first, then the presentation layer.
37
38	---
39
40	## Key Insights
41
42	\| Insight \| Detail \|
43	\|---------\|--------\|
44	\| 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. \|
45	\| 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 \|
46	\| Child card embedding \| FlexCards can embed other FlexCards as child cards, enabling composite layouts with shared or independent data sources \|
47	\| OmniScript launching \| FlexCards can launch OmniScripts via action buttons, passing context data from the card's data source into the OmniScript's input \|
48	\| 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. \|
49
50	---
51
52	## Workflow (5-Phase Pattern)
53
54	### Phase 1: Requirements Gathering
55
56	Before building, clarify these with the stakeholder:
57
58	\| Question \| Why It Matters \|
59	\|----------\|---------------\|
60	\| What is the card's purpose? \| Determines layout type and data density \|
61	\| Which data sources are needed? \| Identifies required Integration Procedures \|
62	\| What object context does it run in? \| Determines record-level vs. list-level display \|
63	\| What actions should the card expose? \| Drives button/link configuration and OmniScript integration \|
64	\| What layout best fits the use case? \| Single card, list, tabbed, or flyout \|
65	\| Are there conditional display rules? \| Fields or sections that appear/hide based on data values \|
66
67	### Phase 2: Design & Layout
68
69	Read `references/best-practices.md` for layout patterns, SLDS compliance, accessibility requireme

People who liked this also viewed

6 picks

Type

omnistudio-flexcard-generate

744stars272forks

View on GitHub

How to install omnistudio-flexcard-generate?

forcedotcom/sf-skills/omnistudio-flexcard-generate

$npx -y skills add forcedotcom/sf-skills --skill omnistudio-flexcard-generate

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# omnistudio-flexcard-generate: OmniStudio FlexCard Creation and Validation
2
3	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.
4
5	## Scope
6
7	- 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
8	- 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`)
9
10	---
11
12	## Core Responsibilities
13
14	1. FlexCard Authoring: Design and build FlexCard definitions with proper layout, states, and field mappings
15	2. Data Source Binding: Configure Integration Procedure data sources with correct field mapping and error handling
16	3. Test Generation: Validate cards against multiple data states (populated, empty, error, multi-record)
17	4. Documentation: Produce deployment-ready documentation with data source lineage and action mappings
18
19	## Document Map
20
21	\| Need \| Document \| Description \|
22	\|------\|----------\|-------------\|
23	\| Best practices \| [references/best-practices.md](references/best-practices.md) \| Layout patterns, SLDS, accessibility, performance \|
24	\| Data binding \| [references/data-binding-guide.md](references/data-binding-guide.md) \| IP sources, field mapping, conditional rendering \|
25
26	---
27
28	## CRITICAL: Orchestration Order
29
30	FlexCards sit at the presentation layer of the OmniStudio stack. Ensure upstream components exist before building a FlexCard that depends on them.
31
32	```text
33	omnistudio-dependencies-analyze → omnistudio-datamapper-generate → omnistudio-integration-procedure-generate → omnistudio-omniscript-generate → omnistudio-flexcard-generate (you are here)
34	```
35
36	FlexCards consume data from Integration Procedures and can launch OmniScripts. Build the data layer first, then the presentation layer.
37
38	---
39
40	## Key Insights
41
42	\| Insight \| Detail \|
43	\|---------\|--------\|
44	\| 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. \|
45	\| 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 \|
46	\| Child card embedding \| FlexCards can embed other FlexCards as child cards, enabling composite layouts with shared or independent data sources \|
47	\| OmniScript launching \| FlexCards can launch OmniScripts via action buttons, passing context data from the card's data source into the OmniScript's input \|
48	\| 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. \|
49
50	---
51
52	## Workflow (5-Phase Pattern)
53
54	### Phase 1: Requirements Gathering
55
56	Before building, clarify these with the stakeholder:
57
58	\| Question \| Why It Matters \|
59	\|----------\|---------------\|
60	\| What is the card's purpose? \| Determines layout type and data density \|
61	\| Which data sources are needed? \| Identifies required Integration Procedures \|
62	\| What object context does it run in? \| Determines record-level vs. list-level display \|
63	\| What actions should the card expose? \| Drives button/link configuration and OmniScript integration \|
64	\| What layout best fits the use case? \| Single card, list, tabbed, or flyout \|
65	\| Are there conditional display rules? \| Fields or sections that appear/hide based on data values \|
66
67	### Phase 2: Design & Layout
68
69	Read `references/best-practices.md` for layout patterns, SLDS compliance, accessibility requireme

People who liked this also viewed

6 picks

Type