Version 2.7.0 introduces Health Metrics, an assessment of project and team health. Five metrics show where the way of working needs attention, and the assessment is visible on the Overview, in the Teams view, and on individual project and team pages. Calories now also include work in Azure Boards and on Azure Wiki pages, and you can pull data from Jira via API, without configuring webhooks.

Below you will find a detailed description of the most important changes.

---

New Features​

Health Metrics​

A new component shows in one place how work is organized across projects and teams. On the Overview, it appears as the "Project health summary" and assesses the projects the user has access to. In the Teams view, under the name "Team health summary", it lets you step through the organization structure level by level. On the page of a single project or team, it shows the status of that node together with the metrics that need attention.

• Five health metrics. Q247 assesses:

  • Oversize PRs
  • Unreviewed PR
  • Stale PRs
  • Lightning PRs, meaning merged without review almost immediately
  • Overtime Activity

  The first four metrics are calculated from Pull Requests, and Overtime Activity from events in commits and in documentation.

• Project and team assessment. Each metric gets its own status based on the organization's thresholds: Healthy, Watch, or Critical. The assessment of the whole project or team is the status of the worst assessed metric, so a single metric in Critical status is enough to make the whole node Critical. Metrics without a sufficient data sample do not take part in this calculation.
• Thresholds tailored to the organization. The administrator sets the thresholds for each metric in Manage Organization, in the Configuration section. Opening the edit view shows the distribution of the organization's actual data from the last 90 days next to the threshold fields, and the threshold markers move on the chart as you enter the values. Metrics with their own value threshold, meaning Oversize PRs, Stale PRs, and Lightning PRs, have an additional chart showing how many Pull Requests that threshold cuts off. The default thresholds are a proposal for the beta period, chosen from a data sample, and we are still calibrating them.

• "No data" status for a sample that is too small. A project or team without enough data for the assessment to be meaningful gets a separate status and its own position in the summary. Such a node does not affect the assessment of the others or the choice of thresholds.
• Excluding repositories from the assessment. The administrator can mark repositories where assessing the way of working does not make sense, for example automation and infrastructure repositories. The setting is on the Sources list, in the Health Metrics column, and it can be reverted at any time. The exclusion covers only Health Metrics, the repository's other statistics stay unchanged.
• Enabling the module and visibility scope. Health Metrics is enabled with the "Show Health Check" toggle in Manage Organization, in the Configuration section. The module works from Enterprise Plugin version q247-enterprise-plugin-linux-v2.4.2, released in the previous version, and the component stays hidden on older versions. On the Overview, it is visible to people with access to the whole project, and in the Teams view, to people managing at least one team. Everyone sees the health calculated from their own scope.

Learn more: Health Metrics

Calories from Azure Boards and Azure Wiki​

Q247 now calculates calories from work in Azure Boards and on Azure Wiki pages as well. Activity from both sources enters calories under the same rules as work in Jira and Confluence, so it appears in the same views and filters as before. Both sources are connected through a single Azure DevOps connection in Manage Organization, in the Configuration section, and then assigned to projects on the Sources list. The first version covers Azure DevOps Server 2022 in the on-premise variant.

Learn more: Azure Boards

Pulling data from Jira via API​

The Jira connector can now pull data directly via API. Configuring webhooks on the Jira side is no longer needed, which shortens deployment and removes the dependency on Jira administrator permissions. The pull frequency is set in the organization panel, every hour or once a day. The mode works with Jira Data Center and Jira Cloud.

Learn more: Ingestion method

---

Improvements​

Selecting a date range with a single selector​

You now select the date range in a single calendar, with preset 14, 30, and 90 day ranges. The selected range applies across all views and stays remembered after refreshing the page.

Unified pagination​

Paging through lists looks and works the same way in tables, in Workload, in Health Metrics, and in the AI Adoption panel.

Increment hiding threshold covers historical data​

After you set the threshold, Q247 also hides increments scanned earlier. The threshold compares the value shown on the chart, meaning calories calculated after excluding the specified files.

Learn more: Effect on historical data

Removing a name from the profile is visible in all views​

After a user's name is removed, the change appears immediately everywhere their data is shown, including the project list, participant tables, and chart legends.

Version 2.6.2 focuses on performance and stability. Analytical views load faster, and charts and participant selection work smoothly even in teams with thousands of people. This release also starts collecting data for team and project health metrics (Health Metrics), whose views we will make available in the next release.

