What the issue intake agent handles
Inbound issues often arrive incomplete: missing labels, vague descriptions, no component assignment, and inconsistent priority. A Jira issue intake agent handles the enrichment step while keeping an operator in control of the final write.
The task handles three main intake scenarios:
- Field enrichment. The agent reads the issue description and context, then proposes missing fields: component, label, priority, and epic linkage based on your conventions.
- Description standardization. For issues with vague or incomplete descriptions, the agent proposes clarifying questions or enriched summaries based on similar past issues.
- Duplicate detection. The agent compares the new issue against recent backlog items and flags potential duplicates before the issue is finalized.
How the issue intake task runs
The table below shows the trigger, inputs, outputs, and approval logic so you can judge operational fit quickly.
| Task stage | What happens | Output | Approval |
|---|---|---|---|
| Trigger | A new issue is created in Jira from a form, email, or integration | Enrichment job starts | No approval for read phase |
| Inputs | Issue summary, description, reporter context, project conventions | Enrichment proposal | No approval for data gathering |
| Proposed action | Add labels, set component, assign priority, link to epic, or flag duplicate | Prepared issue update | Approval before any write |
| Operator review | Reviewer checks why enrichment was proposed and what fields will change | Approve, reject, or edit | Explicit approval required |
How to set up issue intake
Define your intake conventions in plain language, including required labels, component mapping rules, and priority criteria.
Connect Jira with access to the project, issue types, and custom fields needed for enrichment.
Choose which low-risk enrichments can be batched for review and which edge cases should always surface individually.
Set notifications so the operator sees proposed enrichment batches quickly when inbound volume spikes.
Permissions and visibility
- Read access should cover the issue fields, project conventions, and past issue data needed for enrichment.
- Write scope should be limited to labels, components, priority, epic links, and approved custom fields.
- Duplicate detection should flag matches clearly so manual review can confirm merge or keep decisions.
- Approval views should show both current and proposed field values before commit.
Frequently asked questions
Does issue intake happen automatically or does it require approval?
By default, enrichment proposals are surfaced for review before the issue is updated in Jira. Teams can keep approvals on for edge cases or new issue types and loosen them only for well-understood cases.
How does the agent decide what to enrich or standardize?
The agent applies your intake logic: required fields, label conventions, priority mapping, and component assignment rules. You describe the logic in plain English, and the agent reasons over the issue data to propose the correct enrichment.
What happens if the intake logic changes?
Update the task description, review the new execution plan, and activate. The agent adapts to the new logic without forcing you to rewrite a large set of fixed rules.
Can the agent handle issues from multiple sources?
Yes. The agent can process issues from Jira forms, email-to-issue, Slack integrations, or API submissions. Source-specific enrichment rules can be applied based on where the issue originated.