---
title: "How QueueZero works"
canonical: "https://support.appfire.com/space/RS/3654975588/How%20QueueZero%20works"
format: markdown
---
**QueueZero** can operate as a single point of contact between several systems - Jira, Confluence, GitHub and Bitbucket, and, if you choose, your organization’s LLM models. Its overall flow - the process it follows to move a work item from backlog to PR created - is designed to enhance your team’s efforts while maintaining accountability for code changes and governance standards. The illustration below outlines the QueueZero process, how it interacts with other systems, and the trust boundaries it crosses and when it does so.
> ℹ️ Every line crossing a dashed boundary is data leaving one party's control for another's. The dashed box at stage 03 is a virtual machine built for a run; its working copy is either discarded or parked so your next run on the same branch starts faster, and it is never reachable by another organization. Green marks the human decision points. Merging the pull request cannot be skipped. Plan review can be skipped; single-shot mode ships turned on, or it can be switched off before planning so you can approve the plan before code is written.
## What data moves, and in which direction?
**Stage** indicates the stage in the diagram.
| **Data** | **Direction** | **Stage** |
| --- | --- | --- |
| Issue text, attachments, linked pages | Jira & Confluence → QueueZero | 01 |
| Plan, run status, summary | QueueZero → Jira | 01, 04 |
| Ticket text and relevant source code | QueueZero → model provider | 02, 03 |
| Proposed plan and code changes | Model provider → QueueZero | 02, 03 |
| Repository clone | Your SCM → VM for the run | 03 |
| Branch and pull request | QueueZero → your SCM | 04 |
| Web research queries and fetched pages | Model provider <--> public web | 02, 03 |
> 📝 Your code and ticket content go only to the systems shown above. QueueZero does not sell them, share them, or route them anywhere else.
## Other questions
To what systems does QueueZero connect?
- **Jira and Confluence** — issues, attachments, and linked knowledge pages. Connected per user, so QueueZero sees exactly what that person sees.
- **GitHub or Bitbucket** — repository access to clone, branch and open pull requests. Also per user.
- **Your identity provider** — sign-in, organization membership and roles.
- **A model provider** — Anthropic in the United States by default, or your own Bedrock or Vertex account if you bring your own model.
- **Public documentation sites** — when web research runs, the search is performed by your model provider and fetches public pages. Your repository is never published to them.
The Jira app is a panel inside Jira. It has no separate processing stack of its own — it calls the same backend as the standalone app, so everything on this page applies to both.
Where does the LLM come in?
At two points. At stage 02 the model reads the ticket and enough of the codebase to propose a plan. At stage 03 it writes the actual changes inside the run VM and reacts to failing tests.
The model has no direct connection to your systems. It never holds your credentials and never calls Jira or your repository. Everything it produces comes back to QueueZero, which then acts within the limits described below.
**Default route:** Anthropic, United States. **Optional:** your own Amazon Bedrock or Google Vertex account, in the region you choose, so inference stays inside your cloud.
Where is data stored, and what residency applies?
All **QueueZero** storage and processing is in the United States (AWS us-east-1). Content originates wherever your own tools live — your Atlassian site region, your SCM — and crosses into the US when QueueZero processes it. There is no way to keep processing in-region today.
We do not keep a copy of your repository. We do keep a structural index of it, and code content appears in run logs. The table below is specific about both.
| **Data** | **Kept? ** | **Where and for how long? ** |
| --- | --- | --- |
| A copy of your repository | [NEVER] | The clone exists only in the run environment. Its working copy is either discarded or parked for a limited period so your next run on the same branch starts faster. Only your organization can access it. |
| Structural index of your code | [KEPT] | File and symbol names, signatures, line ranges, imports and dependency manifests. No file contents. Kept in the US, and only while the repository is connected. |
| Tool inputs recorded during a run | [KEPT] | In the US. For file writes and edits, this includes the code the agent wrote. Recorded at the default logging level |
| Prompts and model responses - our copy | [KEPT] | In the US, with secret-shaped values scrubbed. Stored verbatim, along with the contents of files the agent reads, only if a project raises its logging level. |
| Prompts and model responses - at the provider | [NOT OURS] | Governed by your chosen provider's terms. |
| Plans, run history, branch and PR references | [KEPT] | Encrypted in the US database, retained until your organization is deleted. |
| Audit trail | [KEPT] | In the US, visible in product, retained until your organization is deleted. |
| Patterns learned from your completed work | [KEPT] | Rolling 90 days, and deletable on request. |
| Run artifacts in object storage | [KEPT BRIEFLY] | 7 days for the index build, 14 days for run envelopes. |
| Connection credentials | [KEPT] | Encrypted key store, scoped so one customer's credentials cannot be read by another. |
> 📝 **When you leave.** Closing your account triggers a full purge of everything in this table — the structural index, run history, plans, the audit trail, learned patterns, stored credentials, and any parked working copy. It completes within 60 days, under Appfire's standard data deletion policy. Disconnecting a single repository removes that repository's index and any parked copy of it on the same basis.
Is my data isolated, and is it used to train AI models?
**Isolation.** Every customer's records are separated at the database level and credential access is scoped per customer. Run environments hold no long-lived credentials, and a parked working copy can only be reclaimed by a run from the same organization on the same repository and branch. Your structural code index is likewise scoped to your organization. Infrastructure is shared and logically isolated - a fully single-tenant deployment is on the roadmap and is not available today.
**Training.** Appfire does not train AI models on customer data. Not on your code, your tickets, your plans, or anything derived from them. There is no opt-out to ask for because there is nothing to opt out of.
The default route runs on Anthropic's commercial API, whose terms state that inputs and outputs are not used to train Anthropic's models. If you bring your own model, inference runs in your account under your own provider agreement and never reaches ours.
What can I control?
- **Which model runs.** Use the default, or bring your own Anthropic, Bedrock, or Vertex account so inference stays in your cloud and your region.
- **Guardrails.** Org-wide rules the agent must follow on every run — no hardcoded secrets, no unparameterized SQL, no secrets in logs, authorize every new endpoint. Write your own, and lock any of them so an individual project cannot switch them off.
- **Who connects what.** Each person connects their own Jira, GitHub, and Bitbucket accounts. The agent inherits that person's permissions and can reach nothing they cannot already reach. If someone has not connected a repository account, the pull request is opened by the QueueZero app instead of as that user, and the run screen says so before they start.
- **Whether the plan gets reviewed.** Single-shot mode is on by default, so the agent goes from plan to code without stopping. The toggle appears on the run screen every time; switch it off, and a person must approve the plan before the agent writes any code.
- **Whether CI failures are fixed automatically.** On by default: when the pull request's CI fails, the agent pushes a follow-up commit. Switch it off per run, and failures wait for your team.
- **Which repositories and branches are in scope.** Only repositories you connect, and you pick the base branch and PR branch name for each run.
- **How much a run records.** Each project has a logging level. By default, runs record what the agent did and the inputs it passed to its tools. Raise it, and runs also store prompts, model responses, and the contents of files the agent reads — useful when debugging a bad result, and worth turning back down afterward.
**Not yet controllable:** web research cannot be switched off today. It fetches public documentation and doesn't post anything about your code or tickets. A control to disable it is on the roadmap.
What needs approval, and what does the agent do on its own?
| **A person must act** | **The agent does alone** |
| --- | --- |
| - **Review and merge the pull request.** Always, with no way to skip it. It lands in your own repository under your existing review rules, CI and branch protection.
- Start each run and choose which repositories and branches it may use
- Set and lock guardrails at the org level
- Connect each Jira and repository account | - Read the ticket and linked pages
- Plan the change, and — unless you ask to review the plan — start writing code straight away
- Clone the repo, edit files, run your tests until they pass
- Push a branch and open a pull request
- Push follow-up commits when the PR's CI fails, if auto-resolve is left on
- Write status and a summary back to the ticket |
**Plan review is offered on every run and off by default.** Single-shot mode is switched on out of the box, which means the agent plans and then writes code without pausing. The toggle sits on the run screen with its effect spelled out, so the person starting the run decides. Turning it off makes plan approval a required step for that run.
Whichever way that toggle is set, the agent cannot merge, cannot force-push, cannot delete branches, and cannot push to your default branch. The worst case is a pull request your team rejects — the same as one from any other contributor.
What is logged?
Every run leaves a trail against the ticket, visible in the product rather than on request. It records which plan ran, which files were touched, which commands were run, which branch and pull request came out, which model was used, and who approved.
**You choose how much detail it holds.** At the default logging level, the trail includes the inputs the agent passed to its tools, which, for file writes and edits, is the code it wrote. Raise the level, and the trail also holds prompts, model responses, and the contents of files the agent read. That is a debugging aid, and it is also more of your code sitting in our database — so the level is worth checking before you leave it raised.
Values that look like credentials are scrubbed before anything is written. That scrubbing targets secrets, not source code, so it does not stop code content being recorded.
A default guardrail also instructs the agent never to write secrets or sensitive data into logs. Lock it at the org level so no project can turn it off.