No group appears when Pythia cannot associate a macro usage event with a specific Zendesk group.
It is a valid reporting category and does not always indicate an error.
Where “No group” can appear
No group can appear in Usage reports that break macro activity down by group, especially:
- Usage → Individual Macros Usage by Attributes when the chart is set to By group;
- CSV exports generated from that chart.
In Performance Drill-In, Macro Usage History does not use the literal No group label. It shows - when no group can be resolved.
What “No group” means
Each recorded macro usage event is associated with:
- one Zendesk group; or
- no resolved group.
No group means the saved usage record does not contain a resolved Zendesk group ID.
This can happen when:
- the ticket did not have a group when the macro was applied;
- the ticket audit did not contain a usable group value;
- the Zendesk group ID could not be matched to a group synchronised with Pythia;
- the group was deleted or became unavailable;
- Zendesk did not return the required group or audit data;
- the relevant audit history was incomplete or had not yet been imported.
Which group does the report use?
The report uses the ticket’s group context at the time of the macro usage event.
Pythia starts with the synchronised ticket state and reviews ticket audit changes up to the point where the macro was applied.
This means the result is closer to the ticket’s group at the time of macro use than the ticket’s current group.
It is not based on:
- the agent’s default group;
- the macro’s access restrictions;
- a group referenced by a macro action;
- the group currently assigned to the ticket.
Can one usage event belong to several groups?
No.
A single macro usage record can be associated with one group or no group. It is not counted under multiple groups.
Why old records can remain under “No group”
Historical usage records are not automatically relabelled from the ticket’s current state.
A record can remain under No group even if:
- the ticket is later assigned to a group;
- the agent later joins another group;
- the missing Zendesk group is recreated;
- the ticket’s current group is now available.
The report uses the group value stored for the original usage event.
Can I filter by “No group”?
No group is not available as a selectable value in the Group filter.
When no Group filter is applied, rows without a resolved group are included in the report.
When one or more named groups are selected, No group records are excluded because they do not match any selected group.
Is “No group” a data problem?
Not necessarily.
It can be correct when the ticket had no group or when no group could reasonably be resolved for that event.
A high or unexpected amount of No group data may indicate:
- incomplete ticket audit history;
- a group that was deleted;
- a group synchronisation problem;
- older data imported without complete group context;
- delayed synchronisation.
Troubleshoot unexpected “No group” results
For a specific usage event, check:
- Whether the ticket had a group when the macro was applied.
- The ticket event history around the macro application.
- Any
group_idcreation or change events near that time. - Whether the expected group still exists in Zendesk.
- Whether the group is available to the Pythia integration.
- Whether the report includes older or partially synchronised data.
- Whether the issue appears in Usage as
No groupand in Drill-In history as-.
Recent events may need additional time to synchronise.
Contact support
If the result still appears incorrect, contact Pythia support and provide:
- affected ticket IDs;
- macro IDs or titles;
- report date range;
- timezone;
- expected group names;
- approximate time when the macro was applied;
- screenshots or exported rows showing
No group.
This information helps distinguish a valid missing-group event from a synchronisation or data-resolution issue.