> For the complete documentation index, see [llms.txt](https://docs.ox.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ox.security/analyze-with-ox/analyzing-scan-results/issues/assigning-issue-owners.md).
# Assigning Issue Owners
OX assigns an issue owner automatically based on a configurable priority order.
You can define which ownership sources to use and how they are prioritized. OX evaluates these sources from top to bottom and assigns the issue to the first matching owner.
If needed, you can [override the assigned owner manually](#override-issue-owner-manually).
## Assigning issue owners automatically
By default, OX assigns issue owners based on each policy. You can enable issue owner prioritization that allows controlling the assignment flow and fallback logic.
This helps ensure that every issue is assigned to the most relevant owner, even when ownership is not clearly defined by the policy.
> Notes:
>
> * This capability is disabled by default and must be turned on to take effect.
> * This configuration is available to admins only.
> * Manual assignment always overrides automatic prioritization and is preserved across scans.
> * If the default value is not specified and none of the enabled options have an issue owner defined, then no issue owner will be defined for that issue.
When the automatic assignment is enabled, OX evaluates assignment methods in the priority order you define. The first source that returns a matching owner is used.
You can reorder, enable, or disable sources based on your workflow.
For each issue, OX:
* Checks the enabled method in the list.
* If an owner is found, assigns it.
* If not, continues to the next enabled method.
* Repeats until an owner is assigned or all methods are exhausted.
If no method resolves an owner, the issue remains unassigned unless a fallback is configured.
For code-related issues, when multiple files are grouped into a single issue, OX assigns the owner based on the latest commit in the aggregation.
**To configure automatic issue owner assignment:**
1. Go to **Settings > Scan**.
2. Scroll down to locate **Automatic Issue Owner Assignment** and enable it.
3. Select the assignment methods you want to use.
| Method | Description | Notes |
| --------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Code Owner | Assigns the issue based on the repository's CODEOWNERS definition in Git. | Supports individual owners and teams defined in the CODEOWNERS file. For team owners, OX combines the team name with the selected Team email domain to create the team email address. For example, `@org/engineering` is resolved to `engineering@company.com`. If no code owner is defined in Git, this method is skipped. |
| Most Recent Committer | Assigns the issue to the most recent committer. | Commit data is local and may be inaccurate. Based on the latest commit in the issue. |
| PR / MR / Push Author | Assigns the issue to the user who created the pull request, merge request, or push event. | More reliable than commit metadata. Based on the latest commit in the issue. |
| Veteran Developer | Assigns the issue to the developer with the highest number of commits in the repository. | Repository-level calculation. |
| App Security Owner | Assigns the issue to the application security owner. | Defined in application settings. |
| App Dev Owner | Assigns the issue to the development owner. | Defined in application settings. |
| App Business Owner | Assigns the issue to the business owner. | Defined in application settings. |
| Repository Admin | Assigns the issue to the repository admin with the highest activity. | Based on repository permissions and activity. |
| Repository Creator | Assigns the issue to the user who created the repository. | Static assignment. |
| Default Owner | Assigns all issues to a predefined user. | Typically used as a fallback. |
| OX Policy Default | Uses the default owner assignment defined by each policy. | Default behavior when prioritization is not enabled. |
3. Drag the methods to arrange them in priority order that you want (top to bottom).
4. (Optional) Add a fallback method such as **Default Owner** or **OX Policy Default**
OX evaluates the methods in the order you set.
## Overriding issue owner definition manually
If the automatically assigned owner does not match your workflow, you can override it manually. Manual assignment always overrides automatic prioritization and is preserved across scans.
**To override issue owner definition manually:**
1. Go to Active Issues and select the issue for which you want to override the owner.
2. In the issue details dialog box, go to the actions bar at the bottom and select **Change Issue Owner**.
3. In the **Change Issue Owner** dialog, add the details of the new owner that you want to assign to this issue and select **SAVE**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.ox.security/analyze-with-ox/analyzing-scan-results/issues/assigning-issue-owners.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