Below you will find a detailed description of the most important changes.

---

Performance and Stability​

Faster Data Loading in Analytical Views​

We optimized data loading on the Overview page and in analytical views. Depending on the view, load times are now more than twice as fast, which is most noticeable in large organizations with over 1,500 projects. The values shown remain unchanged. We will extend this optimization to further dashboards in upcoming releases.

Charts and Participant Selection in Large Teams​

You can now freely choose which people from a project's team are shown on a chart. The selection is made from a dropdown that defines the chart's content, and it now works smoothly even in teams with several thousand people. The increment details window also opens faster.

Rebuilt Interface Error Handling​

We rebuilt error handling on the interface side to reduce situations where a single error disables the whole application. Instead of a blank screen, the user now gets a message and can keep working in the rest of the view. This also applies to the Overview page, which previously stopped working when AI adoption data failed to load.

Faster AI Assistant Response to the First Question​

The first question in a session used to take noticeably longer to answer than subsequent ones. Response time is back to its previous level.

---

New Features​

Team and Project Health Metrics (Health Metrics)​

We are introducing a data and calculation layer for a new group of indicators describing the health of team and project work. These indicators answer the question of whether the way code work is done creates a risk to quality and delivery pace.

We have prepared five indicators:

• the share of work done within the working hours configured for the organization, which signals a risk of team overload,
• the share of changes merged without review,
• the share of changes waiting for review longer than the accepted threshold,
• the share of changes merged so quickly that a review was not realistically possible,
• the share of effort passing through changes too large to be reliably reviewed.

We collect data on changes submitted for review from GitLab, GitHub, Bitbucket, Gerrit, and Azure DevOps, in both cloud and self-hosted versions. No code or review comment content reaches the platform, and data collection turns on automatically when a repository connection is added.

We will make views with these indicators available in the next release, but data collection starts now. You will see results immediately, together with the history from this period, without waiting for the database to fill up. Data collection requires updating the plugin to the version shipped with this release.

Automatic Scanning of New Repositories​

Once this option is enabled, the system detects new repositories it has access to every day and brings them into analysis without manual configuration. Two modes are available: adding all new repositories to the welcome project, or creating a separate project named after the repository for each one.

---

Improvements​

Statistics During Data Recalculation​

Statistical data is recalculated periodically in the background. The view now shows the previous values until the new ones are ready.

Ingesting Data from Source Systems​

An unusual participant identifier in an event batch no longer stops the rest of the users from that same batch from being created. Azure DevOps repositories whose project name contains spaces are now also handled correctly.

Other Changes​

• The project view presents Project Managers as plain text instead of chips.
• Charts show participant first and last names in the legend and in the increment details window. The detail data comes from the same source as the chart.
• Changing the interface language happens without reloading the page.
• In organization management, time zone names are translated, and the default time zone is the same across all views.
• Sorting the list in AI Adoption now covers the entire data set.
• The last scan date column in the Sources view shows the current value even after data collection is restarted.
• Form fields no longer show irrelevant browser autocomplete suggestions.

Version 2.6.1 continues the development of the workflow metrics introduced in the previous release. Statistics on project, team, and participant cards have a new look and now show the change in value compared to the previous period. We have added new metrics describing the pace of task completion, the number of tasks in progress, and the distribution of work types, available at the project and participant level. This release also includes visual improvements in several views and stability fixes.

Below you will find a detailed description of the most important changes.

---

New Features​

New Statistics Design Showing Value Change​

Statistics on the Project, Team, and Participant views have a new, unified look. Each metric card now shows the change in value compared to the previous period of the same length, so you can see at a glance whether a result is going up or down, without additional comparisons. This makes it easier to spot a trend quickly, for example whether the team's pace of work in the last month is better than the month before. The change applies to how existing metrics such as calories, increments, lead time, and cycle time are presented, not to how they are calculated.

New Pace and Work Type Metrics​

A new group of indicators has been added to the workflow metrics, visible on the project card:

• task completion pace, i.e. the number of tasks completed per week,
• the total number of tasks completed in the selected period,
• the number of tasks in progress at the end of the period, including per developer,
• the distribution of completed tasks by type, for example features and bugs (the type breakdown can be customized in the organization and project configuration).

