Integrations
Q247 does not generate data on its own. Everything visible on the dashboards comes from systems that already run at the Client: code repositories, Jira, Confluence, the identity provider. This part of Configuration handles the connections to them.
Integrations fall into three groups of a different character. The first delivers work data, and without it the platform is empty. The second concerns accounts and sign-in and is optional, because the organization can manage accounts manually. The third supports AI functions: it accepts data about the use of AI tools and provides the language model to the AI Assistant.
Integrations that deliver data
| Integration | What it brings | When it is needed |
|---|---|---|
| Connectors | commits and repository history, from which Calories, Increments and Lines are calculated | always, this is the foundation of how Q247 works |
| Jira | the history of ticket status changes | when the organization wants to measure Lead Time and Cycle Time |
| Confluence | the effort put into documentation | when documentation is a significant part of the team's work |
Connectors are a subcategory: one connector corresponds to one version control system, and Q247 supports seven types, from GitLab and GitHub to repositories added manually.
Running code analysis is a guide to the whole process, from creating the connector to data appearing on the dashboard.
The order of steps matters more than the details of individual fields. The symptom of skipping one of the steps looks identical to an integration failure: the connector shows an Operational status, and the dashboards are empty.
Identity integrations
These two handle different things and are deployed independently.
| Integration | What it handles | What it does not do |
|---|---|---|
| SSO (OIDC) | sign-in through an external identity provider | does not create accounts |
| SCIM Provisioning | creating, updating and deactivating accounts and teams | has no effect on the sign-in method |
You can deploy one of them, both, or neither. With both at once, the identity provider creates the accounts, and users sign in without a password on the Q247 side. With SSO alone, accounts have to be created manually, otherwise sign-in will not find their counterpart in Q247.
AI feature integrations
Both are optional and independent of each other, and each supports a different AI function.
| Integration | What it handles | Data direction |
|---|---|---|
| AI tool logs | receiving telemetry from AI tools, including Claude Code | to Q247 |
| Language Model | the model powering the AI Assistant | from Q247 to the model |
The first feeds the numbers in AI adoption, the second is responsible for the responses of the AI Assistant. AI adoption also works without telemetry, relying then on commit message trailers.
Actions outside Q247
Integrations are the only part of Configuration that requires actions in other systems. Depending on the scope of the deployment, you will need help from people with the right permissions:
- the version control system administrator: a service account and a token with read access to the repositories covered by the analysis,
- the Jira or Confluence administrator: once, to install the Q247 app (cloud versions) or register the webhook (Data Center),
- the identity provider administrator: registering the app for SSO or configuring the SCIM connector,
- the network team: for deployments in which the plugin runs in the Client's infrastructure.
Every integration page has its own prerequisites section with a specific list.
Subpages
Connectors
7 items
Running code analysis
The sequence of steps from an empty organization to data on the dashboards, including steps that are easy to miss.
Jira
The Jira connector in its Cloud and On-Premise variants, from prerequisites to confirming that data actually flows.
Confluence
The Confluence connector in its Cloud and On-Premise variants, identified by space key, with a requirement for visible email addresses.
SSO (OIDC)
Configuring login through an external identity provider, with fields, paths at the provider and account requirements.
SCIM Provisioning
Automatic account creation and deactivation from the identity provider, with group mapping to roles and access.
AI tool logs
Receiving telemetry from AI tools in the OpenTelemetry standard, in two variants: a collector inside the plugin or Dynatrace.
Language model
Three variants for providing the language model for the AI Assistant: the Client's cloud, on-premise, or Q247 infrastructure.
See also
- Configuration: the other sections of this tab, without external connections
- Enterprise Plugin: the component that handles the data integrations
- Enterprise Plugin security: the scope of data exchanged with Q247