V2 UI Reference — Problem Devices Tab

V2 UI Reference: Problem Devices Tab

The Problem Devices tab is where every candidate that did not sail through the V2 pipeline lands for review. It groups problems by category, surfaces severity, and lets you drill into the specific record so you can fix the upstream data, the rConfig configuration, or the reconciliation policy and re-run.

This tab is identical across all V2 drivers — the categories and severities come from the pipeline, not the driver.

Caution

A “completed” run can still leave Problem Devices behind. The Run Insights Open Problems card and this tab are the authoritative measure of whether your sync did everything you wanted.

What “Problem” Means in V2

Anything that prevents a candidate from progressing cleanly to a create or update decision shows up here. The pipeline emits problems at three points:

Stage	Typical problem groups
canonicalize	Missing hostname, missing primary IP, malformed payload, unresolved Device Profile slug.
reconcile	Ambiguous matches (more than one rConfig device matches the candidate’s identity fingerprint).
decide	Conflicts (manual resolution required), or skips that the policy logged as needing operator attention rather than silent.

A candidate can have only one open problem at a time — when you resolve it (or re-run after fixing the upstream), the next pipeline pass either clears it or moves it to a different group.

Reading the Tab

The layout mirrors Run Insights: group summary cards on top, detail rows underneath.

Group Summary Cards

Each group gets its own card, colour-rotated through a six-tone palette so adjacent groups are easy to tell apart. The cards are dynamic — only groups that have at least one open problem are shown for the latest run.

You’ll typically see some combination of:

Group key	Plain-English meaning
canonicalize_error	The driver could not normalize the upstream record into rConfig’s canonical shape.
missing_required_field	A required canonical field (hostname / primary IP / external ID, depending on schema) was empty.
profile_unresolved	Device Profile slug from the upstream did not match any active Device Profile in rConfig.
ambiguous_match	More than one existing rConfig device matched. A human needs to pick the right target.
conflict	A decision-time conflict (e.g. authority disagreement) that requires manual resolution.
create_candidate_blocked	Candidate would have been a create but was blocked by policy (e.g. profile required, none resolved).

The exact group keys come straight from the pipeline — if you see a key not listed here, it is still safe to read the row’s severity and external_id and trace the same way.

Detail Table

Column	What it shows
Reason	The group key for this row — same value as the summary card heading. Acts as the primary triage filter.
Host	Hostname the candidate resolved to (may be empty for canonicalize_error rows).
External ID	Upstream identifier — use this to cross-reference back to the upstream system.
Severity	Coloured badge. Severity is set by the pipeline based on what blocks Apply: critical/high/error are red, warning/medium are amber, info/low are sky, anything else is muted.

Severity tells you whether the row blocks Apply (red), defers Apply for review (amber) or is informational (sky). A red row will stop a Full Sync from acting on that candidate; an amber row generally results in a skip decision rather than a hard failure.

Pagination & Refresh

• Refresh icon (top right) — re-fetches the latest run’s open problems. Use it after running an Apply with policy changes to see what is left.
• Previous / Next — page through long problem lists. The latest run’s problem set is paginated server-side.

Triage Workflow

For each problem row:

1. Identify the row by External ID and Host. Open the upstream system in another tab.
2. Read the Reason to know what to fix:
   • canonicalize_error / missing_required_field — fix the upstream record so the driver can resolve hostname/IP.
   • profile_unresolved — either align the upstream’s group/tag value to an existing rConfig Device Profile slug, or create the Device Profile in rConfig, or set a default profile on the integration instance.
   • ambiguous_match — open the candidate, pick the correct rConfig device, or merge/retire the duplicate device.
   • conflict — open the candidate, review the authority trace, accept either the upstream value or the rConfig value.
3. Re-run a Sync Preview to confirm the row clears (or moves to a different group).
4. Run Apply when the open problem count for the categories you care about is zero.

Don't chase warnings

A handful of info/low rows is normal in any environment. Triage red and amber first, and only chase blue/grey rows when you have a specific reason — they typically represent intentional policy outcomes (e.g. a host the missing-upstream policy chose to leave linked-but-disabled).

What Gets Cleared by What

Problem group	Cleared by
canonicalize_error	Fixing the upstream record (or relaxing schema requirements) and re-running.
missing_required_field	Same as above — populate the field upstream.
profile_unresolved	Adding/aligning Device Profile in rConfig, or setting an instance default profile, then re-running.
ambiguous_match	Manual resolution on the candidate; no automatic clear.
conflict	Manual resolution; conflict records persist until resolved.
create_candidate_blocked	Resolving the upstream gap (often a missing profile slug) and re-running.

Where to Go Next

• See Run Insights Tab for the high-level counters that summarise the totals shown here.
• See Logs Tab for the per-stage error payloads behind each problem row.
• See your driver’s guide for the upstream-specific fields that drive canonicalize and Device Profile resolution.

Asset Inventory

• Screenshot: PLACEHOLDER_v2_problem_devices_tab.png — Problem Devices tab populated with at least three different group cards and a multi-row detail table covering each severity colour.
• Verification: confirm the column order (Reason, Host, External ID, Severity) matches ProblemDevicesTab.vue at the V8.2.0 release tag.
• Verification: confirm the severity → colour mapping (red for critical/high/error, amber for warning/medium, sky for info/low) matches the live severityToneClass logic.
• Verification: the group key list above is descriptive of common categories — confirm against the canonicalize / reconcile / decide stages, and add any release-specific keys.