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:
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 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
Submit the proposed settings to
/admin/ticketing/settings/{findingType}/preview.Review the counts and sample of tickets that would be created or fall outside scope.
Save the settings. The save records the chosen migration action but does not itself close existing tickets.
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, Priorities, and Manual Ticket Creation. Review the actual destination account and project before enabling automatic creation.
Last updated