What FixControl does
From issue to tested fix. FixControl connects your support channels, your documentation and your codebase. A report — from a customer, or from your own team — is investigated with the information that belongs to the project. FixControl proposes a code change, tests it in an isolated sandbox and then puts it in front of your team.
By default, nothing goes to your customers, your repositories or your production environment without a recorded human decision. Code changes arrive as a pull request (or merge request), never directly on your main branch. Automation that acts without a person exists only where your organization switches it on, within limits you set, and it is recorded.
First the right information. Then a proposal. Only after checks, an action.
Two starting points, one route
| Starting point | How it comes in | Example |
|---|---|---|
| A customer report | By e-mail in the Inbox: you turn it into an issue with Create issue, or let FixControl do that per mailbox automatically. Through Slack or Microsoft Teams: the bot proposes an issue and creates it once someone confirms. | "Since yesterday the VAT amount on my invoice is wrong." |
| Work your team starts itself | You file an issue with New Issue, open a work session directly on the codebase, or let your own systems create an issue through the public API. No support ticket is needed. | A known bug, a backlog item, an internal defect. |
Tickets in Freshdesk, Linear, Odoo or TOPdesk do not become issues by themselves, and Jira tickets only when Import new Jira tickets as issues is switched on for the project's Jira link: FixControl creates tickets there and follows their status, and in Slack or Teams you can import an existing Jira or Freshdesk ticket by hand. See Integrations.
From there, the work follows the same steps:
- Investigate — FixControl reads the report, earlier tickets, the documentation you connected and the project's repository. This is read-only.
- Propose — for risky work, first an execution plan that someone approves, then a concrete patch. Nothing has been changed or sent yet.
- Test — the patch runs in an isolated sandbox: install, build and the project's tests. Where FixControl knows how your application starts, it also has to come up.
- Decide — an authorized colleague reviews the change with the test results and approves, rejects or asks for changes. For work without a risk flag this can also be the CTO Review agent, after a passing test (see below).
- Deliver — after approval you open the pull request (or FixControl does it straight away, if the project switched on auto-deliver). Merging is yours, in your own Git provider. A deployment is only affected where you configured that, after its own approval.
Each step is a separate event with its own status. Created, tested, approved, delivered as a pull request, merged and deployed are six different things, and FixControl shows them that way. See Delivering changes.
What happens at each decision point
| Moment | By default | What you can change |
|---|---|---|
| A reply to a customer | A colleague writes or reviews the reply and sends it. The AI only makes a suggestion. | Per organization or project, the AI can prepare drafts or send low-risk replies itself, within limits. You can also require approval for AI replies or for every reply. |
| An execution plan | Requested for work with priority critical or a risk flag (payments, sign-in, security, migrations, data loss, personal data, infrastructure). | Governance policy can require a plan always, or never. |
| Approving a patch | A person decides for work with a risk flag, when the CTO Review agent objects, or when it was not proven that the application still starts. For other work the CTO Review agent may approve the patch — but only after the sandbox test of exactly that version has passed. | Who may decide, and whether several approval stages are needed. |
| Opening a pull request | A colleague opens it after reviewing the title, description and commit message. | A project can switch on auto-deliver: after approval, the pull request is opened straight away. |
| Merging | Never by FixControl. | — |
| A deployment | No effect. | Where your administrator sets up a deployment gate, an approval releases a paused rollout or pipeline. |
A patch can only be delivered when the sandbox test of that version has passed; anyone who departs from that must give a reason, and that reason is placed at the top of the pull request. More in Approvals and Delivering changes.
Your first steps
What you need depends on your role.
Are you your organization's administrator? Start with Admin guide → Admin onboarding. There you set things up in this order:
- Create a project under Projects → New project.
- In that project, under Connections, connect a mailbox or chat channel for reports, and a repository for code.
- Let FixControl check that it can build and test your application (under Environments).
- Add colleagues and decide who may approve.
Do you handle customer questions? Read Inbox and Replies to customers.
Do you work on bugs and features? Read Issues, Work session and Verification and results.
Do you approve? Read Approvals.
The screens you use most
| Screen | What for |
|---|---|
| Inbox | View, answer and turn into issues the e-mail that arrives in connected mailboxes. |
| Issues | All work after intake, with priority, status and the actions per kind of work. |
| Work sessions | A chat with an AI agent on a codebase, for work your team starts itself. |
| Approvals | Everything waiting on a decision: open gates (plans, code changes, deployments) and replies to customers. You reach it through the amber … waiting on you notice at the bottom of the sidebar, or through Notifications. |
| Patches | Proposed changes by status: pending, approved, applied, rejected, archive. |
| Sandbox runs | Every test run with its outcome and evidence. |
| Projects | The boundary: which sources, people and rules belong to a piece of work. |
Which menu items you see depends on your work profile. A new account starts with a short menu; AI results such as Patches and Sandbox runs appear once there is something to show. With the support profile the Inbox is called Customer questions and Issues Tickets; with engineering, Issues is called Problems and Patches Proposed changes.
Key concepts
- Project — a bounded working environment. AI works per project with the sources connected to it, not with everything your organization has. See Projects.
- Issue — a unit of work after intake, with a kind: BUG, FEATURE or SUPPORT.
- Patch — a proposed code change. A patch only becomes a pull request after it has been approved and delivered.
- Sandbox — an isolated, temporary environment in which a patch is built and tested. See Verification and results.
- Gate — a moment at which work waits for a recorded decision. See Approvals.
- Confidence is not risk. Confidence is how sure the model is of itself; risk is a separate judgement of the consequences. A confident answer can still be risky — read both.
What FixControl is not
- Not an AI that does as it pleases. AI prepares work; by default a person decides.
- Not a replacement for your support software, your issue tracker or your Git provider. FixControl works on top of them.
- Not a promise that every codebase can be tested straight away. What FixControl cannot build or start, it names — and then it gives no green result. See Verification and results.
Need help?
- Something is stuck or refused → Troubleshooting.
- You can also ask in the Command Center: "Is this project ready?", "What is waiting on me?" — see Command Center.
- Which settings belong to your workspace → Settings your workspace makes for itself.