Configure Case Display Settings – Reindeer

Overview

Display settings control how an agent's case data appears in Reindeer case views. They are configured on the agent through the external API and are separate from the case state itself.

Use display settings when reviewers, operators, or customer teams need to scan important case fields without opening raw JSON.

Questions This Article Answers

Which case fields should appear in case views?
How should display settings reference case state?
Which fields are safe to show?
What should be checked before changing display settings?

Display Configuration Pattern

Today, display settings support an optional agent icon and case-view configuration.

{
  "icon": "invoice",
  "cases": {
    "fields": [
      {
        "label": "Vendor",
        "path": "$.vendor.name"
      },
      {
        "label": "Total",
        "path": "$.invoice.total_amount"
      },
      {
        "label": "Status",
        "path": "$.validation.status"
      }
    ]
  }
}

The exact cases shape may vary by enabled UI view. Keep the configuration small and focused on fields that help users scan, filter, or decide what to do next.

Field Selection Guide

Field type	Good fit for display?	Notes
Status or outcome	Yes	Useful for triage and review queues.
Customer, vendor, or account name	Yes	Keep names short and consistently formatted.
Document type	Yes	Good for filtering and routing.
Amount, date, or identifier	Yes	Use normalized values where possible.
Confidence score	Sometimes	Useful when reviewers need to understand automation risk.
Raw model reasoning	No	Too verbose and may change between runs.
Large nested objects	No	Better shown in detail views or omitted from display settings.
Sensitive data	Usually no	Prefer masked or derived values.

Choose Stable State Paths

Display settings should reference fields that are stable across runs. Prefer paths that map to the case state schema, such as:

$.classification.type
$.customer.name
$.invoice.invoice_number
$.invoice.total_amount
$.validation.outcome
$.review.required

Avoid pointing case views at temporary fields, raw model reasoning, large nested blobs, or values that may not be returned consistently by the external API.

Sensitive Data

Do not surface sensitive data in display settings unless your access model is designed for it. Prefer masked, summarized, or derived fields for personally identifiable information, credentials, financial details, or private customer content.

Examples:

Show masked_account_number instead of a full account number.
Show review_required: true instead of the full reason if the reason may include sensitive text.
Show document_type instead of the raw document body.

What the Configuring Team Provides

The case state schema or sample case state.
The fields that should appear in the case list or detail view.
Labels for each field.
Empty-state behavior for missing or null values.
Any masking or redaction requirements.
Review from the team responsible for access control and data handling.

Change Management

When you update the case state schema, review display settings at the same time. A display path that no longer exists may render as blank or unavailable in the UI.

Before enabling a display change, confirm:

Each displayed path exists in the current case state schema.
Test cases cover common, empty, null, and missing values.
Long values remain readable.
Sensitive fields are not exposed unintentionally.
External integrations that depend on the same paths are still aligned.