The participant card shows the number of tasks in progress at the end of the period. All the new indicators respond to the selected date range and show the change compared to the previous period. We also clarified the messages shown when workflow metrics are not yet available for a given project, for example because no ticketing system is connected.

---

Improvements​

The Delivery Tracker chart now behaves more predictably. The legend shows the correct participant names, the averaging filter only applies to the selected people, and selected data series no longer reset after switching tabs.

Several visual issues were fixed across the application. In the AI Adoption view, bar scaling and how data is displayed in charts and labels were unified. In the Workload view, navigation to participant details and spacing between elements were fixed.

Performance and Stability​

Improved the stability of organization configuration and of processing data coming in from source systems.

Version 2.6.0 introduces workflow metrics: lead time and cycle time. These metrics show how quickly tasks move from creation to completion. They are visible on every project's card and in the project list on the Overview page. Organizations can define what marks the start and end of the work cycle, and which task types are included in the metrics. We are also introducing an organization-wide calendar of holidays and working hours. Date range selection has been unified across the application: a single, remembered selector in the top bar replaces separate filters on every page.

Below you will find a detailed description of the most important changes.

---

New Features​

Workflow Metrics: Lead Time and Cycle Time​

Lead time shows how long a task's journey takes from creation to completion. It reflects how long the business waits for a result from the moment a need is reported. Cycle time shows the pace of the work itself: the time from when a task is actually picked up to when it is completed. Both metrics are calculated from data in the organization's ticketing system. Results are given in business days as a median. The metrics are visible on every project's card and as new columns in the project list on the Overview page.

This gives the organization ongoing visibility into actual delivery time and team pace, without manual counting in spreadsheets or separate workflow-analysis tools. It also makes it easier to spot where delays are building up in the process. In Manage Organization, administrators can define what marks the start of lead time (by default, ticket creation) and cycle time (by default, the moment work is picked up), as well as which task types should be included in the metrics.

These settings can be overridden at the level of an individual project. Alongside this feature, we are also introducing an organization-wide calendar of holidays and working hours. The new metrics take it into account right away, and we will progressively switch existing statistics calculated in business days over to it in upcoming releases. Data for these metrics is collected from the moment the Enterprise Plugin is updated.

Global Date Range Selector​

Date range selection has been unified across the application. A single selector in the top bar, next to the organization switcher, replaces separate filters on every page. You can quickly pick the last 14, 30, or 90 days, or set a custom range. The selection is remembered when navigating between views and after logging back in.

---

Improvements​

Unified look and behavior across the interface: consistency fixes covering the table edit pop-up, the project manager assignment pop-up, the account edit layout for long team names, the Delivery Tracker chart when there is no data in the selected date range, and the appearance of dropdown lists in the top bar.

Performance and Stability​

Improved stability of the Overview view and statistics views under heavy load.

Version 2.5.0 introduces a key feature for tracking AI adoption in the daily work of development teams - an important capability given the dynamic changes artificial intelligence is bringing to the software development process. Organizations gain visibility into the real scale of AI-assisted tool usage in code creation, with data presented at the organization, team, project, and individual participant level. We have also clarified how documentation content volume is calculated regardless of its source, and expanded visibility of project data for selected administrators.

Below you will find a detailed description of the most important changes.

---

New Features​

Tracking AI Adoption in Development Teams' Work​

Q247 gains a new, comprehensive view showing to what extent teams are using AI-assisted tools - such as Claude Code, GitHub Copilot, Cursor, Aider, Devin, or OpenAI Codex - when writing code.

The view presents the AI adoption indicator along with its trend over time. It also shows the development effort attributed to AI-assisted code (AI calories) against the team's total effort (Coding Calories). This is complemented by token usage and the dollar cost resulting from the use of AI tools. It is also visible how well AI-assisted code holds up over time compared to code written without it.

The data is available on the organization's home page, in the Teams view, and in the detailed views of every project and team, always with the option to expand into more granular data.

Administrators can link accounts used in AI tools to Q247 users (matched automatically by email address by default, with the option for manual correction).

A commit is recognized as AI-assisted when its commit message contains a characteristic phrase - set by default for each supported tool (e.g. Co-Authored-By: Claude for Claude Code), with the option to add custom detection patterns tailored to the organization's specifics.

