Group cases and use table pivoting to find work that needs attention

Case-list grouping collects records with the same field value into sections so you can inspect patterns without reading one long flat list. Use it to review work by Company, owner, status or another supported grouping field. In a B2B operation, this can make it easier to spot a customer with several waiting cases or an uneven distribution of work, then open the individual records that require a decision.

Distinguish grouping, filtering, sorting and reporting  ·  Choose the result before choosing the groups  ·  Enable the grouping bar and group the current list  ·  Choose a personal default grouping  ·  Use grouping for real support decisions  ·  Example: several cases for one customer are waiting  ·  Troubleshoot missing or confusing groups

Distinguish grouping, filtering, sorting and reporting

The UI calls the feature “Grouping bar and table pivoting” because it supports a spreadsheet-like way to organize the grid. It does not promise an unrestricted spreadsheet pivot engine with arbitrary calculated measures or every possible system field. Some columns explicitly do not support grouping.

Choose the result before choosing the groups

1. Open the relevant Cases view and confirm Agent, Queue and any active filters. Grouping starts from this result; it does not search the whole account independently.
2. Choose the operational question. “Which customers have several cases waiting for our next action?” needs different inclusion criteria from “How much work is closed this month?”
3. Check that the field values are maintained consistently. Missing or inconsistent Company, issue or owner information can produce misleading groups.
4. Find a known case that should appear and one that should not. Confirm the view’s result before adding presentation complexity.
5. Choose one useful first grouping. Add a second only when it helps a specific decision. A case-ID group with one case per group often adds clutter rather than insight.

Enable the grouping bar and group the current list

1. Open Cases.
2. Choose the gear labelled Case list options.
3. On Options, turn on Grouping bar and table pivoting, then choose Done.
4. In the list, use a supported column’s grouping interaction, such as dragging its header into the grouping bar. Choose an available field that answers the operational question. A column that does not support grouping cannot be used this way.
5. If a second grouping is needed, add another supported column and check the resulting group order. Start with the broader question, such as customer organization, before a more detailed category.
6. Expand the relevant group and read its case rows. Check the case ID, current state and owner before taking action.
7. Use the grouping bar’s removal control when a group is no longer useful, and recheck the remaining arrangement.

A group label is a way to navigate the result. It does not change the cases’ Company, priority, status or ownership. To change a record, open the case or use an appropriate authorized bulk action after reviewing the exact selection.

Choose a personal default grouping

1. Open Case list options → Defaults.
2. Find Default grouping.
3. Choose the supported default that matches your usual work, or No Grouping for a flat starting list. Available choices include Status, Priority, Issue Type, Company, Contact, Activity, Owner, Asset, Division, Case Id, Created By, Satisfaction Score and NPS. Entity labels may reflect your account terminology.
4. Choose Done and reopen the list to verify the result. Check any separately saved view state if it changes the presentation you expected.

This is a personal starting preference. A reusable view definition, a view’s saved grid state and your default grouping are different settings. Use Save this View’s state when you intend to retain supported current view state; persistence depends on your permission to edit that view. Without that permission, state can apply only to the current tab. Verify by reopening instead of assuming a visible grouping was saved for everyone.

Use grouping for real support decisions

These are recommended review designs, not predefined views or automatic workflow actions. A Company group does not authorize sharing all its case content with every Contact at that Company. Customer access must be checked separately.

Example: several cases for one customer are waiting

Suppose an account manager sees a customer group with several open cases. The group helps assemble the review, but “open” alone does not explain whether support, the customer or a third party owns the next step.

1. Confirm that the view includes the intended cases and excludes unrelated customers. Check the date/status criteria and active list filters.
2. Expand the customer’s group and open the cases with an unresolved commitment. Read the latest activity and the next scheduled task.
3. Separate cases waiting for customer evidence from cases awaiting an internal investigation or a supplier response. Use actual maintained fields and case history rather than inferring the reason from age.
4. For each case, record who owns the next action, what evidence is needed and when the next update is due. Escalate the high-impact dependency through the normal process if needed.
5. Refresh/reopen the list after changes and verify the new state. If sharing an exported agenda, inspect the rows and audience before sending it.

Grouping made the review easier to navigate; the case actions made the review useful. Keep those outcomes distinct when assessing the feature’s value.

Troubleshoot missing or confusing groups

Continue learning

• Design views and understand saved state
• Configure view filters and columns
• Interpret Dashboard widgets
• Use defined KPI measures
• Record and verify the next case action