# The developer workflow

> How a triaged ticket becomes a tracked engineering issue. The GitHub and GitLab pieces, what each one is for, and the loop they close together.

Source: https://triagic.com/docs/concepts/developer-workflow

Triagic touches GitHub and GitLab in two distinct places, and they are configured
separately because they answer different questions:

| Piece                                                  | Question it answers                                     | Configured where                              |
| ------------------------------------------------------ | ------------------------------------------------------- | --------------------------------------------- |
| [GitHub / GitLab data source](/docs/integrations/code) | *"What does the code and its history say caused this?"* | Cloud portal → Integrations (org-wide, admin) |
| [Issue tracker connection](/docs/desktop/issues)       | *"Where does the confirmed bug get filed?"*             | Desktop app (per user)                        |

## The loop [#the-loop]

### A ticket arrives and is triaged [#a-ticket-arrives-and-is-triaged]

From [HubSpot, Zendesk or Jira](/docs/desktop/ticket-sources), or pasted into the
Console. The investigation runs as described in
[How an investigation works](/docs/concepts/how-triagic-works).

### The agent reads the code [#the-agent-reads-the-code]

If the org has connected the [GitHub or GitLab data source](/docs/integrations/code),
the investigator can pull recent commits, pull requests and file contents mid-triage,
so "the checkout regression shipped in PR #482 on Tuesday" is a finding it can make,
not one you have to.

### An engineer reviews the result [#an-engineer-reviews-the-result]

The triaged ticket carries a summary, root-cause hypothesis and evidence trail. Not
every triaged ticket becomes an issue. That judgement stays with a person.

### The confirmed bug is filed [#the-confirmed-bug-is-filed]

One click drafts a GitHub or GitLab issue from the investigation:
summary, root cause, evidence and funnel drop-off, with the reporter's email and user
id deliberately left out. The draft is editable before anything leaves the machine;
see [Filing issues](/docs/desktop/issues).

### The link is kept [#the-link-is-kept]

The filed issue's URL is stored on the ticket, and filing is recorded in the
[audit log](/docs/admin/audit). Support can answer "is this fixed yet?" by following
the ticket to the tracker instead of asking in a channel.

## Self-hosted installs [#self-hosted-installs]

Both pieces speak to self-managed GitHub Enterprise and GitLab instances, including
ones behind an internal CA. The data source takes a host and CA bundle
([details](/docs/integrations/code)), and the issue tracker connection takes a base
URL and the same TLS options ([details](/docs/desktop/issues#a-self-managed-host-behind-an-internal-ca)).

## What stays out of the loop [#what-stays-out-of-the-loop]

Filing is deliberately one-way: Triagic does not comment on, close or edit issues
after they are filed, and it never writes back to the originating ticket source.
The tracker remains the engineering team's system of record; Triagic just delivers a
well-evidenced report into it.