In the current version, the feature collects token usage and cost data from Claude - we are also ready for further integrations with other AI tools, based on customer-reported needs. The feature requires updating the Enterprise Plugin to the latest version, but does not involve any additional installation on users' computers.

---

Improvements​

• Consistent documentation content volume counting - the way documentation content volume is calculated is now unified regardless of its source.
• Broader visibility of Project Managers for organization-level admins - administrators with the Team Member role at the organization level can now see the full list of Project Managers in the organization management view.

Version 2.4.4 introduces a new Workload component - a team workload heatmap on the Project and Team views that shows the distribution of each person's development effort over time and makes it easier to spot overloads and unevenly distributed work. We have also added the ability to specify which repository branches are included in the analysis, which translates into more precise metrics. The remaining improvements increase the accuracy and consistency of analytical data - including better cherry-pick detection and immediate hiding of commits across all views - and strengthen the security of access to the system.

Below you will find a detailed description of the most important changes.

---

New Features​

Workload - Team Workload Heatmap​

A new analytical component that, on the Project and Team views - directly below the Delivery Tracker chart - shows the distribution of each person's development effort over time. Each row corresponds to one person, each column to a consecutive period, and the intensity of a cell's color reflects the level of activity. As a result, you can see at a glance who is overloaded, where work is distributed unevenly, and how the workload changes over time.

The heatmap adapts to the context: it uses the date range and metric type selected for the whole view, and the time scale automatically switches between a daily, weekly, monthly, and quarterly perspective depending on the length of the period. Hovering over a cell shows the details of that person's activity, and the built-in search and sorting (by name or activity, with active people always on top) let you quickly find the information you need. Larger teams are handled with pagination, and the footer summarizes key statistics - the number of people, business days, and the average and peak workload. The scope of visible people always matches the user's permissions.

We also took the opportunity to unify the existing activity heatmap on the Participant view - the same color scale and a richer detail preview - so that comparing workload across views is consistent.

Selecting Repository Branches Included in the Analysis (beta)​

We have made available, in beta, the ability to specify which repository branches commits are counted from - globally for all repositories and individually for selected ones. This lets you skip, for example, experimental or release branches and obtain a more accurate picture of the team's work. At this stage the feature has no user interface and is enabled at an organization's request; it also requires the latest version of the Enterprise Plugin.

---

Improvements​

• Strengthened authentication and access-control security - a set of fixes that improve the security of login, tokens, and granting permissions in the system.
• Higher accuracy and consistency of analytical data - better cherry-pick detection (only the copy of a commit is marked, not the original) and immediate, consistent hiding of commits across all analytical views.
• Participant view and login improvements - a user without elevated permissions now sees their own OTIF component, the view preserves the "Total Metrics" selection after a refresh, dropdown lists open smoothly, and password recovery for SSO-login accounts shows a clear message.
• Interface polish and technology refresh - minor consistency fixes for tables, charts, and login screens, plus an update of the user interface libraries.

Version 2.4.3 introduces OTIF Retention - a new measure of the durability of development work, showing how much of the code that was produced remains in the repository after 1, 7, 30, and 90 days. The indicator is available on the Participant, Team, and Project views and in tabular reports, giving teams and management a consistent picture of how much of the effort invested actually stays in the product. The release also expands control over the quality of analytical data - with the ability to exclude selected files from Coding Calories calculation - and adds Gitea as another repository source.

Below you will find a detailed description of the most important changes.

---

New Features​

OTIF Retention​

Q247 introduces OTIF Retention - a new measure showing how much of the code that was produced actually remains in the repository after a given amount of time. For four periods - 1, 7, 30, and 90 days (R1/R7/R30/R90) - the indicator reports the percentage of lines from a given commit that survived to that point. High retention means the work is durable and genuinely builds the product, while low retention points to temporary code that is repeatedly rewritten or quickly removed - giving teams and management a new, objective dimension for assessing contribution, alongside the sheer number of changes.

The indicator is available as a dedicated component with a date range selector on the Participant, Team, and Project views, presenting the R1/R7/R30/R90 values for the selected person, team, or project. The same values appear as columns in tabular reports - of projects (Overview, Participant), teams (Teams), and participants (Project, Team) - allowing the durability of work to be compared and sorted across the entire organization; 30-day retention is shown by default, and the remaining periods can be enabled in the table settings. Values are presented on a color scale from lowest to highest retention, so strong and weak areas are visible at a glance, and the measurement remains correct regardless of how branches are worked with (merge, squash, rebase, cherry-pick).

