Configure Azure boards for legacy customer

the procedures in this section are valid only for customers onboarded before 6 june, 2024 the user must select the specific organizations or projects they wish to track using , with tracking available at two levels organization level it will track all the projects comprising this organization project level it will track that particular project the presented practice is for organizations that were onboarded before 6 june 2024 if your organization was onboarded on 6 june 2024 or after, you are subject to a new process driven by a new onboarding mechanism the configuration mechanisms that require these processes are in a transition phase driven by the fact that each tool must be individually adapted for the new mechanism, which is more efficient than the legacy mechanism both processes are supported until the transition of all supported tools from the old mechanism to the new mechanism is complete click the following link to review the procedure for the new mechanism creating an application docid\ r oxvj9o68noa0fc6j5ks organization level tracking tool engine azure devops connection select the connection name in the drop down search organization selecting here will display a list of organizations the account is part of, and if does not yet track any organization, the user can choose one and select configure to initiate tracking projects at the organization level, tracking this field should be empty project level tracking tool engine azure devops connection select the connection name in the drop down search organization this option will display a comprehensive list of organizations associated with the selected account, highlighting those not yet tracked by the user can then choose an organization and track its projects accordingly search project upon selecting this option, a list of projects within the selected organization that does not currently track will be presented the user can then select the desired project to be tracked and select configure to initiate tracking after successful configuration, the table on the configuration page will display the configured settings refer to the sample image below for a visual representation of the configuration table repository level tracking for this type of tracking, certain selections have to be made in the system, as follows account refers to the account through which the tracking will be done select workspace for bitbucket cloud by clicking here, a list will display showing all the workspaces that the account above selected is a part of select any workspace to get the list of projects and repos in it select tracking type select repository for repo level tracking search project by clicking here, a list will display with all the projects the account selected is a part of, yet still does not track it select a project whose repo is to be tracked search repository by clicking here, a list will display all the repos that are part of the selected project and are still not tracked then, select any repo that needs to be tracked and select configure if the configuration is successful, a window showing a table with the configuration details will appear the sync feature scans current data for visibility after configuring credentials periodically the intervals are set as follows the account sync interval is set to 5 minutes refresh current data the account delete interval is set to 7 minutes all deleted accounts are updated the history pulled interval is set to 180 days data history for more details, see your delivery representative release terminology in service configuration this section outlines the terminology and format used for managing releases and severity levels in service configurations it details the structure of release names, patterns for identifying releases and categorizing severity levels the content also includes examples and summary tables for quick reference release format prefix signifies the starting sequence of characters for releases, with the default value being release variable signifies the starting sequence of characters for releases, with the default value being empty by default, the release format is all starting with the release when syncall enables, or in older service configurations, the system uses the default release format the release format is applicable to identify the release names in issues and the release branches examples of the patterns identified with the given prefix and variable the system can match various release patterns using the specified prefix and variable for user story fixed release is in which the user story is done for bug fixed release is in which the bug is fixed and can be multiple since fixes can be by default, for azure boards, a fixed release is identified from the iteration path which follows just the release format found releases for bug found release is in which the bug is found, and can be multiple since bugs can be found in old releases by default, azure boards found release is identified from the tags which follows the found + release format severity terminology in service configuration the severity data from the source is mapped to the specific categories as severity1 , severity2 , severity3 , severity4 by default, severity data is identified from severity