Check Results Service

CheckResultsService — reuse any integration check's results

The one idea

Integration checks (2FA, AWS S3 encryption, device posture, …) all write per-resource results to one table (IntegrationCheckResult). CheckResultsService is the single, universal, read-only way to get those results into any feature. It is deliberately feature-agnostic: it fetches results and hands them back in a stable envelope, and it does not know or care what the data means.

Service = fetch the results (generic). Feature = interpret + map + present.

If you're about to query IntegrationCheckResult or CheckRunRepository directly from a new feature — stop. Use this service instead.

• Service: apps/api/src/integration-platform/services/check-results.service.ts
• Exported from IntegrationPlatformModule — inject it into any feature module.
• Reference consumer (copy this): the 2FA feature — two-factor-source.controller.ts.

When to use it

Use it whenever a feature needs the output of an integration check:

• "Show each employee's 2FA status on the People tab" (the current consumer)
• "Surface which S3 buckets failed encryption inside feature X"
• "Show device compliance per user from the MDM check"
• "List which connected integrations can supply data for task T"

The API (3 methods)

// 1. Discover sources: which connected integrations can feed a task, + connection state.
listSourcesBoundToTask(organizationId, taskTemplateId): Promise<CheckSourceInfo[]>

// 2. The primitive: full results of a check's latest REAL run for ONE connection.
getLatestResultsByCheck({ organizationId, connectionId, checkId, resourceType? }): Promise<CheckResultRow[]>

// 3. Convenience: results for a task-bound check from a chosen source (provider slug).
//    Resolves task -> check and slug -> connection for you.
getLatestResultsForTask({ organizationId, taskTemplateId, sourceSlug, resourceType? }): Promise<CheckResultRow[]>

Notes:

• "Latest REAL run" = newest run that isn't inconclusive/held and whose connection isn't disconnected. Held runs (our-side self-heal) never leak to a feature.
• No row cap — you get the full result set (unlike the 30-row task-history display).
• resourceType filters rows (e.g. 'user', 'bucket'). Omit to get all.
• Empty array = "no data" (source not bound/connected, or never really ran). Never throws for "no results".

Person-scoped results: the shape contract

Checks about PEOPLE (employee access, 2FA/MFA, training) follow a standard emission shape — this section is the canonical definition of it:

• One row per person — never a single aggregate row with a roster buried in evidence.
• resourceType: 'user' (exactly this string).
• resourceId = the person's email, lowercased + trimmed. Fallback username || id only when the provider genuinely exposes no email (such rows won't join to members — acceptable, still visible in evidence views).
• evidence carries what the provider knows: email, name, role, isAdmin, status, lastLogin, plus a checkedAt timestamp.
• Access/inventory rows always emit as pass (having access is information, not a violation); compliance-gate checks (2FA, training) pass/fail per person; error paths (bad creds, missing scopes) stay org-level rows.

So a feature joining check results to org members does exactly this — no parsing, no AI:

const rows = await checkResults.getLatestResultsForTask({
  organizationId, taskTemplateId, sourceSlug, resourceType: 'user',
});
const forMember = rows.filter((r) => r.resourceId === member.email.toLowerCase());

If a source returns zero 'user' rows, its check hasn't been normalized to the standard yet (or genuinely has no per-person data) — render that as "no per-person data from this source", and fix the CHECK to emit the shape above. Never work around it by parsing aggregate evidence in the feature.

The envelope you get back

interface CheckResultRow {
  resourceId: string;      // provider-native id: email (2FA), bucket ARN (S3), repo, …
  resourceType: string;    // 'user' | 'bucket' | …
  passed: boolean;         // did this resource pass the check
  title: string;
  description: string | null;
  evidence: Prisma.JsonValue;  // ← check-SPECIFIC payload. The service does NOT interpret it.
  collectedAt: Date;
  runId: string;
  connectionId: string;
}

The evidence rule (important): the envelope is universal; the check-specific data lives in evidence as raw JSON. The service never types or interprets it. Your feature validates evidence at its own edge with a zod schema and reads only the fields it understands:

const TwoFaEvidence = z.object({ isEnrolledIn2Sv: z.boolean() });
const parsed = TwoFaEvidence.safeParse(row.evidence);
// use parsed.data.isEnrolledIn2Sv — never `as any`

For a simple pass/fail feature you often don't even need evidence — just use row.passed and row.resourceId (that's all 2FA needs).