Retention data is calculated by the Enterprise Plugin, so the indicator begins to fill in once it is updated to the latest version. Retention is also calculated for earlier commits, so the historical picture of work durability is available immediately, with no waiting.

Excluding Selected Files from Coding Calories Calculation​

An organization administrator can now specify which files should be skipped during contribution analysis - for example automatically generated files, dependencies, or generated code that distorts the metrics. The configuration is available in the Manage Organization → Configuration panel, where the administrator defines any number of file name or path patterns and can freely add, edit, and remove them. Files matching any pattern are not counted toward Coding Calories or the line count - both in aggregates and on charts; a commit containing both excluded and other files is counted partially, while commits composed solely of excluded files disappear from statistics and analytical views. A change to the patterns takes effect immediately after the configuration is saved. The feature requires updating the Enterprise Plugin to the latest version - it is the plugin that scans the files in commits while applying the defined exclusions.

Gitea as a New Repository Source​

Gitea joins the supported repository sources - both the cloud and self-hosted versions - which the administrator adds in the Manage Organization → Sources panel, authenticating the connection with a username and an access token (Personal Access Token). Gitea repositories are scanned on the same terms as the other sources, so all metrics and analyses work for them without any difference.

History Transfer When Changing a Repository's Project​

After a repository is reassigned to a different project, its existing activity history moves along with it, preserving the rules that route data to the correct projects. As a result, reports stay complete and consistent with the configuration, without manual data cleanup.

---

Improvements​

Automatic Activation Email on Granting Access​

After a user is granted access or an account is created, the system automatically sends an activation message - with a password-setup link for new accounts, or a login link for people who already have a password. The account form shows a note that such a message will be sent, provided automatic notifications are enabled.

AI Assistant in the Interface Language​

AI Assistant responses now match the language set in the interface, so the user receives analysis in their own language without any additional configuration.

Clearer Account Status​

The account status previously labeled "Technical" is now named "Untracked" (Polish: "Pomijany"), which more clearly communicates that the activity of such an account is omitted from analysis.

Clearer Tooltips​

The content of the tooltips describing metrics and commit markers has been updated, including a new description for the cherry-pick marker, making it easier to understand how individual values are interpreted.

Consistent Dropdowns and Filters​

The appearance of dropdown lists and the way values are presented in filters have been unified, so that interacting with filters and selection fields is consistent across the entire product.

More Stable Work Item Synchronization​

Fetching related work items during repository scanning has been improved, so synchronization runs stably and without errors interrupting it.

---

Bug Fixes​

• Selected filters are once again visible in the table filtering field.
• The message of empty commits and of those created through cherry-pick and revert is no longer lost or truncated.
• Exporting tables to a CSV file now works in the Safari browser as well.
• The correct range of email addresses in the "others" tooltip on the Team view.

Version 2.4.2 of Q247 introduces SCIM integration - automatic synchronization of users and teams from identity providers (Okta, Microsoft Entra ID, Google Workspace, and others compliant with SCIM 2.0), with optional control of the ADMIN role and login access on the IdP side. This release also brings detection of cherry-pick, rebase, and revert in repository history with the ability to exclude them from metrics, and a new presentation of the "Others" group in participant tables with an option to copy the list of people. The remaining changes are a series of improvements aimed at making tables and charts, data source configuration, and login screens easier to use, as well as boosting the performance of the Participant view in large organizations.

Below you will find a detailed description of the most important changes.

---

New Features​

SCIM Provisioning - Identity Provider Integration​

Q247 now supports the SCIM 2.0 standard - accounts and teams are automatically created, updated, deactivated, and removed based on events from an identity provider (Okta, Microsoft Entra ID, Google Workspace, or any other SCIM 2.0 system). The identity provider also groups users into teams (each synchronized group appears as a team in Q247) and maintains membership in those teams, while the arrangement of teams in the organization structure (Team Tree), promoting a member to manager, and team-to-project assignments remain on the Q247 side.

The integration is enabled in Manage Organization → Configuration → SCIM Provisioning, where Q247 generates a one-time bearer token and a SCIM endpoint address to configure on the identity provider side; if the token is lost, it can be rotated.

