Issuer Incident Workspace Help and Documentation

Learn how to use the Incident Workspace to locate incident cases, filter by ownership and status, compare cases with alerts and action-queue work, create incidents from qualifying signals, and navigate the incident worklist.

Incident Workspace Overview

The Issuer Incident Workspace is the operational home for durable incident cases. It is designed to track:

  • Incident ownership
  • Case status
  • Triage state
  • Issuer and merchant context
  • Routing queue
  • Priority
  • Closure recommendations
  • Recommended next actions
Incidents are not the same as alerts Alerts and action-queue items can exist before an incident case is created. The Incident Workspace shows durable cases only.

Filters

Filters narrow the incident table. You may use one filter or combine several.

Limit

Controls the maximum number of incident rows returned. The accepted range is 1 to 10,000.

Large limits A limit of 10,000 is useful for broad review or export-style inspection, but a smaller value may be easier to navigate when the incident database grows.

Offset

Specifies how many matching rows to skip before displaying results. Offset 0 begins with the first matching incident.

Status

Filters by incident lifecycle status. The placeholder suggests open. Other valid values depend on the incident workflow implementation.

Triage State

Filters by the current investigation or triage stage. The placeholder suggests investigating.

Owner

Filters cases assigned to a particular owner or operator, such as alice.

Issuer BIN

Filters incidents to one issuer cohort, such as 414720.

Useful combinations Combine Status with Owner to find one operator's open work, or combine Issuer BIN with Triage State to find active cases for a specific issuer.

Apply Button

Select Apply after entering filter values.

The page submits the filter form using a GET request and reloads the incident table with matching rows.

Apply does not modify incidents It changes only the displayed result set. It does not assign, close, or update a case.

Incidents Table

Each row represents a durable issuer incident case. When incidents exist, the table allows operators to compare ownership, severity, routing, and recommended actions.

Incident Table Columns

Incident IDThe unique durable case identifier.
MerchantThe merchant associated with the incident.
Issuer BINThe issuer cohort involved.
CountryThe issuer or incident country context.
BrandThe payment-card brand.
StatusThe incident's lifecycle state.
Triage StateThe current investigation stage.
SeverityThe seriousness of the incident.
OwnerThe operator or team responsible.
QueueThe operational queue handling the case.
PriorityThe urgency assigned to the incident.
Auto CreatedWhether automation created the incident.
Closure RecommendationGuidance on whether the case may be closed.
Recommended ActionThe suggested next operator step.

Previous Page and Next Page

Pagination controls appear above and below the incident table.

Previous Page

Moves to the prior block of incidents by reducing the current offset.

Next Page

Moves to the next block by increasing the offset by the current limit.

Disabled Controls

In the supplied page, both controls are dimmed and unavailable because no incident rows exist and there is no previous or next result page.

Showing Offset and Limit

The text Showing offset 0 with limit 10000 explains the current pagination settings.

No Incident Cases Found

The empty state means no incident records match the current filters.

This can mean:

  • No incidents have been created yet.
  • Alerts exist but have not been converted into incidents.
  • Action-queue work exists without a durable incident case.
  • The active filters exclude existing incidents.
Clear restrictive filters first Before assuming no incidents exist, remove Status, Triage State, Owner, and Issuer BIN filters, reset Offset to 0, and select Apply.

Auto-create Incidents

The empty state includes another Auto-create Incidents link.

This opens the automated creation workflow so qualifying upstream alerts or action items can become durable incident cases.

Avoid duplicate cases Before auto-creating incidents, confirm that the same issuer condition has not already been represented by an existing incident, worklist entry, or operator-owned case.

Recommended Incident Workflow

  1. Open View Alerts and review the upstream issuer signal.
  2. Open the Action Queue to check for existing routed work.
  3. Return to the Incident Workspace.
  4. Clear filters and Apply to verify whether a case already exists.
  5. Filter by Issuer BIN when investigating one issuer.
  6. Use Auto-create Incidents only when a durable case is needed and no duplicate exists.
  7. Open the Incident Worklist to assign, triage, and process cases.
  8. Track Status, Triage State, Owner, Queue, and Priority through resolution.
  9. Review Closure Recommendation and Recommended Action before closing the incident.