List a Workflow’s Findings

Beta

List a Workflow’s Findings

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) and to a direct GET of that finding (Get One Finding).

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

Read-only and safe to poll.

Sample
- Header Properties
- Path Parameters
Responses

Sample

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

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. Always present on this list, the categorized view and Get One Finding: `[]`, never omitted, when it falls into none. Left out of the finding returned by Edit a Finding and by adding or removing an attachment.	array
references	The subjects the run that produced this finding concerns: see 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), 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. 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.	boolean
hasHistory	Whether Get a Finding’s 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 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 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: `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

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.
`riskinsight:JournalResolvedValueUpdateNote`	Set, replace or clear `reviewNote` with Edit a Finding.
`riskinsight:JournalResolvedValueUpdateAttachment`	Add or remove 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.

{
  "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"`

{
  "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"
}

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.

{
  "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

{
  "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"
}

Branch on type, never on the text of title or detail.