Optionally, an administrator can designate two SCIM groups: one automatically grants its members the ADMIN role (locking the role field on the profile), the other decides which IdP-linked users are allowed to log in - the two mappings are independent of each other.

Users and teams managed by SCIM are marked with a purple "SCIM" badge; for such users the name, email, status, and SCIM team membership fields are locked, while project participation and membership in manually created teams remain editable. The configuration can additionally be narrowed with an allowed IP address list, and all SCIM operations are recorded in the change log with "SCIM" attribution.

Cherry-pick, Rebase, and Revert Detection in Repository History​

Q247 classifies commits resulting from cherry-pick, rebase, or revert and lets you optionally exclude them from activity metric statistics (Coding Calories, Increments, Activity, and others). The mechanism is enabled by the organization administrator via the "exclude cherry-pick / rebase / revert from metrics" flag at the organization level; once enabled, classified commits are marked as excluded, stop counting toward team, project, and participant statistics, and by default no longer appear on the Delivery Tracker chart.

The classification works in two ways: first, based on the commit message - the phrase cherry picked from commit in the body indicates a cherry-pick, and the phrase This reverts commit indicates a revert (with precedence if a commit matches both rules); second, based on the commit identity - if more than one commit with an identical author, author date, and identical list of changed files exists on the same remote, the chronologically first one is treated as the base, and the subsequent duplicates as rebase / cherry-pick.

Analogous logic was run retroactively across the entire base of existing commits, so historical metrics reflect the new classification once the flag is enabled. A single excluded commit can be manually restored to the statistics from the commit details on the chart - excluded entries are also visually highlighted.

New "Others" Group Visualization in Participant Tables​

In the Participants table, once a date filter is applied, the "Others" group is now split into two sub-lists: participants who made at least one increment during the selected period, and those who had no activity in that time. Next to each sub-group's header there is a button to copy the list of email addresses to the clipboard (one address per line), making it easy to quickly extract the set of active or inactive people for further communication outside Q247.

The expandable infotip for the "Others" group has also been visually unified with the Design System mockup - consistent colors, backgrounds, font, and divider.

---

Improvements​

Average by Default on the Delivery Tracker Chart - Team and Project Views​

Upon entering the project and team views, the chart shows the average number of calories and the total calories of all participants. The participant range selection dropdown on the Delivery Tracker chart (Project and Team views) changes the "Top 5 participant" option to "Top 15 participant" - selected by the largest total number of calories in the current date range.

Plugin Editing in Manage Organization​

The name of an existing plugin can now be edited - previously it was set only at creation. The form for adding a new plugin has been simplified by removing fields that were not required for configuration.

Table and Chart Readability in Analytics Views​

Minor improvements to tables and charts: a more readable column layout, filter icons that fit within the layout, improved tooltips and sorting, more precise file names on CSV export, and the elimination of brief chart flickers before the skeleton loader is displayed. The favorites widgets on the home page and favorite teams also work more reliably.

Polish Interface Version​

Completed and unified Polish-language interface translations, along with consistent punctuation in notification messages.

Data Source and Connector Configuration​

Form validation in Sources (including the GIT_MANUAL repository URL and source addresses), duplicates eliminated from the source list, a more readable multibar for bulk operations, and consistent default connector settings for new organizations. Minor layout corrections (Client Secret, the "Not working" badge, the Increment Visibility placeholder).

Login and Account Screens​

Improved validation messages during login and account activation, a more readable layout for the MFA and new-password screens, and a properly positioned GO BACK button.

Manage Organization​

In Edit Member, the account status can now be saved after a change, and an attempt to change a project name to an empty value is blocked with a message. The CSV export from the user list clearly distinguishes between Active and Aliased statuses.

Faster Participant View Loading​

The Participant view loads significantly faster in large organizations. The change covers both the participant card itself and the table of all projects.

Version 2.4.1 introduces Work Dynamics Indexes - five new developer activity indicators (Activity, Presence, Effort, Throughput, Work Rhythm) displayed in participant tables on the Project, Team, Overview, and Teams views. The definition of productive days has also been updated: they are now counted exclusively on business days. This release gives administrators the ability to disable automatic welcome email notifications, users get date synchronization between tables and charts, and everyone gains a quick channel for reporting issues without a separate login.

Below you will find a detailed description of the most important changes.

---

Work Dynamics Indexes - 5 New Developer Activity KPIs​

