> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Resolve alerts and re-evaluate
> This guide explains how to update alert statuses via API, trigger a workflow re-evaluation, and retrieve an entity's activity history.
## Resolve alerts
| Portal display | API manualStatus | Description |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
Needs attention | `null` | Indicates that the alert requires review and resolution. |
| 
In review | IN\_REVIEW | Indicates that the alert is being actively investigated or reviewed. |
| 
True positive: Reject | TRUE\_POSITIVE\_REJECT | Indicates that the activity was confirmed or suspected to be fraudulent or high-risk, and the associated activity was rejected (e.g. transaction blocked). |
| 
True positive: Accept | TRUE\_POSITIVE\_ACCEPT | Indicates that the activity was confirmed or suspected to be fraudulent or high-risk, and the associated activity was accepted (e.g. transaction approved with override). |
| 
False positive | FALSE\_POSITIVE | Indicates the alert was reviewed, and confirmed or assumed to be genuine or low-risk. |
### via API
To resolve an alert, update the activity result's status by calling the Update Activity Results endpoint. For more details around classification (applying `tagIds`), see [Classifying activities and alerts](/v2/docs/tm/implementation-classification).
`X-Frankie-Username` is optional. If provided, it identifies the actor in the audit log.
```shellscript theme={null}
curl -X 'PATCH' \
'https://api.uat.frankie.one:443/v2/individuals/{{your_entity_id}}/results/activity' \
-H 'accept: application/json' \
-H 'api_key: X' \
-H 'X-Frankie-CustomerID: {{your_customer_id}}' \
-H 'X-Frankie-Username: example@frankieone.com' \
-H 'Content-Type: application/json' \
-d '{
"processResults": [
"{{processResultId}}"
],
"tagIds": [
"{{tagId}}",
"{{tagId}}"
],
"manualStatus": "TRUE_POSITIVE_ACCEPT",
"comment": {
"text": "Update after speaking to customer over the phone directly.",
"entityId": "{{your_entity_id}}",
"entityType": "{{entityType}}"
}
}'
```
The IDs of the process results (alerts) to update. A process result is created when an activity is flagged for review. Supply one or more UUIDs; the `manualStatus` is applied to each.
The manual outcome to record for the alert. Must be one of:
* `FALSE_POSITIVE` — the result was reviewed and determined to be genuine or low-risk; the activity is within the risk profile to continue.
* `TRUE_POSITIVE_ACCEPT` — the result was determined to be a true positive, and the activity is within the risk profile to continue (for example, the transaction is approved with an override).
* `TRUE_POSITIVE_REJECT` — the result was determined to be a true positive, and the activity is not within the risk profile to continue (for example, the transaction is blocked).
* `IN_REVIEW` — the alert has been picked up and is being actively investigated. "Needs attention" is the unresolved default state of an alert. It corresponds to no manual status being set and is not a value you send through this field.
Optional tags to apply to the alert and its associated activity. Each tag must exist and be accessible to your account (a FrankieOne `SYSTEM` tag or a `CUSTOMER` tag your account owns). Duplicate IDs are removed automatically. A request must not mix `FALSE_POSITIVE`- or `IN_REVIEW`-category tags with tags of any other category — the intent cannot be reconciled and the request is rejected with `400`
See [Tags and Reasons reference](/v2/docs/tm/tags-and-reasons-reference) for the full list of available tags.
An optional comment recorded in the audit log alongside the status change. Because comments are tied to the manual status action, they form part of the compliance audit trail.
The comment text.
The entity the comment relates to, as a UUID.
The entity type — for example, `INDIVIDUAL` or `ORGANIZATION`.
### via Portal
See [Features](/v2/docs/tm/features-resolving-alerts) for more details
## Re-evaluate the results
This is crucial for the entity's overall risk score, which are calculated based on historical activity, and device or customer characteristics.
Once all alerts have been resolved, you must re-run the workflow for the entity.
1. **To update the** `status`: The overall `workflowResult.status` will only be changed by the system from `REVIEW` to `PASS` or `CLEAR` after the workflow is executed again and the steps included in the monitoring workflow confirms that no unresolved hits remain.
2. **To clear** `issues`: The re-execution will cause the steps to re-evaluate the issues. If all PROs that previously caused an `ACTIVITY` issue are now classified as `FALSE_POSITIVE`, the issue will be cleared from the workflow result.
This re-evaluation ensures that your entity’s compliance status is officially updated, reflects the latest risk assessment, and maintains an accurate audit trail.
### via API
To trigger a re-evaluation via API, you will execute the workflow again. Refer to the [Execute a workflow for the given service profile](/api-reference/individual-workflows/execute-a-workflow-for-the-given-service-profile) documentation.
### via Portal
The Portal will automatically re-run the workflow for you once all alerts associated with an activity have been resolved (i.e. no alerts with “Needs attention” and “In review” status remain).
### Detecting manual overrides
It’s crucial to know if a workflow’s result was changed by a person. When an operator manually changes the status (for example, from `FAIL` to `PASS`), the following fields are populated:
* `statusOverrideRequestId`: The unique ID of the override request.
* `statusOverrideBy`: The user who performed the override.
* `statusOverrideAt`: The timestamp of the override.
To detect an override, check if `statusOverrideRequestId` exists and is not empty.
## (Optional) Retrieve all activities
Fetch historical information about the transactions to help get context of the user behavior and investigate.
```shellscript theme={null}
curl -X 'GET' \
'https://api.uat.frankie.one:443/v2/individuals/d2859e0c-1f63-4208-947a-038bcb7b1e5e/activities?sortField=ACTIVITY_AT&sort=ASC&limit=20&page=1' \
-H 'accept: application/json' \
-H 'api_key: X ' \
-H 'X-Frankie-CustomerID: {{your_customer_id}}' \
-H 'X-Frankie-Username: {{example@frankieone.com}}'
```
## Related pages
* [Classifying activities and alerts](/v2/docs/tm/classifying-activities-and-alerts) — set alert statuses and classify activities via API.
* [Interpret activity results](/v2/docs/tm/implementation-interpret-results) — read the workflow result and identify the alerts to resolve.
## Next step
Your implementation is complete. If you encounter errors at any step, see the full list of error codes and response structures: [Error handling](/v2/docs/tm/implementation-error-handling)