> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/configuration-ticketing.md).

# Ticketing Configuration

Configure automatic ticketing separately for each finding type. Start with a connected destination and valid assignee routing; a threshold alone does not determine which project, board, or person receives work.

## Routing and filters

The settings API uses `POST /admin/ticketing/settings/{findingType}` with a `proposal` object. Its fields include:

| Field                                          | Purpose                                                                      |
| ---------------------------------------------- | ---------------------------------------------------------------------------- |
| `isEnabled`                                    | Enable automatic ticket creation for this finding type.                      |
| `priorityThreshold`, `severityThreshold`       | Set the finding thresholds.                                                  |
| `defaultBoardId`                               | Fallback destination board/project.                                          |
| `teamRoutingEnabled`                           | Route through the owning team's configured destination.                      |
| `unroutedBehavior`                             | Choose the supported fallback behavior when a team route cannot be resolved. |
| `filtersRepoAllowlist`, `filtersRepoBlocklist` | Include or exclude repositories.                                             |
| `filtersCweAllowlist`, `filtersCweBlocklist`   | Include or exclude weakness classes.                                         |

Use the [Admin API schema](/api-reference/api-reference/api-admin.md) for accepted values and the exact request shape. Manual creation can accept a destination override on supported finding endpoints; it is not always locked to the global project.

## Preview changes before cleaning up tickets

1. Submit the proposed settings to `/admin/ticketing/settings/{findingType}/preview`.
2. Review the counts and sample of tickets that would be created or fall outside scope.
3. Save the settings. The save records the chosen migration action but does **not** itself close existing tickets.
4. If cleanup is intended, use the explicit bulk-ticket action and its dry-run/confirmation flow. Track the returned operation ID until completion and inspect errors.

Tightening a threshold is not evidence that every old ticket was closed. Settings history and ticket activity provide separate audit trails.

## Remediation SLAs

SLAs carry `severity`, `priority`, `maxDaysToFix`, and `allowExtensions`. Read them with `GET /admin/sla`, create through `POST /admin/sla`, patch a policy through `PATCH /admin/sla/{slaId}`, or save the grid through `PUT /admin/sla/bulk`.

The current dashboard's SLA grid shows **Urgent**, **Important**, and **Negligible**, initially 7, 21, and 60 days respectively when no saved row supplies a value. The single-policy POST path has a narrower accepted priority list (`URGENT`, `IMPORTANT`, `MEDIUM`, `LOW`). Do not copy a UI label into a different API operation without checking that operation's validation. Bulk updates are severity-keyed; keep distinct rows associated with distinct severities.

## Fix-effort mapping

`GET /admin/fix-effort` returns the saved easy/medium/hard weights. `PUT /admin/fix-effort` accepts a `fixEffort` object containing `id`, `easy`, `medium`, and `hard`. Preserve the returned ID when updating the mapping. These values feed story-point estimates in supported ticketing workflows; they do not change finding severity.

## Jira-specific behavior

See [Assignee](/connectors/jira/assignee.md), [Priorities](/connectors/jira/priorities.md), and [Manual Ticket Creation](/connectors/jira/manual_creation.md). Review the actual destination account and project before enabling automatic creation.