Participant tables on the Project, Team, Overview, and Teams views now display five new activity indicators. Activity (the average of the other four) is shown as a five-level bar chart with a percentage tooltip, and tables are sorted by this value by default.

• Presence - shows how regularly a participant was active during the selected period. Calculated as the ratio of business days with at least one increment to all business days in the range.
• Effort - measures the intensity of a participant's work. Calculated as the average number of Coding Calories per business day, normalized to a threshold of 50 kcal/day (above this value the coefficient reaches its maximum).
• Throughput - measures the number of increments per business day. Calculated separately for code and documentation, with different normalization thresholds (1 code increment or 10 documentation increments per day = 100%).
• Work Rhythm - shows the regularity of work. Calculated as 1 minus the normalized standard deviation of gaps between a participant's active days - the more regular the gaps, the higher the indicator.
• Activity - a synthetic activity indicator. The arithmetic mean of Presence, Effort, Throughput, and Work Rhythm.

---

Productive / Non-Productive Days Counted on Business Days Only​

Productive Days, Non-Productive Days, and Days Between Increments are now calculated exclusively on business days (Monday–Friday), excluding weekends from the base calculation. This eliminates the underreporting of participant metrics when date ranges include Saturdays and Sundays.

---

Settings in Manage Organization - Welcome Email Toggle​

The Settings tab in Manage Organization gains a new section where an administrator can disable the automatic sending of a welcome email to newly created users - including those created as a result of account aliasing. Emails remain enabled by default, so the behavior for existing organizations does not change.

---

Report An Issue - Submit Issues Without Logging into JIRA Service Management​

A Report An Issue button has been added to the application. It opens the JIRA Service Management portal with the user's email address pre-filled. Requests can be submitted without a separate login to the portal.

---

Default Date Range on Tables and Charts + Date Range Sync​

Tables and charts on the Project and Team views are now synchronized by default in terms of date range - changing the range in one place propagates to the other, and a notice appears on the chart when the range exceeds three months. On participant, team, and project lists, the default table range is the last two weeks.

---

Minor Improvements and Fixes​

• Unified display of user names and emails across all views. Names and email addresses shown in the application are now consistently pulled from the user's organizational profile, eliminating discrepancies previously visible for aliased accounts or accounts with a different login address.
• Filter tooltips + "Last Increment Date" column in the Users view. Filter and table-edit icons now show descriptive tooltips on hover, and the Users table in Manage Organization includes a new "Last Increment Date" column to support decisions about account status.
• Fixes: table column sorting (Polish alphabet and chip columns), first/last name editing for the Member role, a race condition causing 404 errors when switching views quickly, and correct Grade recalculation after changing the Coding/Documentation filter.

Version 2.4.0 is the biggest release in Q247's history. We're introducing Polish language support, the first version of our AI assistant, and we've completely rebuilt the organization management module and the entire permissions system. We've added the ability to assign projects to teams, move repository data between projects, and export CSV data for the entire organization for further analysis in BI tools. The release also includes many smaller UX improvements, bug fixes, and optimizations.

Below you will find a detailed description of the most important changes.

---

Multilingual Support – Polish Language​

We introduced multilingual support in the Q247 platform. As the first additional language, we're making Polish available. Users select the interface language in their profile settings.

The translation covers all key elements of the application – navigation, forms, system messages, and feature descriptions. Technical names remain in English to maintain consistency with source documentation.

---

First AI Assistant in Q247 (Beta, Available for Selected Customers)​

We're launching the first version of the AI Assistant built into the Q247 platform. The feature works in the context of a selected project and serves as a starting point for the broader AI capabilities we're developing in upcoming releases.

The AI assistant helps managers and application users in their daily work and understanding the data visible in Q247.

---

Rebuilt Organization Management​

We've thoroughly rebuilt the Manage Organization module. The new interface is visually consistent, faster to use, and better reflects the actual structure of work in our customers' organizations.

New Projects Tab (Manage Organization)​

We redesigned the organization's project list view:

• new project table,
• sorting by Project Managers and Users columns,
• a dedicated Assign Project Managers form enabling bulk assignment of PMs to multiple projects at once,
• a form for creating new projects.

New Single Project Management View​

We added a dedicated project management view with Sources and Additional Rules tabs. From this level, an administrator can:

