Filter case views with custom fields and verify the results

Custom fields let your team record business information that standard Case fields do not capture, such as a supported product, contract classification or customer-specific reference. A custom-field filter turns that information into a repeatable action list. For B2B support, the benefit is practical: you can find the open equipment issues that need the same specialist, review work for a service segment, or investigate a recurring problem without opening every Case.

Start with the operational question  ·  Prepare the field and access before editing the view  ·  Add a custom-field filter  ·  Verify positive and negative examples  ·  Worked example: investigate recurring equipment problems  ·  Maintain the view when fields or processes change  ·  Troubleshoot custom-field views

Start with the operational question

A view answers a selection question. It does not, by itself, assign work, change an SLA or update a field. For example, a custom field called “Urgency” is separate from the standard Case Priority and its configured behavior. Use automation or the appropriate operational action when a selected Case needs a change.

Prepare the field and access before editing the view

1. Identify the exact field and its location. A similarly named Case field, Company field and Contact field can represent different information.
2. Confirm the field is active and available for the selected view type, category and your role. A field that exists elsewhere in the product is not guaranteed to appear in every editor.
3. Open at least one known matching Case and one known nonmatching Case. Inspect their saved values; do not rely on an assumed or previously displayed value.
4. Confirm you can create or edit the intended view. The applicable view-editor rollout and role permission, including Create global and team-only views where required, control access. Ask an administrator for the appropriate permission rather than broadening customer data access.
5. Decide whether to edit an existing shared view or create a separate view for testing. A change to a shared definition affects the people who use it.
6. Review the field’s configured type and choices with the administrator. Standardized choices are often easier to maintain than free-text spelling variants, but changing an existing field definition needs its own impact review.

For field creation, labels, role/category visibility and choice management, use the custom-field configuration reference linked below. This procedure assumes the field and useful test data already exist. Do not create a second field solely because you cannot find the first in your view.

Add a custom-field filter

1. Open Cases. Choose New View, or open the intended saved view and its editing action. Confirm which definition you are editing.
2. Give the view a task-oriented name, such as “Open equipment Cases — Product A”. The example assumes your account already has a relevant product field.
3. Configure the ordinary Case criteria needed for the task, such as the relevant status or ownership scope. Keep these in mind when diagnosing an empty result later.
4. Open the Fields tab. Find the intended custom field and check its label and location.
5. Turn on Include for that field. A displayed or previously entered value is not the same as an included filter.
6. Enter or select the desired value using the control shown for that field’s type. The editor provides typed controls; there is no single universal operator menu that applies to every custom field.
7. Review any other included fields and the ordinary view criteria. Remove unintended restrictions before saving.
8. Open Ordering & Columns and choose the fields that will help the reader understand and act on the results.
9. Choose Save view, return to the saved view, and perform the verification steps below.

Verify positive and negative examples

1. Locate the known matching Case in the saved view. If it is absent, compare every relevant criterion and your access to that Case.
2. Confirm the known nonmatching Case is absent. If it appears, check that Include is on and that the criterion was saved to the definition you opened.
3. Inspect several result rows and open the underlying Cases. Compare their actual saved field values with the intended question.
4. Reopen the view editor and verify the saved criterion and layout. Check that the name and scope identify the intended view.
5. If the view is shared, have a representative authorized colleague open it. Compare record access and role-visible fields before treating different totals as an error.
6. If the view will feed a scheduled export, separately verify the schedule’s selected view, filters, recipients and output. A correct interactive list does not prove the scheduled delivery configuration.

Use approved test data or existing records whose values are already known. Do not change a live customer’s product, contract or priority solely to manufacture a filter test. A useful verification record states the view name, criterion, sample Case IDs, expected result and observed result without exposing customer data in public documentation.

Worked example: investigate recurring equipment problems

A support lead wants a daily list of open Cases about a particular equipment family. The team already captures the equipment family in a configured field. The lead first checks that agents use the agreed choice consistently, then creates a view with the open-work criteria and includes that field’s intended value. The layout displays the information needed for action, such as the Case, customer context, owner and the selected field where available.

1. Check a known open Case for the equipment family appears.
2. Check a Case for another family does not appear.
3. Inspect whether the results describe the same symptom or merely the same equipment category. A shared field value does not prove a common cause.
4. Assign follow-up through the appropriate Case process and use a linked knowledge article when a verified resolution exists.
5. Review missing or inconsistent field values separately with the team; do not assume every absent record is irrelevant.

The measurable benefit is a repeatable, explainable review process. Track whether the team identifies unowned or overdue follow-ups sooner, rather than claiming that a filter alone reduces resolution time.

Maintain the view when fields or processes change

Saved custom-field criteria can retain values even while a field is excluded. Hidden or unavailable field values and tokens may also be preserved. This protects saved definitions from accidental loss, but it means that hiding a field or changing its definition is not a reliable way to clear an old criterion.

1. When re-enabling Include, inspect the retained value instead of assuming a blank starting point.
2. After a field is renamed, deactivated, restricted or given new choices, review affected saved views and scheduled reports deliberately.
3. If a criterion is no longer editable because of access or field availability, ask an authorized administrator to inspect the saved definition. Do not conclude that the restriction has disappeared.
4. Keep the operational purpose and owner clear. A view called “Weekly review” becomes ambiguous as the organization grows; include the relevant segment or task.
5. Prefer a small set of maintained shared views for recurring team work. Personal investigations can remain separate until their criteria are agreed.
6. Recheck positive and negative examples after a material definition change.

Troubleshoot custom-field views

Continue learning

• Configure custom fields and dropdown choices
• Build and maintain operational views
• Schedule a view for recurring reporting
• Choose the right support operations report