Fix Data Issues and Missing People
People can be off the chart for three different reasons. Check Unassigned first, then skipped rows in Data issues, then rows the web part never received. The warning chip above the chart is visible to everyone who can see the page, not only to editors.
Three causes of missing people
Check in this order.
1. They are outside the charted tree
The chart draws one selected hierarchy. Root candidates who are not selected appear in the Unassigned strip. They are not drawn as extra top cards.
Choosing a Root person does the same for everyone outside that branch.
This is the most common cause. See Unassigned People and Unresolved Managers.
2. The row has a reporting-line problem
Rows that report to themselves, or rows caught in a circular reporting loop, are skipped. They appear in the Data issues panel. They are not drawn.
3. The web part never received the row
The selected View filter and item limit apply before the chart sees the list. A reader only ever sees rows their SharePoint permissions allow. Those people never reach the chart, so they do not appear as Unassigned and they do not appear as skipped rows.
The Data issues panel
A warning chip appears above the chart when the data has something worth reporting. It opens Data issues, described as structural values that need attention — fix them in the source data.
Chip wording:
- {N} row skipped or {N} rows skipped when only skipped rows exist
- {N} data issue or {N} data issues when flagged rows or relationship issues are present
- Setup check when there are no bad rows but the web part has a suggestion
When the chart cannot draw anything and a diagnosis exists, the panel opens by itself once.
Shared list-load errors (access lost, missing list, throttling, view threshold) are documented on Common Error Messages.
Reasons you can see
| Reason shown | Meaning |
|---|---|
| reports to self | The row's manager key is its own key. The row is not drawn. |
| circular reference | The row is part of a reporting loop. The rows in the loop are not drawn. |
| Manager ID {key} does not match any Person ID in this source — branch kept as a separate root | The solid-line manager is not in the loaded rows, often because the selected view filtered that manager out. The person becomes a root candidate. Their reports stay attached beneath them. They appear in Unassigned unless you set Root person to them. They are not automatically another displayed top of the chart. |
| Manager ID {key} does not match any Person ID in this source. | An additional reporting manager was not found. That extra line is dropped. The person stays under their solid-line manager. |
| Person ID {key} appears more than once. Choose a repeated-row relationship format. | You mapped a one-row-per-person format but a Person ID appears on several rows. See Repeated-Row Files. |
| {key} resolves to more than one solid-line manager: {managers}. Only the first is used. | More than one solid-line manager was mapped for one person. |
| Relationship value {value} is not classified. Choose Solid line, Dotted line, or Ignore. | A value in Relationship type has no meaning yet. One issue per unclassified value, not per row. |
| Manager ID {key} has no relationship type value — the row is ignored. | A repeated row is missing its Relationship type. |
| Person ID is blank on this row — nothing can report to this person | The row has no key, so nobody can point at this person as a manager. |
| later rows carry different content ({values}) — the first row's values are shown | Edit mode only. A later repeated row disagrees with the first row's content. |
| Dates: {N} {column} values could not be interpreted. Choose the source date format. | Hire dates are ambiguous. Set Date format. |
A solid-line manager that does not resolve is usually a view or mapping problem: the manager's row was not loaded, or the mapped manager field is not the person key. Fix the view so every manager is included, or map the field whose values match Person ID. Then look in Unassigned for the person who could not resolve.
Likely-cause suggestions
When the shape of the data explains a widespread failure, the panel adds one diagnosis:
- {N} rows loaded, but the mapped Name field '{column}' is empty on nearly all of them. Pick a different Name column, or use the derived First + Last name mapping.
- The Relationship type values {values} have no meaning set yet, so no reporting lines can be drawn. In the pane, under Relationships → Classify relationship values, set each one to Solid line, Dotted line, or Ignore.
- The Manager field '{column}' doesn't resolve against this list's items — its values point outside this list. Map a Person or Lookup column that points at this list, or choose an ID-based Relationship format.
- Person ID is not mapped. Select the column containing each person's unique key — manager IDs need a key column to resolve against.
- The manager field '{column}' doesn't hold person keys — none of its values match the Person ID column '{column}'. It may be a different kind of key (a position or record number), a name, or an email. Map the column that carries each person's manager KEY.
- {N} manager references point at people the view '{view}' filters out. Bind an unfiltered roster view so every manager is included.
Empty chart
The title is No structure found.
List: No rows in the list link to a manager. Check the Relationship format and its mapped fields in the pane — a Manager lookup column, or a Person ID and Manager ID pair that point at this list's own keys.
CSV: No rows in the file link to a manager. Check the Relationship format and its mapped fields — the Person ID and Manager ID columns must carry each person's key and their manager's key.
Unclassified relationship values: The source and fields are mapped. What's missing is what each Relationship type value means: in the pane, under Relationships → Classify relationship values, set every value to Solid line, Dotted line, or Ignore.
CSV file errors (empty file, missing headers, renamed spreadsheet) are listed on Use an HR System (HRIS) CSV Export with Zenpo Web Parts.