A good summary at the top of a page does a quiet kindness for the reader. Before they scroll, before they hunt, they already know the most important things. In OmniStudio, that summary is usually a FlexCard. It is the first pillar most beginners meet, and I think that is fitting, because it is the one you can actually see. Let me show you what a FlexCard is and why it feels so natural once you build your first one.

What a FlexCard is

A FlexCard is a declarative, reusable card that displays data and offers actions. “Declarative” means you build it by configuring elements rather than writing code. “Reusable” means once you design it well, you can drop the same card onto a Lightning page, a community site, an OmniScript, or even inside another FlexCard.

Picture the panel at the top of a customer record: the account name, a status badge, a phone number, and a couple of buttons like “Call” or “Open Case.” That whole panel can be a single FlexCard. You assemble it from elements: text fields, images, blocks, actions, charts. You arrange them on a canvas, bind them to data, and the card renders.

Where FlexCards get their data

A card is only as good as what it shows, so a FlexCard needs a data source. Often that source is a DataRaptor, which reads Salesforce records and hands the card a tidy package of data. It can also pull from an Integration Procedure or receive data directly from whatever page hosts it.

The data arrives as JSON, and your elements reference fields by name. If the data has a field called accountStatus, you can merge it into the card with a token like {accountStatus}. That simple binding is the heart of how a FlexCard stays in sync with real records.

A FlexCard is not a static picture. It is a small, living view that changes its face to match the data behind it.

States: one card, many faces

Here is the feature that makes FlexCards feel alive. A single FlexCard can have multiple states, and it shows the state whose conditions match the current data.

Imagine an account card. When the status is Active, you want a green badge and an “Open Case” button. When the status is Closed, you want a grey badge and the button hidden. Rather than building two cards, you build one card with two states and a condition on each. The card decides which face to wear.

This is also how conditional display works on individual elements. You can tell a single button or field to appear only when a condition is true, like showing a “Renew” link only when a contract is near its end date. The result is a card that feels thoughtful, never cluttered.

Actions: cards that do things

FlexCards are not only for reading. An action element lets a user start something from the card: navigate to another page, open a flow, fire an event, or launch an OmniScript. This is the bridge from looking to doing.

A common pattern is a summary FlexCard with a button that launches an OmniScript. The user sees the customer at a glance, presses a button, and steps into a guided flow to update their details. The card displays; the script collects. Each tool stays in its lane, and the experience feels seamless.

A gentle word on building well

When I teach a new instrument, I tell students to learn one clean phrase before attempting the whole piece. FlexCards reward the same patience. Start with one element bound to one field. Confirm it shows real data. Then add a state. Then add an action. Building in small, verified steps keeps you from chasing mysterious blank cards, which are almost always a data-binding mismatch rather than a deep problem.

Keep cards focused, too. A FlexCard that tries to show everything becomes hard to reuse. Smaller, purpose-built cards, like a “Contact Summary” card and a “Recent Orders” card, can be composed together and reused across pages. That reuse is much of the value OmniStudio promises.

If you want the full picture of where FlexCards sit among the other tools, What Is OmniStudio? lays out all four pillars side by side. But honestly, building one real card teaches more than any diagram. Bind a field, see your data appear, and the idea clicks.

Your next step

Now that the visible layer makes sense, follow the data and the flow:

Mustafa Aksu

Salesforce developer & ISV builder focused on Revenue Cloud, Agentforce, and Data Cloud. I write from real, shipped work.