• start, stop, and set the scanning interval for repositories (also as bulk operations),
• assign sources to the project (e.g. Jira, Confluence, GitLab),
• add, edit, and remove Additional Rules, which are used to assign commits to a project based on a pattern in the commit message field,
• rename the project (the change is immediately visible across all views).

New Sources Tab​

We introduced a separate Sources tab in Manage Organization, displaying all data sources in the organization – regardless of which project they are assigned to. From this level, bulk actions are available: starting and stopping scanning, adding new sources, and assigning sources to projects.

New Configuration Tab – Connector Management​

A new Configuration tab has appeared in Manage Organization, where administrators manage connectors to external systems (Jira, Jira & Tempo Cloud, GitLab, GitHub, Bitbucket, Azure DevOps, Gerrit). Forms for adding and editing connectors have been unified, and required fields are clearly marked.

Additionally, we moved the management of other application elements to this tab, such as SSO configuration and defining the calorie threshold above which a commit is automatically hidden.

Managing Organization Structure – Teams Tab​

In the Users and Teams tab, we added the ability to build multi-level team structures with assigning users to nodes and granting roles (Manager / Team Member) at the level of a specific team. We also improved the search functionality in the Assign Team Members and Assign Managers modals – they now support "first name+last name" phrases and display user email addresses.

---

Rebuilt Permissions System​

We redesigned the entire roles and permissions system in the Q247 platform. The new model is simpler, more predictable, and provides greater control over who has access to which data.

Simplified Organization-Level Roles​

We retired the Owner role – its place is taken by a Manager assigned to the root node (_root) in the organizational structure. Users who previously held the Owner role retain full access to business data after migration.

Three Project Roles Instead of Eight​

Instead of the previous eight project-level roles, we introduced three:

• Project Manager – full project management,
• Project Member – access to project data and metrics,
• Viewer – read-only access.

New Viewer Role​

Viewer is a new role for users who need visibility into dashboards and reports without the ability to modify project configuration or data. The ideal role for stakeholders who consume metrics but are not part of the delivery team.

Roles in the Team Structure​

Two roles are available in the team structure: Manager and Team Member. A user can hold different roles in different nodes, allowing precise modeling of actual areas of responsibility within the organization.

New Project Visibility Model – Three Access Paths​

We introduced a consistent project visibility pattern based on three paths:

1. Direct project participation (Project Manager / Member / Viewer),
2. Access through team structure – project assigned to a team to which the manager belongs,
3. Organizational access – through manager assignment in the organizational structure.

Every project created in the organization is automatically visible to users with organizational access, and the Select project dropdown shows only those projects the user actually has access to.

---

Working with Data and Projects​

Assigning Projects to Teams​

As part of the new team structure, you can assign projects to team nodes. This simplifies access management in larger organizations.

Moving Repository Data Between Projects​

We added the ability to move repositories between projects. When changing the assignment:

• all previously scanned events (commits, merge requests, etc.) are automatically reassigned to the new project,
• data in dynamic tables is updated according to the new assignment,
• participants gathered in the repository history are also migrated.

CSV Export with Organization-Wide Data​

We expanded data export capabilities – in the new Integration with BI section, an administrator can download a CSV file containing increments from a selected period for selected projects (or all projects in the organization).

Available options include:

• date range selection (From / To),
• project selection from a dropdown with search functionality and a Select All option,
• a CSV file with a timestamp in the name, correct encoding, and data in tabular format ready for analysis in Excel / Google Sheets / BI tools.

---

Other Improvements​

• Improved calorie calculation for documentation work – we fixed a bug causing incorrect calorie calculation for events where a large amount of content is added at once (e.g. extensive descriptions in Jira tickets, longer entries in Confluence). Applying the fix requires updating the batch plugin on the client side.
• Numeric value formatting – numbers in tables are displayed on a single line with a thousands separator matching the locale.
• Operation confirmations – snackbars confirming the addition/removal of discriminators and sources in the Sources and Additional Rules views.
• Bulk operations in Manage Organization – bulk actions (start/stop scanning, assigning to project, setting interval) now execute on all selected items with progress display.
• Service Desk – a button has appeared in the application with a quick redirect to Jira Service Management, allowing users to submit a problem or inquiry without leaving the platform.
• UX fixes – a series of minor fixes improving daily work with the platform (including visibility of project manager chips, adding a Select All checkbox to tables, refreshing data after profile editing, consistent tab behavior).