FlexCard Pattern #2: Display Data From a Single Record

Simple but powerful – pull a single Salesforce record into your FlexCard. This post is part of the FlexCard Design Thinking mini series.

This pattern assumes you want a FlexCard to appear on a record page and need to use the current record’s Id to display data from the record in the card. You can modify this pattern to do other things, but first, to the basics.

---

Benefits / Lessons Learned

• Cards can be fed the current record page’s record Id, just like with custom Lightning components.
• I can use cards to show a more formatted version of a record layout, especially in Experience Cloud sites where a record might really need to appear more like content.
• Multiple cards can share a DataRaptor, so I don’t always have to create one. After I created my first card, I just cloned it to start others (meaning I only had to configure a card to use a DataRaptor once). Changing that single DataRaptor means that all cards will be affected though, so I have to be careful not to break it.
• I can create conditions that hide fields and other content when they are blank or unnecessary for the current view.
• I learned way too late that FlexCards can pass more than a record Id to its DataRaptor – you can pass lots of context variables available via the FlexCard designer, but you can also pass static values, too. Like a status. If I had learned this sooner, I could have built less DataRaptors, but instead I built lots of them (one for a card that shows applications when Status = Draft and another when Status = Submitted). Live and learn.
• You can often refer to variable names from your DataRaptor even in places where they don’t pre-populate (e.g. an Action button label, URL, conditional visibility setting).
• When I break up complicated cards into child cards, it has a bit of a performance improvement… instead of the user waiting for one big card to load, the cards load independently. For me, this had the effect of cards at the top loading faster than the ones at the bottom of the page, which was fine because they’ve loaded by the time the user scrolls to them.

---

Moving Parts

This pattern includes the following moving parts.

• FlexCard, placed on a community or Lightning record page.
• Data source: 1 x DataRaptor (type = Extract) that queries the one object and outputs all field values for the returned record. The DataRaptor requires an input parameter: the current record Id.
  • To build this DataRaptor, check out DataRaptor: Extract a Single Record.
• On your FlexCard, you’ll need to configure the DataRaptor and the input parameter(s). On the Setup tab:
  • Data Source Type:  DataRaptor
  • Interface Name:  name_of_your_extract_DataRaptor
  • In the Input Map section, click “Add New” and create a new pair:
    • Key:  name_of_your_input_parameter
      This is found in your DataRaptor (e.g. CurrentRecordId).
    • Value:  {recordId}
      This is a standard context variable available for a FlexCard that will appear on a record page. Include the curly brackets.
  • In the Test Parameters section, you’ll have an entry auto-created to match your input parameter. Add a test record Id to the Value field.
  • Click the “Save & Fetch” button. This tests your DataRaptor with the test record Id you provided. It also populates some of the drop-down menus in the FlexCard Designer with the field variables names from your DataRaptor so that you can reference while building your card.

---

Example #1

In this example, I used three FlexCards to display the different parts of a record page in an Experience Cloud site for the purposes of better branding/formatting.

All three cards display data from the current record using the same DataRaptor. To build it, see DataRaptor: Extract a Single Record.

FlexCard #1 replaces the standard header component.

FlexCard #2 presents long text fields as if they are paragraphs and sections on the page.

FlexCard #3 shows some additional record fields in a more formatted way, including an Apply Now button that conditionally displays based on the record’s status field.

The final FlexCard (#4) is a static content card (see FlexCard Pattern #1: Display Static Content).

---