# List a Workflow's Findings

Source: https://docs.pitchpointsolutions.com/api/findings/get_workflow_findings_list/

**Beta**

Every finding in the workflow, as one flat list. Use this when you want all findings without walking categories. Each entry is identical, field for field, to its counterpart in the categorized view ([Get a Workflow's Findings by Category](https://docs.pitchpointsolutions.com/api/findings/get_workflow_findings_by_category)) and to a direct GET of that finding ([Get One Finding](https://docs.pitchpointsolutions.com/api/findings/get_workflow_finding)).

This page holds the full `Finding` field table that every other findings page refers to.

Read-only and safe to poll.

### Sample

```bash
url="https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings"
curl -X GET "${url}" \
  -H "Authorization: Bearer your_access_token_here"
```

#### Header Properties

| Property | Value | Required? |
|----------|-------|-----------|
| Authorization | Bearer *your token* | true |

#### Path Parameters

| Property | Description | Type |
|----------|-------------|------|
| workflowId | The workflow's id, exactly as this API returned it. | string |

> **Warning:** `workflowId`, `findingId` and `attachmentId` are opaque. Send each one back exactly as this API returned it: don't parse it, build one yourself, or add or remove its prefix. A `findingId` or `attachmentId` that isn't exactly as published, including one with its prefix removed, returns a 404 as if it didn't exist.

### Responses

**200**

| Property | Description | Type |
|----------|-------------|------|
| workflowId | The workflow's id, echoed so a stored or logged payload still says which workflow it belongs to. | string |
| findings | Every finding in the workflow, in no particular order. `[]` when the workflow has none, never null. | array |

##### Finding

| Property | Description | Type |
|----------|-------------|------|
| findingId | The finding's opaque id. Use it as the `findingId` path parameter to fetch this finding, its history or its attachments. Always present. | string |
| code | The stable, machine-readable code for what was checked. Branch on this, not on `displayName`. | string |
| displayName | The human-facing label. Written for a person and expected to be reworded, so never branch on it. | string |
| category | The names of the categories this finding falls into: the same names as `category` in [Get a Workflow's Findings by Category](https://docs.pitchpointsolutions.com/api/findings/get_workflow_findings_by_category). Always present on this list, the categorized view and [Get One Finding](https://docs.pitchpointsolutions.com/api/findings/get_workflow_finding): `[]`, never omitted, when it falls into none. Left out of the finding returned by [Edit a Finding](https://docs.pitchpointsolutions.com/api/findings/edit_workflow_finding) and by adding or removing an attachment. | array |
| references | The subjects the run that produced this finding concerns: see [References](https://docs.pitchpointsolutions.com/api/findings/get_workflow_findings_list/#references) below. `[]`, never omitted, when that run names no such subject. | array |
| severity | The severity, as the product configured it. Usually one of `CLEAR`, `LOW`, `MEDIUM`, `HIGH` or `ERROR`, but **not a closed set**: findings produced under older configurations can carry other values. Treat an unrecognized value as unknown and fall back on `reviewed` and `reviewRequired`, rather than dropping the finding or failing the parse. | string |
| result | The check's own outcome, exactly as the check produced it. A later override or review never changes it. Values are defined per check, so this is not a closed set: handle a value you don't recognize. | string |
| resultOrOverriddenResult | The effective outcome: the reviewer's override if one has been recorded (see `overrideResult` on [Edit a Finding](https://docs.pitchpointsolutions.com/api/findings/edit_workflow_finding)), otherwise the same as `result`. An override can be replaced by another, but can't be removed. Not a closed set. | string |
| userMessage | The message written for the person reading this finding. Always an array, `[]` when empty. | array |
| userSuggestion | Suggested next steps. Always an array, and routinely `[]`: a finding that passed has nothing to suggest. | array |
| reviewed | Whether the finding has been reviewed, by a person or by an automated process such as a match against a pre-approved list. Always present, never null. Read it together with `reviewRequired`: see the table below. | boolean |
| reviewRequired | Whether the finding needs someone to review it, whether or not that has happened yet. Always present, never null. It is set when the finding is produced and never changes afterwards: reviewing, un-reviewing or otherwise editing the finding leaves it as it is. | boolean |
| reviewer | Who or what last changed the finding's review status, as a display name. Never a user identifier. While `reviewed` is `true`, that is who reviewed it; after a review is set back to unreviewed, it is who did that. Absent when no change to the review status has been recorded, and when the identity can't be resolved to a display name. This API doesn't tell a person's review apart from an automated one. | string |
| reviewNote | The current review note. When the finding has no note, including after the note was cleared, the key is absent or `null`: treat the two the same. Set, replace or clear it with [Edit a Finding](https://docs.pitchpointsolutions.com/api/findings/edit_workflow_finding). Earlier notes stay on the finding's history. | string, nullable |
| updatedAt | When this finding last changed. RFC 3339 UTC with a trailing `Z`; fractional seconds appear only when they are not zero. Omitted when none was recorded. | string |
| hasAttachments | Whether this finding has at least one attachment. A removed attachment doesn't count. Always present. List the attachments themselves with [List a Finding's Attachments](https://docs.pitchpointsolutions.com/api/findings/get_workflow_finding_attachments). | boolean |
| hasHistory | Whether [Get a Finding's History](https://docs.pitchpointsolutions.com/api/findings/get_workflow_finding_history) returns at least one entry for this finding: `true` once any event has been recorded on it, including its creation. Always present. | boolean |
| authorization | `allow` lists the changes you are permitted to make to this finding, one token per permission you hold: see [Permissions](https://docs.pitchpointsolutions.com/api/findings/get_workflow_findings_list/#permissions) below. `[]` when you hold none. | object |

##### Reading reviewed with reviewRequired

The two fields answer different questions. `reviewRequired` asks "does this finding need someone to look at it?" `reviewed` asks "has it been looked at?" All four combinations occur:

| reviewRequired | reviewed | Meaning |
|---|---|---|
| `true` | `false` | **Outstanding.** The finding needs review and hasn't had it. These are the findings still to work. |
| `true` | `true` | **Review done.** The required review has happened, by a person or automatically. |
| `false` | `true` | **Cleared, though no review was needed.** Typical of an automatically evaluated check that passed, and also the state of a finding someone reviewed even though it didn't require it. |
| `false` | `false` | **No review needed.** Informational; nobody is expected to act on it. |

To find the findings that still need attention, test `reviewRequired` is `true` **and** `reviewed` is `false`; neither field answers that alone. To decide whether a finding has been cleared, read `reviewed` on its own. Setting `reviewed` back to `false` returns a finding that requires review to outstanding, because `reviewRequired` doesn't change. A workflow has no outstanding reviews when no finding is outstanding. [Get a Workflow's Category Counts](https://docs.pitchpointsolutions.com/api/findings/get_workflow_category_counts) reports the same states per category.

##### References

Each entry in `references` names one subject: a person, property, participant or company, or an employer, residence or property of a person.

| Property | Description | Type |
|----------|-------------|------|
| correlationId | The subject's `correlationId`, as recorded for the run that produced the finding: yours when you supplied a usable one, otherwise the one the service generated when that stage was staged. A generated value is the one echoed on the SAMI terms of the same stage. Match it; never parse it. | string |
| type | The kind of subject, in the same vocabulary as the [SAMI terms](https://docs.pitchpointsolutions.com/api/sami_terms/conventions/): `person`, `property`, `participant`, `company`, `employer` or `residence`. A `property` can be the subject property or a property a person owns. Not a closed set: handle a value you don't recognize. | string |

> **Warning:** **`references` is scoped to the workflow-run that produced the finding, not to the finding.** It lists every such subject that run was given, not the one subject a check happened to evaluate, and every finding from the same run carries the same set. Don't infer that a finding is about one particular entry. Findings in one workflow can come from different runs (a reconfirm, for example, adds a run with newly staged subjects), so read each finding's own array rather than reusing one for the whole workflow. Entries are distinct, and their order isn't significant or stable between calls.

The service generates a new `correlationId` on every stage for a subject you didn't give one. So a generated value on a finding from an earlier stage may not appear on the workflow's current terms. Send your own `correlationId` on each term if you need values that match across stages.

##### Permissions

| Token in `authorization.allow` | Lets you |
|---|---|
| `riskinsight:JournalResolvedValueReview` | Set `reviewed` and `overrideResult` with [Edit a Finding](https://docs.pitchpointsolutions.com/api/findings/edit_workflow_finding). |
| `riskinsight:JournalResolvedValueUpdateNote` | Set, replace or clear `reviewNote` with [Edit a Finding](https://docs.pitchpointsolutions.com/api/findings/edit_workflow_finding). |
| `riskinsight:JournalResolvedValueUpdateAttachment` | [Add](https://docs.pitchpointsolutions.com/api/findings/create_workflow_finding_attachment) or [remove](https://docs.pitchpointsolutions.com/api/findings/delete_workflow_finding_attachment) this finding's attachments. |

The list is evaluated for you on every request, so two callers can see different tokens on the same finding. It isn't a closed set: ignore a token you don't recognize. Use it to decide what to offer. Every call checks permission again, so a call can still be refused with a 403: for example, when you may not update the workflow.

```json
{
  "workflowId": "wfpop_0000000000002082611",
  "findings": [
    {
      "findingId": "fndg_0000000000006051384",
      "code": "HP.ST",
      "displayName": "High-priority stated income mismatch",
      "category": ["Income"],
      "references": [
        { "correlationId": "borrower-1", "type": "person" },
        { "correlationId": "subject-property", "type": "property" }
      ],
      "severity": "HIGH",
      "result": "Fail",
      "resultOrOverriddenResult": "Fail",
      "userMessage": ["Stated income does not match the verified source document."],
      "userSuggestion": ["Confirm the applicant's income against the attached document before proceeding."],
      "reviewed": false,
      "reviewRequired": true,
      "updatedAt": "2026-08-07T14:52:10Z",
      "hasAttachments": true,
      "hasHistory": true,
      "authorization": {
        "allow": [
          "riskinsight:JournalResolvedValueReview",
          "riskinsight:JournalResolvedValueUpdateNote",
          "riskinsight:JournalResolvedValueUpdateAttachment"
        ]
      }
    },
    {
      "findingId": "fndg_0000000000006051385",
      "code": "AS.CL",
      "displayName": "Asset verification cleared",
      "category": [],
      "references": [
        { "correlationId": "borrower-1", "type": "person" },
        { "correlationId": "subject-property", "type": "property" }
      ],
      "severity": "CLEAR",
      "result": "Pass",
      "resultOrOverriddenResult": "Pass",
      "userMessage": [],
      "userSuggestion": [],
      "reviewed": false,
      "reviewRequired": false,
      "updatedAt": "2026-08-07T14:52:10Z",
      "hasAttachments": false,
      "hasHistory": true,
      "authorization": {
        "allow": [
          "riskinsight:JournalResolvedValueReview",
          "riskinsight:JournalResolvedValueUpdateNote",
          "riskinsight:JournalResolvedValueUpdateAttachment"
        ]
      }
    }
  ]
}
```

The first finding above is outstanding: `reviewRequired` is `true` and `reviewed` is `false`. The second needs no review. Neither has a note, so neither carries `reviewNote`, and neither has had its review status changed, so neither carries `reviewer`. Both have `hasHistory` `true`, because each finding's history starts with its `created` entry. A finding with no configured category still returns `"category": []`, never a missing key or `null`: see the second finding.

**401**

No credential the service could accept reached it. The body is an RFC 9457 problem document, served as `application/problem+json`, and the response carries a `WWW-Authenticate` challenge. The request body is never read, so a 401 says nothing about whether the rest of your request would have been accepted.

Two problem types tell the cases apart:

| `type` | Meaning | `WWW-Authenticate` |
|--------|---------|--------------------|
| `about:blank` | No credential was presented. | `Bearer realm="Helix"` |
| `https://pointservices.com/problems/invalid-token` | A credential was presented and rejected. The response doesn't say why: an expired, revoked, badly signed and malformed token all look the same. | `Bearer realm="Helix", error="invalid_token"` |

```json
{
  "type": "https://pointservices.com/problems/invalid-token",
  "title": "The access token was not accepted",
  "status": 401,
  "detail": "The access token was rejected.",
  "instance": "urn:pps:request:0000000000000000000000000000000000000000000000000000"
}
```

> **Warning:** Refresh your token on a 401, and only on a 401. An expiring token moves a call from 200 to 401, never to 403, so a fresh token is the fix here and never the fix for a 403.

**403**

You may not read this workflow.

You are authenticated, and the answer is still no. This is an authorization decision, not a statement about your token, so refreshing the token won't turn it into a 200. 

The body is an RFC 9457 problem document, served as `application/problem+json`. Two problem types tell the cases apart:

| `type` | Meaning |
|--------|---------|
| `about:blank` | The request was refused before the operation ran. |
| `https://pointservices.com/problems/not-authorized` | The operation ran, and policy won't let you act on the workflow or finding you named. |

```json
{
  "type": "https://pointservices.com/problems/not-authorized",
  "title": "Not authorized",
  "status": 403,
  "detail": "The authenticated identity is not permitted to perform this action.",
  "instance": "urn:pps:request:0000000000000000000000000000000000000000000000000000"
}
```

A 403 can also come from the edge, before the service is reached: for example, when a request value resembles SQL injection or cross-site scripting. Those refusals carry no problem document. Write your client to handle an error response it can't parse, rather than assuming every failure has a JSON body.

**404**

Unknown `workflowId`.

The body is an RFC 9457 problem document, served as `application/problem+json`. Two problem types tell the cases apart:

| `type` | Meaning |
|--------|---------|
| `https://pointservices.com/problems/not-found` | An id in the path isn't one this API knows. Check that you sent it exactly as the API returned it. |
| `about:blank` | The URL or method isn't one this API serves at all. Check the path. |

| Property | Description | Type |
|----------|-------------|------|
| type | An absolute URI identifying the problem type. This is the stable value to match on; compare it as a string. | string |
| title | A short summary, written for a person. | string |
| status | The HTTP status code, repeated in the body. | number |
| detail | An explanation of this occurrence, written for your logs. Never match on it. | string |
| instance | A URI identifying this occurrence, written as `urn:pps:request:<id>`. The id is the same value as the `x-pps-request-id` response header. Quote it when you report a problem to PPS. | string |

```json
{
  "type": "https://pointservices.com/problems/not-found",
  "title": "No such resource",
  "status": 404,
  "detail": "Workflow[wfpop_0000000000002082611] not found",
  "instance": "urn:pps:request:8d3a1f56-6c94-4e20-b7f8-0a5e9c2d4b73"
}
```

> **Warning:** Branch on `type`, never on the text of `title` or `detail`.