Overview
An agent case schema defines the business fields Reindeer tracks for each case in a workflow. It is the shared contract between the agent, the case page, reviewers, reporting, and any connected systems.
This article is for customer administrators and operational owners who decide what information should appear on cases and how reviewers should work with it.
Questions This Article Answers
- What is an agent case schema?
- Which fields belong on a case?
- How should case fields be named and organized?
- How do schema changes affect reviewers?
- What should be checked before changing a schema?
What a Case Schema Controls
The case schema describes the structured information Reindeer keeps on a case. Depending on your workflow, this may include extracted values, classifications, validation results, review decisions, routing information, and operational status.
The schema helps keep the following parts of the system aligned:
- The fields reviewers see on the case page.
- The values an agent reads or updates during processing.
- The fields used for queues, filters, reporting, or downstream actions.
- The information customer teams use when correcting or approving a case.
Changing the schema can affect how future cases are processed and displayed. Treat it as an operational change, not just a field-label update.
What Belongs in the Case Schema
Include fields that users or workflows need after a case is created.
| Field type | Good fit? | Example |
|---|---|---|
| Business identifier | Yes | Invoice number, customer ID, claim number. |
| Classification | Yes | Document type, request type, priority. |
| Review status | Yes | Needs review, approved, rejected, exception. |
| Validation result | Yes | Passed, failed, warning, reason. |
| Correctable value | Yes | Amount, due date, supplier name, destination. |
| Routing value | Yes | Queue, team, region, assignee group. |
| Raw source text | Usually no | Full email body or full document text. |
| Temporary processing detail | Usually no | Intermediate reasoning or debug-only values. |
Recommended Field Design
Use clear business language that reviewers and operators already understand.
Recommended patterns:
- Group related fields together, such as customer, document, validation, review, or routing.
- Use consistent names for the same concept across workflows.
- Prefer controlled values for statuses and decisions.
- Allow blank values when the source may not include the information.
- Keep list-view fields short enough to scan.
- Separate human decisions from agent-generated recommendations.
- Avoid exposing sensitive information unless users need it for review.
Case Schema vs. Case Layout
The schema defines what information a case can hold. The case layout defines which of those fields users see and where they appear.
| Change type | What it affects | Typical owner |
|---|---|---|
| Add or change a schema field | What data the workflow captures, stores, validates, or reuses. | Administrator, implementation team, or Reindeer support. |
| Rename a display label | What users see in the UI. | Administrator or Reindeer support. |
| Move or hide a displayed field | How reviewers scan and work cases. | Administrator or Reindeer support. |
| Make a field editable | Whether users can correct the value. | Administrator, implementation team, or Reindeer support. |
| Change status logic | How cases move through the workflow. | Implementation team or Reindeer support. |
If users only need a different label or layout, the schema may not need to change. If the agent must capture a new value or use it in decisions, the schema usually does need to change.
Planning a Schema Change
Before requesting or approving a schema change, define:
- The business problem the field solves.
- Who will use the field.
- Whether the field is required, optional, or only used for certain case types.
- Whether reviewers should be able to edit it.
- Whether it should appear in lists, detail views, reports, or exports.
- Whether the value is sensitive and needs masking or restricted access.
- Whether existing active cases need to keep working with the old field.
Compatibility Guidelines
Schema changes can affect active cases. Use a gradual rollout when possible.
Recommended approach:
- Add new fields before removing old fields.
- Keep old fields visible until active cases have completed or migrated.
- Avoid renaming a field if reports, filters, or integrations already depend on it.
- Use blank or "unknown" values when the source does not provide a field.
- Test the change on representative cases before enabling it broadly.
Testing Checklist
Test the updated schema with:
- A normal case.
- A case with missing source information.
- A case with long values.
- A case with sensitive values.
- A case from each major category or document type.
- A case that requires manual correction.
- A case that should pass without review.
- A case that should fail validation or route to an exception queue.
Confirm that reviewers can still understand the case, make the right decision, and avoid entering the same information in multiple places.
Common Mistakes
- Adding fields because they are available, not because users need them.
- Using different names for the same concept in different workflows.
- Mixing agent recommendations and human decisions in one field.
- Making every value required, even when the source may not include it.
- Removing a field before active cases and reports no longer depend on it.
- Showing sensitive values in list views when a masked value would be enough.
Related Articles
- Understand Case Fields and Views in Reindeer
- Request Changes to Case Fields and Layouts
- Avoid Duplicate Cases and Case IDs
Comments
0 comments
Please sign in to leave a comment.