Card-List Rendering

Whenever a REDA AI agent needs to show a list of records in chat — open cases, available time slots, search results, line items — it renders the list as a stack of native cards: a bold title, supporting metadata, optional coloured status badges, and an optional action button on each card. Cards work consistently across every chat surface (internal Lightning, Experience Cloud, and external website widgets) so the experience feels the same whether a user is logged into Salesforce or chatting from your public site.

What a Card Shows

Each card in a list is composed of:

• Title — the most identifying label (record name, case subject, slot description).
• Subtitle — secondary line, typically a record number plus a date.
• Photos & video (optional) — one or more images, and optionally a video or virtual-tour link, shown as a slider across the top of the card. See Photos & Video below.
• Badges — small coloured pills for status, priority, type, etc. Colour palette is fixed: info (brand blue), success (green), warning (amber), danger (red), or neutral (grey). Keep labels short.
• Body (optional) — a one-line description for cards where the title alone isn’t enough context.
• Action button (optional) — a clickable label such as “Show details for case 00001137” or “Schedule for 10:00”. When the user clicks it, the label is sent back into the chat as their next message — so the action label is also the prompt the agent receives. This means action labels need to be self-contained utterances, not generic verbs like “View”.

Lists are capped at 10 cards per response. If the agent has more results, it summarises the rest in prose after the card list and offers to narrow the search.

Photos & Video

Cards can carry visuals. When a record has photos — a property’s images, a product shot, a room or site view — the agent can show them as a media slider across the top of the card, above the title and details. This turns a plain result list into a rich, scannable gallery, so a user can size up a listing at a glance instead of clicking through to a record.

• One photo shows as a single banner image on the card.
• Several photos become a swipeable slider, with a small counter in the corner (for example, “4”) showing how many there are.
• Video & virtual tours show as a play tile. Selecting it opens the video or tour in a new browser tab — this works for a hosted video file, a YouTube or Vimeo link, or a Matterport-style virtual tour.
• Photos come first, then any video tiles, all in the same slider. A single card holds up to 10 media items in total.

Moving through the slider

Users navigate in whatever way is natural for their device — both methods are always available:

• On a computer — left and right arrow buttons sit over the slider; a click moves one image at a time and loops around at the ends.
• On touch screens and the Salesforce mobile app — users simply swipe left and right, and each swipe snaps neatly onto the next image. The arrow buttons are also present, with larger, finger-friendly tap targets.

The slider behaves identically on the internal Salesforce chat, the Community widget, and the website widget. (The headless API channel has no user interface, so it shows no cards or media — see Where Cards Render.)

Making sure images display

For photos to appear inside the internal Salesforce chat, two things must be true of each image’s web address:

• It must be served over HTTPS (a secure https:// address). Insecure (http://) or non-web addresses are safely ignored, and the card still renders without that image.
• Its domain must be approved by Salesforce’s content-security policy. Images hosted in Salesforce Files and by common image services (for example, Cloudinary) are already approved out of the box.

If your photos are hosted on a different domain and don’t appear in the internal chat, add that domain as an approved image source — a one-time step per domain:

1. Go to Setup → Security → CSP Trusted Sites.
2. Choose New Trusted Site and enter your image host (for example, https://images.yourcompany.com).
3. Under the site’s CSP Directives, enable img-src, then save.

Where Cards Render

How Agents Decide When to Use Cards

Card-list rendering is part of the default response-formatting guidance that ships with REDA AI. Out of the box, agents on chat surfaces (Internal, Community, External Widget) prefer cards for record lists; bullets for short informational lists; and tables only for aggregate summaries (totals, counts grouped by category) where columnar comparison genuinely helps.

The headless API channel does not render cards — programmatic callers receive plain-text or structured responses instead.

Action Buttons — Designing Good Labels

Action button labels are critical because they double as conversation utterances. When the user clicks “Show details for case 00001137”, that exact text becomes their next chat message. The agent then has full context to act on it.

Good labels are:

• Self-contained — “Show details for case 00001137”, not “Show details”.
• Specific — reference the record number, name, or identifying field so the agent doesn’t have to guess which item the user clicked.
• Brief — aim for under 50 characters; long buttons wrap and look cluttered.
• Action-oriented — verb first (“Open”, “Schedule”, “Cancel”, “Confirm”) so the user knows what will happen.

Streaming Behaviour

While an assistant response is streaming into the chat word-by-word, the chat panel hides any in-progress card list until it’s complete. The user sees the prose lead-in stream in normally, then the cards appear as a single, finished block — no flicker, no half-formed content.

Customising Appearance

Cards inherit the same colour tokens and typography as the rest of the chat widget. If you’ve customised your widget colours via Widget UI Customisation, cards pick those up automatically — primary brand colour for badges and action buttons, neutral text colour for titles and bodies. There’s no separate “cards theme” to configure.

Card spacing, border radius, and badge shapes are intentionally fixed across all surfaces for consistency. If your brand requires different visual treatment, raise it with REDA AI support — we can discuss customisation options.

Limitations

• Maximum 10 cards per list. If more results match, the agent summarises the remainder in prose.
• A card holds up to 10 media items (photos and video tiles combined).
• Photos in the internal Salesforce chat must use a secure https:// address on an approved domain (Salesforce Files and common image services are approved; other domains can be added under CSP Trusted Sites). See Making sure images display.
• Video plays by opening in a new browser tab — it is not embedded or auto-played inside the chat panel.
• Cards are read-only beyond the action button. Users cannot inline-edit a card’s fields.
• Cards do not appear on the API channel (headless callers).
• Action button labels become user messages on click — they are not separate “quick action” primitives. Make sure each label is something the agent can act on as a chat instruction.

Clearer email, record and scheduled actions

Email actions distinguish a Contact or Lead recipient from the related business record, support To/Cc lists, and check the supported recipient opt-out cases. Contact/Lead values supplied as related records are handled as recipients instead of invalid activity links. Record confirmations surface fields that were not applied, rather than silently implying success. Plan steps are reconciled one-to-one; relative scheduled times retain UTC correctly. Disabled agents and disallowed nested actions are checked before confirmed execution. File-link confirmation reuses the supported access-aware path. New Pending or rescheduled time-based actions require a runnable scheduled processor; email-reply tracking and ordinary history/status updates remain valid. Delayed jobs run as their scheduler owner, not by impersonating the requestor. Host guidance reduces duplicate use of another email/calendar connector; it cannot guarantee the host's behaviour.