FlexCard
A FlexCard is an OmniStudio component that displays formatted, read-only data from one or more sources inside a configurable card layout.
Definition
A FlexCard is an OmniStudio component that displays formatted, read-only data from one or more sources inside a configurable card layout. It pulls fields from Salesforce objects, external systems, and computed values, then shows them in a single visual surface. A common example is an account summary card with the customer tier, current balance, a list of recent cases, and a few action buttons. FlexCards live on Lightning record pages, inside OmniScripts, on Experience Cloud sites, and in external containers.
FlexCards are part of OmniStudio, the toolset Salesforce gained from the Vlocity acquisition and now ships across its Industries products. You build one in the FlexCard Designer, a drag-and-drop canvas where you place fields, blocks, charts, and buttons without writing a Lightning Web Component by hand. The card reads its data from a Data Mapper (formerly DataRaptor), an Integration Procedure, a custom Apex method, or another FlexCard, then maps the returned JSON to each display element.
How a FlexCard renders data on a record page
Picking a data source
Every FlexCard has a data source that supplies the values it shows. You configure it in the Setup panel of the FlexCard Designer. The most common choice is a Data Mapper Extract that reads fields straight from Salesforce objects. When the card needs to blend Salesforce records with an external API response, an Integration Procedure is the right pick because it orchestrates several calls server-side and returns one combined payload. You can also point a card at a custom Apex method or at another FlexCard. Whatever the source, it returns structured JSON, and the FlexCard maps JSON paths to fields on the canvas. A card can read from more than one source at once, which lets a single surface combine account data, billing data, and case data without a custom component. The Data JSON panel in the designer shows the raw response so you can confirm each path resolves before you style anything. Getting the source right early saves rework, because the field bindings all depend on the shape of that JSON.
The designer canvas and its panels
The FlexCard Designer is a WYSIWYG editor split into a few panels. The Build panel on the left holds Fields (driven by your data source) and Display elements: text, images, icons, blocks, actions, charts, menus, and datatables. You drag these onto the central canvas and arrange them. Select any element and the Properties panel lets you set its label, choose which data field value to display, and pick the field type. The Style panel handles backgrounds, borders, padding, fonts, and responsive sizing in real time, so the card looks right on desktop and mobile. The Setup panel manages the data source, custom permissions, tracking, session variables, and event listeners. Blocks group related elements and can be shown or hidden by condition, so a section appears only when a value is present. You can nest a child FlexCard inside a parent with no documented limit on depth, which is how teams reuse a small card (a single contact tile, say) across many larger layouts.
States and conditional display
A FlexCard can define multiple states, each a different version of the card that shows based on the underlying data. An order card might render a green state when status is Shipped, an amber state when it is Pending, and a plain state otherwise. Conditions decide which state wins and which elements draw, so the same card adapts to whatever record loads it. This is one of the features that makes FlexCards more than a static template. Beyond full states, individual blocks and fields carry their own conditional visibility, evaluated against the data source JSON. The result is a card that handles the messy reality of production records, where optional fields are blank and lists are sometimes empty. Designers test these conditions with the Test Parameters and Data JSON tools in preview, feeding real record IDs to confirm each state triggers as intended. Without states, you would build several near-identical cards and toggle them in App Builder, which is harder to maintain.
Actions, flyouts, and events
FlexCards are read-only for data, but they are interactive through actions. An action button can navigate to another record or URL, launch an OmniScript, open a flyout, update a field, or fire a custom event that another component listens for. The classic pattern is a Pay Now button on an invoice card that opens a payment OmniScript, passing the invoice context along. Flyouts deserve their own mention: a flyout shows details on demand in a child FlexCard or OmniScript that slides over the page, so the parent card stays compact while deeper data is one click away. Events let FlexCards talk to each other and to the wider page through a publish and subscribe model, which is how selecting a row in one card can refresh another. The Action Debugger in the designer captures each action and event request and response, so you can trace why a button did or did not do what you expected. Together these turn a data display into the start and end point of a customer transaction.
Where FlexCards run, and the LWC under the hood
When you activate a FlexCard, the platform compiles it into a Lightning Web Component behind the scenes. That compiled component is what you drop onto a Lightning record page in the Lightning App Builder, or onto an Experience Cloud page in Experience Builder. Because the output is a real LWC, you can also embed a FlexCard inside your own custom component using the lightning-omnistudio-flexcard wrapper, passing the card name and the records it should display. FlexCards reach beyond the core app too: they render on any device, inside OmniScripts, in external content systems such as Adobe Experience Manager, and in custom web containers like Heroku. This portability is a big reason Industries customers lean on them. One important gotcha is that many FlexCard validation errors surface only at runtime preview, not at deploy time, so a card can activate cleanly and still misbehave until you test it against a live record.
Versioning, activation, and the deployment lifecycle
FlexCards follow a version lifecycle. A card you are editing is a draft; activating it compiles the LWC and makes that version live on every page that references the card. The previously active version is kept, so you can roll back if a release goes wrong. Teams managing many cards treat activation as a deliberate step in their release process rather than an afterthought. The metadata is exportable, which means you can track FlexCards in Git through Salesforce DX and move them between sandboxes and production with the rest of your source. This adds discipline the designer UI alone does not enforce. Caching is part of the performance picture: the underlying Data Mapper or Integration Procedure can cache its result for a set time, which cuts SOQL load on frequently viewed records. For live values such as a current balance, you turn caching off so the card always reads fresh. Tuning cache per card, against how stale the data is allowed to be, keeps pages fast without showing wrong numbers.
Managed Package versus OmniStudio Standard
For years OmniStudio shipped as a managed package you installed and updated separately from the core platform. Salesforce now offers OmniStudio Standard, a runtime built natively into the Salesforce Platform. Standard activates instantly, skips the install and upgrade steps, and Salesforce reports performance up to nine times faster than the legacy package for the same work. New customers with an Industries license get the standard designers without installing anything; existing managed-package users migrate to reach them. The standard FlexCard Designer was reworked to be more intuitive, with elements on the left, the canvas in the center, and properties on the right, and creating a card now takes about two clicks. The same migration renamed DataRaptor to Data Mapper across the tooling, though existing FlexCards keep their name and continue to work. If you are documenting or building today, know which edition an org runs, because the designer layout and some terminology differ between the package and the standard runtime.
How to build a FlexCard in the FlexCard Designer
You build a FlexCard in the FlexCard Designer, an OmniStudio tool. The flow is the same idea on the managed package and on OmniStudio Standard, though the standard designer is more streamlined. Confirm OmniStudio is enabled and you have a data source ready (a Data Mapper or Integration Procedure) before you start.
- Create the FlexCard
Open the OmniStudio FlexCards tab and create a new FlexCard. Give it a name, optional title and subtitle, and save. On OmniStudio Standard this takes about two clicks.
- Set the data source
In the Setup panel, choose the data source: a Data Mapper Extract for plain Salesforce fields, or an Integration Procedure when you need to blend systems. Run it once so the Data JSON panel shows the returned structure.
- Build the layout
From the Build panel, drag fields, blocks, images, and charts onto the canvas. For each field, pick the JSON path from your data source, then set labels and types in the Properties panel and styling in the Style panel.
- Add states and actions
Define states so the card changes by condition, and add action buttons that navigate, launch an OmniScript, open a flyout, or fire an event. Use the Action Debugger to confirm each action works.
- Preview, activate, and place
Preview against a real record ID across device viewports, fix anything the Data JSON panel reveals, then Activate. Drop the card onto a Lightning record page in App Builder or an Experience Cloud page in Experience Builder.
The unique API name of the FlexCard. You reference this name when embedding the card in App Builder, Experience Builder, an OmniScript, or a custom LWC wrapper.
Where the card reads its values. A Data Mapper Extract, an Integration Procedure, an Apex method, or another FlexCard. Without a source, fields have nothing to bind to.
A FlexCard must be activated before it renders on a page. Activation compiles the card into a Lightning Web Component and makes that version live.
- Many validation errors appear only at runtime preview, not at deploy time. A card can activate cleanly and still break against a live record, so always test with real data.
- Caching lives on the data source, not the card. Leave it on for stable lookups and turn it off for live values like balances, or the card will show stale numbers.
- Designer layout and some labels differ between the OmniStudio managed package and OmniStudio Standard. Confirm which edition the org runs before following older screenshots.
Prefer this walkthrough as its own page? How to FlexCard in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on FlexCard.
Hands-on resources to go deeper on FlexCard.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. A FlexCard typically pulls the values it displays from which kind of source?
Q2. FlexCards belong to which Salesforce toolset, and how are they primarily authored by builders?
Q3. How does a designed FlexCard end up rendering with live data on a Lightning record page?
Discussion
Loading discussion…