[space] Home [title] Project Threads and Context Persistence [path] Console/Dashboards/AI Consult/Workbench dashboard/Microsoft Suite of Products/ **Workbench **project threads help you organize customer-project conversations and continue your work across Microsoft Teams and Microsoft Word. Within a thread, Workbench can use recent conversation history for follow-up questions, while selected information can be saved for longer-term reuse as a Stitch or Context Variable.  # Understand project threads  Workbench uses three related concepts to maintain project continuity:  | **Concept**  | **Description**  | **When to use it**  | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Thread  | A durable, named container for a project-focused or topic-focused conversation. A thread organizes related context, Stitches, Context Variables, actions, decisions, and insights.  | Create or open a thread when you begin or continue work for a specific customer project or workstream.  | | Stitch  | A named, reusable reference that stores the query and source path used by Workbench. When rerun, it retrieves current information based on the saved query, current permissions, and source availability.  | Save a Stitch when you want to reuse the same query or retrieve updated information later.  | | Context Variable  | A named, point-in-time value that stores selected response data, facts, summaries, milestones, decisions, opportunities, or other project insights.  | Save a Context Variable when you want to preserve the current response or a specific piece of information for future reference.  | ## How these concepts work together  - A thread can contain multiple Stitches and Context Variables.  - Stitches and Context Variables remain associated with the thread in which they were created.  - A Stitch preserves how to obtain information.  - A Context Variable preserves the information itself at the time it was saved.  - Recent conversation history helps Workbench understand follow-up questions, but it is not automatically stored as permanent thread memory.  - Only information that you explicitly save becomes durable context.  :::hint{type="info"} Workbench does not automatically save every response as long-term memory. ::: # Workbench context  Workbench uses two types of context.  ## Session conversation context  Session conversation context includes recent questions and Workbench responses in the active thread. Workbench uses this information to interpret natural follow-up questions while you are working.  For example, after Workbench provides customer news, you can ask:  Which opportunities align with that news?  Workbench uses the active thread and recent conversation to understand what “that news” refers to.  Session conversation context is working context and should not be considered permanently saved.  ## Durable thread context  Durable context consists of information that you explicitly save to the active thread as:  - A Stitch  - A Context Variable  Saved items can be listed, retrieved, updated, or deleted later  ## Project threads  A project thread provides the context boundary for your customer-project work. Before saving or managing a Stitch or Context Variable, create or open the appropriate thread.  ### Create a thread  Create a thread with a unique, human-readable name that represents the customer's project or workstream.  A thread name is required; use a name that makes the project easy to identify. Description and metadata can also be included when applicable.  Example command: Create a new thread named ACME Project.  After the thread is created, Workbench confirms the thread's name and makes it the active thread.  ### List available threads  List the threads associated with your authenticated user account when you need to locate an existing project.  ### Open or switch threads  Open an existing thread to continue working with its project context.  Workbench confirms which thread is active. New Stitches and Context Variables are saved to that active thread.  :::hint{type="success"} :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/t4dR7d8_VkMw_XdRo_Neo_lightbulb.svg" alt caption width="57" height="57"} **Tip: **Check the active thread before saving important information to help prevent content from being stored under the wrong project. ::: ### Retrieve thread details  You can retrieve the details of an existing thread by using its thread ID.  ### Delete a thread  You can permanently delete a thread by using its thread ID, provided that you have the required authorization.  Deleting a thread also deletes its related Context Variables, Stitches, and associated thread data.  ### Ask follow-up questions in context  When a thread is active, Workbench uses the recent conversation, previous responses, project context, and authorized source context to interpret follow-up questions.  Workbench uses the active thread and recent conversation to interpret the reference without requiring you to repeat the customer name, original query, or previous response.  Follow-up questions can refer to previous:  - Questions  - Responses  - Customers  - Opportunities  - Evidence  - Recommendations  If the reference is unclear, Workbench asks you to identify the response or information you mean.  # Save reusable information  You can intentionally retain valuable project information by saving it as a Stitch or Context Variable. Use the following guidance when deciding what to save:  | **If you want to…**  | **Save as…**  | | ------------------------------------------------------------------- | ------------------------------------------ | | Run the same query again later  | Stitch  | | Retrieve updated information from the same source  | Stitch  | | Preserve the query and source reference  | Stitch  | | Retain the current response data  | Context Variable  | | Preserve a point-in-time fact, summary, decision, or insight  | Context Variable  | | Reference a saved value later without rerunning the original query  | Context Variable  | ## Stitch  Save a response as a Stitch when the query and source reference are valuable for future reuse. Workbench saves the query and source reference used for the current response in the active thread and confirms the Stitch name.  A Stitch does not store a frozen copy of the response. When the Stitch is executed later, Workbench uses the saved query and source reference, subject to:  - Current user permissions  - Source availability  - Current source content  - Applicable authentication and access controls  ## Context Variable  Save a Context Variable when the response data itself is valuable as point-in-time project knowledge.  Workbench saves the current response data as a durable, named value in the active thread and confirms the Context Variable name.  Context Variables can be used to preserve information such as:  - Project milestones  - Customer preferences  - Opportunity summaries  - Decisions  - Facts  - Recommendations  - Key insights  ## Manage saved context  Context items include both Stitches and Context Variables. You can manage the context items stored in the active thread:  - List context items  - Retrieve a context item  - Update a context item  - Delete a context item  # Continue work between Teams and Word  The same project thread lifecycle and context-management capabilities are available in Workbench for Teams and Word.  For the same authorized user:  - A thread created in Teams can be opened in Word.  - A thread created in Word can be opened in Teams.  - A Context Variable saved or updated in one experience is available in the other.  - A Stitch saved or updated in one experience is available in the other.  - Saved items remain associated with their original thread.  - Current permissions and source availability continue to apply.  This continuity allows you to move between supported Workbench experiences without recreating the project thread or manually restating saved project information. [title] Console tour [path] Console/ tour is a virtual journey that introduces first-time users to the fundamental functionalities of . It is an experience designed to understand the navigation from across the entire . This tutorial provides information on the following topics: - Navigation to Services Catalog - Use of Account Switcher - Location of Widgets - Use of Services Switcher - Navigation to help and support functionalities - Introduction to CollabDrive # Accessing the tour :::hint{type="info"} The tour is not available if you are on the Service Catalog page. ::: To access the tutorial, navigate to from the Global menu on the left side of the page. 1. This action takes you to . If this is your first time accessing , the tour will automatically play. 2. You can choose to: 1. Begin the tour 2. Skip the tour 3. Not show the tour again :::hint{type="info"} To revisit the tour, click the user profile icon on the top right side of the page and select &#xNAN;** Tour**. ::: # tour The tour is a virtual journey that introduces users to the fundamental functions of . It is an experience designed to understand navigation from across .  Upon logging in to for the first time, a pop-up message appears with the tour details. Alternatively, you can find the ** Tour** option available under the **Support** section for easier access. The tour offers a personalized experience, allowing you to skip or turn off sections according to your preferences. The following options are available: - **Let’s Go:** Launches a “Getting started with ” guide, highlighting key features and navigation. - **Skip:** Redirects to the “Help & Support” section of the tour. After clicking **Done**, the pop-up will not show again. - **Don’t show again:** Prevents the pop-up from displaying on future logins.   - Close the pop-up without selecting the above options: Closing the pop-up will cause it to appear again on your next login. This tutorial provides information on the following topics: - Platform navigation  - Local navigation  - Manage dashboards  - Add and edit dashboards  - Switch workplaces  - - Help and support  ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/qsMS36t2IzeV33PeA_ym1_image.png" size="50" isUploading="false" width="809" height="615" darkWidth="809" darkHeight="615" showCaption="false"} The tour provides the same tour experience across all account types, while showing different welcome pages for ACME and non-ACME users. [title] Account set-up [path] Getting Started/ [title] Managing quotations [path] Console/Managing Console/ The Quotations page helps you track and manage service quotation requests submitted through Kyndryl Bridge. From a single location, you can review request details, monitor quotation status, and access available actions throughout the quotation lifecycle. This page provides visibility into your requests and helps you stay informed as quotations progress. # Accessing quotations From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **** → **** → **Quotations**. The Quotations page displays all quotations made by an account, along with an **Explore All Services **card that allows you to explore the . From this page, you can take various actions to manage your quotations and quotation requests. Any status updates will be reflected in . # Quotations table - **Quote ID: **Unique identifier associated with your quotation request. - **Service Name: **Name of the service that you are interested in requesting a quotation for. - **Request Date:** Date when the quote request was submitted. - **Requested by:** Email address of the user requesting the quotation. - **Status: **Status of your quotation request. - **Actions: **Ability to interact with your quotation request. Select the Action that corresponds to the status of your quotation. # Quotations status Following is the list of possible statuses for the quotations, along with the actions you can take. - **Draft: **Your quotation is in draft mode and has not been received by the Service Provider team yet. You can choose any of the following actions per your requirement: - **View Request: **When selecting this option from the quotations table list, a new page displays detailed information about your request. Alternatively, you can **Talk to an Expert **or **Cancel Request **if possible.  - **Resume Draft: **When selecting this option from the quotations table list, you are directed to the Request a quote page to continue with your quotation request. - **Delete Draft: **When selecting this option from the quotations table list, confirm that the draft will be deleted; all the selected service configurations previously saved will be lost. - **Talk to an expert: **When selecting this option from the quotations table list, you are redirected to the Request a quote page to discuss your quoted services with a Kyndryl expert. Use the pagination actions at the bottom of the page to navigate through all your quotation requests. [title] Global navigation [path] Console/Navigation/ features a global navigation bar, providing a consistent experience across the entire platform. This global navigation aids you regardless of your location. After logging in to your account, the following navigation options are available to you. | **Icon** | **Name** | **Description** | | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption} | **Main menu** | The main menu serves as a quick-access menu that allows you to jump seamlessly through the platform, providing a consistent experience across the entire platform. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/44RqGJYWOoU7wMXmDwsCF-20260601-205930.svg" alt caption} | **Favorites** | The Favorites section gets you easy access to your preferred pages. Select your favorite items by selecting the** favorite **icon from the menu items available. To remove a favorite, click the **favorite** icon again to unpin it.
Favorites are saved to your user profile and remain available across sessions for the same account. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/isiaBAbWKWfZiqWQYbN-V-20260601-204819.svg" alt caption} | **Recently Viewed** | The Recently Viewed section stores up to ten of your most recent locations. The most recent is shown at the top. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ZPN7lzZU4wj2SXHF9s6Ll-20260527-201148.svg" alt caption} | **** | The menu takes you to different dashboards available in your account, including:
* **:** A dashboard that serves as a single pane of glass, allowing you to digitally manage all IT solutions. * **Dashboards:** A categorized list of dashboards that support monitoring and operational awareness, including the AIOps IT Health Indicators Dashboard. Dashboard visibility depends on your role and permissions. You can access Operational Insights from this page, which replaces the previous Actionable Insights experience. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/k4h84BPANqew-zvOdHBHb-20260527-201200.svg" alt caption} | **Services** | The Services menu lists all services available in your account. You can see the services listed under the following categories:
* **Kyndryl Services:** Services that you subscribe to. * **Platform Services:** Kyndryl Bridge out-of-the box or ready-to-use services. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ofbr9cEvF-CkleoanoSr_-20260527-201144.svg" alt caption} | **Catalogs** | The Catalogs menu takes you to the available catalog pages, including:
* Bridge Private Catalog * * Enablement (legacy) * Enablement Catalos * Kyndryl Service Library (legacy) * Orchestration Catalog
**Note:** Some of these catalogs are only available to limited users. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/cD1NKQBsBg3kpQwrQHylN-20260527-201138.svg" alt caption} | **Administration** | The Administration menu takes you to your management pages, including:
* * Enterprise Service Management * Policy Service * Bridge Automation Management * Service Operations *
** Note:** Some of these management items are only available to limited users. | [title] User onboarding [path] Getting Started/Account set-up/ The account model is designed for enterprise use. Each account represents a customer organization and contains all the data, permissions and access rights associated with that enterprise. An enterprise can have multiple accounts, managed by its administrators. Account administrators can add users directly or allow designated users to send invitations through the [Bridge Access Management](docId\:WKY94VwKocjtRWvpooL4x) page in . Users can be associated with one or more enterprise accounts, allowing them to view and interact with data for their organization. When inviting a new user, administrators provide basic details such as an email address and assign the appropriate access group from the available list. Invitees receive an email invitation and, after accepting it, can log in as users of that specific account. New users must complete registration and set up multi-factor authentication using their corporate email address. :::hint{type="info"} After being added to the enterprise account, users must be granted access to each application they need. Application permissions are managed separately within . For more details, see [Understanding Bridge Access Management](docId\:ZrxU_G76DRxWkHiBkquF-). ::: # Accessing accounts New users can join through an invitation from their enterprise account administrator. The invitation email includes a link that starts the activation process. Once registration and authentication are complete, users can log in to with their corporate credentials and access the services associated with their account. ## New user sign up As a new enterprise account user, you are invited by your account administrator to join the account. After accepting the invitation, you can log in to and complete the registration and multi-factor authentication steps using your corporate email address. Users need a **Kyndryl ID** or must have their organization’s identity provider (IDP) federated with Kyndryl ID. This setup must be completed if the user has not previously registered with Kyndryl. :::hint{type="info"} To ensure proper activation, access directly through the **Activate \ account** link provided in your **Welcome to ** email. Accessing from any other page may prevent correct account linking. ::: 1. Open the invitation email from . 2. Select the **Accept invite** link to open . 3. Select **Sign up**. 4. Enter the following details: - Corporate email address - Password for your corporate email - Country (select from the dropdown list) 5. (Optional) Provide consent for communications: - **Email consent:** Allows Kyndryl to inform you about services and offerings via email. - **Phone consent:** Allows Kyndryl to inform you about services and offerings via phone. If selected, a phone number is required. 6. Select **Sign up**. 7. Enter your corporate email password again when prompted. 8. Check your inbox for an activation email from Kyndryl and select **Activate Kyndryl ID**. 9. You will be redirected to e to set up your preferred authentication method. To defer this step, select **Set up later**. After setup, you will be redirected to the ** home page**. ## Existing user sign-in It is required to sign in every time you access the account. 1. From the home page, select the **user **icon :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/yaI7M1rz34ekJaffwNJtd-20260601-220142.svg" alt caption width="23" height="23"} 2. Select **Log in**. 3. Enter your corporate email address and select **Next**. 4. Enter the password for your corporate email. 5. Select **Verify**. 6. Complete two-factor authentication using your preferred method. After successful authentication, you will be redirected to the &#xNAN;** home page**. [title] Console Overview [path] Console/ aims to deliver a **One Experience** platform for Kyndryl customers, providing a unified operational view that optimizes IT operations through real-time insights from multiple sources, controls, alerts and reporting. It enables you to manage business actions on requests initiated in the Services Catalog, including consultations, quotations and subscriptions, and also provides functionality for active subscriptions registered to your account. Business actions available include viewing, editing or canceling requests or generating requests to leverage specific aspects of an active subscription, depending on the Service's defined options. Overall, enables you to "see the whole picture" across services and environments without needing to switch contexts. # Key capabilities of - **Unified operational view:** Monitor insights across Kyndryl services through widgets without launching individual applications. - **Dashboard customization:** Create, customize and manage multiple dashboards tailored to your needs. - **Direct access to services:** Launch Kyndryl Services and Platform Services directly from . - **Unified navigation:** Access applications, dashboards and digital solutions through a consistent experience. - **Service management:** Manage consultations, quotations, subscriptions, and other service requests from a centralized location. dashboard customization capabilities allow you to build a personalized experience by creating multiple dashboards and populating them with widgets from Kyndryl Bridge and your subscribed services. [title] 02. Getting Started [path] / [title] 03. Console [path] / [title] Managing support tickets [path] Console/Managing Console/ The Support Tickets page helps you track and manage support requests submitted through Kyndryl Bridge. From a single location, you can monitor ticket status, communicate with support agents, review issue details, and track progress toward resolution. # Accessing support tickets From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **** → **** → **Support Tickets**. The **Support Tickets** page displays the total number of tickets created by an account, along with a [Create Request](docId\:nFbfvQtiJz6ZeSJmhg8B9) card, which allows you to create a new support ticket. :::hint{type="info"} If you are a platform administrator, the **Total Tickets** card values displayed may vary depending on the filters used in the tickets table list. Otherwise, you can see only the tickets you requested within the account. ::: # Support tickets table The Support tickets table provides a list with the following information: - **Ticket ID**: Unique identifier associated with your support ticket. - **Title**: Title of your issue. - **Impact**: Level of impact that you have assessed in your issue. - **Urgency**: Level of urgency that you have assessed in your issue. - **Status**: Status of your support ticket request. - **Service Name**: Name of the service that you are experiencing the issue with. - **Submitted by**: Email address of the user submitting the issue. - **Last Update**: Date when your ticket was last updated by a Support agent or yourself. - **Actions**: Ability to interact with your support ticket. Select the action that corresponds to the status of your ticket. # Support tickets status Following is the list of possible statuses for the support tickets, along with the actions you can take. - **New: **Your ticket has been submitted and is waiting for a Support agent to acknowledge it. You can view the ticket details. - **Open: **Your ticket has been acknowledged by a Support agent and is currently being worked on. You can view the ticket details. - **Awaiting Info: **The Support agent needs more information or clarification from you to resolve your ticket. Please reply to the agent's comments. You can view the ticket details. - **Resolved: **The Support agent has proposed a solution for your ticket. Please confirm or decline the proposed solution. You can view the ticket details. - **Closed: **Your ticket has been resolved to your satisfaction. You can view the ticket details. :::hint{type="info"} Use the pagination actions at the bottom of the page to navigate through all your support requests. To learn about the levels of priority, go to [Support framework](docId\:jJU_dDKSGMlcVNIHwkPiH). ::: # Filtering support tickets You may filter your tickets based on the following criteria: - **Status: **All Status, New, Open, Awaiting Info, Resolved, Closed. - **Submitted By: **Only Kyndryl Bridge Platform Administrators can see this filter, which displays the tickets created by all users under that Enterprise account (All from account), or only the tickets created by yourself (Me). Tickets created by ‘Me’ is the default and only value if you do not have Kyndryl Bridge Platform Administrator permissions. - **Last Update: **All dates, Last week, Last month, Last 3 months, Last 6 months, Last year. - **Search: **You may also use the search bar to find the tickets that you are looking for faster. The columns that can be searched on include Ticket ID, Title, Impact, and Urgency. # Viewing ticket details When you trigger the **View Details **action from the Support tickets** **table list, a new page is opened, which shows detailed information about your ticket. It also allows you to interact with a Support agent. # Discussion section The Discussion section allows you to interact with a support agent who will help you out with troubleshooting and fixing your issue. You can post all your comments and questions to clarify any doubts that you or the Support team may have. # Confirming or declining resolution After the Support team has assessed your issue, they will propose a resolution before closing the ticket to guarantee that you are satisfied with the solution and that the issue has been fixed to your satisfaction. This is marked with the status **Resolved**. You have the following options: - **Confirm: **Make sure that you confirm if your issue has been fixed. In this way, you will let our Support Team know that the ticket can be closed. If we do not hear from you in 3 business days, the ticket will automatically be closed, and you will no longer be able to interact with this ticket. For any unresolved issues, you will need to open a new ticket. - **Decline: **Make sure that you provide a reason why you feel your issue has not been resolved. The Support team will reopen the ticket and will troubleshoot the issue one more time to guarantee your satisfaction. [title] Kyndryl ID self-registration guide [path] Getting Started/Account set-up/ Use this guide to self-register for a Kyndryl ID if your company domain is not federated with Kyndryl ID. The guide provides the steps required to create your account and gain access. For any assistance with the registration of a Kyndryl ID or for issues with any of the instructions in this document, send an email to Kyndryl-ID\@kyndryl.com for support. # Kyndryl ID registration procedure To complete your Kyndryl membership, you must have a Kyndryl ID, which requires a two step process the following procedure: ## Initial registration 1. In a web browser window go to [https://login.kyndryl.com](https://login.kyndryl.com/app/bookmark/0oagvjud2qWNyAODi697/login). Then select Sign up. 2. Enter the form fields as described in the following table: | | | | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Email** | This is your email address; it will be the user id you will use to sign in to Kyndryl ID. | | **First name** | Your first name. | | **Last name** | Your last name. | | **Country code** | Choose country from drop down menu. | | **I allow Kyndryl to use my contact data and keep me informed of services and offerings by email.** | Check it if you allow Kyndryl to use your contact data and keep you informed of services and offerings by email. | 3. Click the Kyndryl ID Privacy Statement link, a new browser tab opens. When you are done reviewing the privacy policy, navigate back to the browser window shown below. 4. Click **Kyndryl ID Privacy Statement**. The service presents the privacy statement. 5. Read the privacy statement. 6. Click the green **Sign Up** button to submit the registration form. The service presents the **set up security methods** dialog. 7. Click **Set up** under **Email**. 8. You must **immediately** check your inbox for the email verification and activation link email. Click on the green **Activate Kyndryl ID Account** button. The activation link in the email will expire five minutes after it is activated. If it expires before you are able to verify your email and activate your Kyndryl ID, you cannot continue with self-registration. In that circumstance, you must contact Kyndryl-ID\@kyndryl.com for assistance. 9. Click **Enter a verification code instead** link. The service responds by presenting a verification code in a browser pop-up. 10. Enter the verification code from the pop-up in the browser. 11. You will then be returned to the popup shown below to complete the setup of your security methods. The service posts the Set up Security dialog\:You must continue to step 9 to set up your Password ***immediately*** to ensure proper provisioning of your Kyndryl ID; the activation link expires five minutes after activation. If you aren’t able to proceed to set up your password at after the link is activated, contact Kyndryl-ID\@kyndryl.com for assistance with the provisioning of your Kyndryl ID. 12. Click **Set up** under **Password**. The service posts the Set up Password dialog. 13. Enter your password as prompted. 14. Click **Next.** ## Set up security methods After the initial registration, the service requires the set-up of security methods such as two factor identification. Use the following procedure: 1. Click the Set up button under Okta verify. The service navigates to the Set up Okta verify dialog. :::Paragraph{indent="1"} Leave the QR code window up as you proceed to the next steps to install the Okta Verify app on your mobile device. Once installed, you will be scanning the QR code to configure your Kyndryl ID account in the Okta Verify app. ::: :::hint{type="info"} The Okta Verify App can be downloaded on any personal Apple/iOS mobile device using the Apple App Store. Okta Verify is NOT used by Kyndryl to monitor anything on your phone. It is like any other app publicly available in the Play Store. ::: 2. Click the icon labeled **Play Store** or **App Store** on your device. Your mobile device opens the store service. 3. In the search field type “**Okta Verify**”. 4. Download **Okta Verify**. 5. Complete the installation process. Your mobile device prompts you for an account type. 6. Select **Organization**. Your mobbile device posts a ready to scan dialog. 7. Click **Yes, Ready to Scan**. If you are asked whether to allow Okta Verify to use the camera on your mobile device, click **Allow**. 8. Scan the QR code displayed on your monitor in step 1. After successfully scanning the QR code, you may be asked to allow push notifications. Click ‘Allow’. It is highly recommended that you allow push notifications as it is much easier than typing a code from your phone into your workstation. You may be prompted to select **Allow** a second time. If you have iOS, you will now be prompted to enable Face ID or Touch ID, depending on which biometric option you have setup on your mobile device already. 9. Click **Done**. # Unable to scan QR code If you cannot scan the QR code, perform the following procedure: 1. Click '**Can’t Scan?'** under the QR code. The service posts a More Options dialog 2. Select **Email me a setup link** or **Text me a link**. Depending on your choice, the service prompts you for your e-mail address or phone number. 3. On your mobile device, click the **Activate Okta Verify** button in the email or link in the text. You will be redirected to your mobile browser. 4. Click **Open**’ when the “Open this page in ‘Okta Verify’?” screen appears. You will be redirected to the application Okta Verify on your mobile device. You will get a *Welcome to Okta Verify* screen confirming which account you are setting up. 5. Click **Get Started**. You can select **Allow’ for Push Notifications** (recommended) or ‘Skip’. If Face ID is available on your device, you can allow Face ID to be enabled by clicking ‘Enable’ or ‘Not Now’ to skip. You will receive verification that the account was successfully added. You may now set up any other optional security methods like Google Authenticator or Security Key or Biometric Authenticator by clicking on the “Set up” button for your desired option and following the prompts. If you do not want to set up any additional security methods right now, click on the green “Set up later” button. You are now signed into the Kyndryl ID dashboard end-user settings. Here you can see your Kyndryl ID profile settings and are able to set up additional Security Methods if desired and edit your profile preferences. # Errors ## Required fields There are multiple required fields on the Sign-up popup. If you leave any of the required fields blank and click the “Sign Up” button, a default error message appears next to the blank field: “This field cannot be left blank.” ## A user with this email already exists If you try to create an account with an email that already exists, you will get the error: “A user with this Email already exists.” [title] [path] Console/ [title] Introduction to Kyndryl Bridge [path] Getting Started/ is a cloud-native architecture that enables Develop, Build, Test, Deploy and generally manage Kyndryl Services for our customers and partner providers. The goal of the service is to provide a subscription-based digital concierge to the world of Kyndryl services. This digital approach simplifies the management and growth of customer IT estates, reduces resource costs, encourages innovation and accelerates a customer's digital transformation journey. is an open integration platform designed to help customers deploy and manage complex, heterogeneous, multi-cloud and hybrid IT estates. It combines technology consulting, delivery, and alliances expertise to allow access to default integrations, native partner collaboration, and a catalog of third-party services. Customers can easily explore and deploy new services, gain insight into improving business operations, and leverage the expertise of expert teams to help them innovate, expand and be more productive. It offers a vast catalog of services categorized by service type. Each service comes with detailed descriptions that includes benefits, configurations, and other resources so you can learn the scope of the offerings and make smart decisions regarding your subscriptions. However, if more information is needed and you need more directions about the services, you can schedule a consultation call with a representative who can guide you throughout the process. Thanks to the insights and recommendations from real-time analytics, technology leaders can grow their digital businesses, bridging estate composition, deploying new services, preventing downtime and forecasting future requirement sand costs more effectively. Work can be optimized with data and Artificial Intelligence, delivering improved outcomes and enabling a digital business with modern capabilities. # roles employs a Role-Based Access Controls (RBAC) system for enabling appropriate access for individuals assigned those roles. A role comprises a collection of permissions allowed to create an [Access Policy](docId\:Q-6FFyrLj8tBcEuGqJ3kl), it defines a set of actions and permissions that a user can perform within Bridge Core Service. You can also enable a subject ([Users](docId\:Lz55L0ZB11dit1U4NusBF)  or [Service ID](docId\:r_ctIGt9hnbzeJSm7LZrV)) to perform a specific set of permissions on a resource.  There are two different types of roles: - **Out of the Box roles **(Administration Platform Roles and Services Roles): - **Administrator**: Manages all access to . It is the role given to the first user of the platform. - **Editor**: Has limited administrative access to . - **Viewer**: Views public information and acts on their user IdP preferences. - **Operator**: Performs platform actions required to configure and manage services. - **Custom Roles**: Kyndryl Bridge allows you to combine the different actions that the out-of-the-box roles include. For additional details on the roles available and permissions required to execute specific actions in Kyndryl Bridge, visit the [Roles management](docId:7JKgccySx6iD0SK5bZwDa) page. # functions As a customer looking to grow your IT estate, you can perform the following functions of : - **Onboard users**: Understand the different [Kyndryl Bridge Accounts](docId\:gYq4GiMMed2mQvaA3EFOv). - **Set up the Enterprise account**: [Invite Users ](docId\:WKY94VwKocjtRWvpooL4x)and define the corresponding [Access Groups](docId\:QjJYLqshxQVRY3Opyj3ie).  - **Access the services catalog**: Perform different requests ([Managing consultations](docId\:paFmnpB2enJxyEjYDFtBU), [Managing quotations](docId\:Hcrn9D6C0OltIz6Jg1FAO) or [Managing subscriptions](docId:7mgKVCrIQfwEMqDUB54Et)) from Services Catalog. - **Set my services**: Grant access to the services and applications for the different resources. - **Manage requests**: Manage the status of consultations, notifications, quotations, subscriptions, and support tickets. View a complete history thanks to all dashboards and widgets available in [Console Overview](docId\:f6lnLLBczD49EpcQtzE_q). - **Manage audit services**: Review all actions executed in Kyndryl Bridge from the [Audit](docId\:maPzuBZNCw1cCBnbUBfnD) page. - **Contact Bridge Support**: Contact them to resolve any critical issues. # Common Services in Common Services are a set of curated base solutions, services and capabilities providing key added value by . They range from ordering, provisioning and delivering services to observability, telemetry and automation and come by default with your Enterprise account. These are services and applications that users can consume, including: - - - - - - - - [title] Navigation [path] Console/ [title] [path] Console/Dashboards/AI Consult/Workbench dashboard/ [title] Home [path] / :::Iframe{iframeHeight="0" code="

Kyndryl Bridge Documentation hub

"} ::: Find everything you need to integrate services, automate workflows, and scale solutions with Kyndryl Bridge. :::Iframe{iframeHeight="0" code="

New to Kyndryl Bridge?

Start here with our comprehensive getting started guide. You'll be up and running in minutes.

Get Started
"} ::: ### Popular guides Explore the most frequently used guides and tutorials. ::::LinkArray{contentSource="CUSTOM"} :::LinkArrayItem{headerType="IMAGE" headerImage="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/mmmOt10P9wRI65rzu8dR2-20260528-160610.svg"} ## Create access groups Organize users into access groups to simplify permissions and manage platform access at scale. [Learn More](docId\:HZc4qy5Gh7gwkLHfYsAyC) ::: :::LinkArrayItem{headerType="IMAGE" headerImage="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nDs9XTSjv8fMW-15MgB58-20260528-160917.svg"} ## Establish a connection Connect external systems and services to Kyndryl Bridge to enable secure integrations and data exchange. [Learn More](docId\:hR8jAv4KVMPk5N8nuq1Sf) ::: :::LinkArrayItem{headerType="IMAGE" headerImage="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ZPN7lzZU4wj2SXHF9s6Ll-20260527-201148.svg"} ## Manage dashboards Create, customize, and organize dashboards to monitor services and visualize operational insights. [Learn More](docId:2h4UjmzE4iafVZjsOV4c4) ::: :::: [title] Managing subscriptions [path] Console/Managing Console/ Use the Subscriptions page to view and manage your Kyndryl Bridge service subscriptions. You can monitor subscription status, review request details, and take actions based on the current stage of the subscription process. # Accessing subscriptions From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **** → **** → **Subscriptions**. The Subscriptions page displays the total number of subscriptions for your account, including an **Explore All Services **card, which redirects to the to explore the Kyndryl Bridge services.** ** # Subscriptions table The Subscriptions table provides the following information: - **Order ID**: Unique identifier associated with your subscription request. - **Service Name**: Name of the service that you are interested in requesting a subscription for. - **Subscription Package**: Name of the service package that you are subscribing to. - **Date**: Date when the subscription request was submitted. - **Submitted by**: Email address of the user requesting the subscription. - **Status**: Status of your subscription request. - **Actions**: Ability to interact with your subscription request. Select the action that corresponds to your subscription status. :::hint{type="info"} Check the status of your request. The subscription must be reviewed, approved, signed, and provisioned before the service can be used. Remember to use the pagination actions at the bottom of the page to navigate through all your subscription requests. ::: # Subscription status Following is the list of possible statuses for the subscriptions, along with the actions you can take. | **Status** | **Description** | **Available actions** | | --------------------------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | **Draft** | Your subscription request has not yet been submitted to the Service Provider team. | View Request, Resume Request, Delete Draft, Talk to an Expert | | **Request Submitted** | Your subscription request has been submitted and is awaiting review by the Service Provider team. | View Request, Cancel Request, Talk to an Expert | | **Generating Contract** | The Service Provider team is preparing your contract. | View Request, Talk to an Expert | | **Contract Ready for Review** | Your contract is available for review and approval. | View Request, Talk to an Expert | | **Contract Signed** | The contract has been accepted and processing can continue. | View Request, Talk to an Expert | | **Provisioning in Progress** | The Service Provider team is enabling and configuring your service. | View Request, Talk to an Expert | | **Active** | Your subscription is active and the service is ready to use. | View Request, Go to Service, Cancel Request, Talk to an Expert | | **Validating** | An existing subscription is being reviewed and validated before activation. | View Request, Talk to an Expert | | **Activating** | Your request to activate an existing service is currently being processed. | View Request, Talk to an Expert | | **Denied** | Your request to activate an existing service was not approved. | View Request, Talk to an Expert | | **Expired** | Your subscription has expired according to the contract terms. | View Request, Talk to an Expert | | **Pending Cancellation** | Your cancellation request is under review by the Service Provider team. | View Request, Retry Cancellation, Talk to an Expert | | **Canceled** | Your subscription request was canceled before the contract was signed. | View Request, Talk to an Expert | ## Action description | **Action** | **Description** | | --------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **View Request** | Opens the subscription details page, where you can review request information and available actions. | | **Resume Request** | Returns to the subscription request process so you can complete and submit a draft request. | | **Delete Draft** | Permanently removes the draft request and any saved configuration information. | | **Cancel Request** | Initiates a cancellation request that is reviewed by a Kyndryl representative. | | **Retry Cancellation** | Resubmits a cancellation request if a previous attempt was unsuccessful. | | **Go to Service** | Launches the subscribed service. Available only for supported services. | | **Talk to an Expert** | Opens a consultation request to discuss the service with a Kyndryl representative. | [title] Monitoring - KPI Trends [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - KPI Trends** page presents data visualizations that enable an understanding of current KPI such as number of nodes that have failed over a given period. In addition to data visualizations, the page provides a quick filter to enable the narrowing of data without complex queries. Parameters include the following: - **Customer Name:** Devices owned by specific customers. - **GSMA Code:** Devices associated with a specific GSMA code. - **Data Source:** Any supported data source used to track network devices and operating systems. - **Node Name:** Specify a node by name. - **Interface Name: **Specify a supported interface. - **Event Type:** Specify an event type. Each parameter allows a boolean **Include/Exclude** option. - Click **Include** to limit the result to include your selection. - Click **Exclude** to limit the result to exclude your selection. Hover over the right upper corner to present the display options icon (elipsis). The following display options for the visualization are supported: - **Settings:** Apply a custom time range or other options. - **Inspect:** Download a report. - **Maximize:** Enlarge the visualization to see more information. The control toggles to Minimize. # Data visualizations The data visualization parameters include the following: | **Visualization** | **Plot Type** | **Description** | **trics** | | ---------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Interface Trends** | Scatter Plot | Displays average interface utilization during the selected time range in daily increments. | • Timestamp
• Outbound or inbound percent utilization
• Interface traffic caption | | **Node-CPU** | Scatter Plot | Displays average daily CPU usage for each node during the selected time range. | • Timestamp
• CPU usage
• Node name | | **Node-Memory** | Scatter Plot | Displays average daily memory usage for each node during the selected time range. | • Timestamp
• Memory usage
• Node name | Refer to the following image for more details on KPI Trends ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/4m8veFI_EoJmYAL33izZJ_upload.png) [title] Assessment Result dashboard [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/ The Assessment Results dashboard in the dashboard provides a unified view of cybersecurity compliance results. It displays outcomes from the integrated assessment tool used to measure how well a client aligns with a selected cybersecurity framework. uses an assessment solution from Ostrich Cyber‑Risk, which offers patented questions and built‑in evidence-and-notes capture to generate measurable compliance results. Although Ostrich supports multiple cybersecurity frameworks, the application tracks and reports on assessments for the NIST Cybersecurity Framework (NIST CSF) 2.0. The dashboard presents these results in a clear format to help users identify compliance status and gaps. # Dashboard access Follow these steps to access the Compliance dashboard and view compliance metrics, assessment results and performance insights for your monitored environment: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → **** → **Assessment Result**. :::hint{type="info"} The Assessment Result page appears only if the account has at least one assessment tracked by ::: # Main capabilities The main capabilities of this insight provide visibility into compliance performance, control effectiveness, risk exposure, and assessment trends, helping teams monitor compliance posture and prioritize remediation activities. | **Capability** | **Description** | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Assessment Visibility** | Provides a consolidated view of assessment results and control performance across the monitored environment. | | **Compliance Monitoring** | Helps identify compliant and non-compliant areas, supporting ongoing governance and regulatory requirements. | | **Control Effectiveness Analysis** | Evaluates how effectively controls are performing and highlights opportunities for improvement. | | **Trend Analysis** | Tracks assessment outcomes over time to identify patterns, recurring issues, and progress toward compliance goals. | | **Risk-Based Prioritization** | Helps teams focus remediation efforts on the most significant control gaps and compliance risks. | | **Operational Insights** | Supports data-driven decision-making through dashboards, KPIs, and assessment metrics. | The Assessment Results dashboard displays the compliance status for each assessment retrieved from the integrated Ostrich Cyber‑Risk assessment tool. Users can view framework‑aligned controls, review sub‑category details and evaluate performance against target scores. # Selecting an assessment At the top of the dashboard, users can choose an assessment using the Assessment Name dropdown or by identifying the assessment with the latest Last Updated timestamp. Once an assessment is selected, the dashboard automatically updates to show the number of controls associated with each NIST CSF 2.0 Function: Detect, Govern, Identify, Protect, Recover and Respond. # Viewing NIST functions The function tabs allow users to switch between NIST functions. Selecting a function displays all associated categories and sub‑categories (controls) in the Ostrich tool where answers have been submitted. A search box and filter options are available to help locate specific sub‑categories. # Reviewing categories and sub‑categories Each selected function displays multiple sub‑category panels. Each panel includes: - Sub‑category name and a brief description. - Framework Mapping, showing how the sub‑category aligns to one or more cybersecurity frameworks. - Aspect Score (%): - Score (current control score) - Target (desired maturity level) - Assessment Status, automatically determined based on scoring thresholds. - Assessment Start Date. - Question Count required to calculate the sub‑category score. - Assessment Tool (Ostrich Birdseye). # Assessment status criteria Assessment status is determined by comparing the assessment score against the defined target, helping users quickly evaluate overall performance and compliance readiness. - **Fail: **Score is 0–50% of the target - **Marginal:** Score is 50–75% of the target - **Pass:** Score is ≥75% of the target [title] AIOps Extensions Framework Troubleshooting Guide [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Other resources / ## Introduction This guide is designed to help L1 and L2 Support personnel troubleshoot issues with the AIOps Extension and Dashboard problems before creating a SNOW ticket for L3 Developers. The goal is to identify and resolve issues by way of either L1 or L2 support and, failing that, enlist either Development or Platform teams as appropriate. AIOps relies on data collection extensions to optimize the health and uptime of Network resources and are therefore an integral part of workflows and planning. Kyndryl has therefore implemented incident management and ticketing systems to notify support personnel of when data collection extensions fail. Using this guide, support personnel can perform procedures specific to individual extensions and understand when to escalate the issue at hand. ### Key components of the manual 1. **Architecture Overview**: Visual diagrams explaining how Producer Extensions, Synapps Messaging, Consumer Extensions and Kibana Dashboards interact within the AKS environment. 2. **Dashboard Troubleshooting**: Detailed procedures for addressing: - Missing data issues - Stale data problems - Data inconsistencies - Complete troubleshooting flow chart for efficient issue identification 3. **Producer Extensions Troubleshooting**: - Checking pod status and logs - Addressing authentication issues - Resolving external connectivity problems - Verifying successful data transmission to Synapps 4. **Consumer Extensions Troubleshooting**: - Diagnosing message processing errors - Checking Elasticsearch connectivity - Resolving index mapping conflicts - Monitoring consumer group lag 5. **Clear Escalation Guidelines**: - Specific criteria for when to escalate to L3 Developers - When to route issues to Platform teams instead 6. **Azure Kubernetes Service Commands**: AKS-specific kubectl commands for: - Pod status monitoring - Resource usage tracking - Configuration management - Network diagnostics - Specific Elasticsearch and Synapps (Kafka) troubleshooting ## Architecture overview ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/eahQJTiolL6D9Vahh7S53_image.png) The AIOps platform uses an Extensions framework to integrate with external systems. There are two types of Extensions: 1. **Producer Extensions**: Pull data from external systems and push it to Synapps topics 2. **Consumer Extensions**: Pull data from Synapps topics and push it to Elasticsearch indices The data is then visualized through Kibana dashboards. ## Common issue categories Issues can generally be categorized as: 1. **Dashboard Issues**: Problems with data visualization in Kibana 2. **Producer Extension Issues**: Problems with collecting data from external systems 3. **Consumer Extension Issues**: Problems with processing data and storing in Elasticsearch 4. **Platform Issues**: Problems with underlying platform services (Synapps, Elasticsearch, Kubernetes, IAM, Vault, etc.) ### Dashboard-related issues Dashboard issues are often the first problems reported by users. These typically manifest as missing data, stale data, or data that does not add up correctly. ### Missing data troubleshooting flow ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/wV1sma0vMlyZFMnWvUN2-_image.png) :::hint{type="info"} **Note: **In the case of a consumer extension failure, restart the consumer extension. If the problem persists, escalate to L3. ::: **Step 1: Verify Dashboard Configuration** 1. **Check Time Range** - Ensure the dashboard is set to the correct time range - Try expanding the time range to see if data appears 2. **Check Filters** - Verify that no filters are inadvertently excluding data - Reset all filters and see if data appears 3. **Check Index Pattern** - Verify the dashboard is using the correct index pattern - Command to check available indices: `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/_cat/indices?v'` **Step 2: Check Elasticsearch Data** 1. **Check if data exists in the Elasticsearch index** `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/index-name/_search?size=1&pretty'` 2. **Check index mapping** `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/index-name/_mapping?pretty'` 3. **Check document count** `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/index-name/_count?pretty'` **Step 3: Stale Data Issues** 1. **Check the last updated timestamp in the index** `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/index-name/_search?sort=@timestamp:desc&size=1&pretty'` 2. **Verify Consumer Extension schedule**: Check the consumer extension logs for scheduled runs `kubectl logs -n extensions $(kubectl get pods -n extensions -l app=consumer-extension-name -o name | head -1) --tail=100` **Step 4: Data Consistency Issues** If data does not add up correctly: 1. **Check for duplicate data** - Look for duplicate entries in Elasticsearch - Check if the consumer extension is properly handling deduplication 2. **Check aggregation settings** - Verify that dashboard aggregations are configured correctly - Ensure the proper time field is being used for time-based aggregations ### Producer Extensions Issues **Step 1: Check Producer Extension Status** 1. **Check if the producer pods are running** `kubectl get pods -n extensions -l app=producer-extension-name` 2. **Check the producer extension logs** `kubectl logs -n extensions $(kubectl get pods -n extensions -l app=producer-extension-name -o name | head -1) --tail=100` 3. **Check pod resource usage** `kubectl top pod -n extensions $(kubectl get pods -n extensions -l app=producer-extension-name -o name | cut -d/ -f2)` **Step 2: Common Producer Extension Issues** 1. **Authentication Issues** - Look for authentication errors in logs - Verify IAM/Vault integration is working - Check if credentials need to be updated `# Check if extension can access vault` `kubectl exec -it -n extensions $(kubectl get pods -n extensions -l app=producer-extension-name -o name | head -1) -- curl -s http://vault.vault-namespace:8200/v1/health` 2. **Connection Issues** - Look for timeout or connection errors in logs - Check network connectivity to external system - Verify external system is operational 3. **Rate Limiting** - Check for rate limiting errors in logs - Verify rate limit configuration in extension 4. **Data Format Changes** - Look for parsing errors in logs - Check if external API has changed format **Step 3: Producer to environment Integration** 1. **Check if producer is successfully sending to your environment** - Look for successful message publishing logs 2. **Check environment topic status** `kubectl exec -it -n namespace $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-topics.sh --describe --topic topic-name --bootstrap-server synapps:9092` 3. **Check message count in environment topic** `kubectl exec -it -n namespace $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list synapps:9092 --topic topic-name` :::hint{type="info"} **Note:** The example commands uses the variable *namespace* as a placeholder for the environment namespace. Insert your environment namespace in place of the placeholder. ::: ## Consumer Extensions Issues **Step 1: Check Consumer Extension Status** 1. **Check if the consumer pods are running** `kubectl get pods -n extensions -l app=consumer-extension-name` 2. **Check the consumer extension logs** `kubectl logs -n extensions $(kubectl get pods -n extensions -l app=consumer-extension-name -o name | head -1) --tail=100` 3. **Check pod resource usage** `kubectl top pod -n extensions $(kubectl get pods -n extensions -l app=consumer-extension-name -o name | cut -d/ -f2)` **Step 2: Common Consumer Extension Issues** If logs have not been recently populated, restart the consumer and revalidate the logs. If necessary, repeat the restart up to three times with a delay of 15 minutes between restarts. When logs have been populated, perform the following procedure. 1. **Message Processing Errors** - Look for deserialization or processing errors in logs - Check if schema validation is failing 2. **Elasticsearch Connection Issues** - Look for Elasticsearch connection errors - Check if Elasticsearch is accessible from consumer pods `kubectl exec -it -n extensions $(kubectl get pods -n extensions -l app=consumer-extension-name -o name | head -1) -- curl -s elasticsearch.elasticsearch-namespace:9200` 3. **Index Mapping Conflicts** - Look for field mapping errors in logs - Check if new fields are causing mapping issues 4. **Consumer Group Issues** - Check consumer group status `kubectl exec -it -n synapps $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-consumer-groups.sh --describe --group consumer-group-name --bootstrap-server synapps:9092` **Step 3: Synapps to Consumer Integration** 1. **Check if consumer is successfully reading from Synapps** - Look for message consumption logs 2. **Check if messages are being processed but failing to index** - Look for Elasticsearch indexing errors 3. **Check consumer lag** `kubectl exec -it -n synapps $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-consumer-groups.sh --bootstrap-server synapps:9092 --describe --group consumer-group-name` ## When to Escalate to L3 Developers Escalate to L3 Developers **ONLY** when: 1. **Confirmed Code Bugs**: - Reproducible extension failures with clear error logs - Incorrect data transformation logic - Parsing errors due to incorrect code logic - Schema validation failures due to code issues 2. **Dashboard Development Issues**: - Dashboard visualization errors (when data exists in Elasticsearch) - Incorrect aggregations or calculations in dashboards - Missing fields in visualizations when fields exist in Elasticsearch 3. **Extension Performance Issues**: - Slow data processing not related to infrastructure - Memory leaks in extension code - High CPU usage due to inefficient algorithms :::hint{type="info"} **Important:** Before escalation, gather the following information: ::: - Detailed error logs - Reproduction steps - Time window of the issue - Specific data samples showing the issue - Screenshots of dashboard issues - All troubleshooting steps already performed ## When to Escalate to Platform Teams Escalate to Platform Teams when: 1. **Synapps Issues**: - Synapps cluster unavailability - Topic configuration issues - Message retention issues - Performance problems with Synapps 2. **Elasticsearch Issues**: - Elasticsearch cluster unavailability - Index capacity issues - Elasticsearch performance problems - Shard allocation issues 3. **AKS/Kubernetes Issues**: - Node failures - Pod scheduling issues - Network connectivity between services - Resource constraints at the cluster level 4. **IAM/Vault Issues**: - Authentication service unavailability - Token expiration issues - Secret access problems - Role permission issues **Appendix: Useful kubectl Commands** **Pod Status Commands** `# Get all pods in extensions namespace` `kubectl get pods -n extensions` `# Get detailed information about a specific pod` `kubectl describe pod [pod-name] -n extensions` `# Get logs from a specific pod` `kubectl logs [pod-name] -n extensions` `# Get logs from previous instance of a pod (if it restarted)` `kubectl logs [pod-name] -n extensions --previous` `# Watch pod status in real-time` `kubectl get pods -n extensions -w` **Resource Usage Commands** `# Get CPU and memory usage for all pods` `kubectl top pods -n extensions` `# Get CPU and memory usage for nodes` `kubectl top nodes` **Configuration Commands** `# Check ConfigMaps used by extensions` `kubectl get configmaps -n extensions` `# View a specific ConfigMap` `kubectl describe configmap [configmap-name] -n extensions` `# Check Secrets used by extensions` `kubectl get secrets -n extensions` `# Check service accounts` `kubectl get serviceaccounts -n extensions` **Network Commands** `# Check services in the extensions namespace` `kubectl get services -n extensions` `# Describe a service to see endpoints` `kubectl describe service [service-name] -n extensions` `# Test network connectivity from a pod` `kubectl exec -it [pod-name] -n extensions -- curl -v [service-url]` `# Check DNS resolution from a pod` `kubectl exec -it [pod-name] -n extensions -- nslookup [service-name]` **Troubleshooting Extensions** `# Check events related to a pod` `kubectl get events -n extensions --field-selector involvedObject.name=[pod-name]` `# Get a shell in a pod for advanced troubleshooting` `kubectl exec -it [pod-name] -n extensions -- /bin/` `# Check environment variables in a pod` `kubectl exec [pod-name] -n extensions -- env` `# files from a pod for inspection` `kubectl cp [pod-name]:/path/to/file /local/path -n extensions` **Elasticsearch Specific Commands** `# Check Elasticsearch cluster health` `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/_cluster/health?pretty'` `# List all indices` `kubectl exec -it $(kubectl get pods -n elasticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch -- curl -s 'localhost:9200/_cat/indices?v'` `# Check index settings` `kubectl exec -it $(kubectl get pods -n el curl -s 'localhost:9200/[index-name]/_settings?pretty'` **Synapps (Kafka) Specific Commands** `asticsearch -l app=elasticsearch -o name | head -1) -n elasticsearch --` `# List all topics` `kubectl exec -it -n synapps $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-topics.sh --list --bootstrap-server synapps:9092` `# Describe a topic` `kubectl exec -it -n synapps $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-topics.sh --describe --topic [topic-name] --bootstrap-server synapps:9092` `# Check consumer groups` `kubectl exec -it -n synapps $(kubectl get pods -n synapps -l app=synapps-admin -o name | head -1) -- bin/kafka-consumer-groups.sh --list --bootstrap-server synapps:9092` [title] Managed Network Services [path] Services/Kyndryl Services/Network & Edge/ [title] Monitoring - KPI Utilization [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - KPI Utilization** page provides data visualizations that help users understand KPIs associated with network devices. The page also includes a quick filter feature that enables users to narrow results without creating complex queries. ## Filter parameters The following filter parameters are available: | **Filter Parameter** | **Description** | | ------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Customer Name** | Filter devices owned by specific customers. | | **GSMA Code** | Filter devices associated with a specific GSMA code. | | **Data Source** | Filter by any supported data source used to monitor network devices and operating systems. | | **Node Name** | Filter by node name. | | **Device Type** | Filter by device type. | | **Interface Name** | Filter by a supported interface. | ### Filter Options Each parameter mentioned above supports the following boolean options: | **Option** | **Description** | | --------------------------------------- | --------------------------------------------- | | **Include** | Limit results to include the selected values. | | **Exclude** | Limit results to exclude the selected values. | ## Visualization display options Hover over the upper-right corner of a visualization to display the options menu (ellipsis icon). The following display options are supported: | **Option** | **Description** | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Settings** | Apply a custom time range or configure additional visualization options. | | **Inspect** | Download a report. | | **Maximize** | Expand the visualization to display additional information. Select the control again to restore the visualization to its original size. | # Data visualizations ### KPI summary The KPI Summary section includes the following visualizations: | **KPI Name** | **Description** | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Nodes Down** | Number of SolarWinds nodes that were down during the selected period. | | **Hardware Failure** | Number of devices reporting a critical hardware status. | | **BGP Down** | Number of devices reporting an idle state, indicating a BGP (Border Gateway Protocol) failure that prevents communication with peers. | | **Tunnel Down** | Number of tunnels that were down out of the total monitored tunnels. | | **InErrors** | Number of input errors reported on devices. | | **OutErrors** | Number of output errors reported on devices. | | **InDiscards** | Number of inbound packets discarded by devices. | | **OutDiscards** | Number of outbound packets discarded by devices. | ### CPU and memory utilization This section is classified into the following: - CPU Usage - CPU Usage Hosts - Memory Usage - Memory Usage Hosts | **Utilization Type** | **View** | **Utilization Category** | **Number of Devices (Nodes)** | **Number of Associated Records** | **Percentage of Total Devices** | **Description / Identifier** | | ------------------------------------------------- | ------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------- | | CPU Usage | Distribution | Less than 70% | Yes | Yes | Yes | CPU utilization distribution
across devices. | | CPU Usage | Distribution | 70%–85% | Yes | Yes | Yes | CPU utilization distribution
across devices. | | CPU Usage | Distribution | Greater than 85% | Yes | Yes | Yes | CPU utilization distribution
across devices. | | CPU Usage Hosts | Host-Level | N/A | No | No | No | CPU utilization per host,
identified by hostname. | | Memory Usage | Distribution | Less than 70% | Yes | Yes | Yes | Memory utilization
distribution across devices. | | Memory Usage | Distribution | 70%–85% | Yes | Yes | Yes | Memory utilization
distribution across devices. | | Memory Usage | Distribution | Greater than 85% | Yes | Yes | Yes | Memory utilization
distribution across devices. | | Memory Usage Hosts | Host-Level | N/A | No | No | No | Memory utilization per host,
identified by hostname. | | | | | | | | | ### Interface utilization The Interface utilization section includes the following: | ******Report / Table Name****** | ******Description****** | ******Metrics Included****** | ******Utilization Categories****** | | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------- | | Tx\_Interface Usage | Table showing outbound interface utilization. | Number of interfaces, Number of associated records | Less than 70%
Between 70% and 85%
Greater than 85% | | Tx\_Interface Details | Table providing outbound interface communication details. | Number of interfaces, Number of associated records | Less than 70%,
Between 70% and 85%
Greater than 85% | | SolarWinds KPIUtilization – TX Usage Interfaces | Table providing details about nodes with outbound communications monitored by SolarWinds. | Node/interface utilization details | Not specified | | SolarWinds KPIUtilization – RX Interfaces | Table providing inbound interface communication details. | Number of interfaces, Number of associated records | Less than 70%,
Between 70% and 85%
Greater than 85% | | RX Usage Interfaces | Table providing details for all nodes engaged in inbound communications. | Inbound communication/interface details | Not specified | | | | | | ### KPI utilization The KPI Utilization section includes the following visualizations: | **KPI Name** | **Description** | | --------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Top Nodes – CPU Utilization** | List of nodes ranked in descending order by CPU utilization. | | **Top Nodes – Memory Utilization** | List of nodes ranked in descending order by memory utilization. | | **Top Interfaces – TX Interface Utilization** | List of interfaces ranked in descending order by outbound communication (transmit traffic). | | **Top Interfaces – RX Interface Utilization** | List of interfaces ranked in descending order by inbound communication (receive traffic). | ### KPI status The KPI status section includes the following categories: | **KPI Name** | **Description** | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Top Nodes by Node Down | List of all nodes ranked by the number of downtime occurrences in descending order. | | Top Interfaces by Interface Down | List of all interfaces ranked by the number of downtime occurrences in descending order. | | Top Nodes by BGP Down | List of all nodes in an idle state, indicating a BGP (Border Gateway Protocol) failure, ranked by the number of idle occurrences in descending order. | | Top Nodes by Tunnel Down | List of all tunnels ranked by the number of downtime occurrences in descending order. | | SolarWinds KPI Utilization – Interface In Errors | List of all interfaces showing the average number of inbound errors. | | Interface Out Errors | List of all interfaces showing the average number of outbound errors. | | Interface In Discards | List of all interfaces showing the average number of inbound discards. | | Interface Out Discards | List of all interfaces showing the average number of outbound discards. | | CPU Usage by Hour | Scatter chart displaying node CPU usage at specific timestamps. | | Memory Usage | Scatter chart displaying node memory usage at specific timestamps. | | TX Interface Usage | Scatter chart displaying outbound interface communication activity at specific timestamps. | | RX Interface Usage | Scatter chart displaying inbound interface communication activity at specific timestamps. | ### KPI trends All charts include filters that allow users to show or hide specific data elements. For example, on a chart displaying both inbound and outbound interface discards, users can choose to display either metric independently or both together. | **Visualization / Chart Title** | **Chart Type** | **Metrics Tracked** | **Description** | | ------------------------------------------------------------ | ------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------- | | CPU & Memory Usage | Trendline | CPU Utilization, Memory Utilization | Displays overall system resource utilization trends over time. | | TX Interface & RX Interface | Trendline | Outbound Traffic (TX), Inbound Traffic (RX) | Tracks network interface communication volume and bandwidth direction over time. | | SolarWinds KPI Utilization – Interface In & Out Errors | Trendline | Inbound Errors, Outbound Errors | Monitors physical and logical interface transmission errors over time. | | SolarWinds KPI Utilization – Interface In & Out Discards | Trendline | Inbound Discards, Outbound Discards | Shows inbound and outbound packet drops across network interfaces over time. | | SolarWinds KPI Utilization – KPI Status – Node | Trendline | Node Down Occurrences | Tracks network device downtime and failure events over time. | | SolarWinds KPI Utilization – KPI Status – Interface | Trendline | Interface Down Occurrences | Displays interface status failures and connection drops over time. | | SolarWinds KPI Utilization – BGP Status | Trendline | Idle BGP Occurrences | Tracks BGP protocol failures and peer disconnect occurrences over time. | | SolarWinds KPI Utilization – Tunnel Status | Trendline | Tunnel Downtime | Monitors VPN and network tunnel outages and downtime events over time. | | | | | | Refer to the following image for more details on KPI Utilization: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/O1zTNgvtqJOV71bNey0zw_upload.png) [title] Datacenter Networking Dashboards [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Dashboards/ supports observable data in your datacenter networking implementation, enabling greater uptime and optimization through the presentation of captured performance data on three primary dashboards: - Datacenter Networking - Metrics - Datacenter Networking - Alerts - Datacenter Networking - Inventory - Datacenter Networking - Fabric Subsequent sections provide details regarding the data displayed on these dashboards. Each dashboard contains filters that enable data narrowing. ## Global filter The global filter enables you to narrow the observable data set, limiting it to only data necessary to your circumstance. The filter is located directly below header. The filter comprises two buttons: - Filter control (grounding icon): - Add filter: Add a filter element. - Apply to all\:Apply the filter to the data set. - Clear all: Clear all applied filters, restoring the defalut data set of all data. - Add filter (plus icon): Add a filter element. Use the following procedure to specify the time range for the current data set by time range and other parameters: 1. Select a time range. The default time range is **Last 7 days**. If no changes have occurred in the default or selected date range, data visualizations will not populate. Examples of such changes include new nodes, new interfaces, and events. To change the current date range, use the following procedure: 1. Click the calendar icon. The service displays the quick select dialog, presenting a range field that you can manually set and a list of preselected options. 2. From the units field dropdown menu, which defaults to **7 Days ago**, select the unit, **Days**, **Weeks**, **Months**, **Years**. Set the quantity by entering, incrementing, or decrementing the unit quantity. For example, select **Months**, then decrement **7** to **6** to change the value from **7 days ago** to **Last 6 months**. 3. Click **Update**. The service updates the data for the selected date range. :::Paragraph{indent="1"} The default time range, **7 Days ago**, applies initially to all six dashboards; adjust each as needed. ::: 2. Click the **Plus **icon. The service presents the filter editor. 3. Select a field from the **Select a field** dropdown menu. You can select from any supported field in the network device or operating system record. 4. Select an operator from **Select operator** field: - **is**: Equal to - **is not**: Not equal to - **is one of**: Some fields might have more than one value. This operator specifies a specific value in such a field. - **is not one of**: Some fields might have more than one value. This operator specifies that none of the values exist in such a field. - **exists**: Any device or operating system description that contains the specified field. - **does not exist**: Any device or operating system description that does not contain the specified field. 5. Select a value from the **Select a value** field. 6. **Optional:** Add a an additional parameter by selecting boolean **OR** or Boolean **AND**: 1. Repeat steps 2 through 4. 2. **Optional:** Repeat step 5. 7. Click **Cancel** to cancel the filter addition or **Add filter** to add the filter you constructed. You may add additional filters as required to adequately narrow your data set. You can also edit a constructed filter as a Domain Specific Language query by clicking the **Edit as Query DSL** link located at the far right of the **Add filter** editor. You can also filter by the following account attributes: - Customer Name - Source - Blueprint ID - System Label # Data visualization The Datacenter Network Dashboard helps you monitor the health, performance, and availability of your datacenter network from a single location. It provides visibility into network devices, traffic utilization, alerts, routing protocols, hardware inventory, and connectivity to support both daily operations and troubleshooting. Find the data available for visualization below: | **Area** | **Data visualization** | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Network Health & Performance** | Monitor node health, CPU, memory, disk utilization, and network quality indicators such as alignment errors, symbol errors, giants, and runts. | | **Traffic & Capacity** | Analyze uplink and downlink traffic across spine and leaf switches and identify the most heavily utilized devices and interfaces. | | **Interface Monitoring** | Review port status, interface operational state, and connectivity details across the datacenter network. | | **Alert Management** | Track alerts by severity, source, role, cause, type, and timeline to quickly identify and investigate issues. | | **Hardware Inventory** | View hardware inventory details for spine and leaf switches, including vendor, model, software versions, IP addresses, and serial numbers. | | **Network Inventory** | Monitor resource pools, capacity allocation, utilization percentages, and network resource consumption. | | **Routing & Connectivity** | Review BGP status, routing stability, flap activity, autonomous system information, and VRF details. | | **Link Aggregation** | Monitor LAG and MLAG performance, traffic utilization, link speeds, and aggregated network connections. | | **Network Segmentation** | View VLAN, VXLAN, and VNI configuration details across the datacenter fabric. | | **Link Visibility** | Examine link relationships, endpoint states, interface assignments, IP addresses, and connection speeds across the network. | [title] Drill Planner [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/Service usage/Dashboards/ The Drill Planner is designed for a specific customer to manage Disaster Recovery (DR) test results periodically (quarterly, annually, etc.). It enables users to upload data related to DR drills for multiple applications and view the results in a dedicated dashboard. It helps organizations track and analyze DR test outcomes, including metrics such as: - Number of tests completed - Tests passed or failed - Pending or overdue tests This data is used to ensure compliance and readiness for disaster recovery scenarios. # Process flow diagram The following diagram illustrates the underlying process flow: ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/H_DAib2XQx26QOJ2PAV6T_image.png" size="70" isUploading="false" width="892" height="580" darkWidth="892" darkHeight="580" showCaption="false"} # Process Follow these steps to complete the process: 1. **Download the template: **Navigate to the **Bulk Configure** screen and download the **Standard Drill Planner CSV Template**. Then, go to **Download **> **Standard Drill Planner CSV template. **This template includes all required fields for data entry. :::hint{type="info"} For more information related to the Bulk Configure screen, go to: [Bulk Configuration](https://docs.kyndryl.com/bulk-configuration). ::: 2. **Populate Data: **Fill in the template with DR test details for each application. **CSV file for uploading drill results** The following fields are mandatory to fill in the downloaded CSV file. You must ensure to populate the following information before uploading the CSV file. - **App ID: **Unique identifier for the application. - **Short Name: **Short name of the application. **Columns descriptions** See the following column descriptions: - **App ID**: Unique identifier for the application - **Short Name**: Short name of the application - **Platform**: Open System, Cloud, Mainframe - **Resiliency Tier (RT)**: Tier 1, and 2 (Application needs to be tested every year from the date of the last test), Tier 3 (Application need to be tested 2 years once) - **Category**: SST (Steady State Test), FTE (First Time Enablement), Re-Cert (Re Certification) - **Disaster Recovery Status**: Enabled / Not Enabled - **MF Dependency**: Yes / No - **Planned Start Date**: Date of DR test - **Status**: Pass / Fail 3. **Upload the CSV file: **Use the **Quarterly Drill Results Upload Template** option on the same screen to upload the populated CSV file. Click **Create > Quarterly Drill Results Upload Template.** 4. **Validation Rules: **Application ID and Short Name must be present. Blank rows will be ignored. 5. **View Results: **After a successful upload, the data will be processed and displayed in the **Drill Planner** dashboard. # Access the Dashboard To access to this dashboard, from the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → **Intelligent Recovery Services **→ **Recovery** **Dashboard** **menu** → **Dashboard **→** Drill Planner.** ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/-CjU4vsu_v_2861mUjFzx_image.png" size="40" isUploading="false" width="744" height="1022" darkWidth="744" darkHeight="1022" showCaption="false"} If you have not uploaded the completed CSV file to the **Bulk Configure** screen, the following message appears. Click **Upload drill templates** to go to the **Bulk Configure** screen. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NmrssnyObGFGDKUuaP9vw_image.png" size="40" isUploading="false" width="702" height="696" darkWidth="702" darkHeight="696" showCaption="false"} After the CSV file is uploaded, the Drill Planner dashboard displays the validated data. When users upload Q4 information, a message with a refresh link appears. This indicates that the dashboard is displaying the current year's data and is ready to show next year's data. Refreshing resets the information, recalculating pending and overdue items for all applications. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/bYvvY1n9Vmr-VvI_6QmGm_image.png) # Features The following features are available in this dashboard: - **Filters: **The Filter feature enables users to refine the dashboard view by applying specific criteria after uploading a CSV file. Users can expand or collapse filter options, select applications and states from the available choices, and apply the filter to update the displayed data. Once applied, all dashboard elements, including graphs, widgets, and the data table, dynamically adjust to reflect the selected filters, ensuring a tailored and focused data view. - **Key Metrics:** - **Total Applications**: Displays the total number of applications included in the uploaded data. - **Completed**: Shows the count of successful DR drills. - **Failed**: Indicates the number of drills that were executed but failed. - **Pending**: Represents applications that still need to be tested. This includes overdue items, failed drills, and those scheduled for the current cycle. - **Overdue**: Calculated during the year-end process. It includes drills that were supposed to be executed but were missed or failed in the previous year. - **Compliance Status**: Displays the percentage of successful vs. failed drills in a graphical format for quick compliance assessment. - **Select Year: **The Drill Planner includes a year‑based view that helps users to review drill data for both the current and previous years. For the current year, the view displays planning‑related metrics such as Pending and Overdue drills, along with the Next Year Planned information. When a past year is selected, the Drill Planner automatically switches to a historical view: Pending and Overdue metrics are hidden, the Next Year Planned column is omitted from the Application Drill Status table, and only outcome‑based metrics such as total, completed, failed, and compliant drills are shown. In addition, the metrics section heading updates to reflect the selected year, making it clear which year’s data is being viewed. Filters, table data, and downloads update dynamically based on the year selection, while the 3-year trend view remains unchanged to provide consistent long‑term insights. - **Graphs** - **Current Year View (Left)**: Shows quarterly drill results for the current year, including pass/fail counts. - **Three-Year Trend (Right)**: Consolidates data for the last three years (e.g., 2023, 2024, 2025), highlighting success and failure trends. - **Success Percentage Line**: A blue line indicates the success rate for each quarter. Hovering over a point shows detailed percentages. - **Target Indicator**: A green line indicates the target success rate for comparison. - **Download: **The Download button allows users to export the data displayed in the dashboard’s data table into an Excel file for offline viewing. The downloaded file exactly matches the table, preserving column names, order, and data integrity. When filters are applied, only the filtered data is included in the download. - **Application drill status** - **Application ID: **A unique identifier assigned to each application. - **Short Name: **A short or abbreviated name for the application. - **Tier: **Indicates the resiliency tier of the application, which determines drill frequency: - Tier 1 & Tier 2: Highest priority; drills performed annually. - Tier > 2: Lower priority; drills performed once every two years. - **Category: **Specifies the type of drill activity: - SST: Steady State Test - FTE: First Time Enablement - Re-Cert: Recertification - **DR Status: **Shows whether Disaster Recovery is enabled for the application: - Enabled or Not Enabled - **Test Quarter: **Indicates the quarter in which the drill was performed (e.g., Q1, Q2, Q3, Q4). - **Test Date: **The exact date when the drill was executed. - **Test Status: **Represents the current status of the drill: - Scheduled: Drill planned but not yet executed - Success: Drill completed successfully - Failed: Drill executed but failed - Overdue: Drill was due but not performed within the scheduled cycle - **Next Test Planned: **Displays the next scheduled drill date, calculated based on the application’s tier and previous execution date. [title] Overview [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/ is a recovery orchestration and resiliency platform that helps organizations prepare for, manage, and recover from disruptive events such as system outages, disasters, and cyber incidents. Built on , the service brings together automation, observability, and recovery management capabilities into a single experience, providing visibility into recovery readiness and supporting the restoration of critical applications and services across hybrid and multi-cloud environments. By automating recovery processes and centralizing recovery operations, helps reduce manual effort, improve operational efficiency, and accelerate recovery outcomes. The service provides real-time insights into resiliency health, recovery objectives, backup and replication status, and recovery activities, enabling organizations to make informed decisions and strengthen business continuity. With support for diverse technologies and environments, it helps organizations improve cyber resilience, reduce downtime, and maintain confidence in their ability to recover critical business operations when disruptions occur. # Key features ## Comprehensive resiliency metrics and monitoring - **RPO and RTO insights**: RPO and RTO metrics help businesses maintain optimal data recovery points and minimize recovery time for critical systems. - **Resiliency health monitoring**: Track the health of your resiliency configurations with dynamic resiliency health status to ensure systems are recovery-ready. - **Replication health and backup status**: Provides a granular view of data replication health and backup completion status, enabling proactive issue detection. - **Alerts**: Monitors the predefined resiliency matrix and raises alerts with varying levels of criticality based on deviations. ## Kibana-powered dashboards for in-depth observability - **SLO monitoring**: Service Level Objective (SLO) dashboards provide continuous insight into performance against predefined recovery goals. - **Recovery execution status**: This dashboard provides execution reports for drill and recovery workflows, ensuring transparency into recovery operations. - **Alerts observability**: A centralized alerts dashboard provides immediate visibility into potential risks and resiliency gaps. - **Cyber Recovery dashboard**: A security-focused dashboard provides visibility into cyber resilience and recovery readiness. ## Modular architecture for customizable recovery solutions It is built around four key modules, enabling tailored recovery solutions that can grow with your organization’s needs: - **Discovery and configuration**: Ensures seamless automated workload onboarding and configuration aligned with resiliency monitoring and recovery objectives. - **Insights**: Provides detailed analysis of the resiliency matrix, offering visibility into snapshot health, historical data, and trends that influence recovery effectiveness. - **Recovery orchestration**: Delivers orchestrated, automated recovery capabilities, supporting both single-workload and multi-workload recovery to streamline complex recovery operations. - **Drill orchestration**: Provides orchestrated drills along with pre-check and post-check support to ensure recovery readiness, disaster recovery compliance, and seamless recovery. # Key benefits Provides a resiliency service delivery platform designed to be robust, adaptable, and highly automated, meeting the requirements of modern business environments. The following are key highlights and benefits of: - **Unified resilience management**: Offers a single interface for managing resilience and recovery. - **Automated workload resiliency**: Simplifies workload management with automated onboarding, monitoring, and orchestration. - **Accelerated operational efficiency**: Optimizes workflows, reduces manual tasks, and enhances efficiency. - **Flexible and scalable**: The modular design suits organizations of all sizes, with adjustable modules to support evolving needs. - **Data-driven insights**: Provide comprehensive observability for proactive monitoring across the application stack. - **Application-aware orchestration**: Enhances reliability in application recovery and business continuity. - **Cost-efficient solutions with vendor integrations**: Plug-and-play integrations deliver rapid, cost-effective resiliency solutions. - **Customizable solution experience**: Offers the flexibility to customize services, adding value across the service delivery chain. With its emphasis on enhancing operational efficiency, automation, and service orchestration, the solution is set to elevate standards in resiliency automation, empowering organizations to meet evolving business and compliance requirements with confidence. [title] [path] Services/Kyndryl Services/Applications, Data & AI/ [title] Continuous Controls Monitoring & Management [path] Services/Kyndryl Services/Security & Resiliency/ [title] Network-Performance-Monitoring [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/ [title] Introduction [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/Control Dashboard/ The dashboard is a specialized interface designed to support the implementation of the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF). It focuses on the Protect function, specifically addressing the Configuration Management (CM), Technical Drilldown for CM and Maintenance (Lifecycle) categories. This dashboard enables the creation, monitoring and management of cybersecurity controls designed for these categories, providing end users with a clearer view of their organization’s security status. By complying with NIST CSF standards, the dashboard enables organizations to regularly assess and enhance protective measures across their digital systems. # Main capabilities | **Capability** | **Description** | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Risk Visibility** | Provides insight into current cybersecurity risks affecting organizational assets, operations, and users, helping teams understand and prioritize potential threats. | | **Vulnerability Monitoring** | Tracks vulnerability data across the environment, including active vulnerabilities, severity levels, and remediation status. | | **Control Effectiveness Monitoring** | Helps organizations evaluate whether security controls are operating as intended and supporting compliance objectives. | | **Trend Analysis** | Displays historical trends and patterns, allowing users to monitor changes in vulnerability levels and security posture over time. | | **Compliance Support** | Supports continuous monitoring activities that align with cybersecurity frameworks such as NIST CSF. | | **Actionable Insights** | Highlights critical issues that may require immediate investigation or remediation, helping teams focus on the highest-priority risks. | # Key widgets The dashboard includes widgets that help users evaluate risk and control performance from multiple perspectives: - **Risk Assessment: **Evaluates cybersecurity risks and provides the foundation for ongoing control monitoring and management. - **Average Vulnerabilities per Scan: **Shows the average number of vulnerabilities detected during security scans. - **Oldest Unremediated Critical Vulnerability: **Highlights critical vulnerabilities that have remained unresolved for the longest period. - **Active Vulnerabilities by Severity: **Displays unresolved vulnerabilities grouped by severity level. - **Vulnerability Discovery Over Time: **Tracks vulnerability findings across scans to help identify trends and changes in risk levels. - **Recent Scans and KEV Detection: **Summarizes the most recent scan activity and identified Known Exploited Vulnerabilities (KEVs). - **Scan Coverage Adherence: **Measures whether assets are being scanned according to defined schedules and policies. # Accessing the dashboard From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services **→ ****→ **Control Overview**. [title] Monitoring - Enhance KPI [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - Enhance KPI** page provides visualizations for monitoring network device performance, including stacked switches and SNMP nodes. It also includes quick filters to refine results without complex queries. Available filters - Customer Name - GSMA Code - Data Source - Switch Stack Name Each filter supports: - **Include:** Show only selected results. - **Exclude:** Remove selected results. ## Visualization display options - **Settings:** Configure time range and options. - **Inspect:** Download reports. - **Maximize:** Expand or minimize the visualization. ## Available visualizations | **Category** | **Visualization / Metric** | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Switch Stack Node Status** | Total Stack Switches | | | Master, Member, Standby, and Down Switches | | | Switch Stack Summary Table | | | Switch Roles Graph by Time | | **SNMP Node Status** | Total Nodes | | | Nodes Down | | | SNMP Nodes Summary Table | | | SNMP Unresponsive Warning Status Nodes | | | Unresponsive Nodes Table | | **Module Failure/Error Summary** | Failed Hardware Summary Table | | | Top 10 Hardware Devices Pie Chart | | | Hardware Category Status Bar Chart | | | Hardware Category Status Pie Chart | | **Failover Status for F5** | Total F5 Nodes | | | F5 Status Pie Chart | | | F5 VIP Status | | **HSRP/VRRP Summary** | HSRP/VRRP Status | | | Total CustomPoller Node ID | | | HSRP/VRRP Status Down | | | HSRP/VRRP Visualization | | **Volume Utilization** | Total Nodes | | | Nodes at 98% Volume Capacity | | **Volume Utilization** | **Trend (Scatter Chart):** Node capacity usage every 3 hours:
• ≥ 95%
• \< 95% and > 80%
• \< 80% | | | **Summary Table:** Node % Usage and % Capacity with filters (e.g., Device Name) | | | **Line Chart:** Trend of % Available and % Volume Used over 7-day intervals | | **Connection Count** | **F5 Connections ≥ 50:** F5 nodes with 50 or more connections | | | **F5 Connections \< 50:** F5 nodes with fewer than 50 connections | | | **F5 Connection Count:** Total F5 node connections | | | **F5 Connection Status:** F5 nodes by status | | **BIG-IP Failover Status** | **Standby:** BIG-IP nodes in standby status | | | **Unknown:** BIG-IP nodes with unknown status | | | **Sync Needs Manual:** BIG-IP nodes requiring manual synchronization | | | **Sync Failed:** BIG-IP nodes with failed synchronization | | | **Failover Status:** BIG-IP nodes in active status | | | **Sync Details:** Table of BIG-IP failover synchronization details | | | **Status:** All BIG-IP nodes by status | Refer to the following image for more details: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/FvtuPWqSQ_UZg3auKa2-g_upload.png) [title] Netowork Monitoring Extension Enablement(Zabbix) [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Other resources / # requirement As a DP and Service Delivery analyst I want to view Network Performance Monitoring Dashboards in Bridge AIOps, so that I can understand the health of my customer's network. As a customer, I want to view Network Performance Monitoring Dashboards in Bridge, so that I can understand the health of my network. **Solution**: Develop and deploy shared extension to pull network devices metrics from source Zabbix instance for multiple customers. ### Assumptions - Zabbix host tags are defined - Zabbix item keys used are a defined for lab devices | **ADO Feature** | **Description** | **Status** | | -------------------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | 2476651 | Develop Shared Zabbix Instance Extension for Performance Monitoring Dashboards | Development Complete
& prod deployment process
in progress | ## Architecture ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/8aflr68Y6TcsX50yX50PM_image.png) ### Tests performed - Onboarded devices on NPM dashboard - Devices with multiple gsma\_code are pulled from Zabbix - Pull network devices based on tag definition 'class\:network' - Extension check for Zabbix instance availability & gsma\_code - Extension polling and payload from log. ### Support - Existing L1/L2/L3 support model ### Appendix ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/2Pz7Et-OhKUsI_GGw7-3A_image.png) ## O\&A naming conventions ### Create Hosts Groups ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/5RdxHiYN6gnz3rq0veYJY_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/5YyFY-HHYh9gKbmQucuG5_image.png) ## Naming convention The naming convention is mostly optional, but recommended naming conventions are as follows: ### Host naming The Name must be unique in the Zabbix Instance, therefore there can be conflict between different accounts. It is recommended to add prefix with customer code. The recommended naming for Hosts is: \{Customer code}.\{Short hostname} **Example:** m12.eu1d63lpm1eslap1 A single agent can have multiple Host Names, this can be used to identify monitoring for susbsystems and instances. Then follow naming as: \{Customer code}.\{Short hostname}.\{Subsystem name}.\{Subsystem instance} **Examples**: m12.eu1d63lpm1eslap1.mysql.production ### Proxies and proxy groups The name of the proxy and especially proxy group should allow the Account Admin to clearly identify which proxy group (or proxy) should be used for which devices. It should usually contain: Customer Code and specific scope in form of location or type of devices, for which is the proxy group dedicated. Recommended: \{Customer code}-proxy-\{Scope} Considering that many admins may manage multiple accounts in single environment (optionally adding a number as \{ID}, as result \{Customer code}-proxy-\{ID}-\{Scope}). ### Host groups The host groups are used to assign access to user groups. The Zabbix organize groups and subgroups as “nested” groups: -        For example, the group named “/Europe/Belgium” is a subgroup of group named “/Europe”. This is usually used to grant access to group and all its subgroups. The account hosts will be assigned to a group with following naming standard ### Accounts/\{Customer code} Where \- \*\*CustomerCode\*\* - Customer tricode The following additional separation is optional: Accounts/\{Customer code}/\{Type}/\{Group}/\{Environmnet} Where \- \*\*Type\*\* - Type of Server belong to ('os', 'db', 'middleware', 'app', 'service', 'web', etc...) \- \*\*Group\*\* - Group of types ('linux', 'windows', 'mysql', 'mssql', 'was', etc...) \- \*\*Environment\*\* - Depend of customer (usual 'prod', 'dev', 'preprod', etc...) **Examples:** Accounts/hmc/os/linux/prod Customers/ib1/os/aix/dev Template Groups Template group for accounts should follow below naming standard (schema): Templates/\{Customer code} -or- Templates.\{Customer code}/ depending on your agreement with O\&AaaS. The following additional separation is optional: Templates/\{Customer code}/\{Type}/\{Group} Templates.\{Customer code}/\{Type}/\{Group} **Examples:** Templates/tbe/os/linux Templates/tbe/os/linux/modules Templates.tbe/os/aix [title] Control Library dashboard [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/Control Dashboard/ This dashboard delivers a powerful, centralized mapping view of internal controls across various regulatory frameworks. You can define a control once and seamlessly apply it across standards like NIST, ISO 27001, DORA and OSFI. With a comprehensive single view, you gain a clear understanding of how controls align with requirements and supporting evidence. This tool empowers you to effectively track compliance, pinpoint gaps and maintain audit readiness with increased efficiency. This integration enhances transparency, minimizes duplication and streamlines compliance management across various regulatory standards, facilitating more effective governance and decision-making. It offers role-based views for control owners, designers and compliance teams, complete with KPI dashboards. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/OXuTw_n92LZCTIqA6hwwd_image.png" size="70" isUploading="false" width="1099" height="855" darkWidth="1099" darkHeight="855" showCaption="false"} The centralized UCF control library features versioned templates and includes visual status indicators for control support, with green indicating "supported" and grey indicating "unsupported." It also offers dashboards for framework coverage, readiness scores and gap analysis, along with dynamic filtering based on user subscriptions. # Compliance frameworks Compliance Frameworks defines the compliance standards and regulatory frameworks available within the platform, enabling administrators to review and manage compliance requirements relevant to their organization. The following are the compliance framework available in this page: - ISO/IEC 27001:2022 - DORA - NIS2 - NIST CSF 2.0 To have a complete overview of all available information, select the **All** tab. This view displays all widgets across compliance frameworks, including the following key details: - **Framework**: Informing which are selected. - **Last Assessment:** Showing the last assessment date. - **Target Date**: Showing the target date. - **Status**: Showing if it is active. # Dashboard graphs Dashboard Graphs provides visual representations of compliance and assessment data, enabling administrators to monitor trends, track progress and gain insights through interactive charts and metrics. The dashboard offers different graphs that shows in detail the capacity by: - **Total Supported Controls**: Users can view a doughnut graph showing monitored, customed and not supported controls and how many controls are supported. - **Overall Readiness Status**: Users can view a vertical bar chart that shows the number of supported controls by regulation framework. - **Control Distribution Across Regulations**: Users can view a categorical heatmap that compares patterns and coverage across regulations and control categories. - **Control Support Trend (Last 6 Months)**: Users can view an area chart with a trend of the control supported for the past six months. - **Framework-wise Control Mapping**: Users can view a bar chart comparing control counts by function, also called domain in other frameworks, while showing the composition of each function by support status. - **Data Source**: Users can view a bar chart showing control counts by data source. # Control details Control Details provides detailed information about a selected Unified Compliance Framework (UCF) control, including its metadata, mapped frameworks, associated evidence and filtering options to help you locate and review specific controls efficiently. The information will be displayed as follows: - **UCF Summary**: Unified Compliance Framework (UCF) shows the title, and a brief description of the UCF along with its ID, Source and Status. - **The Status can be one of the following**: Monitored (Auto), Monitored (Manual), Custom or Not Supported. - **Linked Frameworks**: A table of cybersecurity frameworks mapped to the UCF control and corresponding framework control IDs. - **Evidence Summary**: Showing a linked authority document, last refreshed date and validity expired date. You can filter by using the following options: - **Search**: Use a simple search by typing. - **All Sources**: By selecting from the drop-down menu. - **Monitored**: Check the box if you wish to see monitored controls. - **Not Support**: Check the box if you wish to see not supported controls. - **Custom**: Check the box if you wish to see customed controls. [title] Onboard an account [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/ uses AIOPS platform services like Automation Service, and CACF to provide Orchestration and Monitoring for DR and CIR Solutions. The following instructions guide you through the steps to gain access, and enable the account. # Prerequisites 1. Account should be onboarded to - Owner Account DPE. 1. To request the Onboarding of accounts in , accounts must be previously deployed in , to make this request follow [Account Onboarding to Integrated AIOps](https://kyndryl.sharepoint.com/sites/IntegratedAIOps/SitePages/Onboarding.aspx?OR=Teams-HL\&CT=1717518531925\&clickparams=eyJBcHBOYW1lIjoiVGVhbXMtRGVza3RvcCIsIkFwcFZlcnNpb24iOiI0OS8yNDA1MDMwNzYxNCIsIkhhc0ZlZGVyYXRlZFVzZXIiOmZhbHNlfQ%3D%3D#new-onboarding-process) steps. 2. For **Strategic Markets** clients, fill out this [Onboard Form](https://kyndryl.sharepoint.com/sites/Strategic-Markets-Innovate/SitePages/Onboard-Form.aspx) to start with the necessary processes. 2. Account should be onboarded to [Account Onboarding to CACF](https://kyndryl.sharepoint.com/sites/CACF/SitePages/CACF%20Delivery/Account%20Onboarding.aspx) - Owner Account team. 3. Onboarding account to [Automation Service](https://kyndryl.sharepoint.com/sites/CTO-Automation/SitePages/Automation-Service-Enablement.aspx#step-1.3-request-the-profile-via-arms-https-bat.bats.kyndryl.net-arms2-user-accessassignments%20%20https%3a//kyndryl.sharepoint.com/sites/CTO-Automation/SitePages/Automation-Service-Enablement.aspx%23step-2-setting-up-the-execution-platform) - Owner Account team.  # Onboard an account To onboard an account, follow the steps below: 1. Enable Resiliency Catalogue - Owner- Account DPE. - To enable or subscribe to an account, the user must have **account-admin** privileges for that account (Organizational Unit). 2. Log in to the delivery.kyndryl.net 3. From the main menu, click **Administration** and go to **Enablement**. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/j0emPC-n2021Vx5TKP6xm_screenshot-2026-07-08-at-85801-am.png) 4. In the **Section** dropdown, select** Intelligent Recovery.** ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/v-d36sFJsaxBRtCMbRc4H_image.png" size="95" isUploading="false" width="948" height="366" darkWidth="948" darkHeight="366" showCaption="false"} 5. Find** Incident Recovery **in the services list and click **Manage.** ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/e5Cte6agDK3IrX32GHlqO_image.png) 6. On the next page, click **Subscribe** to enable the service. 7. Determine your [Access Profile ](https://app.archbee.com/docs/9byBUTcg0npJ8Y72MW4ZY/0A_ZR6GNlnKsUvb5eglPi)- Approval - Account DPE. 8. Request the profile, Individual via **ARMS**. 9. Access . ## Owner - Delivery - Data collection for onboarding customer workloads onto . - Inventory and runbooks. - Exercise to determine the out of box solutions and customize the blueprint and solution if required. - Develop a solution guide. - Implement customization if required. # Configuring Tower for operations ### Owner – Delivery and Account TAA 1. Add Resiliency specific variables to Tower: In the tower setting, update the following: - SFS\_UPLOAD\_URL  will be in the Job Settings - sfs\_url\_folder will be taken from the inventory ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/ib147cHycmtsH7a6DIWpD_image.png" size="80" isUploading="false" width="960" height="126" darkWidth="960" darkHeight="126" showCaption="false"} ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/JMjUp7dMIKpCUT6xIxfXX_image.png" size="60" isUploading="false" width="877" height="642" darkWidth="877" darkHeight="642" showCaption="false"} 2. Add Hosts with define credential type. The details are as follows: - **Credential Type \*: **Red Hat Ansible Automation Platform - **Red Hat Ansible Automation Platform:** URL - **Username**: User ID (This field is optional) - **Password**: Password (This field is optional) - **Auth Token:** Token ID ((This field is mandatory) - **Organization**: Current Organization Mapped to the Organization of the Client - Name of the Credentials should be **\\_cred\_tower** Create Project and select the right Solution(blueprint)- [Setup and Configuration](https://app.archbee.com/docs/9byBUTcg0npJ8Y72MW4ZY/JZfMm9EZPN1ZcolA5cX11). :::hint{type="info"} Steady State Operations - The user must have **Incident Recovery Viewer** role privilege. ::: ## (Optional) Netcool extension for If the customers want to use the Netcool service (customer’s own service or Kyndryl’s Netcool service) for a consolidated view of the alerts, refer to the topic for the steps to deploy the Netcool extension of . ## (Optional) Workflow approval configuration user guide The workflow approval configuration in allows users to define approval requirements for workflows using the Bridge policy service. - Approval is configured by solution (blueprint) and operation type. - Supports single-level and dual-level approval. Policy service evaluates approval rules during workflow execution. ### Prerequisites Ensure that the following prerequisites are completed before the configuration: - Policy service enabled. - GitHub repository for policy bundles available. - GitHub access token with read access. ### High-level flow User the following steps to configure workflow approval: 1. **Create new GitHub repository: ** - Create a new repository. Refer this README to create a Github Repo for policies: *https\://github.com/kyndryl-cto/bdg-gps-res-kirs-workflow-approval-policy-template/blob/main/README.md* - Follow the policy bundle folder structure (Rego + data.json). Use sample template repository: *https\://github.com/kyndryl-cto/bdg-gps-res-kirs-workflow-approval-policy-template* ### Create GitHub connection To create a GitHub connection, see the following steps: 1. Navigate to **Bridge** → **Connections Management.** 2. Add **GitHub Content Connection**. 3. Provide **repository URL, username, token, branch.** ### Create policy bundle - *https\://kyndryl.sharepoint.com/sites/Policy-and-Automation/SitePages/Policy.aspx#creating-policy-bundles* - *https\://kyndryl.sharepoint.com/sites/Policy-and-Automation/SitePages/POA-Onboarding-and-Enablement.aspx#manage-policy-bundles* 1. Navigate to **Manage & Administer** → **Policy Management**. 2. Click **Create Bundle**. 3. Provide **bundle name** as approval policy. 4. Select GitHub connection and repository details. ### Publish and activate policy bundle *https\://kyndryl.sharepoint.com/sites/Policy-and-Automation/SitePages/POA-Onboarding-and-Enablement.aspx#publish-policy-bundle* 1. Build the bundle. 2. Publish the bundle. 3. Activate the account. 4. Only Active bundles are used during workflow execution. # Subscribing to dashboards The following dashboards are available for subscription for : - SLO Dashboard - Cyber Recovery Dashboard - Automation Execution Dashboard - Observability Dashboard - Audit and Traceability Dashboard ## Prerequisites Before you subscribe to the dashboards of , you need to have approved access **Insights-service-administrator** role in ARMS. 1. Click **Enablement**. 2. In the search field of the **Common** **Catalog** screen, type the name of the dashboard. 3. Click **Manage**. 4. Click **Subscribe**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/XT287PdI2TuKNyJOu2Lj9_image.png" size="80" isUploading="false" width="1431" height="538" darkWidth="1431" darkHeight="538" showCaption="false"} [title] Monitoring - Home [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - Home** page presents data visualizations that enable an understanding of network device and KPI status. It is the default page provided by the service when you navigate to the Network Performance Monitoring Dashboard. ## Global filters In addition to data visualizations, the page provides a global filter to enable the narrowing of data without complex queries. Parameters include the following: | **Filter Parameter** | **Description** | | ------------------------------------------------- | ------------------------------------------------------------------------------ | | **Customer Name** | Devices owned by a specific customer. | | **GSMA Code** | Devices associated with a specific GSMA code. | | **Data Source** | Any supported data source used to track network devices and operating systems. | | **Node Name** | Specify a node by name. | | **Interface Name** | Specify a supported interface. | | **Event Type** | Specify a supported interface. | ### Include / Exclude Filtering Options Each filter parameter supports the following Boolean options: | **Option** | **Function** | | --------------------------------------- | ------------------------------------------------------------------------- | | **Include** | Displays only records that match the selected filter value(s). | | **Exclude** | Removes records that match the selected filter value(s) from the results. | ### Visualization Display Options Hover over the right upper corner to to present the display options icon (elipsis). The following display options for the visualization are supported: | **Display Option** | **Description** | | ----------------------------------------------- | ----------------------------------------------------------------------------------- | | **Settings** | Apply a custom time range or other options. | | **Inspect** | View detailed data behind the visualization and download a report. | | **Maximize / Minimize** | Enlarge the visualization to see more information. The control toggles to Minimize. | # Data visualization The page presents the following data visualizations: ### Device status and history | **Metric** | **Description** | | --------------------------------------- | --------------------------------------------------------------------------------------------- | | **Nodes** | The number of devices connected to SolarWinds. | | **Interfaces** | The number of interfaces monitored by SolarWinds. | | **Nodes Up** | The number of SolarWinds nodes that were up during the selected time range. | | **Nodes Down** | The number of SolarWinds nodes that were down during the selected time range. | | **Nodes Critical** | The number of SolarWinds nodes that were in a Critical status during the selected time range. | | **Nodes Warning** | The number of SolarWinds nodes that were in a Warning status during the selected time range. | | **Nodes Summary** | A tabular list of SolarWinds nodes, including details and the current status of each node. | | **CPU > 95%** | The number of devices that exceeded 95% CPU utilization during the selected time range. | | **CPU Idle** | The number of devices with idle CPU during the selected time range. | | **Memory > 95%** | The number of devices that exceeded 95% memory utilization during the selected time range. | | **Memory Idle** | The number of devices with idle memory during the selected time range. | | **Vendor Distribution** | A donut chart showing the top five device vendors on the network by device count. | | | | ### Component status | **Metric / Visualization** | **Description** | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Event Counts** | The total number of unique events that occurred during the selected time range. | | **Top 10 Contributing Events** | A bar chart showing the top 10 event types by event count during the selected time range. | | **Top 10 Contributing Nodes** | A bar chart showing the top 10 nodes that generated the highest number of events during the selected time range. | | **Nodes Contributing to Events** | The number of nodes generating events. | | **Interfaces Contributing to Events** | The number of interfaces generating events. | ### KPI utilization status | **Metric / Visualization** | **Description** | **Categories / Details** | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | **Hardware Failure** | The number of devices with a critical hardware status. | N/A | | **RX Interface Usage** | A bar chart showing the number of interfaces by Rx utilization percentage. | Less than 70%, Between 70% and 85%, Greater than 85% | | **CPU Usage** | A bar chart showing the number of devices by CPU utilization percentage. | Less than 70%, Between 70% and 85%, Greater than 85% | | **Nodes Down** | The number of nodes that have experienced a node-down event. | N/A | | **BGP Down** | The number of devices reporting an idle BGP (Border Gateway Protocol) state, indicating a failure to communicate with peers. | N/A | | **TX Interfaces Usage** | A bar chart showing the number of interfaces by Tx utilization percentage. | Less than 70%, Between 70% and 85%, Greater than 85% | | **Memory Usage** | A bar chart showing the number of devices by memory utilization percentage. | Less than 70%, Between 70% and 85%, Greater than 85% | | **Tunnel Down** | Of the 121 tunnels, the number that were down during the selected time range. | N/A | | **Hardware Summary** | A tabular summary of network devices, including identifying details and current status. | N/A | Refer to the image below: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/q3uO8M9mC-nKixVm84u4v_upload.png) [title] Monitoring - Reports [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The Reports Dashboard transforms that information into meaningful insights, allowing you to move beyond reactive monitoring and gain a broader understanding of how your services are performing over time. By bringing reporting capabilities into a single experience, the dashboard helps you quickly identify opportunities for optimization, improve visibility, and make more confident decisions. Use the Reports Dashboard to: - Access operational and performance reports from a single location. - Review historical and current network data to identify trends and patterns. - Monitor key indicators that support service health, availability, and operational efficiency. - Generate insights that help drive informed decisions, improve service quality, and support business outcomes. - Share report findings with stakeholders to support planning, governance, and service reviews. # The dashboard also shows information about the latest data load and processing status, along with navigation links to related dashboards. You can choose from the available filters such as Customer Name, GSMA Code, Node Name, Device Type, and Interface Name, based on your requirements. ## Features The system provides comprehensive reporting capabilities for monitoring performance and availability metrics. The following reports are available: - **CPU & Memory Utilization** – Displays processor and memory usage trends over the selected period. - **Node Availability** – Indicates the operational status and uptime of monitored nodes. - **Interface Utilization** – Shows traffic and utilization statistics for network interfaces. - **Disk Utilization** – Reports storage usage and capacity trends for disks. :::hint{type="info"} **Note:** All reports support time‑based filtering and can be downloaded for offline review or further analysis. ::: Refer to the following image for more details on Report Dashboard: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/eje50nEfUToNtQWyHsgSN_upload.png) # Access and download of Network Performance Reports 1. Navigate to . 2. Sign in using your authorized credentials. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/luoPwt1w3gnU0GLvV5j7a_image.png" size="80" isUploading="false" width="1154" height="448" darkWidth="1154" darkHeight="448" showCaption="false"} 3. From the main menu, select **Services**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/oGKk3GmX4nprCv4pYkkiv_image.png" size="80" isUploading="false" width="1163" height="502" darkWidth="1163" darkHeight="502" showCaption="false"} 4. Select. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/UR9wMF_Jb5BTOzP0VJuYR_image.png" size="80" isUploading="false" width="1027" height="445" darkWidth="1027" darkHeight="445" showCaption="false"} 5. In the left navigation pane, select **Network Performance Dashboard**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/VP_MTfpZ-XXO6_bqzBScD_image.png" size="80" isUploading="false" width="1046" height="555" darkWidth="1046" darkHeight="555" showCaption="false"} 6. Select **Reports**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/LsEnpfaHSV9v1dOntp2H-_image.png" size="80" isUploading="false" width="1047" height="532" darkWidth="1047" darkHeight="532" showCaption="false"} 7. Choose the required date range. 8. Select the report that you want to generate. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/CHgb0ENNtE4Cj4nsNzj6S_image.png" size="80" isUploading="false" width="1043" height="433" darkWidth="1043" darkHeight="433" showCaption="false"} 9. After the report is generated, select **Download**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/plqkqf-PyWiepVOh18OPf_image.png" size="80" isUploading="false" width="1030" height="449" darkWidth="1030" darkHeight="449" showCaption="false"} 10. Save the report to your local device. 11. Repeat these steps for each report that you want to download. # Troubleshooting | **Issue** | **Resolution** | | -------------------------------------- | ---------------------------------------------------------------------------------- | | is not visible in Bridge | Verify that the KMNS Service Catalog subscription is active. | | Unable to access reports | Confirm that your Managed Network bundle access has been granted. | | Access request remains pending | Contact the designated DPE for approval status. | | Download option is unavailable | Verify that the report has been generated and that a valid date range is selected. | [title] Network Extension Enablement Overview [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Other resources / # Introduction Integrated AIOps supports services that extend the base function of the I-AIOps service in the form of an extension that enables extended services. This expansion capability promotes a more holistic view of and influence on your IT estate than would be possible with I-AIOps alone. This enablement framework positions I-AIOps as a centralized service that integrates with other existing services that do a related set of things well. It increases the capability of the base service without significantly increasing the service footprint or complexity. Extension Service is an Integration Framework and part of the Integrated AIOps Kyndryl Delivery Platform also known as . An Extension is anything that extends the function of the platform. The Extension Service provides a modular self-service marketplace where any integration base code or software can be hosted on the platform. Each extension is essentially a template that describes some finite integration method. More information on extension Service can be found at the following link: [Extensions](docId\:E74ldMGZ3vqCMWBFQhAL-) It is important to understand there are two types of extensions: - Dedicated - Shared Dedicated extensions are those activated by an account for integration with dedicated tools or data sources specific to that account. These extensions are expected to be managed and supported by the account. Education for skilling up the account resource can be found at the following link: [Kyndryl Bridge Extension Developer Community](https://engage.cloud.microsoft/main/org/kyndryl.com/groups/eyJfdHlwZSI6Ikdyb3VwIiwiaWQiOiIxNDI4OTQwMzkwNDAifQ/all) Shared extensions are those activated at the dataplane level on behalf of the region for integration with common shared tools or data sources. Kyndryl ServiceNow is an example of a shared extension. In shared extensions, individual account do not run the extension; the regional dataplane runs the extension. # Supported extensions The extension framework, called Extension Service, has been added as a catalog to which you can navigate from the I-AIOps home page, through the Enablement menu. The catalog lists all supported extensions in the form of interactive tiles each of which provides details and allows users with the correct roles to add and configure the extensions for the I-AIOps account that you are using. # Enabling specific extensions To enable an extension, navigate to the Enablement page: 1.       In I-AIOps, click the hamburger icon to display a dropdown navigation menu. 2.       Click **Enablement**. The service navigates to the Common Catalog. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/aSJwP3I0FHeYtPrWRgGxx_image.png) The catalog presents all supported extensions as well as other AIOPS common catalog items. To assist you with narrowing the number of displayed extensions, the catalog provides a search field, three multiselect filter fields, and an array of state filter fields. The search field enables you to search for the extension by name, the filter fields provide logical groupings of extensions such as **Network**, and the state filters display all the extensions for a given set of states such as **Configured**. ## Filter fields The following are the filter fields: - **Section:** Select the type of extension, such as **Action**, **Automation**, and **Insights** and those supported by base services such as AIOps. - **Categories:** Select the class of extension, such as **Application Management**, **Automation**, **Event Management**. - **Tags:** Select a tag from a dropdown menu to see only extensions that have been identified with a specific tag. - For Network & Edge extensions, select **Network** from the **Tags** dropdown menu. ## State filters The following are the state filters: - **Certified:** Extension that have been validated (security, function, and other criteria). - **Community:** Extensions that are associated with a specific IT Community such as Security or Network. - **Private:** Extensions that are private to the account of the extension creator. - **Configured:** Extensions that have been configured after creation. Extensions instances can exist without being configured. - **Not Configured:** Extension instances that are not yet configured. - **In Progress:** Extension instances that have been created and are still being provisioned. - **Exposed:** Catalog items that are exposed to external clients. # Extension Roles I-AIOps extensions support the following actions necessary to maintain them and make them operational: - Deploy - Configure - Start - Stop - View - Update (when catalog item receives update, extension also present an option to update) ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/D-FcQ5xB27ybcnl95x9pp_image.png) The following roles are required to perform these actions - **extension-editor:** Deploy, Configure, Start, and Stop - **extension-editor-catalog:** Deploy, Configure, Start, and Stop - **extension-operator group access:** View, Start, and Stop - **extension-viewer:** View-only Follow the regular instructions to request access through ARMS, selecting the appropriate role within the extension service as shown: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/9juZCfZDvPRu1nol60wz7_image.png) More detailed instructions can be found at the following link: # Extension configuration Before your extension can become operational, you must configure the extension. The extension details are provided in GitHub, which contains a readme file and a configuration script (yaml). Use the following procedure to find extension details in GitHub: 1. Find the extension for which you require details. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/N5WUxWHCXAG1ict4Mg_OA_image.png) 2. Ensure the extension is permitted to be deployed to production. 3. Click **Details**. The catalog navigates to the extension details page. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/dZhhMCcwJlkq-NOENZeXk_image.png) 4. Click **Detailed Documentation**. The catalog navigates to the GitHub extension documentation. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/sECQAmvrI1Bmv-Qpx3IV0_image.png) The yaml configuration file and the readme file are circled in red for your reference. You can create multiple instances of the same extension, each of which is configured differently. Use the following procedure to view configuration details: 5. Click the **Manage** link on the extension tile. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/r79DBElzWaxwQxBMeAQ4w_image.png) The catalog navigates to the extension Manage page, displaying instantiated extension. 6. Click the instance of the extension to see configuration details. You can also use this procedure to create a new instance of the extension. 7. Click Manage on the Extension tile as you did in step 1 of the previous procedure. The service presents a blank configuration dialog: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/FvwzZNJan9scSkSb8olvz_image.png) 8. Complete the configuration form. 9. Click **Create**. The service will produce a confirmation dialog. 10. Confirm the creation of a new instance. The service navigates to the My Extensions page: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/qYgijKhY08A0LeDwP_JJr_image.png) 11. Use the search bar to search for the extension instance by Extension name. The service displays a list of matches: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/5xTi-biPaK61Wo6CdpFeC_image.png) 12. Click **Start** for the new instance. The service starts the new Extension instance. For more details on how to manage, support and maintain extensions please refer to the [Extensions](docId\:E74ldMGZ3vqCMWBFQhAL-) [title] [path] Services/Kyndryl Services/ [title] Network Utilization Dashboard [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Service components/ The **Network** **Utilization Dashboard** provides detailed insights into CPU and Memory usage for network devices over a selected time period. It enables users to monitor performance trends, identify anomalies, and take proactive action. The dashboard contains two main widgets: - **Network CPU Utilization** - Displays CPU usage across devices grouped by percentage ranges. - **Network Memory Utilization** - Displays memory usage across devices grouped by percentage ranges. The dashboard uses **three color levels** to represent utilization severity: | **Indicator** | **Range** | **Meaning** | | ------------------------------------------ | -------------------------------------- | -------------------------------------------------------------------------------- | | 🟢 Green | Low (0–50%) | Normal usage – No immediate action required | | 🟡 Yellow | Medium(51% – 80%) | Moderate usage – Monitor closely | | 🔴 Red | High(81% – 100%) | High usage – High utilization – Critical condition requiring immediate attention | The top section displays a tabular summary of devices with key metrics: | **Column name** | **Description** | | -------------------------------------------- | ------------------------------------------------------------------------ | | Device Name | Name of the network device | | CPU Usage | Current CPU utilization percentage (displayed with status indicators) | | Memory Usage | Current memory utilization percentage (displayed with status indicators) | | Type | Device category (e.g., Switch) | | Location | Physical or logical device location (e.g., Brazil) | # Utilization trend charts Two trend graphs are displayed as follows: :::Paragraph{indent="1"} 1\. Network CPU Utilization Trend ::: :::Paragraph{indent="1"} 2\. Network Memory Utilization Trend ::: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/BrzXHE5wnbt-fitAmdPiH_image.png) [title] Monitoring - Events [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - Events** page provides data visualizations that help users understand events associated with network devices. The page also includes quick filters that allow users to narrow results without creating complex queries. Available filter parameters include: - **Customer Name:** Filter devices owned by specific customers. - **GSMA Code: **Filter devices associated with a specific GSMA code. - **Data Source:** Filter by supported data sources used to track network devices and operating systems. - **Node Name:** Filter by node name. - **Interface Name:** Filter by supported interface name. - **Event Type:** Filter by event type. Each parameter supports Include and Exclude options: - **Include:** Limits results to include the selected value. - **Exclude:** Limits results to exclude the selected value. To access visualization display options, hover over the upper-right corner of a visualization and select the ellipsis icon. The following options are available: - **Settings: **Apply a custom time range or configure additional options. - **Inspect: **Download a report. - **Maximize:** Expand the visualization for a larger view. The control changes to Minimize when expanded. # Data visualization The page includes the following data visualizations: ### Events summary | **Metric / Visualization** | **Description** | | ------------------------------------------------------- | ---------------------------------------------------------------------- | | Monitored Nodes Count | Displays the number of devices connected to SolarWinds. | | Monitored Interface Count | Displays the number of interfaces monitored by SolarWinds. | | Event Counts | Displays the number of events recorded during the selected time range. | | Nodes Contributing to Events | Displays the number of devices generating events. | | Interfaces Contributing to Events | Displays the number of interfaces generating events. | | Top 20 Nodes | Displays the 20 devices generating the highest number of events. | | Top 20 Interfaces | Displays the 20 interfaces generating the highest number of events. | | Top Events by Event Type | Displays the 20 most common event types. | | Events Trend | Displays the hourly event rate for the selected time period. | ### Events analysis | **Metric / Visualization** | **Description** | | ------------------------------------------------------- | --------------------------------------------------------------------------------------- | | **Events by Location** | Displays the top 10 locations generating the highest number of events. | | **Events Summary Table** | Displays a tabular summary of events, including identifying details and current status. | Refer to the following image for more details: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/alODPyJDv780eUQ-Zv4Y9_upload.png) [title] Overview [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/ enables secure, seamless connectivity for applications, workloads, employees and customers, regardless of location. For global enterprise CIOs aiming to build future-ready, flexible infrastructure, optimize IT resources, and manage enterprise risk across complex IT and OT environments. The service enables organizations to modernize, integrate, and differentiate specific network devices, tools, and applications. This technological advantage enhances the user experience while providing a competitive edge through automation and observability. subscribers enjoy the following benefits: - **Cloud network and WAN services:** Kyndryl WAN offerings unify multiple OEM partners into a single solution module, providing versatile options to address diverse market needs like multicloud connectivity, enhanced security, and simplified management across industries. - **Wireless, LAN, and edge services:** Modern enterprises leverage wireless networks with dedicated frequencies and edge computing to enable secure, high-speed communication and realtime data processing. To navigate to Managed Network Services, go to main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"} **> **Services **>** . # Core capabilities With, you can: - Monitor network performance and network health from centralized dashboards. - Connect network monitoring, event management, inventory, and ITSM tools into a single platform experience. - Gain visibility into network devices and operating systems across your environment. - Track device inventory and lifecycle status. - Monitor End of Life (EOL) and End of Service (EOS) risks affecting network hardware and operating systems. - Analyze network device distribution and lifecycle trends through statistical dashboards. - Extend observability using integrations with network and operational management tools. - Useinsights to support daily operations and strategic decision-making. [title] [path] Services/ [title] Widgets [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/Control Dashboard/ The widgets on the dashboard are categorized into distinct classes of information. Each class provides a specific perspective for monitoring, evaluating and optimizing operations. These classifications enable users to efficiently identify trends, measure performance and support data-driven decision-making. The dashboard offers the following features: # Control overview ## Identify | **Capability / Widget** | **Description** | | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Identify** | Maintains awareness of current cybersecurity risks, enabling informed decision-making and prioritization of security efforts. | | **Risk Assessment** | Evaluates cybersecurity risks to organizational operations, assets, and individuals, providing the foundation for control implementation and monitoring. | | **Average Vulnerabilities per Scan** | Displays the average number of vulnerabilities detected during each scan. | | **Oldest Unremediated Critical Vulnerability** | Identifies the oldest critical vulnerability that remains unresolved. | | **Active Vulnerabilities by Severity** | Displays unresolved vulnerabilities grouped by severity level. | | **Vulnerability Discovery Over Time** | Tracks the number of vulnerabilities detected during each scan over time. | | **Recent Scans & KEV Detection** | Summarizes the five most recent scan dates and the vulnerabilities identified, including Known Exploited Vulnerabilities (KEVs). | | **Scanned Vulnerability Severity Trend** | Shows monthly trends of vulnerabilities categorized by severity. | | **Scan Coverage Adherence** | Measures the percentage of assets scanned according to the defined scanning schedule. | | **Engine Signature Freshness** | Indicates the number of days since the vulnerability scanning engine was last updated. | ## Protect - Configuration management | **Capability / Widget** | **Description** | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Protect** | Focuses on implementing and actively managing safeguards to reduce cybersecurity risks and improve organizational resilience. | | **Configuration Management** | Ensures configuration management practices are defined, enforced, and monitored to maintain system integrity and reduce vulnerabilities. | | **Overall Compliance Posture (KPI)** | Percentage of assets requiring a HealthCheck that have a valid HealthCheck scan. | | **Compliance Depth View (KCI)** | Percentage of HealthCheck-required assets achieving at least 75% policy compliance. | | **Non-Compliant Asset Count** | Number of HealthCheck-required assets whose latest HealthCheck status is missing or expired. | | **Newly Detected Non-Compliance** | Number of HealthCheck-required assets with more than one finding in their latest HealthCheck scan. | | **Top 10 Policy Failures** | Lists the ten most common HealthCheck violations grouped by check description. | | **Compliance Scan Coverage** | Shows the distribution of HealthCheck scans performed automatically versus manually. | | **Compliance by Platform Category** | Compares operating system families against HealthCheck status. | | **Unsupported Assets Overview** | Displays the total number of systems that are End-of-Life (EOL) or End-of-Support (EOS). | | **Device Lifecycle Breakdown** | Compares EOL and EOS percentages for hardware and software assets in production environments. | ## Protect - Change & Vulnerability Management | **Capability / Widget** | **Description** | | ------------------------------------------------------ | ------------------------------------------------------------------------------------ | | **Change Management (Deployed)** | Percentage of changes successfully deployed to production. | | **Change Management (Emergency)** | Percentage of emergency changes deployed to production. | | **Open Changes – Age Range vs Priority** | Tracks open changes by age and priority level. | | **Open Changes – Category vs Priority** | Shows the distribution of open changes by category and priority. | | **SLA Breach – Critical Vulnerabilities** | Tracks critical vulnerabilities that were not remediated before their SLA due dates. | | **Critical Vulnerabilities Patched Within SLA (KPI)** | Percentage of critical vulnerabilities remediated within the defined SLA timeframe. | | **Patch Backlog (Pending Systems)** | Number of systems awaiting patch deployment following a vulnerability scan. | | **Average Time to Patch (KPI)** | Average time between vulnerability identification and remediation. | | **Vulnerabilities Patched by Severity** | Monthly count of patched vulnerabilities grouped by severity. | | **Patch Success Rate Over Time** | Monthly trend of patching outcomes, such as successful, failed, or pending. | | **Pending Patch Volume by Platform** | Lists systems with pending patches grouped by platform. | | **Vulnerabilities Patched by Time-to-Remediate Range** | Categorizes patched vulnerabilities by remediation time. | | **Patch Backlog by Severity** | Displays outstanding vulnerabilities grouped by severity level. | | **Remediation Progress Trend** | Tracks monthly trends in vulnerability remediation activity. | | **Known Exploited Vulnerabilities** | Total active vulnerabilities detected on production devices. | | **Last Scan Date** | Most recent completed vulnerability scan date. | ## Protect - Identity Management, Authentication and Access Control | **Capability / Widget** | **Description** | | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Identity Management, Authentication, and Access Control** | Ensures access to physical and logical assets is restricted to authorized users, services, and devices through risk-based authentication and authorization controls. | | **Shared Credentials in Vault** | Verifies that shared credentials are stored in a managed vault to support accountability and protect sensitive information. | | **Shared UIDs in Vault (Distribution)** | Shows the distribution of shared user IDs based on whether they are stored in a vault. | | **UID Actions by Type & Outcome** | Displays pending local user IDs by action type and outcome, such as suspensions or removals. | | **Pending Local UID Removals** | Number of local user IDs that remain active despite being scheduled for removal. | | **Access Revalidation (KPI) – Non-Privileged UID Revalidation** | Percentage of systems that have completed non-privileged user ID revalidation. | | **Access Revalidation (KPI) – Privileged UID Revalidation** | Percentage of systems that have completed privileged user ID revalidation. | | **Access Revalidation (KPI) – Role Entitlement Revalidation** | Percentage of systems that have completed role entitlement reviews. | | **Access Revalidation (KPI) – Role Membership Revalidation** | Percentage of systems that have completed role membership reviews. | | **Asset Access Revalidation (KPI)** | Measures completion of required access revalidation activities across managed assets. | | **Employee Access Termination (KPI)** | Measures the percentage of user IDs removed within the required timeframe after employee termination. | [title] Dashboards [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/ [title] [path] / [title] End of Life and End of Service Widgets [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Service components/ supports widgets that report End of Life (EOL) and End of Service (EOS) status summaries for network devices and operating systems using four widgets: - Hardware EOL Status Summary - Hardware EOS Status Summary - OS EOL Status Summary - OS EOS Status Summary These widgets provide at-a-glance visibility of devices and operating systems approaching or at end of life or end of service. They display summarized counts and percentages for device operating systems with EOL/EOS reached, approaching EOL/EOS within 90 and 180 days, and those without an EOL date. **End of life (EOL)** refers to the stage when a product is no longer manufactured, sold, or actively developed by the vendor. After the EOL date, vendors typically stop providing updates, or enhancements, and security updates. Devices past EOL may pose performance and compatibility, and security risks if not replaced or modernized. **End of support (EOS)** refers to the point when a vendor stops providing software maintenance, security patches, or technical support for an operating system or firmware. Devices or systems past EOS may remain functional but become vulnerable to security threats and compliance issues without ongoing vendor updates. A **View details** link navigates to the consolidated EOL/EOS insights dashboard, pre-filtered to show network devices. There you can: - Quickly view the size and urgency of devices requiring lifecycle action. - Identify security and compliance risks from unsupported or undocumented devices. - Access the consolidated dashboard with filters already set to network inventory. - Support managed services delivery by giving DPEs one-click access to prioritized device lists. # Supported vendors Kyndryl supports all models from the following vendors for all EOL and EOS widgets: - Cisco - F5 - Checkpoint - Fortinet - Palo Alto # Pre-requisites The following items are prerequisite to view and add widgets: - Access to OU - Access to in - Network inventory available in the inventory service, with vendor, model, and populated EOL metadata. - EOL/EOS consolidated dashboard available with filtering for Category = network. - You must have Administrator privilege to add widgets to the landing page dashboard and to edit them. # Configuration Perform the following procedure to configure the landing page dashboard: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. 2. Confirm the network landing page includes the EOL and EOS widgets. 3. Add or edit widgets through the dashboard designer. 4. Place the widget at the primary grid size, then adjust for other screen sizes. # Widget data mapping Widgets indicate the following: - **EOL/EOS reached:** devices where EOL date is in the past. - **EOL/EOS approaching \< 90 days.** - **EOL/EOS approaching > 180 days.** - **EOL/EOS Date Not Available:** Missing lifecycle metadata. # EOL and EOS summary widgets access and use Use the following procedure to access and exercise the EOL and EOS summary widgets: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. 2. Locate the EOL widget showing lifecycle segments in a donut chart. 3. Hover over chart segments to view counts and percentages. 4. Click View Details to navigate to the EOL/EOS Insights page. 5. Toggle between donut chart and list data (per widget). 6. Maximize individual widgets one at a time. 7. Download data or graphic in the following formats: - CSV - PNG - JPG # EOL and EOS Insights The EOL/EOS Insights page is available from the View Details link located at the bottom right of each widget. The page contains the following sections: - Filter Matrix - Filter data using fields such as Customer name, lifecycle status, and Device. - Summary data array: - Total Devices (count) - End of Life (percentage of all devices) - End of Support (percentage of all devices) - Total devices Reached EOL or EOS (count) - EOL and EOS details - EOES and EOEPS details EOL/EOS and EOES/EOEPS per category - Detailed View – Device details table - EOL, EOS. EOES. EOEPS Metrics: Graphics displaying percentages of EOL/EOS and EOES/EOEPS data breakdowns as a percentage of total hardware and software. # Troubleshooting Use the following guide to ensure your data is visible and correct: - If data is missing, confirm EOL metadata is included in the inventory service. - If EOL Date Not Available is unusually high, reconcile inventory records. - If the widget is not visible, confirm user permissions and page configuration. [title] Get access through ARMS [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/ The Automated Roles Management System (ARMS) is used by applications inside Kyndryl. It helps these applications manage user's authorization by: - Taking control of the storage of role assignments. - Providing an API to easily retrieve data. - Performing daily role re-validation. The ARMS solution delivers improved role management to local applications. ARMS covers access control management, delegations, and re-validation of accesses as required by ITCS104. This application stores data for more than 18,000. This data is used by more than 20 applications. The application was deployed in IMTs: NA, LA, and EMEA. # Required links Use the following links to access ARMS for requesting access to : - Production: [https://bat.bats.kyndryl.net/arms2/user/myAssignments](https://bat.bats.kyndryl.net/arms2/user/myAssignments) - Development and Staging: [https://eu1sr1lnarms-dev.bats.kyndryl.net/arms2/user/myAssignments](https://eu1sr1lnarms-dev.bats.kyndryl.net/arms2/user/myAssignments) # Prerequisite Connect to Cisco Secure Client (AnyConnect VPN). # Access request is hosted on the platform. To get access to the , users must request access with the appropriate privileges. Upon approval, the user can perform operations according to their assigned roles and privileges. Before proceeding with access requests, review the following descriptions of the Role: # Role descriptions  The role currently available under Incident recovery menu to enable user to perform actions on . Along with the following roles, user need to raise access to respective service with the right privileges for insights & automation module.  - **Incident Recovery Admin**: Possesses the highest level of access, enabling all actions permitted for the editor and viewer roles, in addition to administrative tasks such as configuring global settings applicable only to . - **Incident Recovery Editor:** Individuals in this role are authorized to create, configure, and delete resiliency entities, initiate data collections, and execute workflows or automations applicable only to . - **Incident Recovery Operator**: Currently not in use. - **Incident Recovery Viewer**: Grants read-only access, allowing individuals to view resiliency entities without permissions for execution, creation, configuration, or deletion applicable only to . - **Insights service administrator: **Enables users to subscribe to the dashboards of . - **Incident Recovery Primary Approver:** Grants authority to review and approve workflow execution requests at the first level of the approval process. Individuals assigned to this role can assess submitted execution requests and either approve or reject them before they proceed to the secondary approval stage. - **Incident Recovery Secondary Approver:** Grants authority to review and approve workflow execution requests at the second and final level of the approval process. Individuals assigned to this role can assess requests that have received primary approval and provide final authorization for workflow execution. - **Incident Recovery Zerto Operator:** Individuals in this role are authorized to execute only Zerto workflows. This role enables users to initiate resiliency operations through . - **Incident Recovery Commvault Operator:** Individuals in this role are authorized to execute only Commvault workflows. This role enables users to initiate resiliency operations through . # Access types There are two types of access in ARMS: Standard and Advance. The Standard access enables users to access the service with limited capabilities, while the Advance access enables users to perform the advanced capabilities. The following table describes the access details that you get when you select Standard or Advance. | **** | | | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Production | \[AIOps] Resiliency Orchestration - aiops-viewer
\[Insights] Resiliency Orchestration - bundle-aiops-analytics
\[Insights] Resiliency Orchestration - bundle-automation
\[Insights] Resiliency Orchestration - bundle-backup-and-resiliency
\[Insights] Resiliency Orchestration - bundle-environment-build-and-decommission
\[Insights] Resiliency Orchestration - bundle-event-management
\[Insights] Resiliency Orchestration - bundle-growth
\[Insights] Resiliency Orchestration - bundle-hardware-and-software-currency
\[Insights] Resiliency Orchestration - bundle-identity-and-access-management
\[Insights] Resiliency Orchestration - bundle-inventory-management
\[Insights] Resiliency Orchestration - bundle-mainframe-management
\[Insights] Resiliency Orchestration - bundle-performance-and-capacity
\[Insights] Resiliency Orchestration - bundle-security-and-compliance-management
\[Insights] Resiliency Orchestration - bundle-service-maintenance
\[Insights] Resiliency Orchestration - bundle-service-management
\[Insights] Resiliency Orchestration - bundle-storage-management
\[Insights] Resiliency Orchestration - bundle-transformation-management
\[Extensions] Resiliency Orchestration - extension-viewer
\[Inventory] Resiliency Orchestration - inventory-viewer
  | Select the specific access that you need to get advanced capabilities. | | Staging | \[AIOps] Resiliency Orchestration - Staging - aiops-viewer
  | Select the specific access that you need to get advanced capabilities. | | Development | \[AIOps] Resiliency Orchestration - Dev - aiops-viewer
\[Automation] Resiliency Orchestration - Dev - automation-viewer
  | Select the specific access that you need to get advanced capabilities. | ## Standard access To raise the standard access request to the development and staging environments, refer to the following screen, and select the options accordingly: ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/TGkePAsVgY0qpmchMEREm_image.png) 1. Click** OU Access Group Request**. 2. Click **Request Access Group**. 3. From the **OU Type** drop-down, select **account**. 4. In the **OUs** field, type **Resiliency**. The relevant options for the Resiliency OU appear. 5. Based on your requirement, select **Resiliency Orchestration -Dev** or **Resiliency Orchestration - Staging**. 6. Click **Submit**. You get the options to select **Standard **or **Advance**. Click **Standard**. 7. Add a business justification and click **Submit**. ## Advance access ### Access request for incident-recovery-viewer To view the Incident Recovery dashboards, you need the OUs access to the Automation and Insights along with the Incident Recovery. 1. Login to **ARMS**. 2. Follow the instructions provided in the following infographic: ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/uIjqFhZzG3L4fuUbFJWBe_image.png) 3. **Request multiple OUs access** page appears on your screen.  ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/nxBHTs_6Ums9Xz9FiHGua_image.png) 4. In the **Automation** field, select **automation-viewer.** 5. In the **Insights** field, select **bundle-backup-and-resiliency**. 6. In the Incident Recovery field, select Access Groups(s) as **incident -recovery-viewer**. 7. Click **Submit.** 8. Provide the business justification. Click on **Submit.** Once submitted, your approver receives an approval request. The account DPE or delegate is the approver of requests. Once approved, you can access the application from the UI of I-AIOPs. ### Access request for incident-recovery-admin   For the incident-recovery-admin role, you need the OUs access to the Automation, Insights, and Extensions along with the Incident Recovery.  1. Login to [ARMS](https://bat.bats.kyndryl.net/arms2/user/myAssignments). 2. Follow the instructions provided in the following infographic: ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/PcGZwKNFx4ZG9TyRSITmy_image.png) 3. **Request multiple OUs access** page appears on your screen. 4. In the **Automation** field, select **automation-admin.** 5. In the **Insights** field, select **bundle-backup-and-resiliency**. 6. In the Extensions field, select Access Groups(s) as **extension-editor. **For more information on the Resiliency Data Protection extension, see Resiliency Data Protection extension. 7. In the Incident Recovery field, select Access Groups(s) as **incident -recovery-admin**. 8. Click **Submit.** 9. Your approver receives an approval request. 10. Once your request is approved, you can access the application from the UI of I-AIOPs. ### Access request for incident-recovery-editor  For the incident-recovery-editor role, you need the OUs access to the Automation and Insights along with the Incident Recovery.  1. Login to [ARMS](https://bat.bats.kyndryl.net/arms2/user/myAssignments). 2. Follow the instructions provided in the following infographic: ![](https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/PcGZwKNFx4ZG9TyRSITmy_image.png) 3. **Request multiple OUs access** page appears on your screen. 4. In the **Automation** field, select **automation- editor.** 5. In the **Insights** field, select **bundle-backup-and-resiliency**. 6. In the Incident Recovery field, select Access Groups(s) as **incident -recovery-editor**. 7. Click **Submit.** 8. Your approver receives an approval request. 9. Once your request is approved, you can access the application from the UI of I-AIOPs. ### Access request for insights-service-administrator Under the Insights tab, select **Insights-service-administrator** role to be able to subscribe to the dashboards of . Once your access request is approved, you can subscribe to the dashboards of . ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/ywbMJGIDkBO2nJGRZLRP6_image.png" size="80" isUploading="false" width="1170" height="723" darkWidth="1170" darkHeight="723" showCaption="false"} ### Access request for incident-recovery-primary-approver or incident-recovery-secondary-approver For the incident-recovery-primary-approver role, you need the OUs access and incident-recovery-viewer. Some other workflows require both L1 and L2 approvals. In such cases, the request is first routed to the level 1 approver and, upon approval, is forwarded to the Level 2 approver for final approval. Follow these steps to get L1 and L2 roles through ARMS: 1. Go to: *https\://bat.bats.kyndryl.net/arms2/user/accessAssignments* 2. Click AIOPs Assignment and then click Request Access Groups button. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/JC_47aIM4R8E1TwMD8NuX_image.png) 3. A new page for requesting the access group is displayed. 4. Enter the following information: - **OU Type**: Select **account**. - **OUs’s**: Select **Global Internal-KIRS ACME** 5. Click **Next.** ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/XPghYKn9WP1bPXzDHqPfP_image.png) 6. Click **Advanced Form **tab. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/1BDP6kI5cpL79uv2pKfuf_image.png" size="80" isUploading="false" width="826" height="1108" darkWidth="826" darkHeight="1108" showCaption="false"} 7. A new page is displayed. Go to **Intelligent Recovery Service** field. 8. Select the **primary** and **secondary** approver roles as applicable. 9. Click **Next**. 10. Provide a **Business Justification**. 11. Click **Submit** button. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/WYhQGfX17eRTigaK9XkLG_image.png) [title] Cloud Networking Dashboards [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Dashboards/ Kyndryl supports observable data in your Cloudflare implementation, enabling greater uptime and optimization through the presentation of captured performance data on three primary dashboards: - Cloud Networking - Cloudflare Events Dashboard - Cloud Networking - Cloudflare Firewall Dashboard - Cloud Networking - Cloudflare Tunnels Dashboard Subsequent sections provide details regarding the data displayed on these dashboards. Each dashboard contains filters that enable data narrowing. # Global filter The global filter enables you to narrow the observable data set, limiting it to only data necessary to your circumstance. The filter is located directly below header. The filter comprises two buttons: - Filter control (grounding icon): - Add filter: Add a filter element. - Apply to all\:Apply the filter to the data set. - Clear all: Clear all applied filters, restoring the defalut data set of all data. - Add filter (plus icon): Add a filter element. Use the following procedure to specify the time range for the current data set by time range and other parameters: 1. Select a time range. The default time range is **Last 7 days**. If no changes have occurred in the default or selected date range, data visualizations will not populate. Examples of such changes include new nodes, new interfaces, and events. To change the current date range, use the following procedure: 2. Click the calendar icon. The service displays the quick select dialog, presenting a range field that you can manually set and a list of preselected options. 3. From the units field dropdown menu, which defaults to **7 Days ago**, select the unit, **Days**, **Weeks**, **Months**, **Years**. Set the quantity by entering, incrementing, or decrementing the unit quantity. For example, select **Months**, then decrement **7** to **6** to change the value from **7 days ago** to **Last 6 months**. 4. Click **Update**. The service updates the data for the selected date range. :::Paragraph{indent="1"} The default time range, **7 Days ago**, applies initially to all six dashboards; adjust each as needed. ::: 5. Click the **Plus** icon. The service presents the filter editor. 6. Select a field from the **Select a field** dropdown menu. You can select from any supported field in the network device or operating system record. 7. Select an operator from **Select operator** field: - **is**: Equal to - **is not**: Not equal to - **is one of**: Some fields might have more than one value. This operator specifies a specific value in such a field. - **is not one of**: Some fields might have more than one value. This operator specifies that none of the values exist in such a field. - **exists**: Any device or operating system description that contains the specified field. - **does not exist**: Any device or operating system description that does not contain the specified field. 8. Select a value from the **Select a value** field. 9. **Optional:** Add a an additional parameter by selecting boolean **OR** or Boolean **AND**: 1. Repeat steps 2 through 4. 2. **Optional:** Repeat step 5. 10. Click **Cancel** to cancel the filter addition or **Add filter** to add the filter you constructed. You may add additional filters as required to adequately narrow your data set. You can also edit a constructed filter as a Domain Specific Language query by clicking the **Edit as Query DSL** link located at the far right of the **Add filter** editor. You can also filter by Customer Name and on the CloudFlare Tunnels dashboard you can filter by Tunnel name as well. # Data visualizations supported | **Name** | **Description** | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Incidents** | The number of incidents that occurred during the selected time range. | | **Components** | The number of components during the selected time range with a status of **Degraded**, **Outage**, or **Under Maintenance**. | | **Notifications** | The number of notifications that occurred during the selected time range. | | **Incident Alerts** | A table presenting details of the incidents that occurred during the selected time range. | | **Component Alerts** | A table presenting details of components with a status of **Degraded**, **Outage**, or **Under Maintenance**during the selected time range. | | **Notification Alerts** | A table presenting details of notifications that occurred during the selected time range. | | **Events by Type** | A scatter plot that displays event types during the selected time range by occurrence in three-hour increments. | | **Audit Logs** | A table displaying a summary of historical changes made within a Cloudflare account during the selected time range. | # Widget visualization supported | **Widget** | **Description** | | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | **Total Firewall Events** | Total number of firewall events recorded during the selected time range. | | **Firewall Events – Blocked** | Number of firewall events that were blocked during the selected time range. | | **Firewall Events – Skip** | Number of firewall events with an unknown or skipped status during the selected time range. | | **Top 10 Allowed Source Addresses** | Donut chart showing the top 10 source addresses generating allowed firewall events, ranked by event volume. | | **Top 10 Allowed Destination Addresses** | Donut chart showing the top 10 destination addresses receiving allowed firewall events, ranked by event volume. | | **Top 10 Denied Source Addresses** | Donut chart showing the top 10 source addresses associated with denied firewall events, ranked by event volume. | | **Top 10 Inbound Allowed Connections by Country** | Donut chart showing the top 10 countries generating inbound connections that were allowed by the firewall. | | **Top 10 Outbound Allowed Connections by Country** | Donut chart showing the top 10 countries receiving outbound connections that were allowed by the firewall. | | **Top 10 Firewall Rules Hit** | Donut chart displaying the firewall rules most frequently triggered during the selected time range. | | **WAF Attacks** | Summary section providing metrics related to Web Application Firewall (WAF) threats and attack activity. | | **RCE Score** | Remote Code Execution (RCE) score indicating the level of detected RCE attack activity. | | \**SQLI Score* | | # Data visualizations supported | **Data visualizations** | **Description** | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Total Site Tunnels** | The number of site tunnels during the selected time range. | | **Site Tunnels Up** | The number of site tunnels that were operational during the selected time range. | | **Site Tunnels Down** | The number of site tunnels that were not operational during the selected time range. | | **Site Tunnels Degraded** | The number of site tunnels with a status of **Degraded** during the selected time range. | | **Site Tunnels With Traffic** | The number of site tunnels with active traffic during the selected time range. | | **Tunnel Health** | A table that displays health details for each tunnel. | | **Bit Rate Over Time** | A trend line chart that displays the average bit rate of all tunnels during the selected time range in daily increments. | | **Magic Tunnels Map** | A global map that displays traffic volume, measured in bits, by geographic location during the selected time range. | [title] Zabbix Multi-Instance Onboarding [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Other resources / The Network Service Gateway supports multiple Zabbix environments. Instead of using a single Zabbix server, devices can be onboarded to different regional or functional Zabbix instances, such as: - ZBXEUAP1 - ZBXGBL1 - ZBXUSN1 - ZBXDNS1 A single onboarding request may contain devices destined for different Zabbix instances. The system determines the correct destination by using the `Zabbix Instance Alias` specified for each device record. # Runtime design: the lazy-init connection pool Connections to Zabbix instances are managed by` ZabbixInstancePool `(*app/api/modules/zabbix.py*), wired up as the `ZABBIX_POOL` singleton and the `get_zabbix_instance(alias) `helper in *app/api/modules/environment.py*. ### Key properties - **Lazy initialization** — a connection for a given alias is created only on the first `ZABBIX_POOL.get(alias)` call, not at process startup. This avoids needing to know every possible alias in advance and avoids connecting to instances that are never used. - **Caching** — once created, the `Zabbix `instance (and the credentials used to build it) are cached in memory for that alias. Subsequent requests reuse the same connection with no extra Vault reads, up to a TTL (30 minutes by default). - **Self-healing** — if a call fails with a session-expiry error (`Zabbix.is_session_error)`, the caller evicts the cached entry `(ZABBIX_POOL.evict(alias))` and re-resolves the alias, which forces a fresh Vault read and a new login. This means a rotated Vault token or an expired Zabbix session recovers automatically, without restarting the pod. - **Thread-safety** — a lock in the pool prevents two concurrent requests from initializing the same alias twice. This design was chosen over "connect to everything at startup" because startup-init cannot recover from token rotation or session expiry without a restart, and over "read Vault + reconnect on every request" because that would multiply Vault reads and TCP/login overhead by every row in every request. See *docs\_review/zabbix-multi-instance-review-2026-06-24.md* for the full design tradeoff analysis. ## Request-level flow (*/onboarding/zabbix *and */onboarding/zabbix/validate*) 1. The endpoint reads the JSON payload (a list of device rows) and normalizes SNMPv3 protocol casing. 2. Every row's `Zabbix Instance Alias `is validated for **format** (string, ≤255 chars, matches `^[a-zA-Z0-9_.\-]+$)` and for **presence** (non-blank — there is **no default-instance fallback**; every row must declare its alias). Either failure short-circuits the whole request with a 422 before any Vault/Zabbix call is made. 3. Rows are grouped by alias (`_group_rows_by_alias`), preserving each row's original index so error reporting can still point at the exact \`\[row, col]\` cell in a request that interleaves rows for different aliases. 4. For each alias group: - `get_zabbix_instance(alias)` resolves (or reuses) the pooled connection. - If resolution fails (unknown alias, unreachable host, DNS failure), the rows in that group get a per-row error and other groups continue processing independently — one bad alias does not fail devices destined for a different, healthy instance. - If resolution succeeds, `ZabbixOnboarding.create_inventory() / validate_inventory()` runs against that instance for just that group's rows. - If a session-expiry error is detected mid-call, the pool entry is evicted and the group is retried once against a freshly authenticated instance. 5. Errors from all groups are merged back into a single response keyed by the original row/column coordinates, so the response format is identical to the single-instance case from the caller's point of view. # Vault secret structure for Zabbix All Zabbix instance credentials live under **one** Vault secret — there is no per-alias sub-path. The secret is a single JSON object keyed by alias, and follows the structure of a plain Python dictionary: **Path:*** services/network-service-gateway/secrets/zabbix* \{ "\": \{ "token": "\", "url": "\", "user": "\" }, "\": \{ "token": "\", "url": "\", "user": "\" } } Real, production example (values sanitized): \{ "ZBXUSN1": \{ "token": "\", "url": "https\://zabbix-pg-tsdb.ona.kyndryl.net/api\_jsonrpc.php", "user": "\" } } ### Rules - **The top-level key is the alias.** This is the exact string that must appear in the `Zabbix Instance Alias` column of the templates CSV. If a row's alias does not match a key in this secret, `ZabbixInstancePool` raises KeyError and the row is reported as an invalid/unresolvable alias. - **Each alias entry carries its own \`token\`, \`url\`, and \`user\`** (token auth is the standard for production instances; `user/password`is also supported by the underlying `Zabbix `client shape if a given instance uses password auth instead of a token). - **\`url\` points at the Zabbix JSON-RPC API endpoint**, i.e. it ends in `/api_jsonrpc.php (e.g. https://zabbix-pg-tsdb.ona.kyndryl.net/api_jsonrpc.php)`, not just the host root. - **Aliases are case-sensitive.** Vault paths and the credential lookup are case-sensitive — real-world provisioned aliases are commonly upper case (e.g. `ZBXUSN1`), and the gateway deliberately does **not** normalize case, so the CSV value must match the Vault key exactly. - **There is no default/fallback instance.** Every alias used in a CSV must be provisioned as a key in this secret; there is no "use ZABBIX singleton if alias is missing" behavior for onboarding — the alias column is always required and always resolved through the pool. - Adding a new instance means adding a new key to this one secret (no Helm `values.yaml `change is needed per instance, since it is all one path) and making sure whoever prepares templates CSVs knows the new alias. ## Updating the secret via script Production updates to this secret are performed with the *DxVaultApiClient* CLI script (*temp/vault.py*), not the Vault UI directly. The script authenticates (token file or AppRole), then prompts for an **action**. When prompted for the **service path** (`create/update/read/delete` actions), enter just *zabbix *— the script automatically prepends `SECRET_BASE_PATH (services/network-service-gateway/secrets)`, so the resulting path resolves to `services/network-service-gateway/secrets/zabbix,` matching what `environment.py` and `ZabbixInstancePool` read from at runtime. Do not enter the full path, and do not enter a per-alias path (e.g. `zabbix/ZBXUSN1`) — this deployment uses the single-object layout (§3), where every alias is a key inside the one `zabbix` secret. For the generic `create/update` action, the script prompts for the secret contents as a **Python dict literal** (parsed with `ast.literal_eval`, not JSON) — this is where the "must be minified" requirement comes from: the value must be typed as a single-line dict, e.g.: `Enter the secrets dict (e.g. {'token': 'abc', 'url': 'https://example.com'}):` `{'ZBXUSN1': {'token': '', 'url': '>', 'user': ''}}` Equivalently, JSON is accepted as long as it is valid Python-dict syntax on one line (double quotes work fine with `ast.literal_eval),` e.g.: `{"ZBXUSN1":{"token":"","url":"https://zabbix-pg-tsdb.ona.kyndryl.net/api_jsonrpc.php","user":""}}` Under the `create/update `action, the script **already reads the existing secret first and merges** your input on top of it `(merged_secret_data = {**existing_secret_data, **new_secret_data})` before writing back — so submitting just the one alias you are adding/changing is safe and will not delete other already-provisioned aliases. (This merge safety only applies to the generic `create/update` action; the dedicated `put-zabbix `action in the script instead overwrites the whole secret with its local `ZABBIX_INSTANCES` dict, so that action should only be used with `ZABBIX_INSTANCES` fully populated with every alias that must remain.) # Templates CSV: the Zabbix Instance Alias column The onboarding templates CSV/JSON schema (`ZabbixOnboarding.schema` in *app/api/modules/onboarding.py*, mirrored by` ZabbixTemplate.schema` in *app/api/modules/zabbix\_templates.py*) includes a `Zabbix Instance Alias` column alongside the existing columns (`Hostname, Host IP, Host Group, Proxy, SNMP version, `etc.). The column rules are as follows: | **Metric** | **Description** | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Type | String | | Maximum Length | 255 characters | | Allowed Characters | :::BlockQuote Letters, numbers, periods (.), underscores (\_), hyphens (-), ^\[a-zA-Z0-9\_.\\-]+$ ::: | | Required | Every row must have a non-blank value.
There is no default instance. | | Case | Not normalized — must match the Vault secret key
exactly (case-sensitive). | ## Why this matters on every row - **Routing, not documentation.** The alias isn't metadata — it is what the gateway uses to decide *which live Zabbix connection* handles that row. Two rows in the same file can (and often will) target completely different Zabbix servers. - **A blank or wrong alias fails only that row.** Because grouping happens per alias, a mistyped alias on one row produces a per-row `[row, col]` error pointing at that exact cell — it does not block or misroute the other rows in the file, but it also means that row's device will not be onboarded until the alias is corrected. - **No silent fallback exists.** If a CSV omits the alias for a row (e.g. because it was optional in an older template version), the request fails fast with a clear "non-blank value is required" error for that cell rather than guessing an instance — guessing wrong would silently create a host on the wrong Zabbix server. - **Typos look like "invalid alias", not "instance down".** An alias that doesn't exist as a key in the Vault secret is indistinguishable, from the CSV author's point of view, from a genuine typo — both surface as "Zabbix instance alias value is not valid. Check with your administrator for possible values." Always double-check the exact alias spelling/case against the list of provisioned aliases before assuming an instance is down. - **Mixed-instance files are expected and supported.** A single onboarding submission may legitimately contain, e.g., 40 devices for `ZBXEUAP1` and 10 for `ZBXGBL1 `in the same file — this is by design (Class B: one alias per logical group of rows), not an edge case to avoid. ## What NOT to do - Do not leave the alias blank "to use the default instance" — there is no default; the request will be rejected. - Do not assume alias matching is case-insensitive — `zbxeuap1 `and `ZBXEUAP1 `are different keys unless Vault happens to have both. - Do not invent new aliases in a CSV without first confirming they exist as a key under `services/network-service-gateway/secrets/zabbix` — an unprovisioned alias will always fail resolution. [title] Managed Network Services landing page [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/ The landing page presents the Network Inventory dashboard containing critical data regarding the status of your network devices, and the operating systems pertaining to them. Navigate to the landing page as follows: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. The dashboard displays details of **Insights **and** Data Table **in the Kyndryl Bridge dashboard for Network and Edge management, which provides visibility into device inventory, network health, compliance metrics, and life-cycle management. Refer to the following table for user permissions and entitlement mapping details: | **ID** | **Email domain** | **Audience** | **KMNS entitlement** | **Internal User** | **View rights** | **Edit rights** | | ----------------------------------- | --------------------------------------------- | ----------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------- | -------------------------------------------- | -------------------------------------------- | | P1 | @kyndryl.com | Internal | kmns-account-viewer or iaiops.network-account.view | True | True | False | | P2 | @kyndryl.com | Internal | kmns-account-operator or iaiops.network-account.edit | True | True | True | | P3 | @kyndryl.com | Internal | kmns-account-administrator or iaiops.network-account.administer | True | True | True | | P4 | non-Kyndryl | External | kmns-account-viewer | False | True | False | | P5 | non-Kyndryl | External | none | False | False | False | ## Insights ### Dashboard overview metrics cards The top section of the **Insights** tab displays high-level health and operational metrics: - **Devices Created**: Tracks the newly added network devices within the past 24 hours. - **Network Devices (KIS)**: Shows total discovered devices in Kyndryl Inventory Services. - **Network Devices (NIC)**: Shows total discovered devices in Network Inventory Controller. - **Active Devices**: Displays the count of devices currently online and reachable. - **Offline Devices**: Lists devices which are inactive. - **Missing Health Details**: Identifies devices lacking operational health metric. - **Missing Compliance Data**: Highlights devices with unavailable or incomplete compliance information. :::hint{type="info"} The tool tip provides more information about each card. ::: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/fLScE1f1MLijDcPOVlNDF_image.png) :::Paragraph{indent="1"} ::: :::hint{type="info" indent="2"} - Users can use the **Search tab **to find specific devices by name, model, vendor, or site. - Users can use the **Filter** option to narrow down displayed records using specific attributes. ::: ## Device inventory breakdown charts The visual donut and bar charts categorize your total inventory by various attributes: | **Chart Name** | **Chart Type** | **Key Data Included** | **Image** | | ------------------------------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Device Distribution by Type** | Donut Chart | The distribution of devicesacross sites to support capacity planning, operational oversight, and inventory management.
**For example:** Router, Switch, Firewall etc. |
::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/Er7hC3fdFs1zbHvX7jsDu_image.png" size="70" isUploading="false" width="309" height="271" darkWidth="309" darkHeight="271" position="flex-start" showCaption="false"}
| | **Device Distribution by Site** | Donut Chart | The distribution of devices across supported network device categories within the inventory.
**For example:** Phoenix-DC, ATL-DC, Remote etc. | ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/pY6EuKW_eG0FQlJkForN8_image.png" size="70" isUploading="false" width="361" height="277" darkWidth="361" darkHeight="277" position="flex-start" showCaption="false"}
| | **Device Distribution by Location** | Donut Chart | Visualizes how network devices are distributed across geographic locations, providing visibility into asset deployment and infrastructure coverage across your environment.
**For example:**
US-TX, US-NY etc. | ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/eGkjRWbNKxdMmRYk6OpAD_image.png" size="80" isUploading="false" width="404" height="293" darkWidth="404" darkHeight="293" position="flex-start" showCaption="false"}
| | **Network Vendor Distribution** | Horizontal Bar | Shows how network devices are distributed across vendors, providing visibility into infrastructure composition, vendor diversity, and asset coverage across the network environment.
**For example: **Cisco, Juniper, etc. | ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/i4lCH5uAPvPv9KJWTXHAa_image.png" size="70" isUploading="false" width="385" height="202" darkWidth="385" darkHeight="202" position="flex-start" showCaption="false"}
| | **Software Version Distribution** | Horizontal Bar | The distribution of software versions across devices, providing visibility into version adoption, standardization, and potential upgrade needs across the environment
** For example:**
Cisco - IOS-XE 17.9.4
Juniper -Junos 23.2R1
**** | ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/D5ngMvgm49Swz9IMdLJTr_image.png" size="80" isUploading="false" width="385" height="201" darkWidth="385" darkHeight="201" position="flex-start" showCaption="false"}
| ## Lifecycle and support status tracking The lower section monitors critical hardware and operating system milestones: | **Name** | **Definition** | ******Examples** | **Image** | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Hardware End of Life (EOL) Status** | The distribution of network devices by hardware lifecycle status, including devices that are supported, nearing End-of-Life (EOL), or past vendor support dates. | Visualizes EOL progress across categories—EOL Reached, EOL Approaching \< 90 Days, EOL Approaching \< 180 Days, EOL > 180 Days, and EOL Data Not Available.
| ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/jbZIuA-bmoPIphDu_AAxg_upload.png" size="70" width="266" height="277" isUploading="false" darkWidth="266" darkHeight="277" position="flex-start" showCaption="false"}
| | **Hardware End of Support (EOS) Status**
| The distribution of network devices by hardware End-of-Support (EOS) status or have exceeded vendor support periods. | Tracks hardware support across categories like EOS Reached, EOS Approaching \< 90 Days, EOS Approaching \< 180 Days, EOS > 180 Days, and EOS Data Not Available. | ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nYPQuKoBDCKuatY589-IG_upload.png" size="70" width="266" height="270" isUploading="false" darkWidth="266" darkHeight="270" position="flex-start" showCaption="false"} | | **Operating System End of Life Status** | The Network operating system versions that are supported, nearing End of Life, or no longer receiving vendor support, updates, or maintenance. | Summarizes OS service life cycles indicating EOL Reached, EOL Approaching \< 90 Days, EOL >90 Days, and EOL Data Not Available.
| ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/FK44xj-UfgMWTqGjWr_rT_upload.png" size="70" width="235" height="241" isUploading="false" darkWidth="235" darkHeight="241" position="flex-start" showCaption="false"} | | **Operating System End of Service Status** | The Network operating system versions that are supported, nearing End of Service, or no longer receiving vendor support, updates, or maintenance. | Displays OS status breakdowns, indicating EOS Reached, EOS Not Reached, or EOS Data Not Available.
| ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ySTK1p1mnjap8-uNSdFin_upload.png" size="70" width="253" height="263" isUploading="false" darkWidth="253" darkHeight="263" position="flex-start" showCaption="false"} | | | | | | ## Data table The data table view provides detailed list views in the Network Inventory module displays detailed hardware and software specifications for managed network devices, including support lifecycle dates. :::hint{type="info" indent="2"} - Users can use the **Search tab **to find specific devices by name, model, vendor, or site. - Users can use the **Filter** option to narrow down displayed records using specific attributes. ::: ### Inventory data columns | **Column Name** | **Definition** | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Hostname** | The unique name assigned to a device on the network. | | **Vendor** | The manufacturer or vendor of the device (for example, Cisco, Juniper, Dell). | | **Model** | The specific hardware model of the device. | | **Site** | The site, facility, or location grouping where the device is installed. | | **Location** | Physical location of the device, such as building, floor, room, or data center. | | **OS Version** | The version of the operating system currently running on the device. | | **HW EOS Date** | Hardware End of Support date, after which vendor support for hardware is no longer provided. | | **OS EOS Date** | Operating System End of Support date, after which support and updates for the OS are no longer available. | | **HW EOL Date** | Hardware End of Life date, indicating the hardware is no longer sold or officially supported. | | **OS EOL Date** | Operating System End of Life date, indicating the OS is retired and no longer maintained. | | **Date Data Last Collected** | The most recent date when inventory or device information was gathered from the device. | | **Device Type/Role** | The functional role of the device, such as router, switch, firewall, load balancer, or server. | | **Serial Number** | The manufacturer's unique identifier assigned to the device. | | **Firmware Version** | The version of firmware currently installed on the device. | | **Management IP** | The IP address used to manage, monitor, and access the device administratively. | Refer to the image for more information: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/wRxsV4fqnCmUYvaFopzc1_image.png) :::Paragraph{indent="1"} For details refer to [End of Life and End of Service Widgets](docId:-X9eDNuffy1FMkxUdXMqO) and [Network OS Insights Widgets](docId\:OIEHCA11JNHFXwWt7D4h4). ::: - [End of Life and End of Service Widgets](docId:-X9eDNuffy1FMkxUdXMqO): Ascertain an at-a-glance End of Life and End of Service status for network devices and operating systems. - [Network OS Insights Widgets](docId\:OIEHCA11JNHFXwWt7D4h4): Determine mission critical insights into OS hotspots by country and lifecycle status. - [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN): Understand the widgets available to you in Network & Edge. [title] Network & Edge [path] Services/Kyndryl Services/ [title] Cisco ACI Dashboard [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Dashboards/ Cisco ACI, or Cisco Application Centric Infrastructure, is a software-defined networking (SDN) solution specifically designed for data centers. It employs a policy-based approach to enhance security, performance, and scalability, meeting the demands of modern applications. This solution enables organizations to manage complex environments more effectively through network automation, which increases operational efficiency. Cisco ACI enables network infrastructure to be defined by policies, simplifying, optimizing, and accelerating the application deployment lifecycle. Cisco ACI consists of four dashboards that provide a comprehensive view of monitoring data center solutions. These dashboards include oversight of devices such as controllers and nodes (both spine and leaf nodes), as well as the management of logical sections like policies. To access the Cisco ACI dashboard, navigate to **Dashboards**, select **Network Management**, and then **Cisco ACI**. Alternatively, you can find the dashboard using the search bar under the **Insights** tab. # Technical prerequisites - CISCO ACI is deployed and accessible - Data Streaming service and SynApps setup with a topic # Cisco ACI landing page The Cisco ACI Home page offers an overview of all metrics. To access the dashboard, navigate to **Dashboards**, select **Network Management**, and then choose **Cisco ACI**. Alternatively, use the search bar under the **Insights **tab to find the dashboard. This section provides details about the most recent data load and the status of data processing. It also includes navigation links to other dashboards. From the available drop-down menu, you can select the customer name, site name, components, and IP address. ## Inventory The Inventory section displays the health status of both the DOMAINS and the FABRIC. **Domains: **The controller's availability status is displayed. The Application Policy Infrastructure Controller (APIC) is the main component of the Cisco ACI solution, serving as the central point for automation, management, policy enforcement, and health monitoring of the Cisco ACI fabric. **Fabric: **The health status of POD, SPINE, and LEAF components is classified as Healthy, Warning, or Critical. "Fabric" refers to the layout of computing, networking, and software elements in a data center, including device connections. A Pod consists of interconnected ACI leaf and spine switches managed by an APIC cluster. ## Alerts The Alerts section provides an overview of critical faults in Cisco ACI, including customer and site names, fault causes, and instance counts. You can export these details in raw or formatted format as needed. **APIC and POD Health Trends: **This section offers insights into APIC and POD Health Trends. - **CPU % Per Device:** The line graph displays timestamps on the X-axis and CPU usage per device on the Y-axis. You can hide or deselect the API, and the line graph will update accordingly. - **Memory % Per Device:** The line graph shows timestamps on the X-axis and Memory % per device on the Y-axis. You can hide the API, and the line graph will update accordingly. - **Storage Utilization % Per Device:** The line graph shows timestamps on the X-axis and storage utilization percentages for each device on the Y-axis. You can deselect or hide any APIC, and the graph will update in response. - **Health % Per Device:** The line graph shows timestamps on the X-axis and health percentages for each device on the Y-axis. Deselect any Pod or Spine to hide it and update the graph. Hover over a device for detailed information. ## Leaf and Spine Inventory Insight This section offers insights into the health of the CPU and memory. You can view the following metric details: - **Device Count Per CPU Health: **This bar chart shows the unique device count by CPU health, filtered to critical, warning, and healthy. You can also select any one of the filters (critical, warning, and wholesome) to visualize the data. - **Device Count Per Memory Health:** This bar chart provides a unique count of devices by memory health, filtered by the critical, warning, and healthy states. - **Device Count per Site: **This chart provides details on device counts per site. - **Cisco ACI - Landing Page - Leaf Spine Inventory:** This section provides insights into the Leaf Spine Inventory, including Site Name, role, In-Band Address, Mac Address, state, and more. You can export these details in raw or formatted options as needed. ## Tenants' Insight Displays an overview of tenants, including counts for tenants, VRFs, bridge domains, EPGs, and application profiles. - **Tenant Health Over Time:** This line graph displays the time stamp on the X-axis and tenant health on the Y-axis. - **Top 5 Tenant: **Displays the top 5 tenants for the account in the Pie chart. - **Tenant Status: **The Tenant status includes customer name, site name, count, and more. Use filters to retrieve specific information, and export details in raw or formatted formats as needed. # Cisco ACI faults The Cisco ACI Faults dashboard offers valuable insights into faults, their causes, and health trends. To access the dashboard, use the following navigation: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Dashboards** → select and then choose **Cisco ACI** followed by **Cisco ACI Faults**. The dashboard displays the latest data load and processing information, along with links to other dashboards. You can select the customer name, site name, cause, and severity from the available drop-down menus according to your specific needs. You can view the following metrics details: | **Dashboard Component** | **Description** | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Cisco ACI - Fault Details - Critical:** | The number of faults is displayed based on severity, with a focus on critical issues. | | **Cisco ACI - Fault Details - Major:** | Shows the number of faults categorized by severity level, specifically highlighting major issues. | | **Cisco ACI - Fault Details - Minor:** | The display shows the number of minor faults, categorized by severity. | | **Cisco ACI - Fault Details - Warning:** | Displays the number of faults categorized by warning severity. | | **Cisco ACI - Fault Details - Cleared:** | This section shows the number of faults that have been fixed or cleared. | | **Cisco ACI - Fault Details - Fault By Type:** | This pie chart shows details of faults categorized by type, including the number of faults and their corresponding percentages. | | **Cisco ACI - Fault Details - Fault By Cause:** | This pie chart shows fault details categorized by cause. You can see the quantity of faults per cause along with the corresponding fault percentage. | | **Cisco ACI - Fault Details - Fault Domain:** | This pie chart illustrates fault details categorized by fault domain, displaying the number of fault domains and their corresponding fault percentages. | | **Cisco ACI - Fault Details - Fault By Domain & Severity:** | This bar graph shows fault details by domain and severity, with domains on the X-axis and record counts on the Y-axis. Filters can also be applied for specific fault details. | | **Cisco ACI - Fault Details - Fault By Type & Severity:** | This pie chart displays fault details categorized by type and severity. You can also apply filters to view specific fault details. | | **Cisco ACI - Fault Details - Top Fault By Rule:** | This bar graph displays the top Fault by rule. The X-axis shows the count, and the Y-axis shows the Fault rule. | | **Cisco ACI - Fault Details - System Faults:** | This graph shows system faults by severity, with severity on the X-axis in descending order and count on the Y-axis. | | **Cisco ACI - Fault Details - Fault Overall Details:** | Provides overall fault details, including customer name, Severity, cause, and timestamp. You can also export the Fault overall details via the Export option, in raw or formatted format, as required. | # Cisco ACI tenant details The Cisco ACI Tenant Details dashboard provides clear information about managing the data center. It shows details about health trends and overall performance. To access the dashboard, use the following navigation: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Dashboards** → **Network Management** → **Cisco ACI **→ ** Tenant Details.** You can find information about the latest data load and data processing, along with links to other dashboards. From the available drop-down menu, you can select the customer name, site name, tenant, VRF, bridge domain, and EPG. The details will be displayed based on your filter selections. - **Customer name:** Provides the customer's name. - **Site name:** Provides details of the site. - **Tenant:** A tenant is a container for application policies that allows administrators to enforce domain-based access control. It isolates policies without indicating a private network and can represent customers, organizations, or group policies for convenience. - **VRF: **Virtual routing and forwarding (VRF) IP technology enables multiple independent routing tables within a single router, allowing overlapping IP addresses without conflict. - **Bridge Domain: **The Bridge Domain is a logical interface that enables bidirectional traffic flow within a Layer-2 network. - **EPG: **Endpoint Groups (EPGs) are logical entities that consist of a collection of endpoints with standardized policy requirements. - **Application Profile: **An application profile (AP) is a container for endpoint groups (EPG). - **Tenant Detail: **The Tenant Detail table offers an overview of the tenant, including Name, Health, VRF, EPG, and Bridge domain. You can export the data in RAW or FORMATTED format. # Cisco ACI Leaf and Spine Health Dashboard In Cisco ACI, the Spine-Leaf architecture enhances data center connectivity. The "spine" is a key component of this design. With a two-layer, full-mesh topology, the leaf layer connects access switches to servers and users, while the spine layer consists of routing switches at the core. This architecture reduces hop count and minimizes network latency, making it an efficient solution for data centers. The Spine-Leaf architecture offers several advantages: - Improved Redundancy - Increased Bandwidth - Improved Scalability - Lower Costs - Low Latency and Congestion Avoidance - Energy Efficient The Cisco ACI Leaf-Spine Health dashboard provides insights into controllers and nodes, including health trends, CPU usage, and memory utilization. To access the dashboard, use the following navigation: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Dashboards** → **Network Management** → **Cisco ACI **→ ** Cisco ACI-Leaf and Spine Health.** Access the latest data load information and other dashboards. Select customer name, site name, component, and IP address from the drop-down menu. # Fabric details The term **fabric** refers to the arrangement of computing, networking, and software components within a data center. It includes a network that connects devices such as access points, switches, and routers, enabling data to reach its intended destination. The **Fabric Current Details **section provides the current status of CPU and memory usage for both Spine and Leaf components. Below is a list of the available details in the Fabric Current section. | **Component** | **Description** | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Site name:** | Provides the site name. | | **APIC Health:** | Provides the APIC Health status. | | **APIC CPU Utilization:** | Provides the percentage of APIC CPU Utilization. | | **APIC Memory Utilization:** | Provides the percentage of APIC memory Utilization. | | **Cisco ACI Leaf Spine Health - Spine Health:** | This pie chart provides the leaf spine health (Critical/Warning/Healthy). | | **Spine CPU Utilization:** | This pie chart provides the spine CPU utilization percentage (Critical/Warning/Healthy). | | **Spine Memory Utilization:** | This pie chart provides the spine memory utilization percentage (Critical/Warning/Healthy). | | **Leaf Health:** | This pie chart provides the leaf health (Critical/Warning/Healthy). | | **Leaf CPU Utilization:** | This pie chart provides the percentage of leaf CPU utilization (Critical/Warning/Healthy). | | **Spine Memory Utilization:** | This pie chart provides the percentage of spine memory utilization (Critical/Warning/Healthy). | | **Fabric Overall Details:** | The Fabric Overall table provides a detailed view of the Fabric Overall. It includes Account Name, Site Name, Role, % CPU used, % memory used, etc. The search option is available. You can also export the table contents in RAW or FORMATTED format. | The **Fabric Historical Details** section provides insights into CPU performance, memory utilization, and the health status of the Spine and Leaf components. Below is a list of the details available in the **Fabric Historical **section. Additionally, you can customize the time range for all insights to fit your specific requirements. | **Component** | **Description** | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Spine And Leaf CPU Utilization Per Site:** | Provides the % CPU utilization per site. | | **Spine & Leaf Memory Utilization Per Site:** | Provides the % memory utilization per site. | | **Spine and Leaf CPU Utilization Per Device:** | This line graph provides the % of Spine and Leaf CPU utilization per device on the Y-axis and the timestamp on the X-axis. | | **Spine and Leaf Memory Utilization Per Device:** | This line graph provides the % of Spine and Leaf memory utilization per device on the Y-axis and the timestamp on the X-axis. | | **Device Count Per CPU Health:** | Provides the number of devices based on the CPU health status (Critical/Warning/Healthy). | | **Device Count Per Memory Health:** | Provides the number of devices based on the memory health status (Critical/Warning/Healthy). | | **Overall Spine & Leaf CPU Health:** | This line graph shows % CPU utilization on the Y-axis and timestamps on the X-axis. | | **Overall Spine & Leaf Memory Health:** | This line graph shows % memory utilization on the Y-axis and timestamps on the X-axis. | | **Fabric Overall Details:** | The Fabric Overall table provides a detailed view of the Fabric Overall. It includes Account Name, Site Name, Tenant Health, % CPU used, % memory used, etc. The search option is available. You can also export the table contents in RAW or FORMATTED format. | [title] Network-and-Edge-Composition [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/ [title] Network OS Insights Widgets [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Service components/ Kyndryl supports two widgets that report critical insights into network device operating systems: - **Top 5 Countries Network OS: **Number of network device operating systems by country limited to the five largest volume by number. - **Top 5 Lifecycle Statuses Network OS:** Number of network device operating systems by lifecycle status limited to the five largest volumes by number. :::hint{type="info"} These widgets provide at-a-glance visibility of device operating systems regarding location and lifecycle status. A **View details** link navigates to the Inventory Overview. There you can view statistical details that breakdown OS locations lifecycle status for your IT estate inventory. ::: # Supported Vendors Kyndryl supports all models from the following vendors for all EOL and EOS widgets: - Cisco - F5 - Checkpoint - Fortinet - Palo Alto # Pre-requisites The following items are prerequisite to view and add widgets: - Access to OU - Access to in - Network inventory available in the inventory service, with vendor, model, and populated EOL metadata. - EOL/EOS consolidated dashboard available with filtering for Category = network. - You must have Administrator privilege to add widgets to the landing page dashboard and to edit them. # Configuration Perform the following procedure to configure the landing page dashboard: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. 2. Confirm the network landing page includes the EOL and EOS widgets. 3. Add or edit widgets through the dashboard designer. 4. Place the widget at the primary grid size, then adjust for other screen sizes. # OS Insights widgets ## Access and use Use the following procedure to access and exercise the EOL and EOS summary widgets: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. 2. Locate the EOL widget showing lifecycle segments in a donut chart. 3. Hover over chart segments to view counts and percentages. 4. Click View Details to navigate to the EOL/EOS Insights page. 5. Toggle between donut chart and list data (per widget). 6. Maximize individual widgets one at a time. 7. Download data or graphic in the following formats: - CSV - PNG - JPG ## Inventory Overview The Inventory Overview page is available from the **View Details **link located at the bottom right of each widget. The page contains the following elements: - Filter array: Filter data using fields such as Customer name, lifecycle status, and Device. - Summary data array: - All Records - Records in PRODUCTION - Servers - Storage - Network - Unique Assembly Countries - **Top 5 Item Classes:** Types of network hardware such as network devices, servers and storage devices, the five largest by number. - **Top 5 Lifecycle Statuses Top 5 Item Classes:** Types of network hardware such as network devices, servers and storage devices, the five largest by number. - **Top 5 Lifecycle Statuses:** Number of network device operating systems by lifecycle status limited to the five largest volumes by number. - **End of Life/End of Support:** Number of devices that have either reached EOL/EOS or will in less than a year or will in less than 2 years. - **Top 5 Subcategories:** Within network devices, the numbers of network device types such as rack server, blade server, or Windows, the five largest by number. - **Top 5 Countries:** Device locations by country, the largest five by number. - **Top 5 Assembly Country:** Device countries of origin, the five largest by number. - **Individual Inventory Records:** Device details table. # Troubleshooting Use the following guide to ensure your data is visible and correct: - If data is missing, confirm EOL metadata is included in the inventory service. - If the widget is not visible, confirm user permissions and page configuration. - [Network Utilization Dashboard](docId\:aSdcEW1d9-CYfPpyRyaDQ) The **Utilization Dashboard** provides detailed insights into CPU and Memory usage for network devices over a selected time period. It enables users to monitor performance trends, identify anomalies, and take proactive action. [title] Monitoring - Inventory [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/Network Performance Monitoring/ The **Monitoring - Inventory** page presents statistical data regarding your network inventory. The data presents a basic summary of your physical network devices. In addition to data visualizations, the page provides a global filter to enable the narrowing of data without complex queries. Parameters include the following: - **Customer Name:** Devices owned by specific customers. - **GSMA Code:** Devices associated with a specific GSMA code. - **Data Source: **Any supported data source used to track network devices and operating systems. Each parameter allows a boolean **Include/Exclude** option: - Click **Include** to limit the result to include your selection. - Click **Exclude** to limit the result to exclude your selection. Hover over the right upper corner to to present the display options icon (elipsis). The following display options for the visualization are supported: - **Settings: **Apply a custom time range or other options. - **Inspect: **Download a report. - **Maximize:** Enlarge the visualization to see more information. The control toggles to Minimize. # Data visualization The page presents the following data visualizations: **Inventory summary** | **Metric / Visualization** | **Description** | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Total Monitored Nodes** | The total monitored node count. | | **Total Monitored Interfaces** | The total monitored interface count. | | **Nodes Type** | A donut chart showing the percentage distribution of node types. Node types are grouped into categories (such as network switches and servers) and represented using color coding, with a legend/key for reference. | | **Nodes by Vendor** | A donut chart showing the percentage distribution of nodes by vendor. | | **Interface Type** | A donut chart showing the percentage distribution of interface types. | | **Nodes Datasource** | A bar chart showing the count of devices by datasource, such as SNMP and Ping ICMP. | | **Interfaces Datasource** | A bar chart showing the count of devices by datasource, such as SNMP. | | **Inventory Summary** | A tabular summary of network devices, including identifying details and current status. | Refer to the following image for more details: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/dYJmI0OJvqh_ACsLN6MT6_upload.jpeg) [title] Access Managed Network Services Reports in Kyndryl Bridge [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Untitled/ # Prerequisites - Ensure that you have access to . - Ensure that you have a subscription to the **Managed Network bundle** to access in Kyndryl . - Ensure that you have a subscription to the **KMNS Service Catalog** in .to access the KMNS home page. # Request access through ARMS If you do not have the required permissions, submit an access request through ARMS. ## Submit an access request 1. Open the [ARMS portal](https://bat.bats.kyndryl.net/arms2/) 2. Select **Request AIOps Access Groups**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/FeFxOGrtyMuF8bEZEni4i_image.png" size="80" isUploading="false" width="1070" height="481" darkWidth="1070" darkHeight="481" showCaption="false"} 3. For **OU Type**, select **Account**. 4. In **OU's**, enter the account name. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/n63Nywh1O7RHDRBWbcoDv_image.png" size="80" isUploading="false" width="894" height="471" darkWidth="894" darkHeight="471" showCaption="false"} 5. Choose one of the following options: - **Standard Request** to request the default access package. - **Advanced Request** to manually select Network Dashboard access. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/RikmITYjVSJVLJ5H-I1Ku_image.png" size="80" isUploading="false" width="901" height="594" darkWidth="901" darkHeight="594" showCaption="false"} :::hint{type="info"} Access requests must be approved by the appropriate DPE. If approval is delayed or access is required urgently, contact the responsible DPE for assistance. ::: # Subscribe to the KMNS service catalog Subscribe to the KMNS service catalog if the option is not available in Kyndryl Bridge. **Recommended subscribers** The recommended subscribers include: - Users assigned Administrator - Kyndryl Account Manager - Kyndryl Delivery Team - DPE - CPE - CollabDrive Administrator - GTM Experience Administrator :::hint{type="info"} Users with **Viewer **access generally do not need to subscribe unless they require proactive notifications or visibility into platform updates. ::: ## Submit a Subscription Request 1. Open [Kyndryl Bridge](https://www.kyndryl.com/bridge/console/) ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/D8NeEImU3j_RS_KyPHNpQ_image.png" size="90" isUploading="false" width="741" height="394" darkWidth="741" darkHeight="394" showCaption="false"} 2. Select **Bridge Service Catalog**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/VdR5n_Y4XKHQ3z99v69lT_image.png" size="80" isUploading="false" width="740" height="531" darkWidth="740" darkHeight="531" showCaption="false"} 3. In the search box, enter . ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/eQNVBU8XXRqCvEwUKUbPj_image.png" size="80" isUploading="false" width="766" height="452" darkWidth="766" darkHeight="452" showCaption="false"} 4. Select **Kyndryl**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/0kEU9RauVnGQvJJ-beZmn_image.png" size="80" isUploading="false" width="737" height="413" darkWidth="737" darkHeight="413" showCaption="false"} 5. Select **Submit Request**. :::hint{type="success"} After the request is approved and the subscription is enabled, KMNS features become available in . If the **Submit Request** button is unavailable, the service is already subscribed for your account. ::: # Subscription Activation Process The following are the steps to be followed for activating the subscription requests: 1. Log in to . 2. Navigate to **Administration**. 3. Open **Bridge Access Management**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/omxDt68OooVwR1KgmYt0L_upload.png" size="80" width="673" height="365" isUploading="false" darkWidth="673" darkHeight="365" showCaption="false"} 4. Check your **Access Groups**. 5. Confirm that you have the required Account Manager/DP role assigned. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/I3IKe3yOrVBxJx6ChPKOB_upload.png" size="80" width="752" height="376" isUploading="false" darkWidth="752" darkHeight="376" showCaption="false"} 6. Open the left-side hamburger menu. 7. Select **Console**. 8. Navigate to **Bridge Home**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/rquP0Smf9aaLvw7tCbLQ4_upload.png" size="80" width="752" height="390" isUploading="false" darkWidth="752" darkHeight="390" showCaption="false"} 9. In the left navigation pane, select **Subscriptions**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/lPsV_SQgdj9ZeaUPFZLXY_upload.png" size="80" width="752" height="393" isUploading="false" darkWidth="752" darkHeight="393" showCaption="false"} 10. Find the subscription request that is in **Validating** state. 11. Click the **three dots (ellipsis)** next to the subscription request. 12. Select **Review Request**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ABqtWv-9NvBk90uGNtFZ__image.png" size="80" isUploading="false" width="940" height="501" darkWidth="940" darkHeight="501" showCaption="false"} 13. Review the subscription request details by clicking **Review Request** button. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/GmQhxSyYIUdOs0V5w8R4E_upload.png" size="80" width="752" height="324" isUploading="false" darkWidth="752" darkHeight="324" showCaption="false"} 14. Set the **Start Date** as required. 15. Set the **Expiry Date** based on the desired subscription duration (for example, end of the year or one year from activation). 16. In the comments section, enter **Approved.** ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/OR9kB0rrgwMEh_m1AFSyb_upload.png" size="80" width="753" height="389" isUploading="false" darkWidth="753" darkHeight="389" showCaption="false"} 17. **Submit** the request. 18. After submission, the subscription status should change to **Activating**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/PpXmvWWKlo5puKAxsRAY2_image.png" size="80" isUploading="false" width="940" height="426" darkWidth="940" darkHeight="426" showCaption="false"} 19. Wait a few minutes for the process to complete. 20. Refresh the Subscriptions page and verify that the subscription becomes **Active**. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ouNKMSvFOfTONC_ZiSx0O_image.png" size="80" isUploading="false" width="940" height="427" darkWidth="940" darkHeight="427" showCaption="false"} :::hint{type="success"} After successful activation of the subscription: 1. Subscription status changes from **Validating** → **Activating** → **Active**. 2. KMNS-related screens become available in Kyndryl Bridge. 3. Users gain access to the new dashboards and capabilities associated with the subscription. ::: [title] Risk Insight dashboard [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/ This dashboard helps spot risks early and take action faster by combining performance, health, and risk insights in one view. Risk Insights within the framework are Level 3 correlation indicators that provide early warnings and actionable intelligence by combining operational performance, control of health and risk signals. The model is built on three levels: KPIs measure process performance, KCIs assess control effectiveness and KRIs deliver strategic risk views. Together, these insights translate complex data into scenario‑based intelligence, enabling leaders to identify emerging risks and take proactive action before issues materialize. Users can access the Risk Insights Dashboard from by following these steps: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → **** → **Risk Insights**. # Configuration Drift Risk Index (CDRI) The Configuration Drift Risk Index (CDRI) dashboard highlights critical configuration risks and recommends immediate escalation actions to reduce potential impact. The following three sections are displayed on this dashboard: ## Key Risk Indicators The following** Key Risk Indicators** are displayed to users: - **Total Risk Score: **Risk scores show the percentage level of risk detected. - **CHI (Compliance Health Index):** It is calculated as the average of the organization’s Compliance Posture and Depth View scores. - **NCR (Non-Compliance Risk): **Measures the proportion of assets that do not meet defined compliance requirements. - **SCE (Scan Coverage Effectiveness): **Measures how thoroughly security scans cover the organization’s identified assets. ## Weightage Considered Graph The **Weighting Considered** graph illustrates how each key indicator is weighted to calculate the overall risk score. ## Level 1 indicators The **Level 1 Indicators** table on the right side of the graph enables users to analyze the following: - **Indicator Name:** Identifies the specific metric used to track compliance, risk, or asset coverage within the environment. The following categories are available: - Overall Compliance Posture - Non-Compliant Asset Count - Compliance Depth View - Scan Coverage Adherence - Total Managed Assets - **Value: **Represents the quantitative measurement associated with the indicator, expressed as a percentage or numeric count. - **Compliance Posture:** Indicates the classification used to group the indicator value into predefined compliance categories for improved visibility and prioritization. # Internet-Facing Exposure Risk Index (IFERI) The Internet‑Facing Exposure Risk Index (IFERI) dashboard indicates a high‑risk condition, requiring remediation within 30 days to reduce exposure. The following three sections are displayed on this dashboard: ## Key Risk Indicators The following **Key Risk Indicators** are displayed to users: - **Total Risk Score:** Risk scores are categorized into four severity levels to guide prioritization and response actions. - **ICI (Internet-Facing Compliance Index): **Compliance level of internet exposed assets. - **IFVR (Internet-Facing Vulnerability Risk):** Risk from vulnerabilities on internet exposed assets. - **IFPG (Internet-Facing Patch Gap):** Missing security patches on internet exposed assets. ## Weightage Considered The **Weighting Considered** graph illustrates how each key indicator is weighted to calculate the overall risk score. ## Level 1 indicators The **Level 1 Indicators** table on the right side of the graph summarizes the organization’s overall compliance status and enables users to analyze the following: - **Indicator Name:** Identifies the specific metric used to track compliance, risk, or asset coverage within the environment. The following categories are available: - Internet Facing Assets - Internet Facing Non-Compliant Assets - Internet Facing Vulnerable Assets - Internet Facing Unpatched Critical Assets - Total Internet Facing Compliant Assets - **Value: **Represents the quantitative measurement associated with the indicator, expressed as a percentage or numeric count. - **Compliance Posture: **Indicates the classification used to group the indicator value into predefined compliance categories for improved visibility and prioritization. # Vulnerability Exposure Index (VEI) The Vulnerability Exposure Index (VEI) dashboard indicates a low‑risk condition. Ongoing monitoring is recommended on a quarterly basis. The following three sections are displayed on this dashboard: ## Key Risk Indicators The following **Key Risk Indicators** are displayed to users: - **Total Risk Score: **Risk scores are categorized into four severity levels to guide prioritization and response actions. - **VSI (Vulnerability Severity Index): **Overall severity of identified vulnerabilities - **KEVR (Known Exploited Vulnerability Risk):** Risk from vulnerabilities that are actively exploited. - **SCG (Scan Coverage Gap): **Difference between expected and actual scan coverage. - **RLI (Remediation Lag Index):** Time delay between detection and remediation. ## Weightage Considered The **Weighting Considered** graph illustrates how each key indicator is weighted to calculate the overall risk score. ## Level 1 indicators The **Level 1 Indicators** table on the right side of the graph summarizes the organization’s overall compliance status and enables users to analyze the following: - **Indicator Name:** Identifies the specific metric used to track compliance, risk, or asset coverage within the environment. The following categories are available: - KEVs - Vulnerabilities Per Scan - Oldest Critical - Unscanned Assets - Critical - **Value:** Represents the quantitative measurement associated with the indicator, expressed as a percentage or numeric count. - **Compliance Posture: **Indicates the classification used to group the indicator value into predefined compliance categories for improved visibility and prioritization. # Patch Management Effectiveness Index (PMEI) The Patch Management Effectiveness Index (PMEI) dashboard indicates a medium‑risk condition, with remediation recommended within 60 days. The following three sections are displayed on this dashboard: ## Key Risk Indicators The following **Key Risk Indicators** are displayed to users: - **Total Risk Score: **Risk scores are categorized into four severity levels to guide prioritization and response actions - **PSCI (Patch SLA Compliance Index):** Measures how consistently patches are applied within defined SLA timelines. - **CPBR (Critical Patch Backlog Risk):** Indicates the volume of critical patches that remain unapplied over time. - **PLDL (Patch Deployment Lag):** Measures the average delay between patch release and deployment. - **PSE (Patch Sucess Effectiveness):** Indicates how successfully patches are deployed without errors or rollbacks. ## Weightage Considered The **Weighting Considered** graph illustrates how each key indicator is weighted to calculate the overall risk score. ## Level 1 indicators The **Level 1 Indicators** table on the right side of the graph summarizes the organization’s overall compliance status and enables users to analyze the following: - **Indicator Name:** Identifies the specific metric used to track compliance, risk or asset coverage within the environment. The following categories are available: - Average Time to Patch ( MTTP) - Patch Backlog - Low - Patch Backlog - Medium - Patch Backlog - High - Patch Backlog - Critical - **Value:** Represents the quantitative measurement associated with the indicator, expressed as a percentage or numeric count. - **Compliance Posture:** Indicates the classification used to group the indicator value into predefined compliance categories for visibility and prioritization. # Asset Lifecycle Risk Score (ALRS) The Asset Lifecycle Risk Score (ALRS) dashboard indicates a critical risk condition, requiring immediate escalation to mitigate potential impact. The following three sections are displayed on this dashboard: ## Key Risk Indicators The following **Key Risk Indicators** are displayed to users: - **Total Risk Score: **Risk scores are categorized into four severity levels to guide prioritization and response actions - **EAP (EOL/EOS Asset Prevalence):** Indicates the proportion of assets that have reached end‑of‑life (EOL) or end‑of‑support (EOS). - **BCER (Business-Critical EOL Risk):** Measures the risk posed by EOL or EOS assets that support business‑critical services. - **IFEE (Internet-Facing EOL Exposure):** Indicates the exposure risk of internet‑facing assets that are at EOL or EOS. - **RUI (Remediation Urgency Index):** Reflects how urgent remediation actions are required based on risk severity and exposure. ## Weightage Considered The Weighting Considered graph illustrates how each key indicator is weighted to calculate the overall risk score. ## Level 1 indicators Summarizes the organization’s overall compliance status. Level indicators offer comprehensive information regarding: - **Indicator Name:** Identifies the specific metric used to track compliance, risk or asset coverage within the environment. The following categories are available: - Total EOL/EOS Assets - Software EOL Percentage - Hardware EOL Count - Hardware EOS Count - Average Age of EOL Assets - **Value:** Represents the quantitative measurement associated with the indicator, expressed as a percentage or numeric count. - **Compliance Posture:** Indicates the classification used to group the indicator value into predefined compliance categories for improved visibility and prioritization. [title] Network Performance Monitoring [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Performance monitoring pages/ # Network Performance Monitoring When filtering by **Node Down**, **Critical**, or **Warning**, the **Node Summary** view in the **Monitor** tab does not display the timestamp associated with the alert. Adding a timestamp to this view would improve visibility into when the alert was generated, enabling teams to quickly distinguish between active and resolved issues. This enhancement would help reduce unnecessary investigations, minimize warning fatigue, and improve overall operational efficiency. Use the following procedure to navigate to the dashboard: 1. You can access the Network Performance Monitoring dashboard by navigating to **Dashboards → Network Management →Network Performance Monitoring.** 2. Alternatively, you can use the search bar under the Insights tab to find the dashboard. Network monitoring is a set of the following six dashboards. The dashboard filter currently supports the following parameters: - **Data Source** – defaults to Zabbix. Learn more - [Zabbix Multi-Instance Onboarding](docId\:wHQpLC-izesMliZDFGHdW) - **Time Range**– defaults to Last 30 minutes. ## Network performance monitoring composition ### Technical and non-technical prerequisites ### Technical prerequisites - Node Availability (%) measures the proportion of time a node was operational and reachable. It is determined by dividing the number of successful health checks (Up state) by the total number of valid monitoring checks (Up and Down states) and expressing the result as a percentage. - Monitoring System (SolarWinds, Zabbix) deployed and accessible - Data Streaming service and Synapps setup with a topic - Network performance metrics for devices monitored by Zabbix to be visualized in NPM dashboards require below tags configured 1. Host tags with name “DeviceClass” and value “network. 2. Item tags, these tags are part of templates “KD Interfaces by SNMP” and “KD Generic by SNMP”. ::::hint{type="info"} :::Paragraph{indent="1"} **Note:** If these templates are not preconfigured for devices, complete the manual setup on each device before proceeding. ::: :::: | **Item Keys** | **Item Tags** | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | net.if.out\[ | component: interface
metric: intf\_tx\_bits | | net.if.out.discards | component: interface
metric: intf\_out\_discards | | net.if.out.errors | component: interface
metric: intf\_out\_errors | | net.if.in | component: interface
metric: intf\_rx\_bits | | net.if.in.discards | component: interface
metric: intf\_in\_discards | | net.if.in.errors | component: interface
metric: intf\_in\_errors | | memory.util | component: memory
metric: memory\_util | | cpu.util | component: cpu
metric: cpu\_util | | fs.used | component: disk
metric: disk\_used | | volume.utilization | component: disk
metric: disk\_util | | fs.free | component: disk
metric: disk\_free | | fs.total | component: disk
metric: disk\_total | | system.hw\.uptime | component: uptime
metric: hw\_uptime | | system.net.uptime | component: uptime
metric: nw\_uptime | | system.location | component: system
metric: sys\_location | | system.name | component: system
metric: sys\_name | | zabbix\[host,snmp,available] | component: snmp
metric: snmp\_agent\_availability | | system.descr | component: system
metric: sys\_description | | cisco.nexus.hsrp.active.router | component: hsrp
metric: hsrp\_active\_router | | cisco.nexus.hsrp.standby.router | component: hsrp
metric: hsrp\_standby\_router | | cisco.nexus.hsrp.state | component: hsrp,
metric: hsrp\_state | | BGP | component: bgp, metric\:admin\_state,peer\_state,fsm\_state,prefix\_accepted,
prefix\_denied,prefix\_advertised,prefix\_suppressed,
prefix\_withdrawn,routes\_in,routes\_out,updates\_in,
updates\_out component\:ospf metric\:ospf\_down | | net.if.speed\[ | componet\:interface,
metric: interface\_speed | | net.if.status\[ifOperStatus | componet\:interface,
metric: intf\_oper\_status | | net.if.type\[ | componet\:interface,
metric: intf\_type | | icmpping | component: icmp,
metric: icmp\_ping | | icmppingloss | component: icmp,
metric: icmp\_loss
component: packet,
metric: packet\_loss | | net.if.name | componet\:interface,
metric: intf\_name | The dashboard comprises the following elements: - **Global Filter:** Select from a dropdown list of filtering options accompanied by operators and parameters. - **Range Filter:** Select from a range of time spans bounded by **Today** and **Last Year** (the last 12 months). - **Dashboard Segment Title:** The dashboard dispays six tabs, each of which navigates to a separate dashboard displaying different data: - [Monitoring - Home](docId\:ZYwjALpP6CERyt-nTzNDF) (default): Device Status and Inventory :::Paragraph{indent="3"} Acquire a basic understanding of the data presented on the Monitoring - Home page. ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - Inventory](docId\:zwR3W-duzKcaWc2HGChId): Inventory Summary ::: :::Paragraph{indent="3"} Acquire a basic understanding of the data presented on the Monitoring - Inventory page. ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - Events](docId\:QaAufbF6V_fSAUWPrj0UF): Events Summary ::: :::Paragraph{indent="3"} Acquire a basic understanding of the data presented on the Monitoring - Events page. ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - KPI Utilization](docId\:zo1rYEzJv0ogUu2LqiWGT): KPI Summary ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - Enhance KPI](docId\:GBWKalz2zMdWLQnYcivnL): Node status ::: :::Paragraph{indent="3"} Acquire a basic understanding of the data presented on the Monitoring - Enhance KPI page. ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - KPI Trends](docId\:d0cPFY9JsVIngHpmkxgqW): Trends in captured KPIs ::: :::Paragraph{listStyleType="disc" indent="2"} [Monitoring - Reports](docId:8I0LCSRT59s1ILJKRH9id) ::: ## Global filter The global filter enables you to narrow the observable data set, limiting it to only data necessary to your circumstance. The filter is located directly below header indicating the selected tab for the dashboard segment, for example Inventory Overview (Monitoring - Inventory). The filter comprises two buttons: - Filter control (grounding icon): - Add filter: Add a filter element. - Apply to all\:Apply the filter to the data set. - Clear all: Clear all applied filters, restoring the default data set. - Add filter (plus icon): Add a filter element. Use the following procedure to specify the time range for the current data set by time range and other parameters: 1. Select a time range. The default time range is **Last 7 days**. If no changes have occurred in the default or selected date range, data visualizations will not populate. To change the current date range, use the following procedure: - Click the calendar icon. The service displays the quick select dialog, presenting a range field that you can manually set and a list of preselected options. - From the units field dropdown menu, which defaults to **7 Days ago**, select the unit, **Days**, **Weeks**, **Months**, **Years**. Set the quantity by entering, incrementing, or decrementing the unit quantity. For example, select **Months**, then decrement **7** to **6** to change the value from **7 days ago** to **Last 6 months**. - Click **Apply**. The service updates the data for the selected date range. :::hint{type="info" indent="3"} Note: The default time range, **7 Days ago**, applies initially to all three dashboards; adjust each as needed. ::: 2. Click the **Plus** icon. The service presents the filter editor. 3. Select a field from the **Select a field** dropdown menu. You can select from any supported field in the network device or operating system record. 4. Select an operator from **Select operator** field: - **is**: Equal to - **is not**: Not equal to - **is one of**: Some fields might have more than one value. This operator specifies a specific value in such a field. - **is not one of**: Some fields might have more than one value. This operator specifies that none of the values exist in such a field. - **exists**: Any device or operating system description that contains the specified field. - **does not exist**: Any device or operating system description that does not contain the specified field. 5. Select a value from the **Select a value** field. 6. **Optional:** Add a an additional parameter by selecting boolean **OR** or Boolean **AND**: - Repeat steps 2 through 4. - **Optional:** Repeat step 5. 7. Click **Cancel** to cancel the filter addition or **Add filter** to add the filter you constructed. :::hint{type="info"} Note: You may add additional filters as required to adequately narrow your data set. You can also edit a constructed filter as a Domain Specific Language query by clicking the **Edit as Query DSL** link located at the far right of the **Add filter** editor. ::: ## Performance monitoring pages The following are the various performance manitoring pages: - [Monitoring - Home](docId\:ZYwjALpP6CERyt-nTzNDF) Acquire a basic understanding of the data presented on the Monitoring - Home page. - [Monitoring - Inventory](docId\:zwR3W-duzKcaWc2HGChId) Acquire a basic understanding of the data presented on the Monitoring - Inventory page. - [Monitoring - Events](docId\:QaAufbF6V_fSAUWPrj0UF) Acquire a basic understanding of the data presented on the Monitoring - Events page. - [Monitoring - KPI Utilization](docId\:zo1rYEzJv0ogUu2LqiWGT) Acquire a basic understanding of the data presented on the Monitoring - KPI Utilization page. - [Monitoring - Enhance KPI](docId\:GBWKalz2zMdWLQnYcivnL) Acquire a basic understanding of the data presented on the Monitoring - Enhance KPI page. - [Monitoring - KPI Trends](docId\:d0cPFY9JsVIngHpmkxgqW) Acquire a basic understanding of the data presented on the Monitoring - KPI Trends page. - [Monitoring - Reports](docId:8I0LCSRT59s1ILJKRH9id) The Reports dashboard displays detailed insights into Node and Interface utilization and availability. You can access this dashboard by navigating to **Dashboards > Network Management > Network Performance Monitoring > Report** [title] Control-Overview [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/ [title] User onboarding [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/ After subscribing to the dashboard, user onboarding is required to gain access to the console. This step ensures that the right individuals have the necessary permissions to view and manage compliance data. Onboarding helps maintain security, proper governance and role-based access control for your organization. To access the dashboard from , you can sign up or register as an individual user or as a user on a customer account. - If you choose to sign up as an individual user, you will get a personal account. - If you need to sign up for a Customer Account, contact your Kyndryl account focal. The Kyndryl Delivery/Account team will invite you to the specific customer account. # New user sign-up If you are new to , complete the following steps to create an account and subscribe to the service: 1. Sign up for a account using either: - The standard registration process or a customer-specific registration link provided by Kyndryl. 2. Enter your corporate email address, first name, last name and country code. 3. Review and accept the consent agreement, then click **Sign Up**. 4. On the next page, enter the password associated with the corporate email address you provided. 5. Check your email inbox for the Kyndryl account activation message, then click **Activate Kyndryl ID Account**. After activation, you are redirected to the Kyndryl Bridge home page. 6. Configure your preferred **multi-factor authentication (MFA)** method. If you prefer to set it up later, select **Set Up Later**. 7. Open the **Bridge Service Catalog**. 8. Search for 9. Select the service and click **Subscribe**. 10. Complete any additional prompts required to confirm your subscription. After the subscription is approved, the dashboard becomes available from the **Services **menu, where you can begin monitoring controls, compliance status and cybersecurity risks across your environment. # Existing user sign in For existing users, signing in is required every time you access your account: 1. Go to the **** home page. 2. Click the **Sign-In **dropdown menu at the top right corner. 3. Select the **Login** option from the list and enter your company email ID. 4. Click **Next**. 5. Enter the password associated with your email account and click **Verify**. 6. Authenticate the account using your preferred two-factor authentication method. You will now be redirected to the home page. 7. Navigate the on your browser or application. 8. Search for the service. 9. Click the **Subscribe** button to subscribe to the service. 10. Follow any additional prompts to confirm your subscription. 11. Once subscribed, you will find the dashboard available under the **Services** to choose from. [title] Overview [path] Services/Kyndryl Services/Security & Resiliency/Continuous Controls Monitoring & Management/ provides centralized visibility into the effectiveness of security, compliance, operational, and technology controls across your environment. Through a collection of dashboards, metrics and risk indicators, the service enables organizations to continuously monitor control performance, identify compliance gaps, track remediation efforts and maintain a stronger security and governance posture. enables organizations to assess their security posture, identify control gaps and track compliance performance through a centralized dashboard experience. The service helps security, compliance, and operations teams make informed decisions, prioritize remediation efforts and improve cyber resilience through data-driven insights. To access CCMM, from the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → ****. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/eqt7mPTsiZWzqPmY8NoUI_image.png) helps users: - Detect compliance gaps and security risks earlier. - Improve governance through continuous monitoring. - Prioritize remediation activities based on measurable data. - Increase visibility into operational and security performance. - Support regulatory, audit, and cybersecurity requirements. - Make faster, data-driven decisions to improve resilience and reduce risk. # Key concepts | **Concept** | **Description** | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Controls** | Security, operational, or compliance measures used to reduce risk and protect organizational assets. | | **Control Monitoring** | The continuous evaluation of controls to verify they remain effective and compliant. | | **Risk Assessment** | The process of evaluating cybersecurity risks and their potential impact on the organization. | | **Compliance Frameworks** | Industry standards and regulations used to evaluate and measure control effectiveness, such as NIST CSF. | | **KPIs and Metrics** | Dashboard measurements used to monitor control performance, vulnerabilities, compliance status, and operational trends. | # Subscribing to Dashboard To access the dashboard in , a subscription is required. Subscribing ensures that your organization can continuously monitor security controls, identify compliance gaps, and take proactive measures to reduce risk. By subscribing to the dashboard, users gain real-time visibility into control performance and compliance status. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Catalogs** → **** → **Security and Resiliency category **→ **Kyndryl **. 1. Under **Select a Service**, click **Submit Request**. The admin receives a notification to onboard the service for a specific account. [title] Device Inventory Onboarding Support and Troubleshooting Guide [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Other resources / This document describes how to upload inventory and provides an overview of general troubleshooting tips and support procedures for the device inventory onboarding service. ## Onboarding inventory assets The following items are prerequisite to onboarding inventory assets: - When the inventory file is uploaded to Netbox, each device should be set to its default status. Netbox supported statuses include the following: - Offline - Planned - Active - Stage Failed - Inventory - Network-admin role in ARMS or Ensure a tenant has been created in Netbox. If not, create a tenant with the correct GSMA code and bacid. - The upload limit is 5,000 devices at a time - Inventory input is converted to lower case except manufacturer and model. The manufacturer and model is entered exactly as it exists in the Inventory Catalog. - Upon onboarding, devices not using IPv4 or IPv6 will be updated. - The discovery rule enables Zabbix to validate submitted IP addresses against discovered IP addresses. ## Post onboarding: IP validation Kyndryl supports validation of submitted device IP addresses. After devices are onboarded, administrators can run a validation check using defined validation rules. Add a validation rule using the following procedure. 1. Log into Bridge. 2. Click the Hamburger menu located in the upper left corner of the header and select --> 3. Hover over Home and select --> Inventory Onboarding. The service navigates to the Device Inventory Onboarding page: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/pQMTHt-exxRgeHaiRAANN_image.png) 4. Click the **Connectivity Check **tab: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/DgOw_W6UnYFhoP0ugNY7Y_image.png) [title] Supported Widgets [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Service components/ # Prerequisites for supported widgets 1. Access to landing page widgets requires appropriate ARMS permissions. Ensure the following permissions are assigned to the user: - bundle-inventory-management - bundle-network-management - inventory-viewer - network-viewer - aiops-viewer 2. Account has to be subscribed to have **Kyndryl Managed Network Services (KMNS)** **Catalog Service.** 3. To subscribe for the **Catalog Service,** follow these steps: 1. Launch **Kyndryl Bridge**. 2. From the navigation menu, click **Catalogs > Bridge Service Catalog **as shown in the image below: ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/BY1KBtidFEj7-KVz9duRL_image.png" size="70" isUploading="false" width="878" height="415" darkWidth="878" darkHeight="415" showCaption="false"} :::Paragraph{listStyleType="decimal" listStart="3" listRestartPolite="3" indent="2"} On the loaded page, select **Network and Edge**. ::: :::Paragraph{listStyleType="decimal" listStart="4" indent="2"} Click **View All** to display all the available services. ::: :::Paragraph{listStyleType="decimal" listStart="5" indent="2"} Select **Kyndryl Managed Network Services**. ::: ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/Jugl9ygaC115Bn24USW_-_image.png" size="30" isUploading="false" width="362" height="363" darkWidth="362" darkHeight="363" position="center" showCaption="false"} :::Paragraph{listStyleType="decimal" listStart="6" listRestartPolite="6" indent="2"} The **Kyndryl Managed Network Services Overview** [page opens](https://www.kyndryl.com/bridge/catalog/kyndryl-managed-network-services/overview). ::: :::hint{type="info"} For detailed subscription instructions, refer to the [Subscriptions ](https://docs.kyndryl.com/subscriptions#subscribe-to-a-service)documentation: ::: :::hint{type="info"} Without these permissions, users may not be able to view or interact with the corresponding **KMNS** widgets. ::: # F1 dashboard widgets The F1 dashboard widgets are displayed on the Console landing page. To navigate to Console page: 1. Launch **Kyndryl Bridge**. 2. From the navigation menu, click **Console > Bridge Home.** Widgets are available within the **My Dashboard **tab, which serves as the default bridge console upon login. This section allows users to personalize their workspace based on their roles and preferences by selecting, arranging, and saving widgets as needed. Users can add widgets by clicking the **Add widgets** icon :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/4H8zhzM9-aUFl9cR181JX_widget-add.svg" alt caption width="57" height="57"} opening the Widgets panel, and dragging the required widgets onto the dashboard canvas. The selected layout and configurations are saved automatically for future sessions. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/c5dqHXBBfHQf4ERq9HjuF_image.png) ## Widget description The following widgests are supported: - **My Dashboard Widgets: **This list contains all supported widgets for the My Dashboard console. - **Network CPU Utilization: **Displays CPU utilization for all network devices by severity: - Red: Critical – 81% to 100% - Amber – 51% to 80% - Green – 0% to 50% - **Network Memory Utilization:** Displays memory utilization for all network devices by severity: - Red: Critical – 81% to 100% - Amber – 51% to 80% - Green – 0% to 50% - **Create Incidents Over Time Widget: **The Incident Over Time Widget provides a visual representation of incidents tracked over a defined time. It allows users to monitor trends, compare severity levels, and identify spikes or patterns in incident occurrences. Provides a visual representation of incidents tracked over a defined time period: | **Time period** | **Description** | | -------------------------------------------- | ---------------------------------------------------------------- | | Daily | Displays daily recorded incidents over a selected time period. | | Weekly | Displays weekly recorded incidents over a selected time period. | | Monthly | Displays monthly recorded incidents over a selected time period. | Provides different colored lines to represent incident priority levels: | **Indicator** | **Priority level** | **Severity** | **Description** | | ------------------------------------------ | ----------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------- | | 🔴 | P1 | Critical | Highest priority, severe incidents requiring immediate action. | | 🟠 | P2 | High | High-priority incidents needing urgent attention. | | 🟣 | P3 | Medium | Moderate impact incidents. | | 🟢 | P4 | Low | Low-priority or minor incidents. | Click [View More](file:///C:/Users/HP/Documents/Work/Migrations/Kyndryl/Batch%20%233/Network%20&%20Edge/Managed%20Network%20Services/Network-and-Edge-Composition/create-incidents-over-time-detail-page-.html) for more details about this widget. - **Create Network Device Status Widget:** Provides a quick summary of network device status and allows easy navigation. Displays the status of network devices in different stages as given below: | **Color** | **Status type** | **Description** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------- | ---------------------------------------------------------------- | | 🟦 Light Blue | Planned | Devices planned for future deployment or implementation. | | 🟩 Light Green | Production | Devices currently active in the production environment. | | 🟧 Orange | Archived | Devices that are no longer actively used and have been archived. | |
:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/avt39WxI3_SJx8gD5KqfF_pink-button.jpg" alt caption size="10" width="61" height="58"} Pink | In Stock | Devices available in inventory and ready for deployment. | | 🟪 Purple | Idle | Devices that are currently not assigned or in use. | | 🟨 Yellow | Others | Devices categorized outside the standard status groups. | Click [View More](file:///C:/Users/HP/Documents/Work/Migrations/Kyndryl/Batch%20%233/Network%20&%20Edge/Managed%20Network%20Services/Network-and-Edge-Composition/network-device-status-widget-details-page-.html) for more details about this widget. - **Create Network Device Type Widget:** Provides a graphical overview of the distribution of devices across different network categories. It also displays the number of network device type by vendors. The widget uses a donut chart with different colours to help users quickly understand the number and proportion of devices within the environment. | **Color** | **Device type** | **Description** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- | ---------------------------------------------------------- | | 🟦 Blue | Firewall | Security devices that monitor and control network traffic. | | 🟩 Green | Switch | Devices used to connect systems within a network. | | 🟧 Orange | Router | Devices that route network traffic between networks. | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/avt39WxI3_SJx8gD5KqfF_pink-button.jpg" alt caption width="61" height="58"} Pink | Load Balancer | Devices used to distribute workloads across resources. | | 🟪 Purple | Gateway | Devices that connect networks using different protocols. | | ⬜ Light Gray | Hubs | Basic networking devices used to connect multiple systems. | | 🟩 Light Green | Others | Devices that do not belong to predefined categories. | Click [View More](file:///C:/Users/HP/Documents/Work/Migrations/Kyndryl/Batch%20%233/Network%20&%20Edge/Managed%20Network%20Services/Network-and-Edge-Composition/network-device-status-widget-details-page-.html) for more details about this widget. - **Display Network Device Type By Vendor:** Provides visibility into the total number of devices available for each listed vendor as shown below: | **Color indicator** | **Color name** | **Device type** | **Description** | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------- | | 🟦 | Light Blue | Firewall | Security devices that monitor and control network traffic | | 🟩 | Light Green | Switch | Devices used to connect systems within a network | | 🟧 | Orange | Router | Devices that route traffic between different networks> | | :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/avt39WxI3_SJx8gD5KqfF_pink-button.jpg" alt caption width="61" height="58"} | Pink | Firewalls & Security Appliances | Advanced security devices combining firewall and additional protections | | 🟪 | Purple | Wireless Access Point | Devices that provide wireless network connectivity | | 🟨 | Yellow | Others | Devices that do not fall into standard categories | - **Display Firewalls by Vendor:** Provides visibility into vendor diversity, sprawl, and technology standardization. The horizontal bar chart shows the number of network devices by firewall vendor as shown below: | **Vendor** | **Firewall devices** | **Color indicator** | **Notes** | | --------------------------------------- | ------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------ | | 🟦 Fortinet | 4747 devices | Light Blue | Highest number of firewall devices (dominant in chart) | | 🟪 Cisco | Very low (small bar) | Purple | Minimal firewall presence compared to Fortinet | | 🟨 IBM | Near zero | Yellow | Negligible or no visible firewall count | | 🟧 Fortigate | Near zero | Orange | Very small or barely visible data | - **Display Load Balancer Vendors:** Provides clear visibility into the distribution of technologies in use. Through a horizontal bar chart, users can view the number of network devices categorized by load balancer technology, helping identify vendor spread across the environment. | **Color indicator** | **Vendor** | **Number of devices** | **Description** | | ------------------------------------------------ | ---------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | 🟦 | Cisco | 45 | Major contributor with the highest number of load balancers | | 🟩 | F5 | \~2–3 | Minimal number of load balancer devices compared to Cisco | - [Network Utilization Dashboard](docId\:aSdcEW1d9-CYfPpyRyaDQ) The **Utilization Dashboard** provides detailed insights into CPU and Memory usage for network devices over a selected time period. It enables users to monitor performance trends, identify anomalies, and take proactive action. - [Network Incidents Over Time Detail Page](docId\:h4znQdmq3-pQmlPEXEAek) The **Incidents Over Time** **Detail Page** provides a list of incidents and their details in a single view. Users can search, filter, and review incident information such as priority, device details, location, and status. - [Network Device Status Widget Details Page](docId\:QDD3-rtqbpY_8bueScl2V) The table displays network device information in different columns: | **Column name** | **Description** | | -------------------------------------------- | --------------------------------------------------------- | | **Device Name** | Displays the name of the network device. | | **Type** | Displays the category or type of device. | | **Vendor** | Displays the device manufacturer. | | **Location** | Displays the device location. | | **Model** | Displays the model number of the device. | | **Serial Number** | Displays the unique serial number of the device. | | **Last Seen** | Displays when the device was last detected by the system. | | **Status** | Displays the current operational status of the device. | [title] Private Cellular Dashboards [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Dashboards/ The Kyndryl private cellular service comprises 15 dashboards that provide performance and failure management data from private cell APIs such as Nokia Digital Automation Cloud, helping users understand network health and issues. # Technical prerequisites - Nokia DAC is deployed and accessible - Data Streaming service and SynApps setup with a topic # Private cellular dashboard filtering The dashboard comprises the following elements: - **Global Filter:** Select from a dropdown list of filtering options accompanied by operators and parameters. - **Range Filter:**Select from a range of time spans bounded by **Today** and **Last Year** (the last 12 months). The global filter enables you to narrow the observable data set on the Network Performance monitoring page, limiting it to only data to your circumstance. The filter is located directly below header indicating the selected tab for the dashboard segment, for example Inventory Overview (Monitoring - Inventory).The filter comprises two buttons: - Filter control (grounding icon): - Add filter: Add a filter element. - Apply to all\:Apply the filter to the data set. - Clear all: Clear all applied filters, restoring the defalut data set of all data. - Add filter (plus icon): Add a filter element. Refer to the following image for more details ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/bZx85uu_48IE_GwyLrrgz_image.png) ### Filter time range Use the following procedure to filter the time range for the current data set by time range and other parameters: 1. Select a time range. The default time range is **Last 7 days**. If no changes have occurred in the default or selected date range, data visualizations will not populate. Examples of such changes include new nodes, new interfaces, and events. To change the current date range, use the following procedure: 1. Click the **Calendar** icon. The service displays the quick select dialog, presenting a range field that you can manually set and a list of preselected options. 2. From the units field dropdown menu, which defaults to **7 Days ago**, select the unit, **Days**, **Weeks**, **Months**, **Years**. Set the quantity by entering, incrementing, or decrementing the unit quantity. For example, select **Months**, then decrement **7** to **6** to change the value from **7 days ago** to **Last 6 months**. 3. Click **Update**. The service updates the data for the selected date range. :::Paragraph{indent="1"} The default time range, **7 Days ago**, applies initially to all six dashboards; adjust each as needed. ::: 2. Click the **Plus** icon. The service presents the filter editor. 3. Select a field from the **Select a field** dropdown menu. You can select from any supported field in the network device or operating system record. 4. Select an operator from **Select operator** field: - **is**: Equal to - **is not**: Not equal to - **is one of**: Some fields might have more than one value. This operator specifies a specific value in such a field. - **is not one of**: Some fields might have more than one value. This operator specifies that none of the values exist in such a field. - **exists**: Any device or operating system description that contains the specified field. - **does not exist**: Any device or operating system description that does not contain the specified field. 5. Select a value from the **Select a value** field. :::Paragraph{indent="1"} **Optional:** Add a an additional parameter by selecting boolean **OR** or Boolean **AND**: ::: :::Paragraph{listStyleType="decimal" indent="2"} Repeat steps 2 through 4. ::: :::Paragraph{indent="2"} **Optional:** Repeat step 5. ::: 6. Click **Cancel** to cancel the filter addition or **Add filter** to add the filter you constructed. You may add additional filters as required to adequately narrow your data set. You can also edit a constructed filter as a Domain Specific Language query by clicking the **Edit as Query DSL** link located at the far right of the **Add filter** editor. In addition to data visualizations, the page provides a quick filter to enable the narrowing of data without complex queries. Data is tagged that represents useful parameters such as Customer Name and Network Group. An array of tag filters is located below the global filter, each of which includes a dropdown menu. ### Filtering using Tag Filter Use the following procedure to filter current data using the tag filters: 1. Click the dropdown menu from the tag field. 2. Select the desired parameter value. the data is immediately updated. ## Alarms dashboard The alarms dashboard is a view of reactive monitoring for events that might require action (active) or that can be cleared when no action is required. In this dashboard, you can get an overview of alarms by severity and location, the top events triggering the most alarms, and the types of devices triggering them. In this view, you can also see the days and times when the alarms are typically triggered so that preventive actions can be planned. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/Sv2Ejm9gtP91pyayQPO1R_image.png) ## Cell performance dashboard The Cell Performance dashboard provides an overview of key performance metrics for cell devices, including ranks and availability ratios. It identifies poor-performing cells by location and features a daily performance heat map. Key performance indicators (KPIs) include ranking, availability, retainability, mobility, accessibility, and integrity/quality. Performance is categorized as Below Average (0–2), Average (2–3), Good (3–4), or Excellent (4–5). This KPI assesses service availability in cells for end users, focusing on: - RRC connection establishment. - Initial E-RAB setup for network access. - Data radio bearer setup via RRC connection reconfiguration. - E-RAB setup between MME and UE. It also tracks the following: - \- Abnormally released E-RABs ratio. - \- Uplink/downlink retransmission ratios for RLC PDUs. - \- Lost PDCP SDUs ratio. - Handover success ratios (intra-eNB and inter-eNB). - \- RA preamble responses ratio to total RA preambles. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/DpzPBXEiH6IRBKp41kg8B_image.png) ## Executive view dashboard The Executive View Dashboard offers a comprehensive overview of the key devices in the Private Cell network, including Edges, Access Points, and Cells. It displays existing alarms categorized by device type and Location, along with essential indicators of connectivity, availability, and throughput for both uplink and downlink. Additionally, the dashboard highlights trends in these metrics and provides a summary of performance rankings and trends by Location. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/N6G1EQLX3ikQ_x5SHO_Vi_upload.png) ## Cell availability KPIs dashboard The Cell Availability KPIs dashboard focuses on indicators related to cell availability. In addition to overall availability, it provides insights into availability by user state, time-series line charts for key availability metrics, a view of down devices over time, and a summary table for reporting. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/0N7u8Qjl3fPp8l16QDaR__upload.png) ## EDGE performance dashboard The EDGE Performance dashboard provides a comprehensive overview of Edges, including their locations, total device count, and key metrics such as CPU, disk, and RAM usage, as well as disk temperatures. You can view the top utilizations and analyze a time series that displays their behavior over several days. Additionally, you have the option to download a CSV file containing a summary of all the data. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/KjrWzbo02mVx_5fuSqT6n_upload.png) ## Accessibility insights Accessibility Insights offers a range of accessibility indicators, including success ratios for RACH Setup, RRC Connection Setup, and E-RAB Setup. It also displays the failure counts for RACH, RRC, and E-RAB attempts, along with information about the associated cells. The tool highlights the leading causes of RRC and E-RAB attempt failures and tracks how these issues develop over time. Additionally, a downloadable table at the bottom of the dashboard provides comprehensive details about all call setup activities. The Throughput Insights dashboard presents various aspects of the average PDCP (Packet Data Convergence Protocol) uplink and downlink performance over time, categorized by cell. This includes metrics such as the E-Utran Average Active Users with Data in Buffer, as well as the Uplink and Downlink statistics for each cell. Additionally, a downloadable summary table consolidates all the information. The Cell Load Throughput and Radio Condition KPIs dashboard primarily focuses on bandwidth usage by cell and User. Here are the main key performance indicators (KPIs): - Uplink signal strength compared to total wideband received power, which indicates the quality of the signal. Either low or high values may suggest that the cell might not be receiving signals from users effectively. - Average RLC layer throughput per cell for both uplink and downlink. - Average PDCP layer throughput per cell for both uplink and downlink. - PDCP Service Data Unit (SDU) volume on the eUu interface per cell for both uplink and downlink. ## Mobility KPI dashboard The Mobility KPIs dashboard evaluates the performance of E-Ultran mobility, which is fundamental to ensuring a positive customer experience. Several KPIs are based on intra-frequency, inter-frequency, and inter-Radio Access Technology (RAT). Here are the main KPIs summarized: - Inter-Frequency HO Success Ratio: Success rate of inter-frequency handovers confirmed by the source eNB. - Intra-Frequency HO Success Ratio Success rate of intra-frequency handovers confirmed by the source eNB. - Inter-eNB X2 HO Success Ratio: Overall success rate for inter-eNB handovers. - Intra-eNB HO Success Ratio: Overall success rate for intra-eNB handovers. - Intra-sNB HO Attempts: Total number of intra-sNB handover attempts. - Inter-eNB S1 HO Attempts: Total number of inter-eNB S1 handover attempts. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/Hdc1v2e5lHnw8BvIdqVxM_upload.jpeg) ## Call sustainability KPI dashboard The Call Sustainability KPIs dashboard shows metrics and KPIs for calls that succeed, succeed with reestablishment attempts, reestablishment attempt completions, and failures, including drop counts and reestablishment attempt failures. The dashboard includes the following KPIs: - RRC Connection Reestablishment Attempts by type (total, "HandoverFailure", "otherFailure", "reconfigFailure"). - Successful RRC Connection Reestablishment procedures. - Data Radio Bearer Setup Attempts. - Ratio of abnormally released E-RABs from the RAN perspective. - Total reestablishment attempts fail. - Set the success ratio for RRC connection reestablishment to maintain the UE in the LTE RRC\_CONNECTED state during failures. - Average UE-reported Channel Quality Indicator (CQI) value. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/cassV-RORROQVCLAZCfDO_upload.jpeg) ## Subscriber identity model (SIM) card insights dashboard The Subscriber Identity Model (SIM) Card Insights dashboard provides key metrics, including the total number of SIM cards, total active SIM cards, total user equipment (UE) that has been disconnected, total UE that is currently connected, and total UE that has been deregistered. The dashboard also identifies the most utilized SIM cards, access points, and site locations. Additionally, it highlights the SIM cards that have never been connected and tracks their trends over time. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/gk0Iib_UDHYBvbyYHO2dX_upload.png) ## Core metrics dashboard The Core Metrics Dashboard provides an overview of inventory, traffic, SGW, and MME metrics. It includes details on Edges data attach requests and successes, as well as S1U Uplink and Downlink data in bytes. Additionally, it tracks handover (HO) attempts and successes for S1 and X2, alongside paging requests and successes, PDN connections and successes, and TAU requests and successes. This dashboard provides insights into the status and usage trends of DC Edge devices. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/aM6rqUt_WSq5-x1Gi_r6c_upload.png) [title] Onboarding Network Devices [path] Services/Kyndryl Services/Network & Edge/Managed Network Services/Service components/ supports multiple network devices and has automated the ability to concurrently onboard all supported devices in your environment. Administrators access the onboarding feature through the Administrative portal. :::hint{type="info"} Currently has features such as Network Device Onboarding, Network Inventory Controllers like Users, Sites Dialog and Tenants Dialog. However, these features are currently disabled in Bridge. After the AIOps migration is completed these features will be enabled. ::: The administrative portal contains the following features: - **Download CSV Template:** A CSV file containing all the required fields that you must complete for every device you intend to onboard. - **Add Device:** An onboarding wizard that steps you through the process of onboarding your network monitoring devices using the completed CSV form. - **Network device table:** A table that displays accounts for all network devices. Click an account to view all devices that have been submitted including pertinent detauls and onboarding status by Network Monitoring device. The services recognizes all devices in association with a single account and they must be uploaded in that context. :::Paragraph{indent="1"} For example: You have devices on your network owned by three different accounts: ABC, NBC, and CBS. Devices must be submitted and onboarded in the context of only one of those three accounts. ::: ## Onboarding CSV template and validation The CSV template contains placeholders for all supported information for your network devices. After downloading the template, populate it with values for each category in the template for each device. The information you provide will first be validated during the upload, recording basic errors such as duplicate device names and valid serial numbers. Devices that are onboarded error-free will show a green check, and those with validation errors will show a red x. To correct an identified error, you can update the device property in the CSV file and re-submit the file, or click the elipsis at the end of the row. Clicking the elipsis displays an action menu that includes **Edit**. Click **Edit** to display the side drawer containing attributes for the selected network device. If the upload detects errors, the invalid attribute value is displayed in red. Correct the identified errors and submit again. Use the following procedure to upload your network devices: The service is capable of concurrently onboarding devices from both Zabbix, Backbox and Netbox if you are using both. However, you must use the following procedure: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Kyndryl Services** → **** → **Home**. 2. Select **Device Onboarding**. The service navigates to the Network Devices page. 3. Click **Download CSV **Template as shown in the image below. 4. Complete the template form. 5. Click **Add Devices to ACE**. Refer to the following image: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/w7tk6Y8EvYCmdy5yYMfiw_image.png) 7. When adding devices to ACE, users can choose which supported tools should be used during the CSV resubmission process. The available tools displayed in the **Tool Selection** section include: - **NetBox** – Network inventory controller. All Netbox devices with details and onboarding status for each device. - **Zabbix** – Network performance manager. All Zabbix devices with details and onboarding status for each device. For more information - [Zabbix Multi-Instance Onboarding](docId\:wHQpLC-izesMliZDFGHdW) - **BackBox** – Configuration manager and backups. All Backbox devices with details and onboarding status for each device. 8. In the **Tool Selection** section, select the checkbox for each tool you want to include in the onboarding process. :::hint{type="info"} Users may select **one tool, multiple tools, or all available tools** before uploading and resubmitting the CSV file. At least one tool should be selected before submitting the CSV. The fields associated with the unselected tool are not processed. The corresponding values are displayed as a hyphen (-) in the results. ::: Refer to the following image: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/zIs98yv3sWOG9-EAGHX2X_image.png) 9. After updating the relevant fields in the selected tool, click **Upload File** to resubmit the CSV. 10. Use the dialog to submit your completed CSV files. - The service activates the **Upload files** button. - The service validates the file and reports any missing information such as columns that are required. 11. Click **Upload files**. The service then validates the information contained in the file and reports the success or failure of the upload. Example: the service cannot find one of the accounts. The service displays a dialog with a notification that account does not exist and halts the operation. The service displays a new line item in the table for each account that passed the validation. 12. Click the **Account Name** (first column in the table). The service navigates to the account details page. The details page provides the following tabs: - **Summary:** All devices with upload details for each device, such as a time stamp, and the onboarding status. It also provides a device count for Zabbix and Netbox devices. - **Netbox:** All Netbox devices with details and onboarding status for each device. - **Zabbix:** All Zabbix devices with details and onboarding status for each device. For more information - [Zabbix Multi-Instance Onboarding](docId\:wHQpLC-izesMliZDFGHdW) - **Backbox:** All Backbox devices with details and onboarding status for each device. :::Paragraph{indent="3"} Refer to the following image: ::: ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/tuir95rXneC8Vn6cSdbs3_image.png" size="90" isUploading="false" width="1880" height="595" darkWidth="1880" darkHeight="595" position="center" showCaption="false"} 13. Use the search field to filter for specific devices. Once onboarded, customers can submit a list of devices, for the purpose of discovering device details. The Discovery service contacts the onboarded devices from the submitted list and receives self-reported details, which are then passed to the Kyndryl Inventory service. [title] Glossary of terms [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ Use this glossary to familiarize yourself with the key terminology and concepts used in &#xNAN;**. **Understanding these terms will help you navigate the platform more effectively and better understand the configuration, management and operation of container clusters throughout their lifecycle. Glossary: **Service Account**: - A principal identity recognizable by users and peripheral systems, composed of a set of secrets for authentication and authorization. **Cluster Role**: - A cluster-level logical grouping of Policy Rules, accessible as a unit by Role Binding or Cluster Role Binding. **Role**: - A name spaced logical grouping of Policy Rules, accessible as a unit by Role Binding. **Cluster Role Binding**: - Links to a Cluster Role without containing it. It references a Cluster Role in the global namespace and adds information through Subject. **Role Binding**: - References a Role without containing it. It can link to a Role in the same namespace or a Cluster Role in the global namespace, adding 'who' information via Subjects and specifying the namespace of existence. **Config Map**: - Holds configuration data for pods to utilize. **Secret**: - Contains secret data of a certain type. A Service is a named software service abstraction (e.g., MySQL), comprising a local port and a selector to determine which pods respond to requests. **Ingress**: - A collection of rules enabling inbound connections to reach backend-defined endpoints. It can configure services for external URLs, load balance traffic, terminate SSL, and more. **Persistent Volume (PV)**: - A storage resource provisioned by an administrator. **Persistent Volume Claim**: - A user's request for and claim to a Persistent Volume. **Pod**: - A collection of containers that can operate on a host. **Deployment**: - Facilitates declarative updates for Pods and Replica Sets. **Replica Set**: - Ensures a specified number of pod replicas are running at any given time. **Daemon Set**: - Represents the configuration of a daemon set. **Stateful Set**: - Represents a set of pods with consistent identities, defined by network and storage attributes. **Job**: - Represents the configuration of a single job. **CronJob**: - Represents the configuration of a single cronjob. [title] Container Cluster Management [path] Services/Platform Services/Cloud Management/ [title] AWS Cloud [path] Services/Platform Services/Cloud Management/Container Cluster Management/Prometheus and Alerts/ For AWS Prometheus to be effectively configured and to ensure a smooth monitoring experience, it's crucial to follow the right steps and have the necessary prerequisites in place: - **AWS Account Credentials**: Specifically, the accessKey and secretKey from the account that created the cluster. - **Helm**: A vital tool for managing Kubernetes charts. - **Kubectl**: Ensure you're using version 1.18.15 or later. [Get the right version here](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). - **AWS CLI**: If you haven't installed it, [follow these instructions](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). # Procedure 1. **Configure AWS Account**: Open your terminal and enter `aws configure` to set up your AWS account. To double-check your settings, use `aws sts get-caller-identity`. 2. **Establish a Namespace**: Create a dedicated namespace for Prometheus with this command: `kubectl create namespace prometheus`. 3. **Include Prometheus Repository**: Add the Prometheus community chart repository using: `helm repo add prometheus-community https://prometheus-community.github.io/helm-charts`. 4. **Deploy Prometheus**: Use the following command to deploy Prometheus: `helm upgrade -i prometheus prometheus-community/prometheus --namespace prometheus --set alertmanager.persistentVolume.storageClass="gp2",server.persistentVolume.storageClass="gp2"` 5. **Check Your Pods**: Verify if all the pods within the Prometheus namespace are ready using: `kubectl get pods -n prometheus`. 6. **Forward the Prometheus Console**: To make your Prometheus console accessible from your local machine, use: `kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090`. 7. **Access the Console**: Open your browser and go to `localhost:9090` to view the Prometheus console. 8. **Dive Deeper**: If you're looking for a more detailed guide, consider visiting the official [AWS documentation on Prometheus](https://docs.aws.amazon.com/eks/latest/userguide/prometheus.html). [title] Custom resources [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ Custom Resources Definitions (CRD) are Kubernetes API extensions. Unlike regular resources, they are not always available in a default Kubernetes installation. Instead, they are dynamically registered to a cluster. After registering the custom resource, users can manage objects such as namespaces, pods and services. Introducing CRD and extending Kubernetes APIs will allow you to direct Kubernetes to manage more than containers. To view the different Custom resources data, follow these steps to access the data you need: 1. Authenticate into the application by providing credentials to ensure secure access to the management dashboard. 2. Upon successful authentication, proceed to the CCM main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Custom resources** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. # Definitions Once you select View details on a cluster from the Clusters table, the details table will emerge; scroll down to Custom Resources and select Definitions. The Custom resource definitions table presents data about the custom resources that are enabled as follows: - **Name:** Name of the Custom Resource Definition. - **Group:** Name of the Kubernetes or API group. - **Scope:** Category within the cluster, namespaced, cluster, pod, etc. - **Age:** Time since the CRD was enabled. To access details for a specific CRD, Click the overflow menu located to the far right of the table and select **View details;** a new dialog appears with technical service details. The following elements are displayed in this dialog: - The custom resource definition is panel title, label, annotations, version and accepted names. - **Resource/Objects**: This section displays the `Resource / Objects` table with static columns and custom column names. - **Static columns**: If CRD has `Namespaced Scope` then columns would be Name, Namespace and Age; otherwise, the columns would be Name and Age. - **Custom columns**: It is based on CRD response under this attribute `versions.additionalPrinterColumns ([]CustomResourceColumnDefinition)`. - **Conditions**: This section displays the `Conditions` table with the following columns: Type, Status, Last Transition time, Reason and Message. - **Raw JSON** : The data here is JSON data about the selected definitions from the REST API exposed by kubernetes. [title] Prometheus and Alerts [path] Services/Platform Services/Cloud Management/Container Cluster Management/ # Alert manager The Alert Manager manages duplicating, grouping, and routing alerts to the correct receiver integration, such as email and PagerDuty and manages silencing and inhibition of alerts. Alertmanager must be installed on Cluster with service exposed on **port** and **targetPort 9093**. If Alert manager is installed on the cluster, add a default receiver to Alertmanager configMap in the receiver section. # Prometheus Prometheus is an open-source monitoring framework. It provides out-of-the-box monitoring capabilities for the Kubernetes container orchestration platform. It scrapes metrics from instrumented jobs and stores all scraped samples locally. It then manages this data and generates alerts. Prometheus must be installed on a Cluster with service exposed on **port** and **targetPort 9090**. If Prometheus is installed on a cluster, Alertmanager requires data in a specific format to display relevant alert information about the UI. Hence, in the created config map to externalize Prometheus (config-map.yaml), the pod-level queries must include the namespace, pod name and description of the alert under the configuration of alerts. In the previous example, the pod-level query is defined by **expr**, which creates an alert if the pod is using more CPU. The output of **expr** should contain the namespace and the pod name. To add these values in Alert manager, produce the output using **$labels** under **labels section**. Along with Prometheus, **node-exporter** must also be installed for node-level metrics like memory usage, CPU usage, etc. # Prometheus cloud providers Prometheus needs to be configured to each cloud service provider to pull data for its monitoring framework; visit each provider listed below for more details regarding configuration: - [AWS Configuration](docId:46RPAAg54nXqcR2wihW0T) \:Configure an AWS account to enable Container Cluster Management to discover and monitor resources and Kubernetes clusters hosted in Amazon Web Services. - [Azure Configuration](docId:-QIFqY1tGqImZlssX9KWQ): Configure an Azure account to enable Container Cluster Management to retrieve resource and cluster data from Azure Resource Manager. - [GCP Configuration](docId\:tnYUtki-BT7ynfYbv1WXW): Configure a Google Cloud Platform account to allow Container Cluster Management to discover and collect information about cloud resources and Kubernetes clusters. - [IBM Cloud Configuration](docId\:xk2c-1QIug34lj1Ofg0pd): Configure an IBM Cloud account to enable Container Cluster Management to access and collect data from IBM Cloud resources and managed clusters. - [Alibaba Cloud](docId:7zV7I-ZeoKI-RsVPpJ4zo): Understand how to enable Alibaba Prometheus (ARMS), supporting your chosen monitoring and alert system. - [AWS Cloud](docId\:wv9J_RrocBkMrnMm14Wih): Understand how to activate AWS Prometheus Monitoring, supporting your chosen monitoring system. - [Azure Prometheus monitoring](docId\:ruTsOqQ_SHjWbY9Fun0m3): Understand how to Activate Azure Prometheus Monitoring, supporting your chosen monitoring system. - [GCP Cloud](docId\:uAIqH8lJWpkE7JDM5P0B5): Understand how to enable Prometheus on Google Cloud Platform, supporting your chosen monitoring system. - [IBM Cloud](docId\:B8wQovMSeGiA6HvLDpIHt): How to enable IBM Cloud Prometheus, supporting your chosen monitoring system. [title] Executive dashboard [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ View a summary of critical performance data impacting applications to assist in removing obstacles. The Executive Dashboard, titled Executive Overview, contains the following elements that enable efficient navigation and effective oversight of the : - **Global filter**: Enables you to selectively narrow data sources to only those, which are relevant. - **Statistical data summary array**: Displays counts of resource categories such as Total Clusters, Total Nodes and Total Applications. - **Time range filter**: Enables the selection of the time range for the data you want to see. - **Critical performance data summaries**: Displays data that enables quick action. # Global filter supports a data filter to enable the selection of data you want to display in the dashboard, Actionable Insights and the Cluster Overview page. To filter displayed data, select the filter icon under the header. All graphic displays are adjusted to accommodate the filtering criteria. The following filter categories are supported: - **Providers**: Implemented provider integrations - **Connections**: Individual, created connections - **Applications**: Individual, deployed applications - **Environments**: All implement environments, such as development, staging By default all data is displayed, and **All** selection can be applied to any of the filter categories. Select one or more items from each filter category using the drop-down menu and click **Apply** to apply your filter selections or click **Cancel** to abort your selections. When you apply your filter selections, the service displays the selected items in the filter field below the filter icon. You can dismiss any or all of the filter categories by clicking the **X **to the right of the category name; the service updates the dashboard accordingly. # Data summaries The Executive Overview displays the following data summaries: **Statistical data array**: - Total Clusters - Total Env (environments) - Total Nodes - Total Applications - Total Pods - Active Pods - Data Centers **CPU Utilization**: Total CPU use as a percentage of total capacity. The summary provides two additional metrics: - CPU Capacity as measured by the number of CPU cores. - CPU Used as measured by the number of cores in use. **Memory Utilization**: Total memory use as a percentage of total capacity. The summary provides two additional metrics: - Memory Capacity - CPU Used **Storage Utilization**: Total storage uses as a percentage of total capacity. The summary provides two additional metrics: - Storage Capacity - Storage Used **High Storage Activity**: A table displaying a list of applications and their associated storage activities. The table provides data in the following categories: - **Application**: The name of the application. The application name is a navigation link to details regarding that application. - **Read Operation**: The read activity in Mi/s. - **Write Operation**: The write activity in Mi/s - **Environment**: The name of the environemt hosting the named application. - **Data Center:** The name of the data center. **Application Latency - Stateful Services**: A table displaying the number of affected applications. **Storage Placement by Application**: A table displaying metrics for the following categories: - Application - PVC Used - Environment **PVC Lifecycle**: A table displaying metrics for the following categories: - PVCs Created - PVCs Deleted - Net Growth **Node Network Throughput**: A table displaying throughput data with the following details: - Node: Node name - Total Data - Ingress - Egress - Application - Environment **Cluster CPU, Memory and Storage Usage**: A table displaying statistical data for selected resources. The table has a **Settings** (gear) option from you can select the following resources to display in the table: - Cluster: The Cluster name in the Cluster CPU, Memory and Storage Usage table is a navigation link to details regarding that cluster. - Environment - CPU Capacity - CPUused - CPU % - Memory Capacity - Memory Used - Memory % - Storage Capacity - Storage Used - Storage % Each table has a **View All** option that displays only the table. [title] Cluster access control [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ Manage your Kubernetes cluster access using a role-based approach. The Cluster Access Control section provides a role-based access control management system for Kubernetes clusters. Use the following procedure to connect to Access Control: 1. Log into . To learn more about navigating to the different services from each tenant, refer to [Console Overview](docId\:f6lnLLBczD49EpcQtzE_q). 2. Proceed to the main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose a cluster by selecting the cluster name in the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Access control** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. # Access Control The Access Control in Kubernetes includes the following sections: - **Cluster roles:** - A non-namespaced resource. It's assigned names like Role and ClusterRole because Kubernetes objects are either namespaced or not. Uses: 1. Set permissions on namespaced resources within individual namespace(s). 2. Grant permissions on namespaced resources across all namespaces. 3. Define permissions on cluster-scoped resources. - **Roles:** - Always sets permissions within a specified namespace. When creating a Role, the namespace it pertains to must be specified. - **Cluster role bindings:** - While a RoleBinding provides permissions within a particular namespace, a ClusterRoleBinding offers that access across the entire cluster. - **Role bindings:** - Grants the permissions as defined in a role to specific users or groups. It contains a list of subjects (users, groups or service accounts) and references the role that is being granted. Grant permissions within a specified namespace. - **Service accounts:** - These are Kubernetes resources managed via the Kubernetes API. It is intended for in-cluster entities like Pods to authenticate to the Kubernetes API server or external services. # Cluster roles On the cluster roles page, you'll find a comprehensive view of all cluster roles for your cluster. The table displays: - **Name:** Name of the cluster role. **Age:** The duration since the cluster role was created. - duration To explore more details about a cluster role, select either the entire row or the **View details** option. This will present the cluster role's details in a side panel which includes: - **Cluster role name** as the panel title, **Labels** and **Annotations**. - **Rules:** Displays the Rules table showcasing **Resources**, **Verbs** and **API Groups**. - **Raw JSON:** Contains JSON data from the cluster roles API exposed by Kubernetes. # Roles The roles page overviews all roles for a particular cluster within a selected namespace. The table displays: - **Name:** Name of the role. - **Namespace:** The namespace within which the roles are created. - **Age:**The duration since the role has been set. To delve into a role's details, select the row or the **View details** option. A side panel will display: - **Role name** as the panel title, **Labels**, and **Annotations**. - **Rules:** Displays the Rules table showcasing **Resources**, **Verbs** and **API Groups**. - **Raw JSON:** Contains JSON data from the roles API exposed by Kubernetes. # Cluster role bindings This page presents a view of your cluster's role bindings. The table highlights: - **Name:** Name of the cluster role binding. - **Role reference:** Role reference for that specific cluster role binding. - **Age:** Duration since the cluster role binding has been active. For a deeper understanding of a cluster role binding, select its row or the **View details** option. This will bring up a side panel detailing: - **Cluster role binding name** as the panel title and **Labels**. - **Subject:** Showcases the Subject table with columns such as **API Group**, **Subject kind**, and **Subject name**. - **Raw JSON:** Provides JSON data from the cluster role bindings API exposed by Kubernetes. # Role bindings This section presents all role bindings for a specific cluster within a selected namespace. The table contains: - **Name:** Name of the role binding. - **Namespace:** The namespace in which the role bindings reside. - **Role reference:** Role reference for the specific role binding. - **Age:** The duration since the role binding has been set. Select a role binding's row or the **View details** option to view its specifics. A side panel will feature: - **Role binding name** as the panel title and **Labels**. - **Subject:** Details the Subject table columns, including **API Group**, **Subject kind **and **Subject name**. - **Raw JSON:** Contains JSON data from the role bindings API offered by Kubernetes. # Service ccounts This page showcases all service accounts for a specific cluster within the chosen namespace. The table shows: - **Name:** Service account's name. - **Age: **The duration the service account has been active. Select its row or the **View detail**s option to examine a service account in detail. A side panel will reveal: - **Service account name** as the panel title, **Labels** and **Annotations**. - **Secrets:** Lists the Secrets table, highlighting the **Name** and **name type**. [title] Azure Prometheus monitoring [path] Services/Platform Services/Cloud Management/Container Cluster Management/Prometheus and Alerts/ Effective monitoring tools like **Azure Prometheus** are indispensable in today's dynamic cloud ecosystem. Azure integrates flawlessly with Prometheus; setting it up has never been easier. Let's dive right in and set you up with Prometheus on your Azure cluster. # Establishing a connection with Azure Cluster - Log in into your Azure environment using either the Azure Shell or Azure CLI. - To effectively manage your cluster resources via Azure Shell, take a look at this step-by-step guide: [Azure Cloud Shell Overview](https://docs.microsoft.com/en-us/azure/cloud-shell/overview). # Prep your environment with Azure CLI - Begin by installing the Azure CLI. Here's a quick [installation guide](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to get you started. - Fire up the command line and execute `az login` to access your Azure account. - If you don't have `kubectl` already, use the command `az aks install-cli` to get it locally. - Next, set up kubectl to interact seamlessly with your Kubernetes cluster using this command: `az aks get-credentials --resource-group myResourceGroup --name myAKSCluster`. This ensures your CLI is synced with your cluster credentials. # Activating Prometheus on Azure - Begin by installing the Helm package manager for Kubernetes, the backbone for managing Azure Prometheus. - Define the helm repo with this: `helm repo add prometheus-community https://prometheus-community.github.io/helm-charts`. - Refresh with `helm repo update`. - For organized management, carve out a new namespace for Azure Prometheus using `kubectl create namespace`. In this example, we've named it **monitoring**. - Integrate Prometheus using: `helm install prometheus prometheus-community/prometheus --namespace monitoring --set alertmanager.persistentVolume.storageClass="default" --set server.persistentVolume.storageClass="default"`. - To get a live view of your Azure Prometheus dashboard within Azure, utilize port forwarding: `kubectl port-forward -n monitoring prometheusPodName 9090`. [title] Capacity Planning Dashboard [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ The **Capacity Planning Dashboard** provides insights into current cluster utilization and highlights CPU and memory overcommitment. To access the dashboard: 1. Navigate to . 2. In the left navigation bar, hover over the **Dashboard** icon. 3. Select **Capacity Planning**. :::hint{type="info"} Users must have an App Owner, Capacity & Performance Engineer or IT Ops Mgr role assigned to access the Capacity Planning Dashboard. ::: In addition to the Cluster Health by Provider (donut chart), Actionable Insights and the Cluster List table, the dashboard includes three additional tiles that provide an at-a-glance view of capacity and utilization: - **Most utilized clusters**: The number of clusters that exceeded the high threshold for CPU, memory or storage in the last 30 days. - **CPU overcommitted clusters**: The number of clusters that currently exceed the overcommitted CPU threshold. - **Memory overcommitted clusters**: The number of clusters that currently exceed the overcommitted memory threshold. Thresholds for overcommitment follow: - **CPU utilization:** - Green: 0% - 70% (normal range) - Amber: 71% - 80% (warning range) - Red: 81% - 100% (action recommended range) - **Memory utilization:** - Green: 0% - 80% (normal range) - Amber: 81% - 90% (warning range) - Red: 91% - 100% (action recommended range) - **Memory utilization:** - Green: 0% - 75% (normal range) - Amber: 76% - 80% (warning range) - Red: 81% - 100% (action recommended range) Each tile contains a **View** link that navigates to a details table for all affected clusters. Details include critical identifying information such as cluster name, environment, (CPU/memory) utilization and (CPU/memory) request. Directly below the utilization and overcommitment tiles, the dashboard presents two tables: - **Top 20 Pods by Network I/O: **The 20 pods with the highest amount of inbound and outbound network traffic. Click the Pod Name for Utilization details: - **CPU utilization:** A graph that provides instantaneous utilization over time in one-day increments. - **Memory Utilization:** A graph that provides instantaneous utilization over time in one-day increments. - **Storage utilization:** A graph that provides instantaneous utilization over time in one-day increments. - **Network I/O: **A graph that provides instantaneous traffic measurement over time in one-day increments. - **Top 20 Pods by Disk I/O: **The 20 pods with the highest amount of read and write throughput traffic. Click the Pod Name for Utilization details: - **CPU utilization: **A graph that provides instantaneous utilization over time in one-day increments. - **Memory Utilization: **A graph that provides instantaneous utilization over time in one-day increments. - **Storage utilization:** A graph that provides instantaneous utilization over time in one-day increments. - **Disk I/O:** A graph that provides instantaneous disk read and write throughput over time in one-day increments. [title] Integration with applications Container Cluster Management [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ When navigating the Common Inventory landing page (Resources page) and selecting a specific cluster name, upon clicking the consumer link, the application presents detailed cluster information in the Container Cluster Management details menu. Users can easily return to the Common Inventory via the UI, using the **Back to Inventory** link in the UI. # Integration with ## Setting Session Storage and Query Parameters For seamless integration with , every application must set the session storage and correctly pass the query parameters. **Query parameters**: - **appId**: - Mandatory parameter, matching the session storage key. - **appPage**: - Optional parameter, useful for multiple navigations within the same application to the UI. - **namespace**: - Parameter for setting the namespace filter. :::hint{type="info"} This parameter is used to map the application to application Foundation. It is highly recommended to populate the field to match the application name. ::: # Configuring Session Storage For effective integration, applications should configure session storage. The setup differs based on the navigation requirements. ## Single Navigation Session Storage The session storage key must match the appId in the query parameters. The session storage value should include: - **Bread crumb ltems**: An array of objects with titles and links for breadcrumb navigation. - **Back To Link**: An object containing the text and link for the application's Backlink. - I**nclude Cluster Link**: Set to true to display the cluster name as a link to the overview page. [title] Storage [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ Within , a Persistent Volume (PV) represents a segment of storage that an administrator has provisioned for you or that has been automatically set up using Storage Classes. Think of it as a durable container for your data, designed to outlast any individual Pods in your cluster. You have the flexibility to have Persistent Volumes provisioned either statically or dynamically. With static provisioning, your cluster administrator pre-arranges a set of PVs with defined storage capacities that remain at your disposal until they are explicitly removed. Dynamic provisioning, however, is like having a responsive storage solution that automatically creates storage resources whenever your Persistent Volume Claims (PVCs) demand them. The value for you lies in the Persistent Volumes' ability to support your stateful applications, those that need a reliable storage backend that won't forget data when a Pod goes away. PVs empower you to manage your storage needs declaratively, freeing you from worrying about the nitty-gritty of storage infrastructure. The Storage feature in the service provides a consolidated view and management options for Persistent Volumes, Persistent Volume Claims, and Storage Classes. Ensuring a proper configuration of this feature empowers users to maximize the utilization and management of storage resources within their container clusters. To view the different storage data, follow these steps to access the data you need: 1. Log in to . To learn more about navigating to the different services from each tenant, refer to [Global navigation](docId\:mPOJAK2f0JDnP8wR-liZk). 2. Upon successful authentication, proceed to the CCM main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Storage** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. ## Persistent Volumes - View the available persistent volumes. - For a detailed insight, either click on the specific row or select the **View Details** option. ## Persistent Volume Claims - Displays the available Persistent Volume Claims. - Namespace-specific claims can also be viewed. - For detailed information, click on the respective row or opt for **View Details.** ## Storage classes - Shows available Storage Classes essential for creating persistent volumes for pods. - For an in-depth understanding, click on the particular row or hit the **View Details** option. [title] Workloads [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ Kubernetes cluster encompasses all the applications and services that run on it. They include Pods, Deployments, Replica Sets, Stateful Sets, Daemon Sets, Jobs and Cronjobs each serving a specific function in deploying and managing your applications. To view the different Workload data, follow these steps to access the data you need: 1. Log into . 2. Upon successful authentication, proceed to the main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Workload** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. # Workloads The Workloads section in your interface is designed to give you a comprehensive overview and detailed insights into various components running in your Kubernetes cluster. This section is divided into the following sub-sections: - **Pods**: This subsection provides a view of all the pods within your cluster. Here, you can easily monitor each pod's status and conditions, offering a granular understanding of your cluster's runtime environment. - **Deployments**: In this subsection, you get a detailed view of all deployments. It allows you to check the status of each deployment, ensuring that you are always updated on how your applications and services are being managed and scaled in the cluster. - **Replica Sets**: Here, you can view all the replica sets in your cluster. This section provides detailed information about each replica set, enabling you to ensure that the desired number of pod replicas are always running as intended. - **Stateful Sets**: This subsection displays all the Stateful Sets in your cluster. Detailed insights into each Stateful Set help you manage stateful applications more effectively, ensuring they maintain a stable identity and storage across restarts and rescheduling. - **Daemon Sets**: This interface area shows all the Daemon Sets in the cluster and detailed information on each. Daemon Sets ensures that your nodes run a copy of a specific pod, which can be crucial for cluster maintenance and providing services on each node. - **Jobs**: The Jobs subsection offers a view of all the jobs in the cluster. This information is particularly useful for tracking tasks intended to run until successful completion. - **CronJobs**: Lastly, this subsection presents a comprehensive view of all the CronJobs configured in your cluster. It's particularly useful for scheduling and managing tasks that need to run periodically or at a specific time. # Pods The Pods section presents an overview of all the pods in the cluster. The following elements containing this data are available: - Pod Table - CPU Usage - Memory Usage - Network Transmitted - Deployments - Replica Sets - Stateful Sets - Daemon Sets - Jobs - CronJobs # Pod Table The Pod Table presents an overview of pods, containers and init containers that are part of the cluster. The following details are presented in the pod's table: - **Name**: This column displays the names of pods. - **Namespace** : This column displays the namespace in which the pod is running. - **Restarts**: This column displays the restart count. If the count is greater than 0, the warning icon is displayed along with the count. - **Log link**: This column provides a link to view Pod, Container and Init Container logs. Log sections located below the table provide details about the records. Cluster users can search through logs, export the logs and filter the logs based on the duration slider. - **Status**: This column displays the quality of the pod: Succeeded, Running, Pending, Failed and terminated. - **Controlled by**: This column displays the name of 'kind,' associated with the pod. - **Image**: This column displays the image associated with the pod. - **Age**: This column shows the age of the pod. :::hint{type="info"} Duration sliders are shown only if there are more than 50 log lines. The timeline will be displayed if the pod's restart count exceeds 0. ::: To view more details about a pod, the user can click on the `View details` option present at the end of the row. The details about the selected pod are presented in a side panel, as shown below. - **Conditions:** This section displays the `Conditions` table with the following columns: Type, Status, and Last transition time. - **Volumes:** This section displays the `Volumes` table with the following columns: Name, Mount path, Type, and Read-only. - **Environment variables:** This section displays the `Environment variables` table with the following columns: Name and Value. - **Events:** This section displays the `Events` table with the following columns: Type, Reason, Namespace, Message, Involved object, Count and Duration. - **Raw JSON:** This section displays the `Raw JSON` as received from the API. The cluster user can copy the entire JSON using the `Copy to clipboard` button provided. - **Monitoring:** This section displays the graphs for `CPU Usage`, `Memory usage`, `Network Transmitted` based on the selected duration. :::hint{type="info"} The Monitoring tab will display the charts only if Prometheus is configured on the cluster; else, it will show the info note Prometheus is either not installed or properly configured for this cluster. ::: # Namespaces as per policies - Namespace dropdown menu present in all the cluster details pages is used to filter the data as per the namespace selected. - Access to Kubernetes cluster namespaces can be restricted using the namespaces policy attribute. - If the user policy has access to all namespaces, the **All** option will be shown in the namespaces dropdown in the details pages or the dropdown will consist only of the namespaces to which the user has access. - In the latter case, the first option will be used to get the info as per the sorted order. It is the default behavior, and you can switch the namespaces within the allowed list from the dropdown as required. - When the namespaces attribute is present in a policy, the cluster-scoped Kubernetes resource types are automatically restricted from the cluster details menu. # CPU Usage This graph represents the CPU usage by the pod over a period of time. The red line indicates the **CPU limit**. The green line indicates the **CPU usage** and the yellow line indicates the **CPU requests**. On hovering over any particular line on the chart, the tooltip displays the CPU limit, CPU usage and CPU requests at that specific time. :::hint{type="info"} **CPU limit** will be shown only if it is set by the cluster user while creating the pod. ::: ## Memory Usage This graph represents the pod's memory usage across a period of time. The red line indicates the **Memory limit**. The green line indicates the **Memory usage** and the yellow line shows the **Memory requests**. On hovering over any particular line on the chart, the tooltip displays the Memory limit, usage and requests at that specific time. :::hint{type="info"} **Memory limit** is shown only if it is set by the cluster user while creating the pod. ::: # Network transmitted This graph represents the Network transmitted by the pod across a period of time. The red line indicates the **Network transmitted**. The green line indicates the **Network received**. On hovering over any particular line on the chart, the tooltip displays the Network transmitted and Network received at that specific time. :::hint{type="info"} The time duration for the above graphs is set to **5 minutes** by default. This can be changed by using the Drop-down menu present above the charts. ::: # Deployments This section presents a complete view of all the deployments and details so that they can be monitored. The following details are presented in the deployments table : - **Name:** This column displays the names of deployments. - **Namespace:** This column displays the namespace in which deployment occurred. - **Pods:** This column displays the pods running (available replicas / total replicas) - **Replicas:** This column displays the number of replica pods for the named deployment. - **Actionable insights:** This column displays the number of actionable insights generated for the named deployment. Click the number of actionable insights to view details for the insights (Actionable Insights tab on the details page for that deployment). :::hint{type="info"} Click the **Hide deployments without actionable insights** switch to view-only deployments with no generated insights. ::: - **Age**: This column shows the Age of deployment, viz. the duration since the deployment happened. To view more details about deployment, the user can click on the `View details` option present at the end of the row. The details about the selected deployment are presented in a side panel, as shown below. The following tabs enable viewing of details for specific elements of the deployment: - Deployment name as panel title, Label selectors, Strategy and Labels. - **Conditions:** This tab displays the `Conditions` table with the following columns: Type, Status, Reason, Message, Last updated time and Last transition time. - **Replica set:** This tab displays the `Replica set` table with the following columns: Name, Pods and Age. - **Raw JSON:** The data here is JSON code for the selected deployment from the deployments API exposed by the container platform (Kubernetes, OpenShift etc.). - **Actionable insights:** This tab displays details of the actionable insights generated for the selected deployment. # Replica sets This section presents a complete view of all the replica sets of the cluster and its details. The following details are presented in the replica sets table: - **Name:** This column displays the names of replica sets. - **Namespace:** This column displays the namespace in which the replica set is created. - **Pods**: This column displays the pods running (available replicas / total replicas) - **Age:** This column shows the Age of Replica set, viz. the duration of the replica set. To view more details about the replica set, the user can select the `View details` option present at the end of the row. The details about the selected replica set are presented in a side panel, as shown below. The following different sections are presented in detail: - Replica set name as panel title, Label selectors, Strategy and Labels. - **Pods:** This section displays the `Pods` table with the following columns: Name, Namespace, Status, Age, Node IP and pod IP. - **Services:** This section displays the `Services` table with the following columns: Name, Namespace, Service location, Age and Type. - **Raw JSON:** The data here is JSON data about the selected Replica set from the Replica sets API exposed by Kubernetes. # Stateful sets This section presents a complete view of all the Stateful sets that are part of the cluster, and Stateful set details. The following details are presented in a stateful sets table: - **Name:** This column displays the names of stateful sets. - **Namespace:** This column displays the namespace in which the stateful set is created. - **Service name:** This column displays the service name created for the stateful set responsible for the network identity of the Pods. - **Volume claims:** This column displays the volume claims for the stateful sets. - **Pods**: This column displays the pods running (current replicas / total replicas). - **Replicas:** This column shows the count of replicas created for the stateful set. - **Age:** This column shows the Age of the stateful set, viz. the duration since creation. To view more details about the stateful set, the user can click on the `View details` option present at the end of the row. The details about the selected stateful set are presented in a side panel, as shown below. The following different sections are presented in detail: - Stateful set name as panel title, Strategy, Containers and Labels. - **Raw JSON:** The data here is JSON data about the selected Stateful set from API exposed by Kubernetes. # Daemon sets This section presents a complete view of all the daemon sets of the cluster and its details. The following details are presented in the daemon sets table: - **Name:** This column displays the names of daemon sets. - **Namespace:** This column displays the namespace in which the daemon set is created. - **Node selector:** This column displays the Node selector. - **Pods:** This column displays the pods (number of pods scheduled / number of pods available) - **Age:** This column shows the Age of the Daemon set, viz., the duration of the daemon set. To view more details about the daemon set, the user can click on the `View details` option present at the end of the row. The details about the selected daemon set are presented in a side panel, as shown below. The following different sections are presented in detail: - Daemon set names as panel titles, Strategy, Containers, Tolerations and Labels. - **Raw JSON:** The data here is JSON data about the selected Daemon set from the daemon sets API exposed by Kubernetes. # Jobs This section presents a complete view of Jobs in the cluster and Jobs details. The following details are presented in the jobs table: - **Name:** This column displays the names of jobs. - **Namespace:** This column displays the namespace in which the job is created. - **Completions:** This column displays the completions (parallelism/completions) - **Duration:** This column displays the total run time, viz. start and completion times. - **Age**: This column shows the Age of the job, viz. the duration since it started. - **Conditions**: This column shows the state of the job (Completed, Suspended). To view more details about the job, the user can click on the `View details` option present at the end of the row. The details about the selected job are presented in a side panel as shown below. The following different sections are presented in detail: - Job name as panel title, Labels, Label selectors. - **Events:** This section displays the `Events` table with the following columns: Type, Reason, Message and Age. - **Raw JSON:** The data here is JSON data about the selected job from the jobs API exposed by Kubernetes. # Cronjobs This section presents a complete view of the cluster's cronjobs and details. The following details are presented in the cronjobs table: - **Name:** This column displays the names of cronjobs. - **Namespace:** This column displays the namespace in which the cronjob is created. - **Schedule:** This column displays the schedule on which the cronjob is run. Example : `*/1 * * * *` where `*/X` means: every `X` minutes `*` means: `every minute` - **Suspend:** This column displays the suspended status of the cronjob (True/False). - **Last schedule**: This column shows the last scheduled time until now. - **Age:** This column shows the Age of the cronjob viz. the duration since it started. To view more details about the cronjob, the user can click on the `View details` option present at the end of the row. The details about the selected cronjob are presented in a side panel, as shown below. The following different sections are presented in detail: - Cronjob name as panel title, Concurrency policy, Successful jobs history limit and Successful jobs history limit. - **Events:** This section displays the `Events` table with the following columns: Type, Reason, Message and Age. - **Raw JSON:** The data here is JSON data about the selected cronjob from the cronjobs API exposed by Kubernetes. [title] Cluster details page [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ Learn about this resource for a deep view into individual clusters, to acquire a keen understanding of performance and health. # Cluster details The landing page provides an overview of the container clusters in your hybrid IT estate. It enables an at-a-glance view of cluster health by provider and region, and a general resource status for containers, such as CPU and memory, overutilized and underutilized. It also provides a table cluster list table, providing identifying information about each cluster. To view details about a cluster, click the cluster name. The service navigates to the details page for the selected cluster. The page displays the following information: - Cluster name - Status - The connection type, typically identified by cloud provider. - A table containing the following information: - Environment ID - Location - Kubernetes Version - Created Date - Last Sync - All tags - Number of Pods - Number of Nodes - Number of Alerts - Duration (selectable) - A left navigation bar that presents multiple cluster detail selections as follows: - **Cluster:** Presents data about each Cluster. For more information, see [Cluster](docId:-flLU_jjAQyZUEC39m6sx). - **Actions:** Enables taking an action to resolve potential disruptions before they occur. - **Workloads:** Tab presenting applications running in Kubernetes. For more information, see [Workloads](docId\:WVn8xyjcQFQWVMplGzOMz). - **Network:** Displays available Services and Ingress objects. For more information, see [Network](docId\:tI60TC1ASURLBDPHUO8hW). - **Configuration:** Shows details about configmaps and secrets. For more information, see [Configuration](docId:5fQSykEc1zOtSyMat8DUY). - **Storage:** Shows the persistent volumes of the clusters. For more information, see [Storage](docId\:P9XJ_FtDL57_sbiYDLvdS). - **Access Control:** Shows the Access Control details of the cluster. [Cluster access control](docId\:GfBRUkuksLm60qQ3cJn8y). - **Policy:** A cluster policy restricts the ability to configure clusters based on rules that limit the attributes. For more information, see [Policy](docId\:Iio0qx21cmj5fB0SV7d9K). - [Custom resources](docId\:rz-1X6by2k9S1E6x86jdD)**:** Custom resources are Kubernetes API extensions that allow objects to be created, updated and deleted. # Actions provides actionable insights of container clusters, such as memory and CPU underutilization. If, for example, a particular cluster has a CPU utilization of 14%, your organization is committing a high cost for CPU cycles it is not using. This fact will be part of the data reported in the Actionable Insight quadrant of the landing page. When the offending cluster is identified, the underutilization report is accompanied by a recommendation for adjusting CPU resources to an appropriate level. This recommendation; however, must be tested to ensure that the recommended level does not pose a health risk to the cluster in a production environment. The **Actions** section of the details page accommodates request for things such as reduced CPU resources. The Actions section contains links to two pages: - **Create Resources:** Provides details about the cluster, and a YAML configuration canvas that can receive a YAML script and reconfigure supporting resources for the cluster. - **Actions History:** Displays the history of actions that have been taken in the past, which can be filtered by Action type (such as configuration change and state change) and status (such as In Progress and Failed). Use the following procedure to commit an action to the Kyndryl Actions service: 1. Prepare your YAML script containing the proposed configuration for the target resource. 2. Click the cluster name of the identified cluster (action candidate). The service navigates to the details page for that cluster. 3. Click **Actions** → **Create resources**. The service navigates to the Create resources page for the current cluster. 4. Copy your YAML script to the clipboard. 5. Paste your YAML script onto the script canvas identified by the text "Insert YAML text here". The Create button illuminates, indicating it is active. 6. Click **Create** to submit your request or **Cancel** to abort the request. Clicking **Create **submits the configuration specification to the Kyndryl Actions service and the resource will be updated in accordance with your organization's policy. Explore supported [Actions](docId\:YTcHxTzKywctA-6mUlYQW) to enable effective cluster resource management. [title] Cluster [path] Services/Platform Services/Cloud Management/Container Cluster Management/ An overview of your clusters is preeminent to the management of them. provides such an overview in the form of the Cluster page. From there you can detect potential trouble spots that can guide you to other more specific support elements such as Network and Workloads. When you navigate to the Cluster details page, the service defaults to the Cluster Overview page. The following selections are available in the left navigation bar, providing details for specific elements supporting your container clusters: - Overview - Namespaces - Nodes - Events - Alerts # Cluster overview page The Cluster overview page presents a detailed overview of a cluster. It displays the following information: - **Connection:** Provider that hosts the cluster connection. - **Provider:** Displays the name of the Provider. - **Location:** Displays the code of the location where the cluster is located. - **Application:** Displays all applications associated with the current cluster. - **Environment:** The name of the environement in which the cluster resides. - **Version: **The Kubernetes version of that cluster. - **Deprecated APIs:** The list of APIs that have been deprecated for the current cluster. - **Created Date:** The date on which the cluster was created. - **Last Sync:** The length of time since the container was last synchronized. - **Pods:** The number of pods running in the cluster. you can select this option to go to the Pods to view all the required information about the pods configured in the cluster. - **Nodes:** The number of nodes running in the cluster. you can select this option to go to the Nodes to view all the required information about the nodes configured in the cluster. - **Events:**The number of events that have occurred in a cluster. you can review all the required information about all the events happening in the cluster by going to the Events and selecting this option. - **Alerts:**The total number of alerts for the current cluster. - **Actionable Insights:** All supported actionable insights for the current cluster. - **CPU Resources:** This graph represents the CPU Resource usage by the cluster over a period of time. The red line indicates the **CPU limit**. The green line indicates the **CPU usage** and the yellow line indicates the **CPU requests**. This graph lets you quickly identify whether CPU resource usage exceeds the specified limit. On hovering over any particular line on the chart, the tooltip displays the CPU limit, CPU usage and CPU requests at that specific time. - **Memory Resources:** This graph represents the memory resources used by the cluster over a period of time. The red line indicates the **Memory limit**. The green line indicates the **Memory usage** and the yellow line indicates the **Memory requests**. This graph lets you quickly identify if the Memory resource usage is above the specified limit. On hovering over any particular line on the chart, the tooltip displays the memory limit, usage and requests at that specific time. - **Pods: **This graph represents the number of running and pending pods in the cluster across a period of time. :::hint{type="info"} The duration for the CPU and memory resources graphs is set to **5 minutes** by default. This can be changed by using the drop-down menu present above the charts. ::: # Namespaces This section gives you a detailed view of all the cluster's namespaces. We fetch this information from your cluster using on-demand discovery that taps into Kubernetes' APIs. Check out these key details in the Namespace section: - **Name**: Here, you see each namespace's name. - **Pods**: This count reflects the pods in each namespace. Click on the number to delve into pod details. - **CPU Requests**: Find out how much CPU power each namespace requests. - **CPU Limits**: This shows the maximum CPU resources each namespace can use. - **Memory Requests**: Discover the memory demands of each namespace. - **Memory Limits**: Understand the upper limits of memory set for each namespace. :::hint{type="info"} Prometheus needs to activated on the cluster to view the statistics data – including CPU, memory requests and limits and pod count. ::: To view more details about a namespace, you can either click on the row or the **View details** option present at the end of the row. The details about the namespace are presented in a side panel, as shown below. # Nodes This section presents an overview of the nodes present in a cluster. The data presented in this section is fetched directly from the cluster via on-demand discovery (which uses APIs exposed by Kubernetes). The following details are presented in this section: - **Name:** This column presents the name of the nodes. - **OS:** This is the Operating System reported by the node. - **CPU Requests:** This is the CPU resource request made by the node. - **CPU Limits:** This is the specified CPU limit of the node. - **CPU Allocation:** This is the allocatable CPU resource for the node. - **Memory Request:** This is the request for memory resources made by the node. - **Memory Limit:** This is the specified memory limit of the node. - **Memory Allocation:** This is the allocatable memory resource for the node. For each node, further details can be obtained by clicking either on the row directly or on the** View details** option present at the end of each row. The service presents details about the selected node in four tabs: - **Conditions:** This tab displays the `Conditions` table with the following columns: Type, Status, Message, Last transition time, and Last Heartbeat time. - **Pods:** Presents details about the pods running on the node: - Pods name - Namespace - Container - CPU requests - CPU limits - Memory requests - Memory limits - Pod IP :::Paragraph{indent="1"} Click the expand chevron for any pod to view the log for that pod. ::: - **Raw JSON:** Presents the JSON script that defines the selected node. - **Monitoring:** Presents four graphs: - **CPU resources**, displaying usage, requests and limits over time at one-minute intervals: - CPU usage - CPU requests - CPU limit - Physical limit - **Memory resources**, displaying usage, requests and limits over time at one-minute intervals: - Memory usage - Memory limit - Memory requests - Physical limits - **Network transmitted**, displaying data in Bytes over time at one-minute intervals: - Network transmitted - Network received - **File usage**, displaying data in GB over time at one-minute intervals: - File used - File capacity Hover over each graph to display data point details. # Events This section gives details about all the events that have occurred in the cluster. The data displayed here is fetched directly from the cluster via on-demand discovery (which uses APIs exposed by Kubernetes). The following details are presented in this section: - **Type:** This column displays the type of events that have occurred. - **Reason:** This column displays the reason for the occurrence of the events. - **Namespace:** This column presents the event's namespace. - **Message:** This column presents the message related to the event, which is a brief description of what the event is. - **Involved Object:** This column displays the object involved with the event. - **Count:** This column displays the recorded number of occurrences of the event. - **First Seen:** This column displays the date on which the event first occurred. - **Last Seen:** This column displays the date on which the event last occurred. The events can be filtered according to the namespace to which they belong by using the namespace filter Drop-down menu in the top right corner above the events table. By default, events from all namespaces are displayed in the events section. More details about an event can be found by selecting the **View details** option at the end of each row. The data here is JSON data for the selected event. # Alerts This page gives you a complete overview of all the alerts that you have to review for a cluster. Cluster alerts are categorized into two distinct sections: **Pod Alerts** and **Cluster Alerts**. The columns in the corresponding tables differ between these categories. For Pod Alerts, all existing columns are detailed below. Conversely, Cluster Alerts do not include the **Namespace **and **Pod **columns within the table. The following details are presented in the Alerts table: - **Namespace:** This column displays the namespace to which the Pod or Node where the alert occurred belongs. - **Severity:** This column indicates the severity of an alert. - **Status:** This represents the status of the cluster. - **Pod:** This column displays the Pod where the alert occurred. - **Summary:** This presents the overview of the alert. - **Description:** This column presents the Description of the alert. - **Alert Started At:** This displays the time the event leading to the alert occurred. You can sort the alerts table according to the status, Severity of the alerts, or the time they occurred to review the alerts according to priority. - [Workloads](docId\:WVn8xyjcQFQWVMplGzOMz): Acquire essential insights into Kubernetes components such as Pods, Deployments, and others, which are crucial for effective cluster optimization. - [Network](docId\:tI60TC1ASURLBDPHUO8hW): Explore elements of the Network component. - [Cluster Configuration](docId\:YhjWGblS4MlDAUw5_kYG8): Learn the configuration procedures that enable Secrets and HPA (Horizontal Pods Autoscaler). - [Storage](docId\:P9XJ_FtDL57_sbiYDLvdS): Understand the storage architecture. - [Cluster access control](docId\:GfBRUkuksLm60qQ3cJn8y): Manage your Kubernetes cluster access using a role-based approach. - [Policy](docId\:Iio0qx21cmj5fB0SV7d9K): Manage policies and attributes supported by the service. - [Custom resources](docId\:rz-1X6by2k9S1E6x86jdD): Set custom resource definitions to manage objects such as namespaces, pods and services. [title] Missing data notifications [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ # Notification description sources metrics and logs using Prometheus to derive actionable insights and show CPU and memory usage. In the rare event that Prometheus derived data for any resource is missing for more than two days, the notification icon shows an alert providing details of the resource and what metric data is missing. The notification icon displays the number of new notifications. To view the notifications, click the notification icon to display a drop-down menu of these new notifications. Select** View** on the tile containing the missing data notification for details about the resource and the missing metric data. The message will take the following form: The CPU and/or Memory metrics for the container *container\_id* within the *namespace\_name* is missing for more than 48 hours. Please consider validating the connection parameters. [title] Supported Cloud providers [path] Services/Platform Services/Cloud Management/Container Cluster Management/ Review the cloud providers supported by for managing and operating Kubernetes and container-based workloads across both **public and private cloud environments**. Cloud integration enables the secure exchange of data, services, and operational processes between one or more cloud environments. supports major public and private cloud platforms, providing a centralized way to provision, monitor and manage container clusters while maintaining consistent operations across different cloud infrastructures. # Supported cloud provider integration The following cloud providers are supported for real-time data exchange: - **AWS Cloud:** Configure an AWS Cloud account view permission for to pull data from AWS. - **Azure Cloud Account: **Configure an account to view permission for to pull data from Azure Resource Manager. - **Google Cloud Platform**: Configure an account view permission for to pull data from Google Cloud Platform. - **IBM Cloud: **Configure an account view permission for to pull data from IBM Cloud. [title] GCP Cloud [path] Services/Platform Services/Cloud Management/Container Cluster Management/Prometheus and Alerts/ Harness the power of Prometheus within the Google Cloud Platform. By following these user-centric steps, you can easily monitor your cloud infrastructure's performance and health. # Prerequisites - Ensure you have `helm` installed on your system. # Setting Up the environment - Start by adding the public Kubernetes chart repository to your Helm configuration with: `helm repo add stable https://kubernetes-charts.storage.googleapis.com`. - Considering organization and ease of management, let's create a separate namespace named 'monitoring' for Prometheus: `kubectl create ns monitoring`. - With the namespace ready, it's time to deploy the Prometheus Operator chart: `helm install prometheus stable/prometheus-operator --namespace monitoring`. - To confirm everything's in place, execute the following command: `kubectl --namespace monitoring get pods -l "release=prometheus"`. # Prometheus dashboard With Prometheus now up and running, it is time to dive into its comprehensive dashboard: - Use the Kubernetes proxy to access the Prometheus dashboard securely. This method ensures you're tunneling your connection securely through the Kubernetes API server with the following command: `kubectl port-forward -n monitoring prometheus-prometheus-prometheus-oper-prometheus-0 9090`. - Once a secure connection is established, you can access the dashboard. [title] DR for Oracle Database Leveraging Data Guard Broker (DGMGRL) [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/Solution usage/ # Overview This document provides a technical solution guide for integrating Oracle Data Guard Broker (DGMGRL) with the AIOps-based resiliency platform. The platform enables organizations to manage business continuity and cyber resiliency for multiple IT applications and databases through a unified Platform-as-a-Service (PaaS) model. The integration uses the DGMGRL Command-Line Interface instead of SQL\*Plus-based orchestration. Ansible roles and tasks are used to connect to Oracle Data Guard Broker nodes via SSH and execute DGMGRL commands to perform switchover, switchback and failover operations. The integration aims to automate key tasks and configuration activities using the (AIOps) platform, enhancing efficiency, scalability and reliability across IT environments. # Objective Oracle Disaster Recovery (DR) solutions implemented with Oracle Data Guard Broker (DGMGRL) are designed to ensure the availability, reliability and continuity of critical databases during disasters or unexpected failures. Key objectives include the following: ## Business continuity - **Minimize downtime**: Reduce business disruption by minimizing database recovery times using DGMGRL-managed transitions. - **Maintain access**: Ensure continuous data and service availability during unplanned incidents. ## Data protection - **Preserve data integrity**: Prevent data loss and corruption across primary and standby databases through broker-managed replication. - **Ensure consistency**: Synchronize changes between primary and standby environments, monitored via TRANSPORT-ON / APPLY-ON status in the DG configuration. ## Disaster Recovery - **Enable fast recovery**: Support rapid failover to standby databases using the DGMGRL FAILOVER TO command. - **Ensure redundancy**: Deploy geographically dispersed standby databases to safeguard against localized outages and major failures. ## High availability - **Enhance fault tolerance**: Improve system resilience using Oracle Data Guard Broker-managed primary and physical standby databases. - **Balance load**: Distribute database workloads across nodes to maintain performance and prevent bottlenecks. ## Scalability - **Horizontal scaling**: Expand capacity by adding standby databases to the broker configuration. - **Vertical scaling**: Improve performance by scaling Oracle nodes based on demand. ## Flexibility - **Support configuration modes**: Supports MaxPerformance, MaxProtection, and MaxAvailability Data Guard protection modes. - **Provide configuration options**: Support both synchronous and asynchronous replication to meet specific organizational requirements. ## Automated management - **Simplify management with DGMGRL**: Streamline configuration, monitoring, and maintenance of DR environments via the Data Guard Broker CLI. - **Utilize monitoring tools**: Collect show configuration and show database outputs to monitor performance and health of primary and standby databases. ## Compliance and security - **Support compliance**: Align with regulatory requirements for data availability, integrity, and retention. - **Ensure secure communication**: Implement SSH-based authentication and encrypted Oracle connections between primary and standby systems. # Architecture diagram, explanation with the required port number and network flow The Oracle Data Guard Broker Disaster Recovery (DR) solution ensures business continuity for applications running on the Oracle database. It protects data by replicating redo log streams from the production site to a remote DR site, coordinated through the DGMGRL broker process. This replication and orchestration process is automated using Kyndryl Resiliency Orchestration (Ansible Automation Platform), which simplifies management and keeps the DR database continuously synchronized with the production environment through the broker. ## Architecture network flow diagram ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/sUgqMDSIuS6ybtwQ_GHhg_image.png) ## Required Ports ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/cxFhayYtNfeLEg0wljuhH_image.png) # Risk, Assumptions, Constraints and Dependencies (RACD) This section defines the operational expectations, environmental prerequisites, and design boundaries for integrating with Oracle Data Guard Broker. It is intended to promote consistent governance, delivery readiness and reliable steady-state operations. ## Assumptions The following conditions are expected to be true in the customer environment for the solution to function reliably: - Secure, stable network connectivity exists between the automation execution point (Jump Host) and the Oracle Primary (PR) and Disaster Recovery (DR) servers. - A customer-approved Jump Host is available and used as the execution point for data collection, insights, prechecks and orchestration workflows. - Oracle Data Guard Broker is already configured and operational. The dgmgrl binary is available and accessible from the Oracle $ORACLE\_HOME/bin/ directory on both PR and DR servers. - Required host-level entries and access controls permitting automation (Jump Host → PR/DR) are in place. - The automation OS user has the necessary permissions to: - Execute Oracle DGMGRL command-line utilities. - Access $ORACLE\_HOME and $ORACLE\_SID environment variables on the target servers. - The database user assigned for automation has the necessary privileges (SYSDG or SYSDBA) to connect to the Data Guard Broker and execute DGMGRL commands. - Oracle Database version 19c or later is deployed; versions below 19c are unsupported and will fail discovery/validation. - The PR and DR operating system and database credentials are the same across both nodes. This is the user's responsibility. - The ORACLE\_HOME and ORACLE\_SID environment variables are correctly configured on both PR and DR servers and are resolvable by the automation OS user. ## Dependencies The solution relies on the availability and correct operation of the following components: - A customer-provided Jump Host with verified SSH connectivity to PR and DR servers, configured as a two-hop proxy in CACF AAP. Ansible Automation Platform (CACF AAP) with: - Job templates - Inventories - Credentials (OS credentials and Oracle DB credentials as custom credential types) - Execution Environments configured for Oracle DGMGRL workflows - A reachable Git repository containing automation playbooks and roles (kyndryl.dr\_oracle\_dgmgrl, kyndryl.dr\_custom\_actions, kyndryl.dr\_output\_json). - An operational Oracle Data Guard Broker process (dgmgrl) on both PR and DR servers, capable of returning configuration status and replication health information. - The show configuration and show database DGMGRL commands must return parseable output for discovery and validation operations. ## Constraints The solution is bounded by the following architectural and operational constraints: - Supports only Oracle Data Guard Broker (DGMGRL) for replication and orchestration of: - Failover - Switchover - Switchback - (including associated prechecks for each operation) - Workload targeting relies on: - pr\_db\_name and dr\_db\_name mappings defined in the input JSON - Any inconsistency in these names compared to the broker configuration will cause workflow failures. - The solution requires a functioning DGMGRL installation accessible from $ORACLE\_HOME/bin/ on both PR and DR Oracle servers. - Oracle versions below 19c are outside the supported scope and will not pass discovery or validation. - The PR and DR OS credentials must match. Separate OS credentials per node are not supported. ## Risks The following risks are inherent to DGMGRL-based orchestration and require operational vigilance: - Network and access risk: Connectivity issues or firewall restrictions between the Jump Host and PR/DR servers may block SSH access (Port 22), preventing discovery, monitoring, and failover operations. - Configuration drift risk\:Any mismatch in Oracle Data Guard Broker configuration (e.g., DG mode, database names, transport services) may disrupt replication and break orchestration workflows. - Credential and privilege risk: Incorrect or expired OS/DB credentials, or insufficient DGMGRL privileges, will cause all operations to fail. The PR and DR credentials must be identical. - Application write-activity risk: If applications continue writing to the primary during switchover/switchback windows, validations may fail or recovery timelines may be extended. - Replication lag / RPO risk: Excessive replication lag may lead to unacceptable RPO deviations and impact failover outcomes. - Repository dependency risk: Changes or unavailability of the Git repository containing automation assets (kyndryl.dr\_oracle\_dgmgrl) may break workflow execution. - Input correctness risk: Incorrect pr\_db\_name / dr\_db\_name values or mismatches with the broker configuration can lead to targeting failures or false error conditions. Typical mitigations include comprehensive prechecks, credential validation, maintaining consistent Oracle installation paths, enforcing operational sequencing, validating application shutdown before transitions and conducting regular DR drills using standardized runbooks and error-handling guidelines. # Jumphost In many customer environments, direct connectivity to endpoints within the customer's network is not available. In these cases, a **jumphost **serves as a secure access point, enabling connectivity to systems located behind firewalls or within other restricted network environments. The Oracle DG Broker automation uses the resiliency\_host (Jump Host) as the intermediary for all SSH connections to PR and DR servers. It must be configured as a two-hop proxy in CACF AAP by the AAP administrator. For more information, go to: [Jumphost ](docId\:Vh9B2qjBp0AU12ZerzALD)module installation guide for . ## Supported versions | | | | | -------------------------------- | ----------------------------- | -------------------------------------------- | | Oracle Enterprise Linux 7.3 | Oracle Logs 19c/21c (64 bits) | Data Guard Broker (DGMGRL) 19c/21c (64 bits) | | RHEL 7.0 / 8.0 / 8.4 / 8.6 / 9.2 | Oracle Logs 19c/21c (64 bits) | Data Guard Broker (DGMGRL) 19c/21c (64 bits) | :::hint{type="info"} Oracle versions below 19c are not supported and will fail discovery and validation. ::: # Minimum privileges - The database user must have **\`SYSDG\`** or **\`SYSDBA\`** privileges to connect to the Oracle Data Guard Broker via DGMGRL. - The operating system user must have sudo permissions (or equivalent) to execute Oracle tools such as dgmgrl. - The automation OS user must be able to resolve ORACLE\_HOME and ORACLE\_SID environment variables on both PR and DR servers. # Database access and write-location requirements - The database user must have **\`SYSDG\`** or **\`SYSDBA\`** privileges to connect to the Oracle Data Guard Broker via DGMGRL. - The operating system user must have sudo permissions (or equivalent) to execute Oracle tools such as dgmgrl. - The automation OS user must be able to resolve ORACLE\_HOME and ORACLE\_SID environment variables on both PR and DR servers. # Database access and write-location requirements ## Database Access Requirements The DGMGRL-based automation requires the ability to connect to the Data Guard Broker and execute commands. The database user must have the following privileges at minimum: | **Privilege** | **Type** | **Required For** | | ------------------------------------------ | ------------------------------------- | ------------------------------------------------------------------------------- | | SYSDG | System | Connect to DGMGRL and execute broker commands (preferred least-privilege role). | | SYSDBA | System | Full DGMGRL access (used as alternative when SYSDG is not available). | DGMGRL commands used during automation: | **DGMGRL Command** | **Purpose** | | ----------------------------------------------- | ---------------------------------------------------- | | show configuration | Validate broker configuration status and DG mode. | | show database \ | Retrieve database role, transport, and apply status. | | failover to \ | Execute failover to standby. | | switchover to \ | Execute switchover to standby. | | switchover to \ | Execute switchback to original primary. | ## Required write-access locations The automation OS user must have the ability to access the following paths: - \`$ORACLE\_HOME/bin/\` — Execute access to dgmgrl binary. - \`$ORACLE\_HOME/lib/\` — Read access to Oracle runtime libraries. - \`/tmp/\` — Write access for temporary working files and script artifacts generated during automation. # Server permissions and library requirements ## Operating system permissions required | **Permission** | **Path** | **Access Level** | **Purpose** | | ------------------------------------------- | ------------------------------------- | --------------------------------------------- | ------------------------------------------------- | | Execute | $ORACLE\_HOME/bin/dgmgrl | Execute (x) | Execute DGMGRL CLI for broker operations. | | Read | $ORACLE\_HOME/lib/ | Read (r) | Access Oracle runtime and client libraries. | | Read | $ORACLE\_HOME/bin/ | Read (r) | Access Oracle binary path. | | Read/Write | /tmp/ | Read/Write (rw) | Create temporary working files and spool outputs. | ## Environment variables required | **Variable** | **Example Value** | **Purpose** | | ----------------------------------------- | ---------------------------------------------- | ----------------------------------------------------------------- | | ORACLE\_HOME | /u01/app/oracle/product/19c | Specifies Oracle installation path; used to locate dgmgrl binary. | | ORACLE\_SID | PRODDB | Identifies the target Oracle instance for DGMGRL connection. | | PATH | $ORACLE\_HOME/bin:$PATH | Enables access to dgmgrl and other Oracle utilities. | | LD\_LIBRARY\_PATH | $ORACLE\_HOME/lib:$LD\_LIBRARY\_PATH | Ensures Oracle shared libraries are discoverable. | These variables are fetched dynamically from the target servers during automation execution via the get\_oracle\_env custom action task. ## Summary of access levels - OS User - Must be a member of oinstall and dba groups. - Requires read/execute access to $ORACLE\_HOME/bin/dgmgrl. - Database User - Must have SYSDG or SYSDBA privilege for DGMGRL connectivity. - The same DB credentials must be used for both PR and DR servers. - Automation Service Account - Requires SSH access to PR and DR servers. - Must be able to resolve Oracle environment variables (ORACLE\_HOME, ORACLE\_SID). - Sudo Configuration - For automation execution, configure: automation\_user ALL=(oracle) NOPASSWD: /u01/app/oracle/product/19c/bin/dgmgrl # Features of the solution The solution supports the following features: ## Insights - Data collection: Collects DB role, DG status, configured DG mode, transport and apply status from both PR and DR servers using DGMGRL show database commands. - RPO calculation: Provides guidance and visibility into Recovery Point Objectives based on DGMGRL replication lag data. - Data copy (Data Lag): Calculates the data lag between the production site and the disaster recovery (DR) site. - Metrics: Evaluates the server status to determine whether replication is active or has stopped (TRANSPORT-ON / APPLY-ON). - RPO batch: Executes the RPO data collection workflow on a scheduled basis to gather replication lag information and calculate Recovery Point Objective (RPO) metrics for reporting and visualization. - Data copy batch: Executes the data lag collection workflow on a scheduled basis to measure the synchronization gap between the production and disaster recovery (DR) databases and generate data copy metrics. - Metrics batch: Executes the replication health monitoring workflow on a scheduled basis to collect transport and apply status information and determine the operational state of Data Guard replication. - Aggregate insights: Collects metrics, RPO, and data lag in a single combined playbook (aggregate\_insights\_oracledgmgrl.yml). ## Automation - Failover dry run: Checks whether the DR database is ready for failover (Ready for Failover: Yes). - Failover: Initiates a DGMGRL FAILOVER TO \ operation. - Switchover dry run: Validates DG configuration status, database roles, and switchover readiness on both PR and DR servers. - Switchover: Initiates a DGMGRL SWITCHOVER TO \ operation (operation code: DGB\_SO). - Switchback dry run: Validates DG configuration status and switchback readiness on both PR and DR servers. - Switchback: Initiates a DGMGRL switchover back to the original primary (operation code: DGB\_SB). # Benefits of the solution Performs advanced prechecks on all automation to ensure triggers only execute when the system is in the correct state (validates DG configuration status, database roles and switchover/failover readiness before executing). - Conducts automatic post-operation validation of database roles on both PR and DR servers after every switchover, switchback and failover operation. - Uses the DGMGRL show configuration and show database commands to provide real-time broker-level visibility into configuration health. - Detects idempotent states, if the system is already in the target state (e.g., already failed over), the playbook reports success without re-executing the operation. - Executes DR operations only when the DG configuration status confirms broker readiness (no gap, transport active). - Displays real-time metrics and alerts on the dashboard. # Supported alerts, conditions and descriptions | **Alert / Condition** | **Description** | | -------------------------------------------------- | ---------------------------------------------------------------------- | | TRANSPORT-ON | Primary database is actively shipping redo logs to the standby. | | APPLY-ON | Standby database is actively applying redo logs from the primary. | | Ready for Failover: Yes | DR database is ready to accept a DGMGRL failover command. | | DG Configuration SUCCESS | Broker configuration is healthy and all members are in expected state. | | Database Role PRIMARY | Database is operating as the primary instance. | | Database Role PHYSICAL STANDBY | Database is operating as a physical standby instance. | | DG Mode MaxPerformance | Data Guard is configured in maximum performance mode | | DG Mode MaxProtection | Data Guard is configured in maximum protection mode. | | DG Mode MaxAvailability | Data Guard is configured in maximum availability mode. | # The automation flow/tasks within the automation ## Precheck tasks ### Switchover Precheck (\`oracle\_dgmgrl\_switchover\_precheck.yml\`) 1. Initialize variables from resources list (all hosts). 2. Get credentials from AWX. 3. Validate input parameters (validate\_oracledgmgrl\_input.yml). 4. Fetch Oracle home directory from environment on PR and DR servers (get\_oracle\_env). 5. Set oracle\_home and oracle\_sid facts. 6. Validate DG configuration status on DR server (show\_configuration.yml). 7. Validate database role status on PR server — expected: PRIMARY. 8. Validate database role status on DR server — expected: PHYSICAL STANDBY. 9. Validate database switchover readiness on PR server (get\_validate\_db\_status.yml). 10. Validate database switchover readiness on DR server (get\_validate\_db\_status.yml). 11. Generate final switchover precheck output. ### Switchback Precheck (\`oracle\_dgmgrl\_switchback\_precheck.yml\`) 12. Initialize variables from resources list (all hosts). 13. Get credentials from AWX. 14. Validate input parameterS. 15. Fetch Oracle home directory from environment on PR and DR servers. 16. Validate DG configuration status on DR server. 17. Validate database role status on DR server, expected: PRIMARY (post-switchover state). 18. Validate database role status on PR server, expected: PHYSICAL STANDBY (post-switchover state). 19. Validate database switchback readiness on PR and DR servers. 20. Generate final switchback precheck output. ### Failover Precheck (\`oracle\_dgmgrl\_failover\_precheck.yml\`) 21. Initialize variables from resources list (all hosts). 22. Get credentials from AWX. 23. Fetch Oracle home directory from environment on DR server. 24. Validate DR database is ready for failover — checks Ready for Failover: Yes 25. Generate final failover precheck output. ## Automation task flow ### Switchover (\`oracle\_dgmgrl\_switchover.yml\`) 26. Initialize switchover runtime variables. 27. Get credentials from AWX. 28. Validate input parameters. 29. Fetch Oracle home on PR and DR servers. 30. Get database role status on PR and DR servers (parallel). 31. Detect if setup is already in switched-over state (PR=PHYSICAL STANDBY, DR=PRIMARY). 32. Execute run\_switchover.yml task on DR server (operation: DGB\_SO), skipped if already switched over. 33. Validate post-switchover database role on PR server, expected: PHYSICAL STANDBY. 34. Validate post-switchover database role on DR server, expected: PRIMARY. 35. Generate final switchover output. ### Switchback (\`oracle\_dgmgrl\_switchback.yml\`) 36. Initialize switchback runtime variables. 37. Get credentials from AWX. 38. Validate input parameters. 39. Fetch Oracle home on PR and DR servers. 40. Get database role status on PR and DR servers (parallel). 41. Detect if setup is already in switched-back state (PR=PRIMARY, DR=PHYSICAL STANDBY). 42. Execute run\_switchback.yml task on PR server (operation: DGB\_SB), skipped if already switched back. 43. Validate post-switchback database role on PR server, expected: PRIMARY. 44. Validate post-switchback database role on DR server, expected: PHYSICAL STANDBY. 45. Generate final switchback output. ### Failover (\`oracle\_dgmgrl\_failover.yml\`) 46. Initialize failover runtime variables. 47. Get credentials from AWX. 48. Fetch Oracle home on DR server. 49. Get database role status on DR server. 50. Detect if setup is already in failover state (DR=PRIMARY). 51. Execute run\_failover.yml task on DR server, skipped if already failed over. 52. Validate post-failover database role on DR server, expected: PRIMARY. 53. Generate final failover output. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/qGjRAtqLSx-rxdGIe38bB_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/8AowstrqW9S9qtIEZdH0__image.png) # Known limitations and prerequisites The following prerequisites and limitations define the supported operational boundaries, configuration requirements and environmental dependencies for the Oracle Data Guard Broker integration. Understanding these considerations helps ensure successful deployment, reliable automation execution and consistent disaster recovery operations. ## Known limitations - OS authentication is not validated. - The solution has been tested and validated only for users with the SYSDBA or SYSDG role. - The PR and DR operating system and database credentials must be identical. Separate credentials per node are not supported. - A custom credential type must be created in AWX/CACF AAP for Oracle DB credentials (oracle\_user, oracle\_password) and OS credentials (os\_username, os\_password). ## Unsupported scenarios - Multi-site Data Guard environments (more than one standby). - Fallback scenarios. - Reverse failover (failover back to the primary site after an unplanned failover without a switchback). - Data Guard environments not managed by the DGMGRL Broker. ## Prerequisites - Oracle Data Guard Broker nodes must be configured to allow connectivity between the DG server and the Jump Host. They must also be set up as a two-hop proxy in CACF AAP. This configuration is performed by the CACF AAP administrator. - Oracle DG Broker nodes must support SSH access (Port 22). - The Oracle DG server's IP address or fully qualified domain name (FQDN), along with OS username and Oracle DB username/password, must be provided. The primary and disaster recovery (PR and DR) OS and database credentials must be the same. - Port 1521 (default) must be open to allow DG node connectivity between PR and DR. - The dgmgrl binary must be installed and accessible at $ORACLE\_HOME/bin/dgmgrl on both PR and DR servers. - ORACLE\_HOME and ORACLE\_SID environment variables must be configured on the target Oracle servers. - The Oracle hosts (PR and DR) must be added to the AAP inventory. - Credential labels for both the primary and DR Oracle servers must be created in Ansible Tower or CACF AAP. - The Ansible roles kyndryl.dr\_oracle\_dg\_mgrl, kyndryl.dr\_custom\_actions, and kyndryl.dr\_output\_json must be available via the roles/requirements.yml and the configured Git source control project. # Setting up the solution For detailed instructions on the onboarding process, refer to the general onboarding guide. # Inputs for onboarding The following variables are commonly used across the operations: | | | | | | | ----------------------------- | ---------------------------------------------------------- | ----------------------------- | ----------------------------- | ----------------------------- | | pr\_db\_server | Primary database server IP address or FQDN | 192.168.X.XX | Yes | Yes | | dr\_db\_server | Disaster recovery database server IP address or FQDN | 172.168.X.XX | Yes | Yes | | os\_username | Operating system username (same for PR and DR) | oracle | No | Yes | | os\_password | Operating system password (same for PR and DR) | \*\*\*\*\* | No | Yes | | oracle\_user | Oracle database username | sys | No | No | | oracle\_password | Oracle database password | \*\*\*\*\* | No | No | | pr\_db\_name | Primary database name (as registered in DG Broker) | orcl\_pr | Yes | Yes | | dr\_db\_name | DR database name (as registered in DG Broker) | orcl\_dr | Yes | Yes | | oracle\_pr\_db\_role | Oracle database role for primary | SYSDG | Yes | Yes | | oracle\_dr\_db\_role | Oracle database role for DR | SYSDG | Yes | Yes | | pr\_db\_port | Primary database listener port | 1521 | Yes | Yes | | dr\_db\_port | Disaster recovery database listener port | 1521 | Yes | Yes | | resiliency\_host | CACF jump server used for connecting to the Oracle servers | localhost | Yes | Yes | | resiliency\_no\_log | Suppress sensitive output in Ansible logs | true | No | No | | | | | | | ## Inputs for automation The following variables are used for all supported automation playbooks: | | | | | | | | ----------------------------- | --------------------------------------------------------- | ----------------------------- | ----------------------------- | ----------------------------- | --------------------------------------------------------- | | pr\_db\_server | Primary database server host IP address or FQDN | 192.168.X.XX | Yes | Yes\_1 | — | | dr\_db\_server | Disaster recovery database server host IP address or FQDN | 172.168.X.XX | Yes | Yes | — | | os\_username | OS username (same for PR and DR) | oracle | No | Yes | — | | os\_password | OS password (same for PR and DR) | \*\*\*\*\* | No | Yes | — | | oracle\_user | Oracle database username | sys | No | No | — | | oracle\_password | Oracle database password | \*\*\*\*\* | No | No | — | | pr\_db\_name | Primary database name | orcl\_pr | Yes | Yes | Must match broker-registered DB name exactly | | dr\_db\_name | DR database name | orcl\_dr | Yes | Yes | Must match broker-registered DB name exactly | | oracle\_pr\_db\_role | Oracle database role for primary | SYSDG | Yes | Yes | — | | oracle\_dr\_db\_role | Oracle database role for DR | SYSDG | Yes | Yes | — | | pr\_db\_port | Primary database port | 1521 | Yes | Yes | — | | dr\_db\_port | Disaster recovery database port | 1521 | Yes | Yes | — | | resiliency\_host | CACF jump server used to connect to the Oracle servers | localhost | Yes | Yes | Use consistent credential naming across PR and DR servers | | resiliency\_no\_log | Suppress sensitive output in Ansible logs | true | No | No | Set to false for debugging only | | | | | | | | ## Example input JSON (\`input.json\`): ```javascript { "workload_id": "workload-546f4528-91e0-4761-8829-121e99acde76", "bac_id": "112233", "workload_name": "Oracle", "os_username": "oracle", "os_password": "*****", "resiliency_no_log": false, "resources": [ { "pr_db_server": "192.xx.xx.xx", "dr_db_server": "172.xx.xx.xx", "pr_db_name": "orcl_pr", "dr_db_name": "orcl_dr", "oracle_user": "sys", "oracle_password": "*****", "oracle_pr_db_role": "SYSDG", "oracle_dr_db_role": "SYSDG", "pr_db_port": 1521, "dr_db_port": 1521 } ] } ``` ## Project creation A project is a construct/structure used only for the discovery and configuration of workload. You can use it as a filter to navigate across the discovery and configuration menus. A project has a start date and expected end date that help the user track the onboarding time. For detailed instructions on how to create a project, see Project. For this solution, while selecting the blueprint when creating a project, select **DR-OracleDB-leveraging-DataGuard-Broker** from the **Blueprint** drop-down of the **Project Configuration** panel. For this solution, while selecting the blueprint when creating a project, select **DR-OracleDB-leveraging-DataGuard-Broker** from the **Blueprint** drop-down of the **Project Configuration** panel. ## Discovery After mapping the blueprint with the project, the user performs the discovery of all the workloads under the specific blueprint. For detailed instructions on Discovery, see Discovery. For this solution, during the data collection in the discovery phase, the user needs to provide the details for the following parameters: - Primary DB name \\\* - Primary DB Port \\\* - Primary DB Role \\\* - Primary Nodes Host Group \\\* - DR DB name \\\* - DR DB Port \\\* - DR DB Role \\\* - DR Nodes Host Group \\\* - Enter DR Node Group - Credentials Label \\\* - Automation Target Group \\\* - Automation Execution Environment - Automation Target host \\\* ## Resourcing You can create a workload for a specific project and the associated blueprint by selecting a resource on the Resource screen. After discovering a specific blueprint, users can view all the discovered resources mapped with the blueprint on the Resource page. After selecting a workload, click **Configure**. The user is taken to the Onboard screen, where they can add Insights and Automation. For detailed instructions on the Resource, see **Resource.** ## Onboarding The onboard page is used to list the created workloads. The user needs to provide additional configurations that can be used for monitoring and automation. For detailed instructions on the Onboard screen, see **Onboard**. Add Insights and Automation, configure the basic parameters under the Basic tab and validate the provided inputs. Users do not need to configure the parameters appearing under the Insights and Automation tab. ## Troubleshooting The following troubleshooting guidance helps identify and resolve common issues that may occur during Oracle Data Guard Broker discovery, data collection, validation, monitoring and recovery operations. ## SFS upload failed during data collection - Verify that the SFS upload URL is correct. - Confirm that the required upload permissions are granted. ## Data collection succeeded, but resources are not displayed on the UI - Ensure the extension service is up and running. - Check for any issues in the data streaming pipeline. ## DGMGRL connection fails - Verify that ORACLE\_HOME and ORACLE\_SID are correctly set on the target server. - Confirm that the dgmgrl binary exists at $ORACLE\_HOME/bin/dgmgrl and is executable by the automation OS user. - Confirm that the Oracle listener is running on Port 1521 and is accessible from the Jump Host. ## Precheck fails with unexpected database role - Verify that the pr\_db\_name and dr\_db\_name values match the database names registered in the DG Broker configuration (show configuration output). - Confirm that the PR database is in PRIMARY role and the DR database is in PHYSICAL STANDBY role before initiating switchover or switchback. ## Error codes and recommendations | **Error Code** | **Description** | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | 8400 | pr\_db\_server, dr\_db\_server, oracle\_listener\_port, oracle\_db\_role, and Oracle database name are not configured. | | 8401, 8406, 8408, 8410, 8412, 8414, 8417 | ORA error in the output due to misconfiguration. Please validate the inputs provided correctly. | | 8402 | Failed to get the intended state of the database (TRANSPORT-ON or APPLY-ON). | | 8403 | Failed to get the database role status (PRIMARY or PHYSICAL STANDBY). | | 8404 | Unable to get the database configuration status — it should be SUCCESS. | | 8405 | Expected database status does not match with the current status. | | 8407 | Oracle Database configuration status is not in the correct state. | | 8409 | Database failover operation failed. | | 8411 | Database switchover operation failed. | | 8413 | Failed to get the database configuration status. | | 8415 | Failed to get apply log detail from the database server. | [title] IBM Cloud [path] Services/Platform Services/Cloud Management/Container Cluster Management/Prometheus and Alerts/ Improve your IBM Cloud infrastructure monitoring by integrating Prometheus. This straightforward guide walks you through the configuration process, making it simpler and more user-focused. Let’s jump right in! # Initial setup and tool installation - Begin by installing the `ibmcloud` tool on your machine. Get it [here](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli). - If you're using an RHEL machine, opt for this version: [RHEL ibmcloud tool](https://download.clis.cloud.ibm.com/ibm-cloud-cli/2.2.0/IBM_Cloud_CLI_2.2.0_amd64.tar.gz). # Plugin installation - Enhance the functionality of the ibmcloud tool by installing the following plugins: - `ibmcloud plugin install container-service` - `ibmcloud plugin install container-registry` - `ibmcloud plugin install observe-service` # Connection and configuration - Ensure `kubectl` is installed on your system. - Connect to the IBM Cloud CLI with this command: `ibmcloud login -a cloud.ibm.com -r jp-tok -g Default --sso` (Note: Include `--sso` only if you're using a federated ID.) - To focus on your specific cluster for this session, use: `ibmcloud ks cluster config --cluster c50pifut05bcc7pangi0`. - Check if the connection to your cluster is successfully established: `kubectl config current-context`. # Integrating Prometheus with IBM Cluster - Ensure the Helm package manager for Kubernetes is installed. Helm streamlines Prometheus installation and management. - Next, add the Prometheus repository to your Helm list and update it: ```c csharpCopy codehelm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update ``` - Install the Prometheus Helm chart into the 'monitoring' namespace (this will be created automatically if it does not exist): `helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring --create-namespace`. - Validate Prometheus installation by checking the status of the pods: `kubectl --namespace monitoring get pods -l "release=prometheus"`. # Dive into Prometheus dashboard - Access the Prometheus dashboard on IBM cluster using port forwarding: `kubectl port-forward --namespace monitoring svc/prometheus-kube-prometheus-prometheus 9090`. [title] Policy [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ In , you can delve into the intricacies of policies and attributes vital for optimal container orchestration. This section unpacks key policies such as resource quotas, limit ranges and network policies, each playing a pivotal role in balancing resource allocation with workload execution. The guide simplifies complex container management components designed for seasoned users, ensuring users can effectively optimize their clusters. Navigate to understand the significance of each policy and its associated attributes for successful cluster orchestration. To view the different policies, follow these steps to access the data you need: 1. Log into . 2. Proceed to the dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the page. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Policy** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. The Policy section consists of the following sub-sections: Resource quotas, Limit ranges, Pod disruption budgets and Network policies. - **Resource quotas**: Presents a view of all the resource quota details that are part of the cluster - The following details are presented in the resource quotas table: - **Name**: This column displays the name of the resource quota. - **Namespace**: This column displays the namespace of the resource quota. - **Age**: This column shows the Age of the resource quota. - **Limit ranges**: Presents a view of all the limit range details so that the cluster user can see the limit ranges. - The following details are presented in the limit ranges table: - **Name**: This column displays the name of the resource quota. - **Namespace**: This column displays the namespace of the resource quota. - **Age**: This column shows the Age of the resource quota. - **Pod disruption budgets**: Presents a view of all the pod disruption budgets part of the cluster and pod disruption budget details: - The following details are presented in the pod disruption budgets table: - **Name**: This column displays the name of the pod disruption budget. - **Namespace**: This column displays the namespace of the pod disruption budget. - **Min available**: This column displays the min available of the pod disruption budget. - **Max unavailable**: This column displays the maximum unavailable amount of the pod disruption budget. - **Current healthy**: This column displays the current health of the pod disruption budget. - **Desired healthy**: This column displays the desired health of the pod disruption budget. - **Age**: This column shows the Age of the pod disruption budget. - **Network policies**: Presents a view of all the network policies that are part of the cluster and network policy details: - The following details are presented in the network policies table: - **Name:** This column displays the name of the network policy. - **Namespace**: This column displays the namespace of the network policy. - **Policy types**: This column displays the policy type of the network policy. - **Age**: This column shows the Age of the network policy. - To view more details about a network policy, the user can click either on the row or the `View details` option present at the end of the row. The details about the selected network policy are presented in a side panel. - The network policy name is as panel title, labels, annotations, pod selector and policy types. - Ingress rules/Egress rules: The data here is JSON data about the selected network policy's Ingress rules/Egress rules. - Raw JSON: The data here is JSON data about the selected network policy from the network policies API exposed by Kubernetes. [title] Cluster Configuration [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ The configuration section in the tool provides a consolidated dashboard for managing and viewing configurations like ConfigMap, Secrets and Horizontal Pod Autoscaler (HPA). Detailed insights, easy access and direct management features give you total control over your container's configurations. To view the different Cluster configuration data, follow these steps to access the data you need: 1. Authenticate into the CCM application by providing credentials to ensure secure access to the management dashboard. 2. Upon successful authentication, proceed to the CCM main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, located at the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Cluster configuration** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. # ConfigMap - **Overview:** This section provides a glimpse of available configmaps across various namespaces. Namespace-specific configmaps can be easily pinpointed. - **List view**: This table provides a list of all defined registered config maps. For more detailed information about a specific configmap, click the vertical ellipsis to display the overflow menu. The following options are available: - Select the desired row or choose the **View Details** option. - Cert files related to the configmap can be downloaded directly from the details section. - Select **Delete config map** to delete the map. # Secrets supports Kubernetes Secrets, which are objects that contain sensitive data and operate independent of pods, lowering the risk of exposure during normal operations. The service enables viewing specific secrets in JSON format. Use the following procedure to navigate to a specific Secret: 1. Launch the Cluster overview page. 2. Click **Configuration** → **Secrets** on the left side menu to navigate to the Secrets landing page. The service displays the Secrets table containing all registered Secrets. 3. Click on the Secret Name in the Secrets table to view the Secret JSON code. # Horizontal Pod Autoscaler (HPA) - **Overview**: A centralized dashboard displays HPAs defined within the cluster. It gives insights into the resources that are slated for autoscaling. - **HPA Table Details:** - **Name**: Displays the name of the namespaces. - **Namespace**: Indicates the namespace where the autoscaling has taken place. - **Min Pods**: Enumerates the minimum number of pod replicas serving the workload. - **Max Pods**: Showcases the upper limit of pod replicas attending to the workload. - **Age**: Provides a temporal perspective by indicating the duration since the HPA was set. - **Access:** To get a granular view of an HPA: - Either select the row or select the **View Detail** option. - A side panel will appear containing the following information about the selected HPA: - **HPA Name** as the panel title. - **Sections** such as Label, Annotations, References, Replicas and Metrics. - **Conditions**: An illustrative table displaying Type, Status, Reason and Message. - **Events**: Gives insights with columns like Type, Reason, Age, From and Message. - **Raw JSON**: Offers a direct look into the JSON data associated with the chosen HPA. [title] [path] Services/Platform Services/ [title] Setting cluster health parameters [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ # Cluster health parameters Each container cluster is identified in the Clusters table and is designated Healthy or Unhealthy. This designation derived from whether any of the health parameter values have exceeded a defined health threshold. The parameters are predefined as follows: - **Node Health**: Displays how many nodes are deemed unhealthy. Default threshold is 50%. - **Critical alerts**: Displays how many critical alerts have been issued. Default threshold is 1. - **Memory overcommitted**: Displays the amount of memory that could be consumed by individual containers as a percentage of the set memory limit for that cluster. Default threshold is 90% - **CPU overcommitted**: Displays the amount of CPU that could be consumed by individual containers as a percentage of the set CPU limit for that cluster. Default threshold is 90%. As an administrator you can tailor the default parameter thresholds to the specific requirements of your organization. # Setting parameter thresholds provides a Cluster Health Settings page for setting Health Parameter thresholds. To access the Cluster Health Settings page, click the **Settings** button located at the top right page. The service navigates to the Cluster Health Settings page. The Cluster Health Settings page contains a form for setting the thresholds for each of the four health parameters. The following caveats apply: - Users can enter values using the number input fields. - Each rule can be enabled or disabled using the toggle switch. - Click **Save** to apply changes. - Click **Reset** to revert to the previously saved values ***before*** saving. to abort your changes and return to the landing page. - Click **Cancel** to abort your changes and return to the landing page. [title] Container Cluster Management landing page [path] Services/Platform Services/Cloud Management/Container Cluster Management/ enables observability of the health and performance of such containerized systems so you can optimize in accordance with your organization's needs. The Overview page provides a canvas that you can populate with widgets from a library to create a personalized dashboard for monitoring your container clusters, tailored to the specific needs of your organization. :::hint{type="info"} A new dashboard is available, displaying Utilization Insights, complementing observable data on this page and providing a distilled view limited to CPU and memory over-utilization and under-utilization. ::: # Overview page The landing page of the Overview page contains the following elements that enable efficient navigation and effective oversight of the : - **Universal Header: **The landing page header contains user-oriented information that assists with navigation. - **Data and viewing selection: **Filters and dashboard customization enable an at-a-glance understanding of the particulars, such as environments and providers of interest to you, as well as saved dashboard views that enable quick retrieval of information critical to your organization. - **Actionable Insights and graphical data displays: **Displays that provide actionable and otherwise meaningful data to enable quick and effective decisions regarding your managed clusters. - **details table:** A list of clusters with their associated details in tabular form. # Header The dashboard contains multiple tabs that present distinct views tailored to individual requirements within the organization. Supported views include the following: - **Capacity & Utilization Overview:** Limited to subscribers assigned the Capacity & Performance Engineer role, this view enables capacity engineers to view clusters in the context of over- and under-utilization and overcommitted clusters. For more information, see [Capacity Planning Dashboard](docId\:RvMI1Sjf0dgsxLvjIc0JR). - tab: Contains all landing page content described in subsequent sections of this topic. - **APIVerse** tab: Contains the Kyndryl Bridge - Controller Service APIs. # Global filter supports a data filter to enable the selection of data you want to display in the dashboard, Actionable Insights and the Cluster Overview page. To filter displayed data, select the filter icon under the header. All graphic displays are adjusted to accommodate the filtering criteria. The following filter categories are supported: - **Providers: **Implemented provider integrations. - **Connections:** Individual, created connections. - **Applications:** Individual, deployed applications. - **Environments: **All implement environments, such as development and staging. - **Container type:** - Kubernetes - OpenShift By default, all data is displayed, and an **All** selection can be applied to any of the filter categories. Select one or more items from each filter category using the drop-down menu and click **Apply** to apply your filter selections or click **Cancel** to abort your selections. When you apply your filter selections, the service displays the selected items in the filter field below the filter icon. You can dismiss any or all of the filter categories by clicking the **X **to the right of the category name; the service updates the dashboard accordingly. :::hint{type="info"} Note: The global filter is so-called because it is present on all throughout the service. ::: # User preferences dashboard customization The dashboard view can be customized and saved, making it easy to compare applications' performance. Also, it is a great option to maintain the current statistic parameters and revisit them later. The **Clear view** button serves as a reset button for the current customized filtered view; any unsaved customized view of the current dashboard will be returned to its default state when clear view is selected. :::hint{type="info"} Note: The clear view option will be disabled when the default dashboard view shows all data; only when customizing a view from the dashboard will this option be enabled. ::: The **Custom view** button comes with an expanded selection of options that will allow more actions to be performed in the dashboard: - **Save new view:** By selecting Save new view, all current filters available will be saved, including the chosen timeframes and table settings selections. A confirmation window will require inputting a name for the customized dashboard view and selecting whether you want the current default view. - **Update view:** selecting this option allows the update of the current dashboard, including the filters, timeframes, and table settings using different parameters; this is not applicable if the current view is from a default dashboard. - **Delete view:** this option will delete the current customized dashboard view. :::hint{type="info"} Note: If all customized filters are deleted, the displays the default stage dashboard view. This is the view before customization. Also, If an user customizes the dashboard filters but the view is not saved or updated before the end of the session, the system will not honor these customization changes upon the next login session. ::: # Graphic displays landing page presents critical cluster information at a glance in the form of four widgets and a table view: ## Alerts On the Dashboard page, the Alerts section provides all the alerts for all the clusters controlled by the user across the various cloud platforms. The user can navigate to the cluster alerts page to evaluate the cluster alerts from any available cluster table view by selecting the desired cluster on the table. ## Operational Insights The landing page contains four actionable insights widgets that provide insights into your IT estate: - Security and Compliance - Performance - Reliability - Optimization Each widget navigates to the Insights Summary by category page. The page provides statistical data to help you assess the state of your IT estate using status data and an access point to details regarding specific clusters, complete with configuration recommendations. Using it, you can balance resources and take preemptive actions as needed, enabling a more nimbler approach to reliability and efficiency. More information is available at [Actionable Insights](docId\:IGElLTjMSNbKWiJS9vYV9). ## Cluster health by provider The donut chart shows information about the health of the clusters for various providers. The size of the donut chart will be in ratio to healthy and unhealthy clusters. Healthy clusters will be represented in green color, Unhealthy clusters will be shown in red. By hovering over a cloud provider on the Heatmap, the tooltip provides: - The total number of clusters. - The number of healthy and unhealthy clusters. - The cloud provider's name. When you choose a provider, the donut chart displays all of the clusters for that provider. The tooltip displays the full cluster name, the total number of clusters and the percentage of healthy and unhealthy clusters. ## Clusters health by region The Geomap widget displays information about cluster health based on their location. On the Geomap, the number of clusters in each region is displayed. When you hover your mouse over a clustered region, the tooltip reveals the region's name and the number of healthy and unhealthy clusters in that location. ## Interaction between Geomap and Heatmap When a specific provider is selected in the Cluster health by provider widget, the cluster table will be updated with the information about the cluster or clusters within your selection. The same behavior will occur when the provider filters the Cluster by region widget. # Clusters table The Running Clusters table displays the following information about the cluster: - **Cluster Name:** The complete cluster name is displayed in this column. - **Applications:** Applications dependent on that cluster. - **Environment:** The name of the environment hosting the cluster. - **Connections:** The name of the running connection for the cluster. - **Provider:** The name of the cloud provider is displayed in this column. - **Location:** Displays the code of the Location of the cluster. - **Health:** Presents either Healthy or Unhealthy designation dependent on predefined health criteria. Refer to the subsequent *Health Column* section. - **Alerts:** Displays the number of critical alerts for a cluster. - **Version:** Displays the version of Kubernetes used by the cluster. :::hint{type="info"} All the columns in this table can be sorted except the **Connections** and **Location** columns. Above this table, you will find a search box that allows searching for clusters by name and a **Settings** icon that allows changing the table settings to show or hide the additional columns (**CPU Usage**, **Memory Usage** and **File Usage**). ::: ## Health Column The Health column contains a binary designator of each cluster as Healthy (green) or Unhealthy (red). If a cluster is healthy, the designator is inactive. If a cluster is deemed unhealthy, the designator is active, allowing users to click the designator and navigate to a details page that provides specific information on which health thresholds have been breached. The following criteria are used to gauge cluster health: - **Node Health: **Displays how many nodes are deemed unhealthy. The default threshold is 50%. - **Critical alerts:** Displays how many critical alerts have been issued. The default threshold is 1%. - **Memory overcommitted: **Displays the amount of memory that could be consumed by individual containers as a percentage of the set memory limit for that cluster. The default threshold is 90%. - **CPU overcommitted: **Displays the amount of CPU that could be consumed by individual containers as a percentage of the set CPU limit for that cluster. The default threshold is 90%. All health thresholds are set as an administrative function. Refer to [Setting cluster health parameters](docId:1xWriccJvB8iu3xB2J-op) for details. # details table The **Table View **supports detailed views for each cluster. To access details for a specific cluster, click the cluster name for that cluster. The service navigates to the details page for the selected cluster. The left navigation bar presents multiple detail selections as follows: - **Cluster:** Tab presenting data about each Cluster. For more information, see [Cluster](docId:-flLU_jjAQyZUEC39m6sx). - **Actions: **Enables taking an action by way of the Kyndryl actions service. For more information, see [Cluster details page](docId\:Gzk7M2Fi0qmcXZNFm8um1). - **Workloads:** Tab presenting applications running in Kubernetes. For more information, see [Workloads](docId\:WVn8xyjcQFQWVMplGzOMz). - **Network:** Displays available Services and Ingress objects. For more information, see [Network](docId\:tI60TC1ASURLBDPHUO8hW). - **Configuration:** Shows details about configmaps and secrets. For more information, see [Configuration](docId:5fQSykEc1zOtSyMat8DUY). - **Storage:** Shows the persistent volumes of the clusters. For more information, see [Storage](docId\:P9XJ_FtDL57_sbiYDLvdS). - **Access Control:** Shows the Access Control details of the cluster. [Cluster access control](docId\:GfBRUkuksLm60qQ3cJn8y). - [Policy](docId\:Iio0qx21cmj5fB0SV7d9K)**:** A cluster policy restricts the ability to configure clusters based on rules that limit the attributes. - **Custom Resources:** Custom resources are Kubernetes API extensions that allow objects to be created, updated and deleted. For more information, see [Custom resources](docId\:rz-1X6by2k9S1E6x86jdD). - [Capacity Planning Dashboard](docId\:RvMI1Sjf0dgsxLvjIc0JR): Gain a keen understanding of current capacity and the ability to preemptively balance resources for maximum cost efficiency. - [Executive dashboard](docId:5Hn_P_LfJX5i5zFLQCivI): View a summary of critical performance data impacting applications to assist in removing obstacles. - [Cluster details page](docId\:Gzk7M2Fi0qmcXZNFm8um1): Learn about this resource for a deep view into individual clusters, to acquire a keen understanding of performance and health. - [Setting cluster health parameters](docId:1xWriccJvB8iu3xB2J-op): Learn how to set parameter thresholds as the baseline for cluster health. - [Integration with applications Container Cluster Management](docId\:kR3lTBud5fIAXUT9cfspG): Find out how to integrate your application deployments with to observe status, health and regional concentrations of your container clusters. - [Supported hybrid IT estate personnel](docId\:FKXlCcUfHFCpQww3x_Y14): Understand the target users supports. - [User and role management](docId\:vy_2iguh1sL9qJU_qE6t_): Learn how to grant appropriate access to your users in accordance with the type of cluster data they need. - [My Dashboard](docId\:pM_p78hkl5zqLPeyPz68i): Learn how to customize your personal dashboard to tailor disparate data you most commonly need to a common view. - [Missing data notifications](docId\:UvX5SchrNGoYla6kS06TS): Understand the status of missing data through automated notifications. - [Glossary terms](docId\:ENux7Aiwtt8aUxcbgOVxq): Understand the parlance of to comprehend the nuances and details of container clusters managed by users of . [title] My Dashboard [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ Learn how to customize your personal dashboard to tailor disparate data you most commonly need to a common view. Kyndryl introduces the User Definer Dashboard, allowing you to personalize your dashboard experience, quickly summarizing the most important data while finding relevant information at a glance tailored to your unique needs from a single easy-to-use dashboard. Go to the Cluster dropdown menu, then My dashboard. Your Dashboard view will be displayed in a new window. # Creating your own dashboard A user-defined dashboard allows you to construct a dashboard with your chosen widgets or use one of the established templates. To construct your dashboard, navigate to the **My Dashboard** section of . Your Dashboard view will be displayed in a new window. To change the dashboard's name, click the pencil icon next to the name and type in the new name. After changing the name, two buttons will show on the screen: Templates and Add widgets. Create your own using the **Blank Dashboard** template and the **Add widgets** option to select what you want to see on your dashboard. To add widgets to your dashboard, select the **Add widgets** option and drag the Dashboard Components of your choice from the sidebar to the desired location on the dashboard. # Using dashboard templates User Defined Dashboard templates make it simple to create a dashboard that displays the data you want. The dashboard includes templates incorporating established expenses, assets, savings, and analytical graphs and charts. **Among the templates are:** - Blank dashboard. - template. If this is your first time using the dashboard, a Quickstart menu will appear when you access it with the template choice. You may also see the various templates by selecting the Templates option on the right side of the dashboard. After choosing the preferred template, click Select to show the data on the dashboard. You may add dashboard components or widgets to any template by choosing the **Add widgets** button. You may examine all the widget information after selecting it and adding it to your dashboard by clicking the view details button on the right side of the component. This option returns you to the original dashboard, where the data is shown. Close or minimize the widget by clicking the x or - icons on the right side of each component's window. [title] Network [path] Services/Platform Services/Cloud Management/Container Cluster Management/Cluster/ This resource is dedicated to providing you with detailed insights and control over the networking aspects of your container clusters. Here, you will find a structured overview of the Network component, including Services, Ingress, Endpoints and Endpoint Slices within your Kubernetes environment. To view the different Network data, follow these steps to access the data you need: 1. Log into . 2. Upon successful authentication, proceed to the CCM main dashboard. This serves as the central hub for all activities. 3. In the dashboard, locate the **Cluster table**, positioned towards the bottom of the interface. This table lists all the clusters available under your management. 4. Identify and choose the desired cluster by selecting it within the **Cluster table**. This action will direct you to a detailed view of the selected cluster. 5. Within the cluster details view, navigate to the **Network** tab. Here, you will find options to view and manage Persistent Volumes, Persistent Volume Claims and Storage Classes associated with the selected cluster. # Services This section displays services and the namespace-specific services using the Drop-down menu above the table. Namespace-specific list of services: Further details about a service can be obtained by selecting the `View details` option present at the end of each row. The information on the Service will be presented in the side panel as displayed below. # Ingress This section displays the list of defined ingress objects. The user can list ingresses specific to a namespace using the Drop-down menu at the top right corner above the table. # Endpoints To view more details about an ingress, the user can select the `View details` option present at the end of each row. This section displays the list of defined endpoints objects. The user can list endpoints specific to a namespace using the dropdown above the table. To view more details about an Endpoint, the user can click either on the row or the `View details` option present at the end of each row. [title] Oracle RAC with Dataguard [path] Services/Kyndryl Services/Security & Resiliency/Intelligent Recovery Service/Solution usage/ # Overview This document outlines the technical solution guide integration for integrating the AIOps-based Resiliency platform. It provides multiple IT applications and databases business continuity and Cyber Resiliency option to manage from a single platform as a service. (AIOps) platform will automate various tasks and configurations, improving efficiency, scalability, and reliability. This document is focused on Oracle solution integration with the platform. # Objective The primary objectives of Oracle Disaster Recovery (DR) solutions, such as Oracle RAC with DataGuard, are to ensure the availability, reliability, and continuity of critical databases in the event of a disaster or unexpected failure. The key objectives include: ## Business Continuity - **Minimize Downtime:** Ensure minimal disruption to business operations by minimizing the downtime associated with database failures. - **Continuous Access:** Provide continuous access to data and services even during unexpected incidents. ## Data Protection - **Data Integrity**: Maintain the integrity of data across primary and standby databases to prevent data loss or corruption. - **Data Consistency:** Synchronize changes made to the primary database with standby databases to ensure consistent data across all sites. ## Disaster Recovery - **Fast Recovery:** Facilitate quick recovery in a disaster by enabling failover to standby databases. - **Redundancy: **Establish redundant databases in geographically separated locations to protect against natural disasters, hardware failures or other catastrophic events. ## High Availability - **Fault Tolerance: **Enhance fault tolerance by configuring multiple standby databases and leveraging Oracle Real Application Clusters (RAC) for load balancing and failover capabilities. - **Load Distribution:** Distribute database workload across multiple nodes to prevent overloading and ensure optimal performance. ## Scalability - **Horizontal Scaling: **Scale database resources horizontally by adding standby databases to the configuration, allowing for increased capacity and performance. - **Vertical Scaling:** Utilize Oracle Real Application Clusters (RAC) to vertically scale by adding nodes to the cluster to handle increased demand. ## Flexibility - **Snapshot Standby**: Allow temporary read-write access to standby databases for reporting or testing purposes without affecting the primary database. - **Configuration Options:** Offer flexibility in choosing configurations that suit the specific needs of the organization, such as synchronous or asynchronous replication. ## Automated Management - **Data Guard Broker: **Streamline the configuration, management, and monitoring of Data Guard environments through the use of the Data Guard Broker, allowing for easier failover and switchover operations. - **Monitoring Tools**: Provide tools and utilities for monitoring the health and performance of both primary and standby databases. ## Compliance and Security - **Compliance:** Ensure compliance with regulatory requirements regarding data availability, integrity and security. - **Security:** Implement secure communication and authentication mechanisms between primary and standby databases to protect against unauthorized access. # Architecture diagram, explanation with the required port number and network flow Oracle RAC Archive logs with DataGuard DR Solution provide business continuity for the applications that run on the Oracle database. Data protection is done using DataGuard to copy log files and other DB-related files between Production and DR (remote) sites. Since this whole process is automated using Kyndryl Resiliency Orchestration, the management is simplified and the DR database is continuously updated. The following diagram explains how Oracle RAC works with DataGuard to protect Oracle data in the Kyndryl Resiliency Orchestration environment. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/8esEDmwfJp-npgqZB4CV7_image.png) ## Architecture network flow diagram ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/Ma7jPJ6kOGFYnn372VKUp_image.png) # Supported versions | **Supported Versions of the OS and Platforms** | **Supported Versions of Storage (Database/File System)** | **Supported Versions Protection Scheme (Replication)** | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Windows 2016\*
RHEL 7.0/8.0/8.4/8.6/9.2
Solaris 10/11\*
AIX 7.1(not supported) | Oracle RAC Logs 19c/21c (64 bits)
Dataguard 11g\*/18c

| Oracle RAC Logs 19c/21c (64 bits)
Dataguard 11g\*/18c | ## Prerequisites The following are the prerequisites: - Intelligence added where the playbook automation will automatically pick the active instance out of multiple instances and perform the recovery operations. - OS user with sudo permissions to execute Oracle tools: - lsnrctl - srvctl - dgmgrl - Create an execution environment with SQLPLUS on CACF Tower. If not created, the customer must have a dedicated SQLPLUS client. - The user must add the Oracle hosts to the inventory file for both PR and DR. - Create credentials for each host credential type of the machine. - On CACF Tower, a new credential type will be created to perform the automation. Follow the instructions given below: - Login to CACF Tower. - Navigate to Credential type and create a new with the below configuration: - Credential Types :\-resiliency-oracle # Input configuration ### Fields | ******Field ID****** | ******Label****** | ******Type****** | ******Required****** | ******Secret****** | | ------------------------------------------------- | ---------------------------------------------- | --------------------------------------------- | ------------------------------------------------- | ----------------------------------------------- | | username | DB Username | String | Yes | No | | password | DB Password | String | Yes | Yes | | os\_username | OS Username | String | Yes | No | | os\_password | OS Password | String | Yes | Yes | ### Required Fields - username - password - os\_username - os\_password ### Injector Configuration | **Variable** | **Value** | | ----------------------------------------- | -------------------------------------- | | oracle\_user | \{\{username}} | | oracle\_password | \{\{password}} | | os\_username | \{\{os\_username}} | | os\_password | \{\{os\_password}} | # Solution Level Privileges - The user needs admin privileges for this solution. - Both OS and DB authentication are supported for this solution. # Features of the Solution The features of this solution are as follows: - The following features of Discovery and Config Data Model are supported: - Resource Type - Data Collection - BluePrint - The following features of Insights are supported: - RPO Calculation - Datalag Calculation - The following features of Metrics are supported: - Oracle Oracle RAC Dataguard Status - Oracle Log Apply status - Oracle Oracle RAC DataGuard Mode - Oracle Database Status - The following features of Automation are supported: - Failover - Switchover - Switchback # Benefits of the Solution The benefits of this solution are as follows: - Advanced prechecks on all automation so that automation gets triggered when the system is in the correct state. - Advanced Post recovery checks of the database on the DR site. - Automated enabling the Oracle RAC with DataGuard replication in a reverse way. - Performs DR operations only when there is no gap w\.r.t logs between the primary and the secondary sites. - Real-time metrics is displayed on the dashboard along with the alerts. # Known Limitations ## Solution Limitations - DB user with sys equivalent with sysdba role is only supported. - Since Oracle provides datalag in sequence. We can only display the sequence in dashbaord. Displaying datalag in MB is not possible. - The following is the list of unsupported scenarios for the Oracle RAC Dataguard solution. - Multi-Site DG environment. - Fallback is not supported. - Reverse Failover (Failover to PR post Switchover). ## Technology limitations - Recovery operations in Oracle can only be performed with the user which has the highest roles and privileges. - Oracle provides datalag in sequence, which can only be displayed in the dashboard. Displaying datalag in MB is not possible. # Setting up of the Solution ## Inputs for Onboarding **Configure: **Resource type are the properties required to be configured to the existing resource\_type.yml under the DNC-data-model. | **F********ields** | **Description** | **Sample Value** | **Fixed** | **Mandatory** | **Recommended Values** | | ---------------------------------------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------- | -------------------------------------- | ------------------------------------------ | --------------------------------------------------- | | Oracle sid name | Enter the Oracle sid name. | orcl | No | Yes | | | Automatic Target Host | Enter the automatic Target Host name. | 192.168.6.109

172.168.6.109 | No | Yes | | | Automatic Execution Environment | Enter the automatic Execution Environment details. | anisible-ee-sql | Yes | No | | | Configured RPO in minutes | Enter the time to Configure RPO in minutes. | 15 | No | Yes | | | Threshold for Acceptable RPO deviation | Enter the threshold for Acceptable RPO deviation. | 20 | No | Yes | | | Compute interval in minutes | Enter the time to compute interval in minutes. | 5 | No | Yes | | | Configured datalag deviation in MB | Enter the configured datalag deviation in MB. | 15 | No | Yes | | | Configured datalag deviation threshold percentage | Enter the configured datalag deviation threshold percentage. | 50 | No | Yes | | **Automation**: The following table provides the inputs required to execute the automated features. **Failover: **This automation performs the failover test for the solution. | **F********ields** | **Description** | **Sample Value** | **Fixed** | **Mandatory** | **Recommended Values** | | ---------------------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------- | -------------------------------------- | ------------------------------------------ | --------------------------------------------------- | | Credential Label Name | Enter the Credential Label Name | ro1\_cred\_oracle\_dg | No | Yes | | | Oracle sid name | Enter the Oracle sid name | orcl | No | Yes | | | Oracle DR Port Number | Enter the Oracle DR Port Number | 1521 | No | Yes | | | Oracle DR Server | Enter the Oracle DR Server | 172.168.6.109 | No | Yes | | | Oracle DB Role | Enter the Oracle DB Role | sysdba | No | Yes | | | Oracle PR Server | Enter the Oracle PR Server | 192.168.6.109 | No | Yes | | | Automatic Target Host | Enter the Automatic Target Host | 192.168.6.109

172.168.6.109 | No | Yes | | | Automatic Execution Environment | Enter the Automatic Execution Environment details | anisible-ee-sql | Yes | No | | # Error code and recommendation | **Return Code Group** | **Return Code** | **Comments** | | -------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------- | | connection\_issue | 8521,8524,8526 | Unable to connect to the host. Please check the user name and pwd | | misconfiguration | 8501 | dr\_db\_port is not configured | | misconfiguration | 8502 | oracle\_dr\_db\_name is not configured. | | misconfiguration | 8503 | oracle\_dr\_db\_role is not configured. | | misconfiguration | 8504 | oracle\_db\_role is not configured. | | misconfiguration | 8505 | Either PR or DR node group is missing or incorrect. | | misconfiguration | 8506 | All nodes are not reachable | | misconfiguration | 8507 | Nodes are reachable but none of them is active status. | | component\_playbook | 8508 | ERROR: Oracle RAC database instance is not in running state | | component\_playbook | 8509 | Technical issue in running the srvctl command. | | misconfiguration | 8510 | Reachable but not node server is not active. | | component\_playbook | 8511 | no DataBase is available | | component\_playbook | 8522 | DB execution error | | misconfiguration | 8523 | database validation failed | | component\_playbook | 8525 | ERROR: database instance failed to stop. | | component\_playbook | 8528 | ERROR: Failed the backup of the control files. | | component\_playbook | 8529 | ERROR : Failed to get the resources of RAC. | | component\_playbook | 8530 | ERROR: Failed to get the database instance state | | component\_playbook | 8531 | ERROR : Failed to get the status of RAC DB | | component\_playbook | 8532 | Role in not a expected RAC db role | | component\_playbook | 8527 | ERROR: database instance failed to start. | [title] Supported hybrid IT estate personnel [path] Services/Platform Services/Cloud Management/Container Cluster Management/Container Cluster Management landing page/ Kyndryl offerings hinge on granting specific privileges to specific users, aligning their use of the service with the skills those users contribute to post deployment operations. supports two types of users: - **Site Reliability Engineer**: The individual in this position is responsible for system reliability and operational efficiency. equips the individual to do the following: - Monitor clusters based on various parameters like provider, environment and client. - Resolve cross-environment issues through a unified console, enhancing operational coherence. - Access pod logs for in-depth troubleshooting and generate comprehensive reports for stakeholders. - Identify clusters facing resource contention globally and apply necessary interventions. - Seamlessly navigate between OpenShift and Kubernetes clusters on a singular interface. - Analyze Key Performance Indicators (KPIs) such as pod restart frequencies across clusters. - Delve into individual performance metrics for granular insights into each cluster. - **Application Developer**: These individuals represent the creative and development backbone and enables them to do the following: - Access detailed information on selected clusters, gaining vital insights for enhanced decision-making. - Extract relevant data to aid in application debugging, utilizing filters and labels for precision. - Review and search through managed pod logs, along with a comprehensive view of Kubernetes objects on cluster detail pages. - Leverage supported observability tools for an integrated view of metrics data across the cluster. Each of these arenas requires different privileges and so for security purposes, they are given the privileges that enable the activities associated with their position but nothing more. is a role-driven service. Users are assigned roles, which then confer on those individuals the appropriate privileges. For details about roles, refer to [User and role management](docId\:vy_2iguh1sL9qJU_qE6t_). [title] [path] Services/ [title] Logstash Extension Base Template [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/ # Overview The Logstash Extension Base Template (logstash-extension-base) provides a foundation for developing Logstash-based extensions. Integration developers can use this template to create a repository and implement custom data processing pipelines. :::hint{type="info"} Several pipeline templates are available for common Kyndryl use cases and can be used as a starting point for extension development. ::: # Architecture Overview The extension performs the following operations during startup and runtime: - Starts the entrypoint.sh script. - Extracts the keystore and truststore from the configured vault path. - Verifies the Elasticsearch certificate. Loads the Logstash configuration files: - log4j2.properties - pipelines.yml - logstash.yml - Loads the configured pipeline definitions. - Processes incoming data according to the selected pipeline. - Sends output to one or more destinations: - Console (stdout) - Dynatrace - Elasticsearch - DSS Kafka topics # Configuration files | **File** | **Description** | | ----------------- | ------------------------------------------------------------------------------------------- | | config.yaml | Defines extension metadata, deployment probes, and deployment-time configuration variables. | | bin/entrypoint.sh | Prepares runtime variables and starts Logstash. | | log4j2.properties | Configures logging output. | | pipelines.yml | Defines the pipelines to run. | | logstash.yml | Contains Logstash runtime settings. | # Configuration Variables ## Deployment configuration variables The deployment.env-vars section in config.yaml defines the values that users configure during deployment. | **Variable** | **Purpose** | **Default Value** | | --------------------------- | --------------------------- | -------------------- | | DX\_EXT\_CONSUMER\_GROUP | Kafka consumer group ID | Required | | DX\_EXT\_CACF\_TOPIC | CACF input topic | san-port-insights | | CACF\_KAFKA\_BROKERS | CACF broker list | Environment-specific | | DX\_EXT\_KAFKA\_KEYSTORE | Kafka keystore vault path | Vault path | | DX\_EXT\_KAFKA\_TRUSTSTORE | Kafka truststore vault path | Vault path | | DX\_EXT\_KEYSTORE\_PWD | Keystore password | Required | | DX\_EXT\_ELASTIC\_INDEXNAME | Target Elasticsearch index | Required | | DX\_EXT\_LOG\_LEVEL | Extension logging level | INFO | ## Environment Variables ### Standard Environment Variables The following environment variables are available to all Logstash extensions through extension services. | **Variable** | **Example** | **Description** | | --------------------------- | ----------------- | ----------------------------------- | | DX\_EXT\_INTERNAL\_PORT | 5000 | Internal communication port. | | DX\_EXT\_CONSUMER\_GROUP | - | Kafka consumer group identifier. | | DX\_EXT\_CACF\_TOPIC | san-port-insights | CACF Kafka topic. | | CACF\_KAFKA\_BROKERS | - | Environment-specific Kafka brokers. | | DX\_EXT\_KAFKA\_KEYSTORE | Vault path | Kafka keystore location. | | DX\_EXT\_KAFKA\_TRUSTSTORE | Vault path | Kafka truststore location. | | DX\_EXT\_KEYSTORE\_PWD | - | Vault-stored password. | | DX\_EXT\_ELASTIC\_INDEXNAME | - | Elasticsearch index alias. | | DX\_EXT\_KAFKA\_TOPIC | - | DSS Kafka topic. | | DX\_EXT\_LOG\_LEVEL | INFO | Log level. | | DX\_EXT\_HOST\_ALIASES | - | Host and IP mappings. | | DX\_EXT\_SETTINGS | OFF | Advanced settings toggle. | ### Advanced Environment Variables Configure these variables when polling data from CACF or for advanced performance tuning. | **Variable** | **Example** | **Description** | | ---------------------------- | ------------- | ------------------------------------ | | DX\_EXT\_JAVA\_OPTIONS | -Xmx4g -Xms2g | Override Java memory settings. | | DX\_EXT\_BATCH\_SIZE | 125 | Pipeline batch size. | | DX\_EXT\_BATCH\_DELAY | 50 | Pipeline batch delay. | | DX\_EXT\_MAX\_POLL\_RECORDS | 1000 | Maximum Kafka records per poll. | | Number of Kafka Partitions | 10 | Number of processing workers. | | DX\_EXT\_POLL\_TIMEOUT | 20000 | Consumer poll timeout (ms). | | DX\_EXT\_MAX\_POLL\_INTERVAL | 400000 | Maximum delay between polls (ms). | | DX\_EXT\_REQUEST\_TIMEOUT | 700000 | Kafka request timeout (ms). | | DX\_EXT\_HEARTBEAT | 200000 | Consumer heartbeat interval (ms). | | DX\_EXT\_SESSION\_TIMEOUT | 900000 | Kafka session timeout (ms). | | DX\_EXT\_MAX\_BYTES | 1048576 | Maximum payload size. | | DX\_EXT\_VERIFY\_ELASTIC | full | Elasticsearch SSL verification mode. | # Health Probes The container implements the following Kubernetes health checks: - **Liveness probe:** Verifies that the container is running. - **Readiness probe:** Verifies that the container is ready to receive traffic. # Build and Run the Extension **Build the Image** 1. Navigate to the repository directory. 2. Update the .env file with the required settings. 3. Build the Docker image. :::Paragraph{indent="1"} `docker build -t is-logstash.` ::: **Start the ELK Stack (Optional)** :::BlockQuote docker compose up -d ::: **Configure local environment variables** Configure the required variables before running the container locally. `TARGET=logstash-base-elasticsearch-1:9200` `INDEX=ext-services-test` `UNAME=elastic` `PW=test` `IMAGE=is-logstash` `CONTAINER_NAME=is-logstash` `LOGSTASH_LISTEN_PORT=5000` `NETWORK=logstash-base_default` **Run the container** `docker run -d \` `--name "${CONTAINER_NAME}" \` `--hostname "${CONTAINER_NAME}" \` `--restart always \` `--network=${NETWORK} \` `-p "${LOGSTASH_LISTEN_PORT}:5000" \` `-e DX_EXT_INTERNAL_PORT="${LOGSTASH_LISTEN_PORT}" \` `-e DX_EXT_DESTINATION_USER="${UNAME}" \` `-e DX_EXT_DESTINATION_PW="${PW}" \` `-e DX_EXT_ES_URL="${TARGET}" \` `-e DX_EXT_ES_INDEX="${INDEX}" \` `${IMAGE}` **Use docker compose** All environment variables can be defined in either: `- .env` `- docker-compose.yml` :::hint{type="info"} Configure docker-compose.yml according to the chosen method. ::: **Testing and Validation** View Container Logs `docker logs -f is-logstash` **Access the container** `docker exec -it is-logstash /bin/bash` **Send test data** Send a POST request to the configured HTTP listener. Example for Endpoint: *http\://127.0.0.1:5000* Required header `Content-Type: application/json` Example for Payload: `{` `"test": "test",` `"firstfield": "Extensions services",` `"secondfield": "is awesome",` `"hostname": "api-na-1.kyndryl.com"` `}` # Podman Deployment ## Build and run using Podman Perform the following steps: 1. Navigate to the repository directory. :::Paragraph{indent="1"} `cd /path/to/repository` ::: 2. Start the Podman machine. :::Paragraph{indent="1"} `podman machine start` ::: 3. Build the image. :::Paragraph{indent="1"} `podman compose build` ::: 4. Start the container. :::Paragraph{indent="1"} `podman compose up` ::: ## Pipeline reference All pipeline definitions are stored in the ./pipelines directory as .conf files. Developers are responsible for creating and maintaining the .conf file that defines their pipeline configuration. The pipeline templates listed in this section are provided as reference examples to help understand common pipeline patterns and configurations. For information about Logstash pipeline architecture and pipeline development, see: - [How Logstash works](https://www.elastic.co/docs/reference/logstash/how-logstash-works) - [Creating a Logstash pipeline](https://www.elastic.co/docs/reference/logstash/creating-logstash-pipeline) ### Available Pipeline Templates | **Pipeline** | **Input** | **Processing** | **Output** | | ------------------------------- | ------------- | -------------------------------------- | ------------- | | http-elastic.conf | HTTP listener | Field transformation and normalization | Elasticsearch | | cacf\_kafka-dss\_kafka.conf | CACF Kafka | Message decoding and filtering | DSS Kafka | | cacf\_kafka-elastic.conf | CACF Kafka | Validation and routing | Elasticsearch | | kafka-elastic-http\_poller.conf | HTTP Poller | Message parsing | Elasticsearch | | elastic-elastic.conf | Elasticsearch | Data transfer | Elasticsearch | | db2-elastic.conf | DB2 JDBC | Row ingestion | Elasticsearch | ### Common Pipeline Features Most pipeline configurations include: - Standard console logging - Dynatrace integration for failure events - Elasticsearch output plugins - Environment-based credential injection # Logging ## Console output All pipelines use the standard Logstash stdout plugin. :::BlockQuote stdout \{ codec => line \{ format => "INFO ou=$\{\{DX\_ENV\_OU\_KEY} \:: processing data from %\{filename}" } } ::: ## Dynatrace integration Install the Dynatrace plugin in the Docker image: - `RUN /usr/share/logstash/bin/logstash-plugin install logstash-output-dynatrace` The following environment variables are injected automatically: - `DX_ENV_DYNATRACE_API_URL` - `DX_ENV_DYNATRACE_API_KEY` ## log4j2 Configuration The console format uses the following pattern: - `appender.console.layout.pattern = %-5p %d{ISO8601} ou=${env:DX_ENV_OU_KEY} %-25c ${env:DX_ENV_CAT_ITEM_VERSION} %M %p %m%n` # Known issues and limitations - This template supports only Logstash-based integrations. - Other endpoint integrations must be implemented as separate extensions. - Logstash workloads can consume significant resources. - Consider increasing the deployment size to size-large or size-extra-large when processing high data volumes. - Some pipeline files contain hyphenated environment variable names. Use underscore (\_) naming conventions where possible. - The sample DB2 pipeline includes placeholder connection values and must be updated before production use. # Prerequisites Before deploying a Logstash extension: - Ensure that the target Organizational Unit (OU) is onboarded to Integrated . - Verify access to the required Kafka, Elasticsearch, and vault resources. - Review the Integrated onboarding documentation for onboarding requirements and configuration details. [title] Map resources [path] Services/Platform Services/Inventory/Application Inventory/Overview/Onboarding/Business context mapping/ # Mapping resources to Application and Business Portfolio ### Existing resource 1. From the **Not mapped** (Resource-Applications) page, select the desired resource that will be mapped (You can select as many resources (All) as needed) and click the **Proced Mapping **button. An emerging window will appear. 2. Select the **Select from existing** toggle. 3. Select an existing resource and click the **Apply Mapping** button. 4. Once done, an emerging message will notify you that the action was completed. ### Non-existing resource 1. From the **Not mapped** (Resource-Applications) page, select the desired resource that will be mapped (You can select as many resources (All) as needed) and click the **Proced Mapping **button. An emerging window will appear. 2. Select the **Create new **toggle. 3. Fill out the following fields. 4. Application name 5. Application owner 6. Environment 7. Application type 8. Business service 9. Business unit 10. Description ### Sub-resources view A flexible mapping drill-dowm shows how Subsystems, Resources, Sub-Resources, and Applications connect. This will help us accurately represent real-world structures, enable shared resource use, and ensure a clear understanding of dependencies across applications and networks. Sub-system details provides a detailed panel where users can: - Search, filter, and select resources. - View sub-resources and shared resources reused across multiple applications. - Map sub-resources to applications directly - Associate Subsystems and resources with multiple applications. - Proceed to Application Mapping seamlessly. ## Viewing the subsystem details :::hint{type="info"} This option is only available when subsystems were injected containing resources. ::: From the **Not mapped (Resource- Applications)** page, select a resource with an available susbsystem information (look for the down chevron). The **Subsystem details** panel opens. Users can view subsystem to resource relationship along with the following details: - Subsystem resource identifier - Subsystem resource type - Subsytem name - Application owner If needed, you can refine your resource data results by clicking the **Filter** icon. An emerging window will appear where you can select the resource categories and subcategories you want to review and click **Apply**. ## Mapping subsystems to applications ### Existing resource 1. From the **Not mapped** (Resource-Applications) page, select the desired subsystem detail that will be mapped (You can select as many resources (All) as needed) and click the **Proced Mapping **button. An emerging window will appear. 2. Select the **Select from existing** toggle. 3. Select an existing resource and click the **Apply Mapping** button. 4. Once done, an emerging message will notify you that the action was completed. ### Non-existing resource 1. From the **Not mapped** (Resource-Applications) page, select the desired subsystem that will be mapped (You can select as many resources (All) as needed) and click the **Proced Mapping **button. An emerging window will appear. 2. Select the **Create new **toggle. 3. Fill out the following fields. 4. Application name 5. Application owner 6. Environment 7. Application type 8. Click the **Apply Mapping** button. 9. Once done, an emerging message will notify you that the action was completed. [title] Enable SimpCon Consumer [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/SimpCon Extension Templates/ SimpCon Consumer template The SimpCon Consumer template helps you consume messages from Data Streaming Services and transform them into the format required by the receiving system. ## How the extension works The extension runs as a container in Kubernetes when you create an extension instance in the Integrated platform. The extension performs the following actions: 1. Consumes messages from Data Streaming Services. 2. Transforms the requests into the format required by the receiving system. 3. Sends the transformed requests to the configured destination endpoint. For local testing, ensure that your environment meets the following requirements: - A Unix-compatible terminal - Ubuntu - Docker - Access to the required Data Streaming Services endpoint - Valid credentials for the stream endpoint - Familiarity with the extension codebase :::hint{type="info"} Only developers who are familiar with the codebase should run the extension locally. Incorrect configuration might cause unexpected errors. ::: ## Configure the extension When you create the extension from the Integrated user interface, a red asterisk (\*) identifies each required variable. When you run the extension locally, define the following environment variables. | Variable | Default value | Description | | -------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | DX\_ENV\_ENVIRONMENT | "" | Required. Specifies the Integrated deployment environment. Supported values are DEV and PROD. | | DX\_EXT\_BATCH\_FREQUENCY | "" | Required. Specifies the sleep interval, in seconds, between status stream checks. | | DX\_EXT\_EXTENSION\_NAME | "" | Required. Specifies the name of the consumer group. | | DX\_EXT\_SOURCE\_GSMA\_CUSTOMER\_CODES | "" | Required. Specifies the three-character account codes configured in the user interface. | | DX\_EXT\_SOURCE\_INSTANCE\_CODES | "" | Required. Specifies the TEC ID configured in the user interface. | | DX\_EXT\_SOURCE\_URL | "" | Required. Specifies the Netcool destination endpoint URL. | | DX\_EXT\_SOURCE\_IP\_ADDRESS | "" | Required. Specifies the destination IP address. | | DX\_EXT\_SOURCE\_USER | "" | Required. Specifies the destination endpoint user for basic authentication. | | DX\_EXT\_SOURCE\_PW | "" | Required. Specifies the destination endpoint password for basic authentication. | | DX\_ENV\_OU\_KEY | "" | Required. Specifies the organizational unit key used to authenticate with Automation Services. | | DX\_EXT\_SOURCE\_CERT | "" | Required. Specifies the source SSL certificate when the source uses a self-signed certificate or a nonstandard certificate authority. | | DX\_EXT\_LOG\_LEVEL | "" | Required. Specifies the log level. | ## Deploy the extension Use the Integrated AIOps user interface to configure and deploy the extension to an individual OU or compute zone. :::hint{type="info"} The extension is intended for use only within the Integrated platform. ::: ## Run the extension locally Use the ./run.sh script to run the extension from a Unix-compatible terminal. The script contains sample scenarios and can use mock servers for local unit testing. To run the extension: 1. Open a Unix-compatible terminal. 2. Go to the extension repository. 3. Configure the required environment variables. 4. Run the following command: :::BlockQuote{indent="1"} ./run.sh ::: ## Configure local stream access The application does not automatically inject the stream URL. Before you run it locally, specify the appropriate Synapps URL, user name, and password. Create the following file in the repository root: local/\*ensitive.sh Add the following content: :::BlockQuote \#!/bin/bash -eux \# Optional. If not set it will become \# https\://098a759b1e7c.1.account.dev.delivery.kyndryl.net/streams/automations-status \# export STREAM\_SOURCE="\[\[ the stream url ]]" export APP\_SYNAPPS\_USER=\[\[the synapps user for the STREAM\_SOURCE url]] export APP\_SYNAPPS\_PW=\[\[the synapps password for the STREAM\_SOURCE url]] \# recommended: turning this on will disable the internal Event forwarder and \# will make logs a little cleaner. export DISABLE\_EVENT\_FORWARDER=TRUE ::: :::hint{type="info"} Protect the local/sensitive.sh file because it contains credentials. Do not commit credentials to the source code repository. ::: ## Run the test suite The extension includes a test suite that connects to mock servers. To run the test suite from Ubuntu with Docker: 1. Open a terminal. 2. Go to the extension repository. 3. Run the following command: ./tes\*/test.sh ## Run the extension with custom options Use the ./test/run.sh script to run the extension locally with custom options. For example: ./test/run.sh \*-prune --interactive This command performs the following actions: 1. Removes containers and images with names that begin with isg\_netcool\_automation\_. 2. Builds an image with a tag that begins with isg\_netcool\_automation\_. 3. Starts a container with the same prefix. 4. Selects an available port near port 8943. 5. Writes the container logs directly to the terminal. The --interactive option displays log output synchronously in the terminal. To view all supported options, run: ./test/run.sh --help\* Execution result The extension ingests incident records from the dedicated ticketing system and publishes them to the automations-status topic. Pull request requirements Pull requests that involve production branches require at least two reviews. Reviews from contributors who committed code to the same pull request do not count toward this requirement. [title] Enable SimpCon Pull Producer [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/SimpCon Extension Templates/ ## Overview This extension retrieves data from an external source system and publishes the data to a Data Streaming Service topic. The extension requires connection details for the source system, including the endpoint URL and authentication credentials. Optional filters, such as assignment groups and domain-separated company names, can be configured to limit the data processed by the extension. The extension prevents unintended data reingestion after Kubernetes restarts by using a stored date and time offset. The extension compares the value of the DX\_ENV\_USER\_START\_DATETIME environment variable with the current UTC date and time. - During a user-initiated start or restart, the stored value should be within one hour of the current UTC time. - During an automatic Kubernetes restart, the environment variable typically contains a previously cached start time that is more than one hour old. - The comparison helps prevent accidental reprocessing of data after an unexpected container restart. :::hint{type="info"} The extension assumes that both the user start date and time and the current date and time use UTC. The one-hour threshold might not be appropriate for all deployment environments and should be evaluated based on operational requirements. ::: ## Chainguard Migration Starting with version 3.0.0, extensions created from this template use the Simplified Connectors framework running on a Chainguard-based Tomcat image. ## Platform Service Interactions The extension transforms and forwards requests to the following Data Streaming Service topic: :::BlockQuote itil-xxxxx-source ::: ## Configure the Extension The following environment variables must be provided to the container: | Variable | Default | Comments | | ------------------------------------------------------------------ | ------------- | ------------------------------------------ | | DX\_ENV\_ENVIRONMENT (string) | | The type of environment the extension | | is running in: LOCAL, DEV, or PROD | | | | DX\_ENV\_PV\_MOUNT (string) | /var/lib/misc | The path where the extension | | state (state.properties) will be deployed on, always /var/lib/misc | | | | DX\_ENV\_OU\_KEY (string) | | OU Tenant Key | | DX\_ENV\_OU\_BAC\_ID (string) | | BAC id of the client | | DX\_ENV\_OU\_ES\_INSTANCE (string) | | The Elasticearch instance the messages | | are supposed to go to on the Consumer side | | | | DX\_EXT\_CDI\_TOOL\_SOURCE (string) | | Client Tool Mapping value | | DX\_EXT\_CDI\_CUSTOMERCODE (string) | | Client Tool Mapping value | | DX\_EXT\_SOURCE\_QUERY\_URL (string) | | SMT URL to query for ticket state | | DX\_EXT\_SOURCE\_USER (string) | | SMT Username used for Basic Authentication | | DX\_EXT\_SOURCE\_PW (string) | | SMT Password used for Basic Authentication | ## Results from Execution The extension retrieves data from ServiceNow and publishes the data to a Data Streaming Service Kafka topic. Because the extension processes data asynchronously, no application-level response code is returned. The extension: - Processes messages in batches at intervals defined by the configured environment variables. - Runs continuously as a containerized application. - Uses Kubernetes liveness and readiness probes to report runtime health status. ## How the extension works This application is a Simplified Connector Producer designed to run as an extension instance in the Integrated platform. The application runs as a container in Kubernetes and follows a producer workflow that retrieves records from the source system and publishes them to a Data Streaming Service topic ## Deploy the extension The extension is intended for deployment and configuration through the Integrated user interface for a specific Organizational Unit (OU) or Compute Zone. :::hint{type="info"} Local execution is intended only for developers who are familiar with the extension codebase. ::: ## Run the extension locally **Build the container image** 1. Open a terminal session. 2. Navigate to the extension directory. :::BlockQuote{indent="1"} cd \ ::: **Build the docker image** :::BlockQuote docker build -t simpcon-pull-producer:1.0.0 -f ./deployment/Dockerfile ::: **Start the container** Run the container and provide the required environment variables. :::BlockQuote docker run --rm \\ \--network host \\ -itd \\ -p 8080:8080 \\ -e DX\_ENV\_ENVIRONMENT=LOCAL \\ -e DX\_ENV\_PV\_MOUNT=/var/lib/misc \\ -e DX\_ENV\_OU\_KEY=098a759b1e7c.1 \\ -e DX\_ENV\_OU\_BAC\_ID=BAC0000BF2 \\ -e DX\_ENV\_OU\_ES\_INSTANCE=es.was1 \\ -e DX\_EXT\_CDI\_TOOL\_SOURCE=SNOW-extsvc \\ -e DX\_EXT\_CDI\_CUSTOMERCODE=id1 \\ -e DX\_EXT\_SOURCE\_QUERY\_URL=[https://dev.service-now.com/api/now/table/incident](https://dev.service-now.com/api/now/table/incident) \\ -e DX\_EXT\_SOURCE\_USER=\ \\ -e DX\_EXT\_SOURCE\_PW=\ \\ simpcon-producer:1.0.0 ::: ## Monitor the container **View running containers** :::BlockQuote docker ps ::: **View container logs** :::BlockQuote docker logs \ | less ::: **Troubleshoot the container** 1. Identify the container ID. :::BlockQuote{indent="1"} docker ps ::: 2. Open a shell session in the container. :::BlockQuote{indent="1"} docker exec -it \ /bin/bash ::: ## Support The Extensions Development Team owns and maintains this extension. [title] Enable SimpCon Push XML Producer [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/SimpCon Extension Templates/ ## Overview The SimpCon Push XML Producer Extension Template provides a framework for developing extensions that receive XML-formatted records from an external source system and publish the records to a Kafka topic through Data Streaming Services. The extension requires details about the external source system, including the system URL and authentication credentials. Optional filters, such as assignment groups and domain-separated company names, can be configured to limit the records processed by the extension. ## Platform service interactions The extension transforms incoming requests and forwards them to the following Data Streaming Service topic: :::BlockQuote itil-xxxxx-source ::: ## Configure the extension The following environment variables must be passed to the container: | Variable | Default | Comments | | ------------------------------------ | ------- | ------------------------------------- | | DX\_EXT\_EXTENSION\_USER (string) | | Mandatory Bridge Username used | | for Basic Authentication | | | | DX\_EXT\_EXTENSION\_PW (string) | | Mandatory Bridge Password used | | for Basic Authentication | | | | DX\_EXT\_SOURCE\_QUERY\_URL (string) | | Mandatory SMT URL to query | | for ticket state | | | | DX\_EXT\_SOURCE\_USER (string) | | Mandatory SMT Username used for | | Basic Authentication | | | | DX\_EXT\_SOURCE\_PW (string) | | Mandatory SMT Password used for Basic | | Authentication | | | | DX\_ENV\_ENVIRONMENT (string) | | Mandatory The type of environment | | the extension is running in: | | | | LOCAL, DEV, or PROD | | | | DX\_ENV\_OU\_KEY (string) | | Mandatory OU Tenant Key | | DX\_ENV\_OU\_BAC\_ID (string) | | Mandatory BAC id of the client | | DX\_ENV\_OU\_ES\_INSTANCE (string) | | Mandatory The Elasticearch instance | | the messages are supposed | | | | to go to on the Consumer side | | | | DX\_EXT\_CDI\_TOOL\_SOURCE (string) | | Mandatory Client Tool Mapping value | | DX\_EXT\_CDI\_CUSTOMERCODE (string) | | Mandatory Client Tool Mapping value | :::hint{type="info"} Store authentication credentials securely. Do not include credentials in source code repositories. ::: ## How the extension works This application is a Simplified Connector designed to run as an extension instance in the Integrated AIOps platform. The extension performs the following actions: - Receives XML-formatted records from an external source system. - Transforms the incoming requests. - Publishes the transformed records to a Data Streaming Service Kafka topic. The extension runs as a container in a Kubernetes environment. ## Results The extension runs as a containerized application and uses Kubernetes liveness and readiness probes to report runtime health status. ## Deployment The extension is intended for deployment and configuration through the Integrated user interface for a specific Organizational Unit (OU) or Compute Zone. :::hint{type="info"} Local execution is intended only for developers who are familiar with the extension codebase. ::: ### Run the extension locally **Build the container image** 1. Open a terminal session. 2. Navigate to the extension directory. :::BlockQuote{indent="1"} cd \ ::: **Build the docker image** :::BlockQuote docker build -t simpcon-push-producer:1.0.0 -f ./deployment/Dockerfile ::: **Start the container** Run the container and provide the required environment variables. :::BlockQuote docker run --rm \\ \--network host \\ -itd \\ -p 8080:8080 \\ -e DX\_EXT\_EXTENSION\_USER=\ \\ -e DX\_EXT\_EXTENSION\_PW=\ \\ -e DX\_EXT\_SOURCE\_QUERY\_URL=[https://devibmimieu.service-now.com/api/now/table/incident](https://devibmimieu.service-now.com/api/now/table/incident) \\ -e DX\_EXT\_SOURCE\_USER=\ \\ -e DX\_EXT\_SOURCE\_PW=\ \\ -e DX\_ENV\_ENVIRONMENT=LOCAL \\ -e DX\_ENV\_OU\_KEY=098a759b1e7c.1 \\ -e DX\_ENV\_OU\_BAC\_ID=BAC0000BF2 \\ -e DX\_ENV\_OU\_ES\_INSTANCE=es.was1 \\ -e DX\_EXT\_CDI\_TOOL\_SOURCE=SNOW-extsvc \\ -e DX\_EXT\_CDI\_CUSTOMERCODE=id1 \\ simpcon-push-producer:1.0.0 ::: ### Monitor the container **View running containers** :::BlockQuote docker ps ::: **View container logs** :::BlockQuote docker logs \ | less ::: **Troubleshoot the container** 1. Identify the container ID. :::BlockQuote{indent="1"} docker ps ::: 2. Open a shell session in the container. :::BlockQuote{indent="1"} docker exec -it \ /bin/bash ::: ## Support The Extensions Development Team owns and maintains this extension. [title] Cluster Config Assistant [path] Services/Platform Services/Cloud Management/Container Cluster Management/Actionable Insights/ The** Cluster Config Assistant **helps site reliability engineers (SREs) and operations teams identify underutilized clusters and optimize resource consumption. The feature uses a data science (DS) model to analyze cluster utilization data and generate recommendations for downsizing cluster configurations when appropriate. # Access Downscaling Cluster Use the** Downscaling Clusters** page to identify clusters that may be overprovisioned and review optimization recommendations generated by the Cluster Config Assistant data science model. The recommendations are based on historical cluster utilization data and help operations teams evaluate opportunities to reduce resource consumption while maintaining application performance. Reviewing these insights enables informed decisions about cluster sizing by comparing current and recommended node configurations and analyzing utilization trends over time. Follow these steps to access Downscaling Cluster: 1. From the Kyndryl Bridge main menu, go to **Services** → **Platform Services** →** Cloud Management **→** Container Cluster Management** 2. From the left side menu, select **Actionable Insights**. 3. Open **Downscaling Clusters** to open the Downscaling page and view clusters with optimization recommendations. # Downscaling Clusters page The **Downscaling Clusters** page helps operations teams identify clusters that may be overprovisioned and review optimization opportunities generated by the Config Assistant Model. The recommendations are based on historical cluster utilization data collected and analyzed by the data science model, helping users determine whether a cluster can be downsized while maintaining stability and performance. Information in this view is intended to support operational decision-making by providing recommended node configurations, utilization insights and historical usage trends. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/8yDoeGiiVgnht8jYUnnkm_upload.png) ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/EhOxoRhSRGDqCr7it0inF_upload.png) # Page Components ## Last Updated Displays the date and time when the recommendations were last generated, allowing users to verify the freshness of the analysis. ## Utilization Overview Chart This view helps users quickly identify clusters that may have excess capacity and could benefit from downsizing. The model evaluates cluster utilization and recommends reducing node counts when workloads consistently require fewer resources. The chart provides a visual comparison of: - **Actual Utilization** (actively used nodes). - **Underutilized Capacity** (nodes identified as candidates for optimization) . For each cluster, the page identifies resources that have been analyzed and determined to have potential optimization opportunities. The feature identifies clusters with underutilized resources and presents them for review. ## Recommended Action Provides guidance for addressing identified optimization opportunities. The recommended actions include: 1. Validate the recommended node count against workload requirements. 2. Remove surplus nodes in a controlled manner. 3. Monitor cluster utilization after implementing changes. These recommendations are intended to help users safely reduce infrastructure costs while maintaining application availability. ## Optimization Details Table The Optimization Details table provides detailed information for each cluster recommendation, including: - **Cluster Name**: Name of the cluster with an optimization opportunity. - **Cluster Type**: The cluster platform (for example, Kubernetes). - **Applications**: Applications running on the cluster. - **Environment**: Associated environment information. - **Actual Nodes**: Current number of cluster nodes. - **Recommended Nodes**: Suggested node count calculated by the Config Assistant Model. - **Generated Date**: Date when the recommendation was created. To view detailed recommendation information for a cluster, click the cluster name in the Optimization Details table. This opens the recommendation details page, where you can review the suggested node configuration, utilization insights and historical trend data used by the Config Assistant Model to generate the recommendation. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/SyBspwjIIDP436lMFCAUA_upload.png) ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/UDnJkHdNuNhnszYAlXnjW_upload.png) Cluster with higher node counts received recommendations to reduce the number of nodes based on observed utilization data. Users can select a cluster to view more detailed recommendation information and historical utilization trends. # How Recommendations Are Generated The **Config Assistant Model** analyzes historical cluster utilization data to identify underutilized resources and generate cluster downsizing recommendations. These recommendations are intended to help operations teams make informed decisions about resource optimization while maintaining application performance and availability. Consider the following when reviewing recommendations: - Recommendations are generated after a minimum of **7 days** of utilization data is available and are based on all historical data collected, not just the initial 7-day period. As additional data is gathered, the model continues to refine its recommendations using the complete available utilization history. - The model continues to aggregate additional utilization data over time, up to **90 days**. - Additional historical data generally improves the accuracy and reliability of recommendations. - Historical utilization trends are available to help assess whether resource consumption patterns are consistent over time. - Recommendations are advisory and should be evaluated alongside workload requirements, operational constraints, and potential usage seasonality before implementing cluster sizing changes. [title] [path] Services/Platform Services/ [title] SimpCon Extension Templates [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/ ## Overview SimpCon Extension templates provide a framework for developing Data Streaming Service integrations that consume, process, and publish data through Kafka topics. These templates simplify extension development by offering predefined patterns for handling inbound and outbound data streams within the Integrated platform. The available templates support the following integration scenarios: - **Consumer template:** Consumes records from Data Streaming Services, enriches and validates data using client-tool mappings, and forwards transformed requests to the ElasticSearch instance configured for the target Compute Zone. - **Producer template (Source Extraction):** Creates Data Streaming Service producers that extract data from source systems and publish it to Kafka topics. Extensions based on version 3.0.0 and later use the Simplified Connectors framework running on a Chainguard-based Tomcat image. - **Producer template (JSON Input): **Accepts JSON-formatted data pushed from external source systems and publishes the data to Kafka topics for downstream processing. - **Producer template (XML Input):** Accepts XML-formatted data pushed from external source systems and publishes the data to Kafka topics for downstream processing. ## Prerequisites Before deploying this extension, the target Organizational Unit (OU) must be onboarded to Bridge . Known problems and limitations The extension supports only incident ticketing sources. Use separate applications or assets for other endpoint integrations. [title] Insights details on Unsupported & Nearing-end-of-Support Kubernetes or OpenShift Clusters [path] Services/Platform Services/Cloud Management/Container Cluster Management/Actionable Insights/ Kubernetes and OpenShift introduce three new versions each year, offering access to the latest features, security improvements and bug fixes. You can monitor your clusters and associated kKubernetesubernetes or OpenShift versions, allowing you to quickly detect outdated clusters and take appropriate actions guided by recommendations. The Actionable Insights page features interactive tiles showing the count of clusters nearing the end of active support. These clusters fall into three categories: - Number of **Clusters K8s/OCP versions nearing end of active support: **Clusters that will soon exceed active support. - Number of **Clusters K8s/OCP versions with maintenance support only: **Clusters that have passed the end of active support but still receive maintenance support. - Number of **Clusters K8s/OCP versions without support:** Clusters that have gone beyond both the end of active support and maintenance support, hence receiving no support. Click any of these three tiles to update the table list displaying insight details and recommendations related to the selected tile. The table header allows you to search for a specific cluster name, filter by all Kubernetes versions, export the table results to an xlsx file, or configure the table settings. The table includes the following fields: - **Cluster**: The cluster's name. - **Cluster type:** The type of cluster. - **Version number**: The current Kubernetes or OpenShift version running on the cluster. - **Active support end date**: The date when active support for the current version ends. - **Maintenance support end date**: The date when maintenance support for the current version ends. - **Date**: The date when the recommendation was generated. By default, the table is sorted by the recommended date. Selecting a cluster name or the overflow menu under the Action column opens a slider panel with more recommendation details. # Recommendations slider panel This panel provides: - **Cluster**: The cluster's name. - **Recommendation**: Based on the Kubernetes or OpenShift version's support status, including: - Clusters nearing Active Support end. - Clusters with Maintenance Support only. - Clusters with No Support. - **Current Version**: Shows the operating version. - **Latest Version Available for Update**: Displays the latest available version. - **Active Support End**: Date when active support ends. - **Maintenance Support End**: Date when maintenance support ends. - **Additional Info**: Link to the current version's changelog. - **Recommended Date**: Date of recommendation issuance. [title] Set up Access Group or Policy (Authorization) [path] Services/Platform Services/Data Foundation/Data fabric/ ## Overview To query data from the Data Query layer, the requesting user must have the appropriate authorization. Authorization is managed through domain-specific access groups in ARMS and determines which users can access data tables within a domain. Each domain has a dedicated access group that grants read access to all tables registered under that domain. Membership in the required access group is mandatory, regardless of whether the data pipeline is running or the table is registered in the Data Catalog. Queries issued without the necessary authorization return a permission error. Use the procedures in this section to request access to the appropriate domain access group and verify that the required permissions have been assigned. - **Execution Platform:** ARMS - **Request process:** Access Request (request access to the domain-specific access group using ARMS) - **Responsible:** Data Engineer ### Access Group Naming Convention Access groups follow the naming convention: :::BlockQuote *data-domain-\* ::: **Example: **Domain\:Service Maintenance > Access Group\:data-domain-service\_maintenance ### Request Access to an Access Group ARMS supports access group requests through two organizational unit (OU) types: - Account level - Compute Zone level :::hint{type="info"} * Compute Zone-level access groups are being deprecated. Account-level access groups are becoming the primary authorization method supported by the Data Query layer. * Account-level access is currently available in the staging environment and is undergoing validation. Use the Account-level process for new requests. If issues occur, use the Compute Zone-level process until the rollout is complete. ::: ## Account-Level OU Access (Recommended) Use the Account-level OU access model to request authorization for domain-specific data access groups. This model is the preferred authorization mechanism for the Data Query layer and is intended to replace Compute Zone-level access groups. After approval, users can query all tables registered under the authorized domain. **Status:** Available in the staging environment and currently under validation before general availability. **Asset location:** images/getting\_started/arms-account-level-access/ :::hint{type="info"} Account-level access is currently available in the staging environment and is undergoing validation before general availability. If issues are encountered during the rollout, use the Compute Zone-level access process as a temporary alternative. ::: Perform the following steps to request access at the Account-level: 1. Open the [ARMS Portal](https://eu1sr1lnarms-dev.bats.kyndryl.net/arms2). 2. Navigate to **User > AIOPS Requests > Request Access Groups**. 3. Select **OU Type **as** Account**. 4. Use **Filter** to narrow the list by Unit Tag or POD. 5. Select the required account or organizational unit, such as: - Kaiser Permanente1 – Dev - ServiceNow – Dev - ServiceNow - Staging 6. Click **Next**. 7. Review the **Standard Access** groups displayed for the selected accounts. 8. Select **Advanced Form** because domain-specific access groups (data-domain-\*) are not included in Standard Access. 9. Under **Data Lake Service**, search for and select the access group for the required domain. Example: data-domain-service\_maintenance 10. Click **Next**. 11. Enter a business justification. 12. Click **Submit**. 13. The request is routed to the designated approver. 14. After approval, access is granted to query all tables registered under the selected domain. ::::hint{type="info"} :::Paragraph{indent="1"} Request access only to the domains required for job responsibilities to simplify approval and access management. ::: :::: ## Compute Zone-Level OU Access (Deprecated) Use the Compute Zone-level OU access model to request authorization for domain-specific access groups when Account-level access is unavailable or cannot be used. This access model continues to provide access to domain data; however, it is being phased out in favor of the Account-level authorization model. :::hint{type="info"} - Compute Zone-level access groups are being phased out and will be replaced by Account-level access groups. Use the Account-level process whenever possible. - Until Account-level access is fully validated and generally available, Compute Zone-level access remains available as a fallback option. ::: ### Request Compute Zone-Level Access Perform the following steps to request access at the Compute zone-level: 1. Open the [ARMS Portal](https://eu1sr1lnarms-dev.bats.kyndryl.net/arms2). 2. Navigate to **User > AIOPS Requests > Request Access Groups**. 3. Select **OU Type** as Compute Zone. 4. Select the appropriate compute zone, such as: - dev\_was1 - staging\_was1 5. Select **Advanced Form**. 6. Under Data Lake Service, search for and select the access group associated with the required domain. :::Paragraph{indent="1"} **Example:** data-domain-service\_maintenance ::: 7. Click **Next**. 8. Enter a business justification. 9. Click **Submit**. 10. The request is routed to the designated approver for review and approval. 11. After approval, access is granted to query all tables registered under the selected domain. ### Verify Access Assignments After the request is approved, the assigned access group appears in ARMS under: **User > AIOPS Assignments**. ### ARMS Access Group Assignments Use the AIOPS Assignments page to review the access groups assigned to the user account and verify that the required domain access has been granted. :::hint{type="info"} If the domain associated with a target table is unknown, use the [Data Catalog Controller APIs](https://kyndryl.gitbook.io/kyndryl-cto/kyndryl-platform-techdocs/convergence-of-software/datafoundations/overview/getting_started#discovering-domains-and-data-tables-prerequisites-for-querying) to identify available domains and registered tables before submitting an access request. ::: [title] Enable SimpCon Push JSON Producer [path] Services/Platform Services/Data Foundation/Enablement for using Extensions Templates/SimpCon Extension Templates/ ## Overview The SimpCon Push JSON Producer Extension Template provides a framework for developing extensions that receive JSON-formatted records from an external source system and publish the records to a Kafka topic through Data Streaming Services. The extension requires details about the external source system, including the system URL and authentication credentials. Optional filters, such as assignment groups and domain-separated company names, can restrict the records processed by the extension. ## Platform service interactions The extension transforms incoming requests and forwards them to the following Data Streaming Service topic: :::BlockQuote itil-xxxxx-source ::: ## Configure the extension The following environment variables must be passed to the container: | Variable | Default | Comments | | ------------------------------------ | ------- | ------------------------------------------------------------------------------------------- | | DX\_EXT\_EXTENSION\_USER (string) | | Mandatory Bridge Username used for Basic Authentication | | DX\_EXT\_EXTENSION\_PW (string) | | Mandatory Bridge Password used for Basic Authentication | | DX\_EXT\_SOURCE\_QUERY\_URL (string) | | Mandatory SMT URL to query for ticket state | | DX\_EXT\_SOURCE\_USER (string) | | Mandatory SMT Username used for Basic Authentication | | DX\_EXT\_SOURCE\_PW (string) | | Mandatory SMT Password used for Basic Authentication | | DX\_ENV\_ENVIRONMENT (string) | | Mandatory The type of environment the extension is running in: LOCAL, DEV, or PROD | | DX\_ENV\_OU\_KEY (string) | | Mandatory OU Tenant Key | | DX\_ENV\_OU\_BAC\_ID (string) | | Mandatory BAC id of the client | | DX\_ENV\_OU\_ES\_INSTANCE (string) | | Mandatory The Elasticearch instance the messages are supposed to go to on the Consumer side | | DX\_EXT\_CDI\_TOOL\_SOURCE (string) | | Mandatory Client Tool Mapping value | | DX\_EXT\_CDI\_CUSTOMERCODE (string) | | Mandatory Client Tool Mapping value | ## How the extension works The application is a Simplified Connector Producer designed to run as an extension instance in the Integrated platform. The extension performs the following actions: - Receives records in JSON format from an external source system. - Transforms the incoming requests. - Publishes the transformed records to a Data Streaming Service Kafka topic. - The extension runs as a container in a Kubernetes environment. ## Deploy the extension Deploy and configure the extension through the Integrated user interface. The extension supports deployment to individual OUs and Compute Zones within the platform. :::hint{type="info"} Local execution is intended only for developers who are familiar with the extension codebase. ::: ## Run the extension locally **Build the container image** 1. Open a terminal. 2. Go to the extension directory. :::BlockQuote{indent="1"} cd \ ::: **Build the docker image** :::BlockQuote docker build -t simpcon-push-producer:1.0.0 -f ./deployment/Dockerfile ::: ## Start the container Run the following command and replace the placeholder values with the appropriate configuration: :::BlockQuote docker run --rm \\ \--network host \\ -itd \\ -p 8080:8080 \\ -e DX\_EXT\_EXTENSION\_USER=\ \\ -e DX\_EXT\_EXTENSION\_PW=\ \\ -e DX\_EXT\_SOURCE\_QUERY\_URL=[https://kyndryleudev.service-now.com/api/now/table/incident](https://kyndryleudev.service-now.com/api/now/table/incident) \\ -e DX\_EXT\_SOURCE\_USER=\ \\ -e DX\_EXT\_SOURCE\_PW=\ \\ -e DX\_ENV\_ENVIRONMENT=LOCAL \\ -e DX\_ENV\_OU\_KEY=098a759b1e7c.1 \\ -e DX\_ENV\_OU\_BAC\_ID=BAC0000BF2 \\ -e DX\_ENV\_OU\_ES\_INSTANCE=es.was1 \\ -e DX\_EXT\_CDI\_TOOL\_SOURCE=SNOW-extsvc \\ -e DX\_EXT\_CDI\_CUSTOMERCODE=id1 \\ simpcon-push-producer:1.0.0 ::: **Monitor the container** View running containers :::BlockQuote docker ps ::: **View the container logs** :::BlockQuote docker logs \ | less ::: **Troubleshoot the container** Identify the container ID :::BlockQuote docker ps ::: Open a shell session in the container :::BlockQuote docker exec -it \ /bin/bash ::: Support The Extensions Development Team owns and maintains this extension. [title] Business context mapping [path] Services/Platform Services/Inventory/Application Inventory/Overview/Onboarding/ ## Business unit and business service mapping with criticality The system allows users to manage information about Business Units, Business Services, and their Criticality during the onboarding process in the Application Portfolio. Users can add, modify, or delete this information before final submission, but can't update it afterward, which may lead to inaccurate records. Outside of onboarding, users can view and manage Business Units, Business Services, and criticality mappings at any time, giving them control over the information. Feature capabilities: - View Captured Data: The system makes it easy for users to display Business Units, Services, and Criticality values. Users can see all captured values on the Business Units and Services page, providing a sense of ease and convenience. - Add a Business Unit: Admin users can add and save a new business unit, which then appears in the list and is stored in the system. - Modify an Existing Business Unit: A user can update and save details of an existing Business Unit. Changes will be reflected in the list and stored in the system. - Delete a Business Unit: An admin user with the appropriate permissions can delete a Business Unit, which removes it from both the list and the system. - Add or Update a Business Service with Criticality Mapping: Admin can add or modify a Business Service and assign a Criticality value, which will be saved with the service. - Assign Priority Order to Criticality: Changing the priority for Criticality values will save the order and apply it wherever criticality appears. - Map Business Services to Business Units: Admin can map a Business Service to a Business Unit, and the mapping is saved and displayed correctly. ## Entity ID and metadata enrichment A unique identification number has been assigned to each entity, facilitating consistent identification across Bridge services. This will enhance metadata management and integration across systems such as C2E, Inventory, and DevSecOps. A standardized identifier will address issues caused by varying Source IDs, ensuring accurate recognition and mapping of entities throughout the system. These entities are managed by the application and business service portfolio as the Kyndryl Platform's system of record. They use a universal identifier for cross-app correlation, which may be stored for future reference. Entities include: - Application - Deployment - Component (Internal) - Business Unit - Business Service Correlation covers lifecycle and update events: - Entity created - Entity deleted - Entity updated The normalization process removes special characters and spaces, converting all text to lowercase. ## Roles Viewer: Users with viewer roles can view both entityId and entityCRN fields (read-only) on Application or Business Service Foundation entities. Entity ID and Entity CRN are generated and maintained as system-managed backend identifiers for all entities. These identifiers are visible in the UI for Applications, Business Services, and Business Units to support consistent identification and traceability. For Component entities, the Entity ID and Entity CRN are generated and stored in the backend for correlation and integration purposes but are not exposed in the user interface. ## Review and submit This is the final verification stage. 1. Review the following information - Uploaded source files - Business unit assignments - Criticality mappings - Business service relationships 2. If changes are required, users can return to previous stages using the stepper. 3. When complete, select **Submit** **Outcome** *Successful Submission* Users are redirected to the Application Inventory Dashboard, where onboarded applications become available for analysis and visualization *Submission failure* - The affected step is marked incomplete - Validation errors are displayed - Users can correct data and resubmit **Notifications** Notifications automatically dismiss after a few seconds. Users may see temporary system notifications such as: - Manual Upload Required: A required source file has not been uploaded - Processing Previous Upload: The platform is processing a previously uploaded file. **Getting Help** For assistance: - Use the Feedback panel available on every page - Create a Support Ticket from the page footer - Submit a Service Request from the validation screen for technical issues [title] [path] Services/Platform Services/ [title] Containers and Clusters running Kubernetes or OpenShift versions [path] Services/Platform Services/Cloud Management/Container Cluster Management/Actionable Insights/ Survey Kubernetes and OpenShift clusters, using valuable insights that enable optimization of your container deployments. Every year, Kubernetes or OpenShift rolls out three fresh updates, each loaded with new features, fortified security measures, and bug rectifications. The Red Hat OpenShift container platform v4.8 uses a structured lifecycle in which at least four minor versions are sustained simultaneously. The support duration is fixed from the point of the minor version release, offering a range of support and maintenance levels. Red Hat strives to predict releases on a 4-month cycle, giving you plenty of time to prepare. In the Container Cluster Management dashboard, you can survey your clusters and their corresponding Kubernetes or OpenShift versions. This grants you the power to promptly identify and take appropriate measures with clusters operating on outdated Kubernetes or OpenShift versions, guided by our recommendations. # Insights for Containers Container insights collected from various sources are displayed on the Container Cluster Management dashboard. This information is organized into interactive widgets made up of selectable tiles. These tiles present a numeric count of Containers and provide descriptive information regarding the utilization of resources. # Containers Memory overutilized To access and view insights for Containers, follow the steps outlined below 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers with overutilized memory, select the **Containers Memory overutilized** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers Memory underutilized To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers with under-utilized memory, select the **Containers Memory underutilized** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers CPU underutilized To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers with under-utilized CPU, select the **Containers CPU underutilized** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **CPU utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **CPU Usage**: A graph illustrating CPU usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers CPU overutilized To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers with overutilized CPU, select the **Containers CPU overutilized** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **W**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **CPU utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **CPU Usage**: A graph illustrating CPU usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers Running out of CPU To access and view insights for Containers Running Out of CPU, follow the steps outlined below: 1. Navigate to the Actionable Insights widget on your dashboard. 2. Select the **Containers Running out of CPU** tile for more detailed insights. 3. Once the Actionable Insights page opens, the selected insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Deployment Name**: The unique name associated with the specific deployment. - **Namespace**: The domain specifies where the container operates. - **Cluster**: The name of the distinct cluster hosting the pod deployment. - **CPU** **Limit**: The pre-established usage restrictions for the specific deployment. - **Current** **CPU** **Usage**: A historical average of the deployment’s resource utilization. - **Predicted CPU Usage**: The highest anticipated CPU usage over the next seven days. - **Recommendations**: Suggestions derived from usage data to facilitate optimal resource utilization. - **Recommended Date**: The date the pertinent recommendations were formulated. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details as a graphical representation encompassing a prediction zone, highlighted alongside a yellow line that depicts prospective trends for a span extending to a maximum of 7 days based on the projected date. This visual aid assists in apprehending the prospective trajectory of resource usage. As you navigate further, you will find metrics meticulously laid out for you in a tabular form, presenting a detailed breakdown as follows: - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Node**: The node that the Container is running on. - **Container**: The namespace where the Container resides. - **CPU** **Limit**: The pre-established usage restrictions for the specific deployment. - **Current usage**: A historical average of the deployment’s resource utilization. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Predicted date for running out of CPU**: The date predicted for the CPU to run out. - **Recommendation date**: The date the recommendation was made. # Containers Running out of Memory To access and view insights for Containers Running Out of Memory, follow the steps outlined below: 1. Navigate to the **Actionable Insights **widget on your dashboard. 2. Select the " tile for more detailed insights. 3. Once the Actionable Insights page opens, the selected insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container, and columns provide different types of information: - **Deployment Name**: The unique name associated with the specific deployment. - **Namespace**: The domain specifies where the container operates. - **Cluster**: The name of the distinct cluster hosting the pod deployment. - **Memory Limit**: The pre-established usage restrictions for the specific deployment. - **Current Memory Usage**: A historical average of the deployment’s resource utilization. - **Predicted Memory Usage**: The highest anticipated memory usage over the next seven days. - **Recommendations**: Suggestions derived from usage data to facilitate optimal resource utilization. - **Recommended Date**: The date the pertinent recommendations were formulated. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details as a graphical representation encompassing a prediction zone, highlighted alongside a yellow line that depicts prospective trends for a span extending to a maximum of 7 days based on the projected date. This visual aid assists in apprehending the prospective trajectory of resource usage. As you navigate further, you will find metrics meticulously laid out for you in a tabular form, presenting a detailed breakdown as follows: - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Node**: The node that the container is running on. - **Container**: The namespace where the container resides. - **Memory Limit**: The pre-established usage restrictions for the specific deployment. - **Current usage**: A historical average of the deployment’s resource utilization. - **Recommendation**: Specific recommendations for improving the container's performance. - **Predicted date for running out of Memory**: The date predicted for the memory to run out. - **Recommendation date**: The date the recommendation was made. # Containers without CPU limit To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers without CPU limit, select the **Containers without CPU limit** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Deployment**: The name of the deployment for the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **CPU Usage**: A graph illustrating CPU usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers without CPU request To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers without CPU request, select the **Containers without CPU request** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container, and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Deployment**: The name of the deployment for the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **CPU Usage**: A graph illustrating CPU usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers without CPU request and limit To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers without CPU request and limit, select the **Containers without CPU request and limit** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **CPU Usage**: A graph illustrating CPU usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers without Memory limit To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in Containers without memory limit, select the **Containers without Memory limit** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container, and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers without Memory request To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you are interested in Containers without Memory request, select the **Containers without Memory request** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers without Memory request and limit To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you are interested in Containers without Memory request and limit, select the **Containers without Memory request and limit** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container, and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Containers with minimal CPU & Memory utilized To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you are interested in Containers with minimal CPU & Memory utilized, select the **Containers with minimal CPU & Memory utilized** tile. 3. Once the Actionable Insights page opens, the selected Container insight will be displayed in the summary section, with the table below refreshed with information regarding the specific container. This table provides a summary of each Container's current status. Each row of the table represents a specific container, and columns provide different types of information: - **Container Name**: The unique name of the container. - **Container(s)**: The specific containers running in the container. - **Node**: The node that the Container is running on. - **Cluster**: The name of the cluster that the Container is part of. - **Memory utilization**: The percentage of utilized memory. - **Recommendations**: Suggestions for optimizing the performance of the container. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular container, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the container, such as: - **Container**: The name of the container. - **Container(s)**: The name of the container(s) running in the container. - **Namespace**: The namespace where the Container resides. - **Cluster**: The name of the cluster, which is also a link to the cluster. - **Insight**: Detailed information about the Container's current status. - **Memory Usage**: A graph illustrating Memory usage over the last few months. - **Recommendation**: Specific recommendations for improving the Container's performance. - **Recommendation date**: The date the recommendation was made. # Insights for clusters running Kubernetes or OpenShift versions Within the actionable insights widget, you will find interactive tiles that show the count of clusters nearing the End of Active Support, clusters that have gone beyond the End of Active Support but are still receiving Maintenance Support and clusters that have exceeded both the End of Active Support and Maintenance Support. In the cluster list table, you will notice icons to the left of the Kubernetes or OpenShift version number in the column. When you click these icons, you will see a tooltip with information about the version status and a link that opens recommendations in the slider panel. In the recommendations slider panel, you'll find the following: - **Cluster Name**: Displayed as the title. - **Recommendation**: Based on the current state of your Kubernetes or OpenShift version, with three possible pieces of advice: - For clusters nearing the end of Active Support nearing the end of Active Support, you will see a note that Active Support will end in X days, and Maintenance Support will end in X days. We advise you to consider updating to the latest version. - For clusters with maintenance support only, you will be alerted that Active Support ended X days ago and Maintenance Support will end in X days. Again, it's suggested that you update to the latest version. - You'll see a warning for clusters with no support that both Active and Maintenance Support has ended. It is strongly recommended to update to the latest version. - **Current Version**: Shows the current version of Kubernetes or OpenShift on your cluster. - **Latest Version**: Indicates the most recent version of Kubernetes or OpenShift available for installation. - **Active Support End**: Displays the date when the active support for your current version will conclude. - **Maintenance Support End**: Specifies the date when the maintenance support for your current version will terminate. - **Additional Info**: Provides a link to the changelog for your current Kubernetes or OpenShift version, letting you see the changes made and issues addressed. - **Recommended Date**: Presents the date when the given recommendation was generated. # Clusters K8s/OCP versions with support for maintenance only To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you are interested in clusters running Kubernetes or OpenShift with only maintenance support, select the **Clusters K8s/OCP versions with support for maintenance only** tile. 3. Once the Actionable Insights page opens, the selected cluster insight will be displayed in the summary section, with the table below refreshed with information regarding the specific cluster. This table summarizes each cluster's current status; now select the version number of the cluster you are inquiring about. Each row of the table represents a specific cluster and columns provide different types of information: - **Cluster Name**: The unique name of the Cluster. - **Cluster Type**: The specific cluster type, whether it is Kubernetes or OpenShift. - **Version no**: The number of the cluster version. - **Active support end date**: The last day of active support. - **Maintenance support end date**: The last day of maintenance support. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular cluster, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the cluster, such as: - **Cluster**: The name of the cluster. - **Current Version**: The current version of the cluster. - **Latest version**: The latest version of the cluster. - **Active support end**: The last date of active support. - **Maintenance support end**: The last date of maintenance support. - **Additional info**: Reference link to the cluster for additional information. - **Recommendation date**: The date the recommendation was made. # Clusters K8s/OCP versions nearing end of active support To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in clusters running Kubernetes or OpenShift versions nearing the end of active support, select the **Clusters K8s/OCP versions nearing end of active support** tile. 3. Once the Actionable Insights page opens, the selected cluster insight will be displayed in the summary section, with the table below refreshed with information regarding the specific cluster. This table summarizes each cluster's current status; now select the version number of the cluster you are inquiring about. Each row of the table represents a specific cluster, and columns provide different types of information: - **Cluster Name**: The unique name of the Cluster. - **Cluster Type **: The specific cluster type, whether it is Kubernetes or OpenShift. - **Version no **: The number of the cluster version. - **Active support end date **: The last day of active support. - **Maintenance support end date **: The last day of maintenance support. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular cluster, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the cluster, such as: - **Cluster**: The name of the cluster. - **Current Version **: The current version of the cluster. - **Latest version **: The latest version of the cluster. - **Active support end **: The last date of active support. - **Maintenance support end **: The last date of maintenance support. - **Additional info **: Reference link to the cluster for additional information. - **Recommendation date**: The date the recommendation was made. # Clusters K8s/OCP versions without support To access and view insights for Containers, follow the steps outlined below: 1. Navigate to the **Actionable insights** widget on your dashboard. 2. Select a tile of interest to view more detailed insights. For example, if you're interested in clusters running Kubernetes or OpenShift versions without support, select the **Clusters K8s/OCP versions without support** tile. 3. Once the Actionable Insights page opens, the selected cluster insight will be displayed in the summary section, with the table below refreshed with information regarding the specific cluster. This table summarizes each cluster's current status; now select the version number of the cluster you are inquiring about. Each row of the table represents a specific cluster and columns provide different types of information: - **Cluster Name**: The unique name of the Cluster. - **Cluster Type **: The specific cluster type, whether it is Kubernetes or OpenShift. - **Version no **: The number of the cluster version. - **Active support end date **: The last day of active support. - **Maintenance support end date **: The last day of maintenance support. - **Recommended date**: The date the recommendation was provided. For more detailed insights about a particular cluster, go to the overflow menu on the far right of the table and select **View Details**. A new window will open and present additional details about the cluster, such as: - **Cluster**: The name of the cluster. - **Current Version**: The current version of the cluster. - **Latest version**: The latest version of the cluster. - **Active support end**: The last date of active support. - **Maintenance support end**: The last date of maintenance support. - **Additional info**: Reference link to the cluster for additional information. - **Recommendation date**: The date the recommendation was made. [title] Actionable Insights [path] Services/Platform Services/Cloud Management/Container Cluster Management/ provides actionable insights so that as a Site Reliability Engineer (SRE), you can manage your container resources effectively. These insights allow you to identify which clusters might require updates due to unsupported Kubernetes, OpenShift versions, or those nearing end-of-support. You can also pinpoint containers that are either under or over-utilizing resources by comparing actual consumption against allocated Memory and CPU usage. # Calculations for Optimal Resource Utilization As you direct your DevOps team to establish a baseline for Memory and CPU usage, you can rely on the algorithm, which uses CPU request and limit, Memory request and limit and historical data, to inform you of required resource adjustments as described in the following limited examples: 1. **Optimal Memory Limit Recommendations for Containers**: - Metrics include memory requests, limits, frequency of Out of Memory Kills, and usage history. - Action: SRE reviews and adjusts values as needed. 2. **Optimal CPU Limit Recommendations for Containers**: - Metrics include CPU requests, limits, and consumption history. - Action: SRE adjusts node sizing and plans VM migrations for load balancing. # Utilization Rules - Containers are underutilized if CPU or Memory usage is less than 50% of the requested amount. - Containers are overutilized if experiencing frequent Out of Memory issues or if Memory usage exceeds 90% of the set limit. - Upscaling is considered if CPU usage exceeds 90% of the set limit for significant periods. - Containers lacking CPU Limit or Request settings are flagged accordingly. - While generating Capacity & Utilization insights, the ML models consider lesser buffers for lower environments and more buffers for higher environments as follows: - Dev - 20% - UAT - 30% - Pre-Prod – 40% - Prod – 50% :::hint{type="info"} Note: A minimum of 7 days of usage data is required for generating accurate insights. Container replicas are grouped under their deployment names for resource usage analysis. ::: # Actionable Insights page Select any tile within the Actionable Insights widget on the main dashboard to navigate to the Actionable Insights page. The data displayed on this page depends on which tile you select from the dashboard. If, for example, you select Security & Compliance, the page will display data associated with resources that have exceeded warning or comprise thresholds for security and compliance concerns. The page contains the following elements: - Bread crumbs for efficient navigation. - Header to identify your current location in the Bridge Kyndryl portal. - A dropdown list enabling you to select either the default data view or a filtered view that you saved: 1. Filter by **Providers**, **Connections**, **Applications** and **Environments**, **Insights category**, **Kubernetes** and **OpenShift.** Click **Apply** to view only data relevant to your current requirement. 2. Click **Save View** to save the filtered view for a later time, providing a relevant name when prompted. 3. If you further filter data, you can update the current view by clicking **Update View**. 4. Click **Delete** to delete the saved view. - Insights Summary, which displays four of tiles that navigate to insight details within four classes: - Security & Compliance - Performance - Reliability - Optimization - **Insight Type** filter that enables filtering by specific insights within the current insight class. - **Severity **filter that enables filtering by severity level. - An insights table that provides data generated for each cluster, for the current insights class (Security & Compliance, Performance, Reliability and Optimization.. # Supported Insights Insights for Containers and Clusters running Kubernetes or OpenShift enable preemptive action. Insights are listed within the context of four insight classes: - Security and Compliance - Performance - Reliability - Optimization Supported Insights include the following: - **Security & Compliance** - K8S\_VERSION\_REACHED\_END\_OF\_LIFE: Need immediate action. - K8S\_VERSION\_CROSSED\_END\_OF\_SUPPORT: K8s Version crossed support life, now only on maintenance support. - K8s\_VERSION\_EXTENDED\_SUPPORT: K8s Version on extended support. - K8S\_VERSION\_NEARING\_END\_OF\_SUPPORT: Low priority, can wait till it is critical. - NAMESPACE\_WITHOUT\_NETWORK\_POLICY: Namespaces that are not secured with network policies. - **Performance** - CPU\_RUNNING\_OUT: CPU usage with respect to limits is above 90% and is forecasted to go above limits in the next 7 days. - CPU\_OVER\_UTILIZED: CPU usage with respect to limits is above 90% but not running out. - MEMORY\_OVER\_UTILIZED: Memory usage with respect to limits is above 90% but not running out. - **Reliability** - POD\_FAIL\_CRASHLOOP: Pod is in Crashloop back off state and crashing. - MEMORY\_RUNNING\_OUT: Memory usage with respect to limits is above 90% and is forecasted to go above limits in the next 7 days. - POD\_FAIL\_PENDING: Pod is in pending state and not up. - POD\_FAIL\_RESTART: Pod has restarts, but not in crash loop back off or pending. - SINGLETON DESIGN: Pods with one replica. - PVC\_OVER\_UTILIZED: Persistent Volume Claim is more than 20% of what is provisioned. - PVC\_RUNNING\_OUT: Based on the current Persistent Volume Claim usage trend, provisioned PVC will run out in seven days. - **Optimization** - High Risk MINIMAL\_CPU\_MEMORY\_UTILIZED: CPU and Memory usage with respect to requests is below 10%. - CPU\_AND\_MEMORY\_LIMITS\_NOT\_SET\_MINIMAL\_USAGE: CPU and Memory limits are not set and CPU and Memory usage with respect to requests is below 10%. - CPU\_REQUESTS\_LIMITS\_NOT\_SET: CPU requests and limits are not set. - MEMORY\_REQUESTS\_LIMITS\_NOT\_SET: Memory requests and limits are not set. - CPU\_LIMITS\_NOT\_SET: CPU limits is not set and the usage with respect to request is above 50%. - CPU\_LIMIT\_NOT\_SET\_UNDER\_UTILIZED: - CPU\_LIMITS\_NOT\_SET\_MINIMAL\_USAGE: CPU limits are not set and CPU and Memory usage with respect to requests is below 10%. - MEMORY\_LIMITS\_NOT\_SET\_MINIMAL\_USAGE: Memory limits are not set and CPU and Memory usage with respect to requests is below 10%. - MEMORY\_LIMIT\_NOT\_SET\_UNDER\_UTILIZED: - MEMORY\_LIMITS\_NOT\_SET: Memory limits is not set and the usage with respect to request is above 50%. - CPU\_UNDER\_UTILIZED: CPU usage with respect to requests is below 50%. - MEMORY\_UNDERUTILIZED - INACTIVE\_VOLUME: The number of clusters with volumes not currently in use (not mounted or actively transferring data) but still properly recognized and managed by the system. - ORPHANED\_VOLUME: The number of clusters with volumes that have lost association with its parent controller or application for example, the Pod or PVC was deleted, but the actual storage remains. - PVC\_UNDERUTILIZED: Persistent Volume Claim is less than 20% of what is provisioned. - HPA\_RECOMMENDED: Recommended minimum and maximum replicas with optimal configuration recommendation (details page). - NETWORK\_USAGE\_GROWTH: - High: Growth rate is above 25%. - Medium: Growth rate is 10% - 25%. # Actionable Insight details pages The Resource Name in the actionable insights table, is a link to a page containing details for the insights data for that cluster in an expanded form. The details page presents various meta data such as Insight type, severity, application, recommended configuration, current configuration and current usage chart. All data is pulled dynamically and presented in near real time. The type of data varies with the current insight class. - [Container Cluster Management landing page](docId\:CjhiD0AHX0pPPqU-7lSKW) Survey Kubernetes and OpenShift clusters, using valuable insights that enable optimization of your container deployments. - [Insights details on Unsupported & Nearing-end-of-Support Kubernetes or OpenShift Clusters](docId:5hUUwXsxVGjq5I9DqpL_I)Explore insights of managing container clusters running Kubernetes or OpenShift versions that are either unsupported or approaching the end of active support. [title] [path] Services/Platform Services/Discovery/Discovered Data Overview/ [title] Agent Visor [path] Services/Platform Services/Knowledge & AI/Agentic AI/Operate, Orchestrate and Optimize / # Overview AgentVisor serves as the control layer that ensures AI agents operate within approved business and security boundaries, while the Policy Service evaluates whether an agent's actions are permissible. AgentVisor manages Bridge AI agent operations, and the Policy Service determines their allowed actions. As a secure runtime environment for AI agents, AgentVisor functions as a controlled operating environment where agents can execute tasks within defined limits, under oversight, and with accountability. Its design aims to assist organizations by enabling them to: - Isolate agent activities - Control access to tools, APIs, data, and services - Apply policy-based restrictions before actions are permitted - Ensure durable execution and recovery of workflows - Create an auditable trail of agent activities - Support enterprise deployment with compliance controls # Key Benefits of Agent Visor  - **Security by Default:** Automatic security validation in the agent lifecycle. - **Consistent Governance:** Uniform policy adherence across all agents. - **Enterprise Observability:** Full visibility into agent behavior. - **Audit Readiness:** Traceable policy evaluations and agent activities. - **Business-Friendly Experience:** Meaningful outcomes for users without technical skills. - **Scalable Agent Adoption:** Confident deployment and management of numerous AI agents across various domains. # Policy enforcement via AgentVisor To ensure agents function correctly in controlled environments, implementing guardrails is crucial. These mechanisms enforce policies for agent actions, data access, and external tool interactions. AgentVisor acts as a policy enforcement tool, providing clear "allow or deny" responses by integrating various policy checks. Before taking any action, an agent must be verified for necessary permissions. AgentVisor monitors all interactions, intercepting requests to ensure compliance through a model known as Policy as a Service (PaaS). It gives a simple yes-or-no response on whether the agent can proceed. For instance, if an agent wants to shut down a virtual machine (VM), AgentVisor first verifies this action to ensure compliance with security protocols, either approving it (yes) or canceling it (no). Policy Service is the business decision layer that determines whether a requested action should be:  - **allowed**  - **denied**  - **allowed only with approval or additional conditions**  It evaluates requests in real time and applies policy-based controls across data, APIs, services, and agent actions.  By combining these measures, Bridge AI Assist ensures that sensitive information remains secure, and interactions are conducted with the highest level of privacy and protection. ## The policy model (PORC) for Agent Visor  Policy Service evaluates decisions using a model called **PORC, **as required by Agent Visor. So, the Policy Rules (Rego) should be written as per the PORC model to enable policy enforcement by Agent Visor.  PORC provides a business-friendly way to answer a simple question: Who is trying to do what, to which thing, and under what conditions?  - **P — Principal**  :::Paragraph{indent="1"}  The principal is the entity that carries out a specific action. This can include individuals such as named employees, service identities, account contexts, or AI agents operating on behalf of a person or process. ::: - **O — Operation**  :::Paragraph{indent="1"} The operation refers to the specific action that is being requested. Common examples of operations include checking the status of a system, notifying an owner, updating a support ticket, or initiating a recovery process. ::: - **R — Resource**  :::Paragraph{indent="1"} The resource represents the target on which the action is performed. This may include systems, applications, support tickets, data assets, or customer environments that are involved in the operation. ::: - **C — Context**  :::Paragraph{indent="1"} The context refers to the broader business or operational environment surrounding the action. This includes aspects such as production status, designated change windows, ticket statuses, sensitivity of assets, and various approval states. ::: # Why policy model matters to business users  The Policy Model (PORC) plays a crucial role in transforming policy into a coherent decision-making framework, moving away from vague technical controls. It enables business stakeholders to clearly understand the foundations of each decision by considering the following key aspects: - The identity of the individual or group making the request - The nature of the action being proposed - The potential impacts of that action - The relevant business conditions at the time of the decision This structured approach provides clarity, making it simpler to justify, govern, review, and explain decisions within the organization.  # The core business principle: default deny  A key design principle in this model is the concept of "default deny." This means that agents start with no access rights unless it is explicitly granted. This principle is particularly important for business teams as it ensures several critical factors: first, new agents do not inherit any unintended permissions; second, sensitive capabilities are only activated intentionally; third, access is gradually expanded based on documented evidence and actual business needs; and finally, governance remains proactive and aligned with user adoption. # How policies should be used  Users should consider policy bundles as a means to define the governance posture of each account. A policy bundle can illustrate: - The types of actions that are generally allowed - The resources that are deemed sensitive - The actions that require approval - The audit evidence that is necessary - The applicable compliance or residency rules - The additional controls required in production environments # Business policies The business policies for the various accounts can be:  - **Access policies** — who or what can use the agent  - **Environment policies** — how rules differ between production and non-production  - **Approval policies** — which actions require a human checkpoint  - **Operational readiness policies** — conditions such as ticket state or change window  - **Compliance policies** — requirements for data, audit, residency, or regulation  - **Notification policies** — when owners or support teams must be informed  # Audit and transparency  A governed agentic AI model should produce clear evidence of:  - who initiated the action  - what was requested  - what resource was involved  - what business context applied  - what policy decision was made  - whether approval was required  - whether the action was ultimately allowed or blocked  This supports compliance reporting, executive assurance, operational review, and post-incident investigation.  [title] Local set up [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Developing agents/ This guide walks you through setting up your local environment for Bridge agent development. # Create your repository 1. Go to [bdg-sw-agents-bridge-agent-template](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-bridge-agent-template) 2. Click **Use this template** → **Create a new repository** 3. Configure: - **Owner**: kyndryl-agentic-ai - **Repository name**: bdg-sw-agents-\{\{your-agent-name}} - **Visibility**: Private 4. Click **Create repository**  # JFrog Artifactory authentication The Bridge Agent SDK is hosted on a private JFrog Artifactory repository. Get JFrog API Token 1. Go to [https://kyndryl.jfrog.io](https://kyndryl.jfrog.io/) 2. Log in with your Kyndryl SSO. 3. Click your **User Profile** (top right) → **Edit Profile.** 4. Under Authentication Settings, click **Generate an Identity Token.** 5. Copy the generated token. **Configure Authentication (.netrc - recommended)** Create or edit \~/.netrc file: ```javascript # Create .netrc file cat >> ~/.netrc << 'EOF' machine kyndryl.jfrog.io login your-email@kyndryl.com password your-jfrog-api-token EOF # Secure the file (required) chmod 600 ~/.netrc ``` **Security note**: Never commit .netrc to version control. # Install dependencies 1. Activate your virtual environment: source venv/bin/activate 2. Install all dependencies (SDK from Artifactory): pip install -r requirements.txt  3. Install test dependencies: pip install -r requirements-test.txt  **Verify SDK Installation** ```javascript from bridge_agent_sdk import BridgeBaseAgent, BridgeBaseWorkflowAgent, create_llm_client print('✅ Bridge Agent SDK installed successfully!')" ``` #  Runtime modes The SDK supports three runtime modes controlled by the KAIF\_MODE environment variable: | **Mode** | **Description** | **Use case** | | ------------------------------------- | -------------------------------------------------------------------------------------------------- | ----------------------------------------- | | local\_dev | No Bridge Platform access. LLM calls go directly to OpenAI. Token/credentials are stubbed locally. | Local development without VPN | | bridge\_dev | Bridge Platform available at dev URLs. All services route through gateways. | Development with Bridge access | | production | Full Bridge Platform integration. All payload fields required. | Production deployment | # Configure environment ## Option A: local\_dev + OpenAI (default - fastest start) Use this when you have a standard OpenAI API key and want the fastest path to running your agent. Create .env file: - KAIF\_MODE=local\_dev - LLM\_PROVIDER=openai - LLM\_MODEL=gpt-4.1-min  - OPENAI\_API\_KEY=sk-your-openai-api-key-here - OPENAI\_API\_BASE=https\://api.openai.com/v1 - Get your key: [https://platform.openai.com/api-keys](https://platform.openai.com/api-keys) ## Option B: local\_dev + Azure OpenAI Use this when your organization provides Azure OpenAI resources. - KAIF\_MODE=local\_dev - LLM\_PROVIDER=azure\_openai - LLM\_MODEL=gpt-4.1-mini - AZURE\_OPENAI\_ENDPOINT=https\://my-resource.openai.azure.com - AZURE\_OPENAI\_API\_KEY=your-azure-api-key - AZURE\_OPENAI\_API\_VERSION=2024-02-01 - AZURE\_OPENAI\_DEPLOYMENT=my-gpt4-deployment :::hint{type="info"} AZURE\_OPENAI\_DEPLOYMENT is the deployment name you created in Azure Portal, not the model name. If omitted, the SDK uses LLM\_MODEL as the deployment name ::: ## Option C: local\_dev + hosted LLM (custom endpoint) Use this for any OpenAI-compatible endpoint that uses non-standard auth (e.g. internal proxy, Kyndryl-hosted LLM). - KAIF\_MODE=local\_dev - LLM\_PROVIDER=hosted\_ll  - HOSTED\_LLM\_BASE\_URL=https\://integration.chatops.kyndryl.net/v1 - HOSTED\_LLM\_AUTH\_HEADER=Bearer your-token-or-api-key - HOSTED\_LLM\_MODEL=my-custom-model - \# Optional extra HTTP headers (JSON) - \# HOSTED\_LLM\_EXTRA\_HEADERS=\{"X-Team": "my-team"} :::hint{type="info"} You do NOT need OPENAI\_API\_KEY for the hosted\_llm provider - the SDK sets openai\_api\_key="none" internally and uses the Authorization header from HOSTED\_LLM\_AUTH\_HEADER. ::: ## Option D: bridge\_dev mode (with Bridge Platform) Use this when you have access to Bridge Platform and need to test with real LLM Gateway, MCP tools, and platform services. - KAIF\_MODE=bridge\_dev - KAIF\_HOST=https\://dev1-aws-oregon-base.bridge.kyndryl.com - SERVICE\_API\_KEY=your-service-api-key - BRIDGE\_ACCOUNT\_ID=your-account-id - bridge\_dev: What You Get - LLM\_MODEL=gpt-4.1-mini :::hint{type="info"} SERVICE\_API\_KEY is mandatory in bridge\_dev mode, the SDK will crash on startup if it is missing. ::: In bridge\_dev mode, all services route through KAIF\_HOST: # Verify setup - Test local\_dev + OpenAI. See [Open AI](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/01-getting-started/03-local-setup.md#test-local_dev--openai) - Test local\_dev + hosted LLM. See [hosted LLM ](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/01-getting-started/03-local-setup.md#test-local_dev--hosted-llm) - Test bridge\_dev mode. See[ testing](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/01-getting-started/03-local-setup.md#test-bridge_dev-mode) - Run your agent :::CodeblockTabs{indent="2"} ```javascript # local_dev - direct execution KAIF_MODE=local_dev python main.py # bridge_dev - with --execution_context CLI arg (platform-style invocation) KAIF_MODE=bridge_dev python main.py --agent_name my_agent --execution_context '{"agent_data":{"content":"test"},"system_data":{"metadata":{"workflow_id":"wf-1","account_id":"acc-1","instance_name":"test","agent_id":"test","user_id":"u1","session_id":"s1"},"connection_details":[],"timeout":1800,"type":"interactive"},"runtime_data":{}}' ``` ::: - **Run Tests** :::CodeblockTabs{indent="2"} ```javascript pytest tests/ -v ``` ::: [title] Migration guide [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/MCP tools/ This guide walks you through migrating an agent from Elasticsearch (ES) queries to the Bridge MCP Server (Trino/SQL via MCP tools). # Prerequisites - Bridge Agent SDK with MCPClient (already in bridge\_agent\_sdk.mcp) - KAIF\_HOST configured for your runtime (SDK can auto-resolve MCP endpoint) - Bridge MCP server URL via BRIDGE\_MCP\_SERVER\_URL only when you want to override endpoint resolution - Runtime agent\_payload containing account\_id and instance\_name #  Step by step migration 1. **Step 1: Identify your domain and table: **Check which domain and table in Bridge corresponds to your ES index. See [step 1](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#step-1-identify-your-domain-and-table) 2. **Step 2: **[Get column schema](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#step-2-get-column-schem) 3. **Step 3: **[Convert ES queries to Trino DSQL](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#step-3-convert-es-queries-to-trino-sql) 4. **Step 4: **[Use MCPClient in code](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#step-4-use-mcpclient-in-cod) 5. **Step 5: **[Parse response](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#step-5-parse-response) **ES → Trino SQL conversion cheatsheet** | **ES concept** | **Trino SQL equivalent** | | ------------------------------------------- | ----------------------------------------------------- | | term | WHERE field = 'value' | | terms | WHERE field IN ('a','b') | | range.gte | WHERE field >= value | | @timestamp now-1d | CURRENT\_TIMESTAMP - INTERVAL '1' DAY | | @timestamp now-2h | CURRENT\_TIMESTAMP - INTERVAL '2' HOUR | | @timestamp now-30m | CURRENT\_TIMESTAMP - INTERVAL '30' MINUTE | | match | WHERE field LIKE '%text%' | | exists | WHERE field IS NOT NULL | | bool.must | AND | | bool.should | OR | | bool.must\_not | NOT (...) | | sort desc | ORDER BY field DESC | | size | LIMIT | | from | OFFSET | | .keyword | Drop suffix (tenant\_id.keyword → tenant\_id) | For an autonomous documentation creation agent, see this [link](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/05-mcp-tools/06-es-to-bridge-mcp-migration.md#complete-example-autonomous-doc-creation-agent).   # What changed (before vs after) | **Aspect** | **Before (ES)** | **After (Bridge MCP)** | | --------------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------- | | Auth | ES username/password from account settings | agent\_payload auto token via MCPClient | | Connection | requests.post(es\_url/index/\_search) | MCPClient.call\_tool\_parsed("bridge\_execute\_query") | | Query format | ES JSON DSL (bool, must, range, term) | Trino SQL (SELECT ... WHERE ... ORDER BY) | | Response parsing | result\["hits"]\["hits"]\[\*]\["\_source"] | parsed\["data"] or parsed\["rows"] | | Config needed | ELASTICSEARCH\_URL, ELASTICSEARCH\_USER, 
ELASTICSEARCH\_PASSWORD | KAIF\_HOST (+ optional BRIDGE\_MCP\_SERVER\_URL override) | | Time ranges | now-1d in ES DSL | CURRENT\_TIMESTAMP - INTERVAL '1' DAY | **Before (Elasticsearch):** Agent → ES HTTP API → Elasticsearch Index → JSON hits **After (Bridge MCP):** Agent → MCPClient → Bridge MCP Server → Trino SQL → JSON rows **Key differences:** - No more ES credentials — authentication is handled via agent\_payload and the SDK TokenService - SQL instead of JSON DSL — write Trino SQL instead of ES bool/match/range - MCP tools instead of HTTP — call bridge\_execute\_query through MCPClient [title] Human-in-the-Loop (HITL) [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Enabling agentic solutions/ Our agents currently do not operate with complete autonomy, which mandates the integration of Human-in-the-Loop (HITL) processes during their creation. The HITL feature in Bridge is crucial for enhancing control and mitigating risks by requiring human approval for all critical AI actions. This allows for the involvement of multiple participants in a single workflow. If a user fails to respond to a HITL request within the established timeframe, the system will automatically deny it, ensuring a predictable timeout behavior that is thoroughly logged for transparency. Agents will pause for user review in the Bridge AI Assist UI, where decisions can be either approved or denied. If there is no response within the specified timeframe, the decision will be automatically denied. This procedure will continue until full (POA) is established. :::hint{type="info"} Agents involved in HITL steps will automatically defer requests if there is no action taken within a 30-minute window. Additionally, all processes must be completed within a two-hour timeframe. This aims to prevent system overload and ensures that workflows remain streamlined, even when multiple approval layers are involved. ::: # CD process for EA Review Readiness  Bridge agentic AI offers templates for developers to build their agents using the enhanced Bridge SDK, which includes features like knowledge bases and connectors. While deploying an agent is straightforward, it's crucial to ensure that only valuable agents are launched.  To avoid clutter from unused agents, we've established checks in our continuous deployment (CD) process. Developers must submit a pull request (PR) with five key components.   Deployment requires two layers of approval prior to advancement. The first is a business approval, which is currently carried out manually. A panel of two business executives reviews each request, accompanied by a succinct high-level description (no more than five sentences) that conveys the asset's intent. The second layer is a technical approval aimed at evaluating whether the code adheres to best practices, maintains security, and is free from issues such as hardcoding. The technical team, under the leadership of architects, is responsible for endorsing the code.  ## Technical / Business analysis   - **What is the value to Kyndryl Teams? **Describe how this agent helps address the business problem.   -  **What is the value to the client? **Explain how to execute this automation/solution and the benefit of running this solution.   - **What kind of resource utilization will this solution have?** resource utilization on the Endpoint server.   - **Does this solution make any changes to the target server?** Does the solution make changes to the system? Does it reboot? Is there any manual approval in play (Human-In-The-Loop) before making such a change?   - **Is the agent deterministic or strictly rule**‑**based in its execution? **Describe the controls that are in place to prevent hallucination or unintended actions. Explain whether the solution ensures predictable, auditable, and safe behavior.   Once both approvals are in place, the CD process can begin. This means the code can move from development to production, ensuring that each deployed agent is necessary and beneficial for the business.  [title] [path] Services/Platform Services/Knowledge & AI/Agentic AI/ [title] [path] Services/Platform Services/Knowledge & AI/Agentic AI/ [title] Agent Ops [path] Services/Platform Services/Knowledge & AI/Agentic AI/Operate, Orchestrate and Optimize / The control tower for an enterprise’s agent estate. It governs what agents can do, observes what they are doing, and ensures resilience, compliance, and cost control across the full lifecycle **Innovation** - Semantic touter - routing relevance with precision - Bayesian ReAct - reacting with reason and Bayesian guardrails - NLQ for operational searches. Pydantic templates prevent prompt injection attacks **Value proposition** - **Accelerates time-to-market** for agentic solutions — teams can create, reuse, and scale workflows without technical expertise. - **Enables secure, rapid onboarding** with MCP-based integrations, governed access, and an ecosystem that connects enterprise and approved public knowledge. - **Reduces engineering overhead** by removing the need to build and maintain orchestration infrastructure. - **Drives AI adoption** across Delivery, Consulting, and Solutioning — unlocking faster insights, automation, and decision-making. - **Boosts Bridge platform adoption** across Advanced Delivery, DWS, Cloud, and Bridge App. - **Delivers enterprise-grade governance** with built-in CI/CD automation, tool integrations, memory management, and cost monitoring. - **Prevents reinvention** by enabling teams to reuse AI workflows across projects and domains. - **Positions Bridge as the enterprise AI backbone** — scalable, extensible, and ready for future multi-agent innovation. # Agents Ops dashboard   The agent library contains your active agents, making effective management essential. To support this, an observability capability is needed to monitor and manage agents while addressing security and compliance. To access the dashboard, go to **Services** > **Platform Services** > **Knowledge & AI** > **Agents Ops**.   The dashboard provides key monitoring insights to enhance operational efficiency. You can access to agent-specific Key Performance Indicators (KPIs), such as the total number of executing agents, metrics on successful and failed executions, and those active for long durations.   You can assess tenant health, deployment status, total execution counts, and trends in token usage. The dashboard includes an agent topology section displaying model usage, agent status, and a complete agent list. 1. Overall Tenant Health: The report shows whether all components are functioning properly. This overview covers a specific time frame, and users can refresh the information to see the latest updates. 2. Total Agents Registered: This section shows the total number of agents registered during the specified period. Alongside the count, a percentage change indicates whether registrations increased or decreased compared to the previous period. 3. Unique Deployments: Here, you'll find the total number of unique deployments that have taken place. Additionally, a percentage change shows any increase or decrease in deployments relative to the last reporting period. 4. Total Executions: This metric shows the cumulative number of executions during the defined timeframe, along with a percentage change indicating whether this figure increased or decreased compared to the previous period. 5. Successful Executions: This section lists the total number of successful executions. It also provides a percentage change to show whether successful outcomes increased or decreased compared to earlier results. 6. Failed Executions: This section reports the total number of executions that did not succeed. For context, a percentage change shows how this figure compares—whether it has increased or decreased—relative to the last reporting period. 7. Token Usage: This metric captures total token usage, including both input and output tokens. This figure is accompanied by a percentage change comparing current usage to the previous period, highlighting any upward or downward trends. **Weekly Execution Analysis (7-Day Overview):** This comprehensive report offers an in-depth examination of successful and failed executions over the past week. It aims to identify trends and discern patterns within this specific timeframe, providing valuable insights into performance and operational efficiency. **Agents Distribution: ** Metrics for each agent encompass execution counts, success rates, and recent statistics, along with their status (active, inactive, or in draft mode) and overall capacity insights. - Model in Use: This section outlines the models currently in operation, including those scheduled to be activated soon. - Agent Status: A visual representation (in the form of a donut chart) illustrates the distribution of agents based on their current status, offering a quick snapshot of their operational condition. - Agent Type: This breakdown categorizes agents by type, showing the number of agents in each category. - Agent Topology: A graphical display depicts the arrangement and connections between agents, highlighting the overall architecture of the agent network. **Active Agents Table:** This table lists active agents and details essential metrics such as agent name, total executions, success rate, and the date of the last execution. **MCP Server and Tools Registry Table:** This section provides an overview of the MCP server and the total count of available tools, helping track resources and tool utilization efficiently. [title] Obtaining credentials [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Developing agents/ This guide explains how to obtain all the credentials and access needed for agent development. # Obtain credentials :::::WorkflowBlock :::WorkflowBlockItem **Get JFrog API token** 1. Go to [https://kyndryl.jfrog.io](https://kyndryl.jfrog.io/) 2. Log in with your Kyndryl SSO 3. Click your **User Profile** (top right corner) → **Edit Profile** 4. Under Authentication Settings, click **Generate an Identity Token** 5. Copy and save the generated token securely ::: :::WorkflowBlockItem **Repository access** No separate TaaS or additional repository-access request is required to pull the Bridge Agent SDK. If your Kyndryl SSO account can sign in to JFrog, proceed directly with token generation and .netrc setup ::: ::::WorkflowBlockItem **Configure .netrc** 1. Create or edit \~/.netrc: ```javascript cat >> ~/.netrc << 'EOF' machine kyndryl.jfrog.io login your-email@kyndryl.com password your-jfrog-api-token EOF chmod 600 ~/.netrc ``` :::Paragraph{listStyleType="disc" indent="2"} Option A: OpenAI API key (local\_dev): For local\_dev mode, you need direct access to OpenAI. ::: :::Paragraph{indent="2"} **Option A: Personal OpenAI account** ::: :::Paragraph{listStyleType="decimal" listRestartPolite="1" indent="2"} Go to [https://platform.openai.com/api-keys](https://platform.openai.com/api-keys) ::: :::Paragraph{listStyleType="decimal" listStart="2" indent="2"} Sign in or create an account ::: :::Paragraph{listStyleType="decimal" listStart="3" indent="2"} Click **Create new secret ke**" ::: :::Paragraph{listStyleType="decimal" listStart="4" indent="2"} Copy and save the key (starts with sk-) ::: :::Paragraph{listStyleType="disc" indent="2"} Option B: Azure OpenAI (Kyndryl) ::: :::Paragraph{indent="2"} Contact your team lead for Kyndryl Azure OpenAI credentials. ::: 2. Configure environment ```javascript OPENAI_API_KEY=sk-your-key-here OPENAI_API_BASE=https://api.openai.com/v1 ``` :::: ::::: # Bridge Platform credentials For bridge\_dev and production modes, you need Bridge Platform access. ::::WorkflowBlock :::WorkflowBlockItem **Get Bridge Console access** 1. Request access to Bridge Console via your team lead or the KAIF onboarding team 2. Log in to the Bridge Console at your account-specific URL ::: :::WorkflowBlockItem **Create a service ID and get the SERVICE\_API\_KEY** The SERVICE\_API\_KEY is not a personal API key — it is the key associated with a Service ID (a machine/service account) on the Bridge Platform. Your agent uses this key to authenticate with the service and get a bearer token. How to create a Service ID: 1. Log in to the Bridge Admin Console for your account 2. Navigate to **Manage & Administer **→ **Access Management** → **Service IDs**) 3. Click **Create Service ID** 4. Fill in the details: - **Name**: A descriptive name (e.g., incident-enrichment-agent-dev) - **Description**: Purpose of this service ID 5. The platform generates a service API key; copy it immediately 6. Store it securely; this becomes your SERVICE\_API\_KEY env var The key is shown only once at creation time. If you lose it, you must create a new Service ID.  ::: :::WorkflowBlockItem **Get account ID** 1. In Bridge Console, go to **Account** → **Settings** (or check the URL — the account ID is in the host name) 2. Copy your **Account ID** (e.g., 697afe33bc0bab35cc54f8ae) The account ID also appears in the account-specific host URL. For example https\://kaiftestaccount-us-697afe33bc0bab35cc54f8ae.bridge.kyndryl.com ::: :::WorkflowBlockItem **Get KAIF host URL** The KAIF\_HOST is the global Bridge Platform URL used for , LLM, audit, and other platform services. This is different from the account-specific URL. ::: :::: | **Variable** | **URL Pattern** | **Example** | | ----------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | KAIF\_HOST (global) | \{\{global-instance}}https\://-\{\{region}}-\{\{global-id}}}}.bridge.kyndryl.com | https\://globalkaiffvt-us-6997f3f1ffcf5c8001488dfc.bridge.kyndryl.com | | BRIDGE\_MCP\_SERVER\_UR
 (optional) | https\://\{\{account-name}}-\{\{region}}-\{\{account-id}}.bridge.kyndryl.com/kaif/v2/mcp/tools | https\://kaiftestaccount-us-697afe33bc0bab35cc54f8ae.bridge.kyndryl.com/kaif/v2/mcp/tools | :::hint{type="info"} In bridge\_dev mode the SDK automatically builds the MCP endpoint from KAIF\_HOST (\{\{KAIF\_HOST}}/kaif/v2/mcp/tools). You only need BRIDGE\_MCP\_SERVER\_URL if your MCP server lives on a different host than KAIF\_HOST. Ask your KAIF platform admin for the correct KAIF\_HOST URL for your environment. ::: # MCP server access For MCP tools (ServiceNow, Bridge Data, etc.), the SDK auto-resolves the MCP endpoint from KAIF\_HOST in bridge\_dev mode. You only need BRIDGE\_MCP\_SERVER\_URL if your MCP server runs on a different host. The MCP Server URL is account-specific: https\://\{\{account-name}}-\{\{region}}-\{\{account-id}}.bridge.kyndryl.com/kaif/v2/mcp/tools **Configure .env** Only needed if your MCP server URL differs from [KAIF\_HOST BRIDGE\_MCP\_SERVER\_URL](https://myaccount-us-abc123def456.bridge.kyndryl.com/kaif/v2/mcp/tools) ## MCP tool permissions To use specific MCP tools, your account must have them provisioned. Run the [MCP discovery script](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-development-guide/blob/main/docs/02-new-agent-development/05-mcp-tools-discovery.md) to see what's available for your account. Common tools: | **Tool** | **Description** | **Notes** | | ------------------------------------- | -------------------------------------------- | -------------------------------------- | | servicenow\_search\_incidents | Search ServiceNow incidents | Primary way to look up incidents | | servicenow\_get\_all\_incidents | List ServiceNow incidents | Paginated, up to 100 | | servicenow\_create\_incident | Create a new incident | All 4 fields required | | bridge\_execute\_query | Query Bridge Data Lake (Trino SQL) | Most commonly used | | bridge\_list\_tables | List available tables | Enabled by default | | bridge\_list\_domains | List data domains | Enabled by default | :::hint{type="danger"} Tools like servicenow\_get\_ticket and servicenow\_update\_ticket do not exist on the current MCP server. Always verify with the discovery script before writing agent code. ::: ## Langfuse tracing (optional) For observability and tracing: Get Langfuse credentials 1. Request Langfuse access from your team lead 2. Get your project credentials from Langfuse dashboard **Configure .env** ```javascript LANGFUSE_SECRET_KEY=sk-lf-... LANGFUSE_PUBLIC_KEY=pk-lf-... LANGFUSE_BASE_URL=https://cloud.langfuse.com ``` [title] [path] Services/Platform Services/Knowledge & AI/ [title] Troubleshooting [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Developing agents/ | **Error** | **Description** | **Solution** | | --------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "forbidden for user" error | Your JFrog account doesn't have read permission on the SDK repository. | No separate access request is required. Re-login to JFrog with Kyndryl SSO, regenerate your identity token, refresh your local JFrog credentials, and retry. | | "No matching distribution found" | Credentials not configured or no repository access. | See [Developing agents](docId\:u0nqBox9bYe1CN-YialWW) for the complete troubleshooting flow. | | "forbidden for user" (JFrog) | No read permission on SDK repository. | No separate access request is needed. Verify JFrog sign-in and credentials:
1) Re-login to [https://kyndryl.jfrog.io](https://kyndryl.jfrog.io/) using Kyndryl SSO 2) Regenerate your JFrog identity token 3) Refresh your local JFrog credentials and retry pip install | | "401 Unauthorized" (MCP) | SERVICE\_API\_KEY not set or invalid. | 1. Verify SERVICE\_API\_KEY is set in .env 2. Regenerate the key in Bridge Console if expired | | "403 Forbidden" (MCP Tools) | Account doesn't have permission for the specific MCP tool. | Contact Bridge Admin to enable the required tools for your account.
"Connection refused" (KAIF\_HOST) | | "403 Forbidden" | Incorrect KAIF\_HOST URL or no VPN connection. | 1) Verify KAIF\_HOST URL format 2) Ensure you're connected to Kyndryl VPN 3) Check if the environment is up | ## Debug ```javascript curl -u "your-email@kyndryl.com:" \ "https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple/bridge-agent-sdk/" ``` ## pip prompting for credentials ```javascript .netrc not configured or has wrong permissions. chmod 600 ~/.netrc ``` [title] Classification Guide [path] Services/Platform Services/Inventory/Infrastructure & Cloud Inventory 3.0/ # Classification structure | **Hosting Domain**  | **Category**  | **Subcategory**  | | ------------------------------------------------ | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | on-premises  | Operating System  | Appliances, Hypervisor, Linux, Mainframe, Network, Orchestrator, Others, Storage, Unix, Windows  | | on-premises  | Operating System Subsystem  | Analytics Platform, Antivirus, Appliance, Application, Containerization/Orchestrator, Core Infrastructure Services, Cybersecurity, Database Management Systems (DBMS), IT Management, Linux, Mainframe, Middleware, Monitoring, Others, Programming language, Resiliency, Security, Tool/Library, Utilities, Virtualization, Web Server  | | on-premises  | Appliances  | Appliances  | | on-premises  | Other Hardware  | Accessory, Hardware Component, Rack, UPS  | | on-premises  | LPAR  | LPAR  | | on-premises  | Network Hardware  | Appliances, Bridge, Controller, Firewall, Gateway, Load Balancer, Modems, Network, Network Controller, Others, Router, Switch, Wireless Access Point, Tape  | | on-premises  | Server Hardware  | Blade Server, Mainframe, Others, Rack Server, Tower Server, Appliance  | | on-premises  | Storage Hardware  | Block Storage, File Storage, Mainframe, Object Storage, Others, Resiliency, San FC switch, Storage Hardware - Misc, Switch  | | on-premises  | Virtual Machine  | vSphere VM  | | on-premises  | Virtual Machine Cluster  | vCluster  | | on-premises  | Datacenter  | Private Datacenter  | | on-premises  | Hypervisor  | ESXi  | | on-premises  | Virtual Network  | Switch, Network, Distributed Port Group, Uplink Port Group  | | on-premises  | Virtual Storage  | Datastore, Datastore Cluster  | | azure  | Compute  | Virtual Machines, Azure functions - PaaS Serverless Functions service on Azure, Virtual Desktop Workspaces, App Service, VM Scale Sets, Availabiity Sets. | | azure  | Databases  | Azure SQL database, Azure SQL.  | | azure  | Infrastructure  | Recovery Services Vault, Compute Galleries, Backup Vault, Web Apps.  | | azure  | Management and Governance 
  | Cost Optimization, Resource Tagging, Resource Management, Azure Resource Management – PaaS Development Management service on Azure, Log Analytics Workspaces. | | azure  | Network  | Network Interfaces, priveate\_dnszones, Public IP Addresses  | | azure  | Networking  | Azure Network Watcher, Azure Virtual Network Manager, Load Balancer, VPN Gateway. | | azure  | Security  | Access Policies, Role-Based Access Control, Network Security Groups.  | | azure  | Storage  | Azure Managed Disks - IaaS Managed Disks service on AZURE, Azure Container Storage, Azure Managed Disks – IaaS Managed Disks service on Azure, Azure files, Azure Backup, Table Storage, Azure Blob Storage, Storage Accounts. | | gcp  | AI and ML  | Document AI - SaaS Document Processing service on GCP, Vertex AI  | | gcp  | App Development  | Cloud Workstations, Pub/Sub  | | gcp  | App Hosting  | Google Kubernetes Engine (GKE), App Engine, Cloud Run  | | gcp  | Infrastructure  | Virtual Servers, Serverless Functions, VM Images, Health Checks, Instance Groups, Artifact Registry, Artifact Packages, Compute Engine Persistent Disks - IaaS Persistent Disks service on GCP, Disk Snapshots  | | gcp  | Data Analytics and Pipelines  | BigQuery, Cloud Composer, Dataflow, Dataplex, Dataproc, Looker  | | gcp  | Databases  | Bigtable, Cloud SQL, Filestore, Spanner, Firestore, Memorystore for Memcached  | | gcp  | Networking  | Cloud DNS - IaaS DNS Service service on GCP, Cloud Interconnect, Cloud Router, Cloud VPN, VPC Service Controls - SaaS Network Security service on GCP, Cloud Load Balancing, IP Address Management, Virtual Networking, Global IP Addresses, Backend Services  | | gcp  | Storage  | Cloud Storage  | | gcp  | Security  | Network Security, Encryption Keys, Identity and Access Management (IAM)  | | gcp  | Data & AI  | Database Backup, NoSQL Datastore, Realtime Database Rules  | | gcp  | Management  | Auto Scaling, Cloud Deployment Manager - PaaS Deployment Manager service on GCP  | | gcp  | Observability and monitoring  | Monitoring  | | oci  | Networking and Content Delivery  | Virtual Cloud Network, Oracle DNS Resolver - IaaS DNS Resolver service on OCI, Oracle DNS Zones - IaaS DNS Zones service on OCI, Oracle Dynamic Routing Gateway - IaaS Dynamic Routing Gateway service on OCI, Service Gateway, Virtual Circuit  | | oci  | Oracle Databases  | Autonomous AI Database  | | oci  | Compute  | Virtual Servers  | | oci  | Containers and Functions  | Container Instances, Oracle Container Registry - PaaS Container Registry service on OCI  | | oci  | Databases  | Base Database, Exadata Infrastructure, VM Cluster, Exadata Database, Pluggable Database  | | oci  | Security  | Oracle Network Security Groups - IaaS Network Security Groups service on OCI  | | oci  | Storage  | Object Storage  | | aws  | Analytics  | Amazon Athena, Amazon Kinesis, Amazon Redshift, AWS Glue, Big Data Platform, Search & Analytics Engine, Amazon Data Firehose, Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Analytics - PaaS Stream Processing service on AWS  | | aws  | Application Integration  | Message Broker, Amazon Simple Notification Service, Amazon Simple Queue Service, Workflow Orchestration  | | aws  | Machine Learning  | Amazon Lex, Amazon Comprehend, Amazon Polly, AWS Rekognition - SaaS Image and Video Analysis service on AWS, Amazon SageMaker AI, Amazon Transcribe  | | aws  | Business Applications  | Amazon WorkMail  | | aws  | Cloud Financial Management  | Budget Planning, Cost Reporting, Cost Analysis, AWS Pricing Calculator, AWS Reservations - SaaS Reservation Management service on AWS, Cost Optimization  | | aws  | Compute  | AWS Lambda - PaaS Serverless Functions service on AWS, Amazon Elastic Compute Cloud, Virtual Compute, AWS Batch  | | aws  | General Reference  | AWS Support  | | aws  | Containers  | Amazon Elastic Container Service, Amazon ECR - SaaS Container Registry service on AWS, Amazon Elastic Kubernetes Service  | | aws  | Databases  | Amazon ElastiCache, In-Memory Cache, Amazon DynamoDB - PaaS NoSQL Database service on AWS, Amazon Relational Database Service, AWS RDS Reserved Instances - PaaS Reserved Database service on AWS  | | aws  | Developer Tools  | AWS CodeBuild, Source Control, AWS X-Ray, AWS CodeDeploy, AWS CodePipeline  | | aws  | End User Computing  | Amazon WorkSpaces  | | aws  | Networking and Content Delivery  | Amazon API Gateway, AWS Direct Connect - IaaS Dedicated Network Connection service on AWS, Elastic Load Balancing, Static IP,DNS Service, Amazon Route 53,Amazon VPC - IaaS Virtual Network service on AWS  | | aws  | Internet of Things (IoT)  | IoT Event Processing  | | aws  | Management and Governance  | Amazon CloudWatch, AWS Config, AWS License Manager, AWS Organizations, AWS Service Catalog, AWS Trusted Advisor, Systems Management, Auto Scaling, Scaling Policy, Scheduled Scaling, AWS CloudTrail, Performance Insights, AWS Resource Groups, AWS CloudFormation. | | aws  | Security  | AWS Certificate Manager - SSL/TLS Certificates service on AWS,AWS IAM Access Analyzer - SaaS Access Analysis service on AWS,AWS Certificate Manager - SaaS Certificate Management service on AWS, Amazon Cognito - SaaS User Authentication service on AWS, Amazon GuardDuty - SaaS Threat Detection service on AWS,AWS IAM - SaaS Identity & Access Mgmt service on AWS,AWS IAM Assume Role Policy - SaaS Role Assumption Policy service on AWS,AWS IAM Groups - SaaS User Groups service on AWS,AWS IAM Instance Profile - SaaS Instance Profile service on AWS,AWS IAM Policy - SaaS Access Policies service on AWS,AWS IAM Role - SaaS IAM Roles service on AWS,AWS IAM SAML Provider - SaaS SAML Provider service on AWS,AWS IAM Server Certificate - SaaS Server Certificates service on AWS,AWS IAM User - SaaS IAM Users service on AWS,AWS Secrets Manager - SaaS Secrets Management service on AWS,AWS Security Groups - IaaS Network Security service on AWS,AWS Security Hub - SaaS Security Management service on AWS,AWS Shield - SaaS DDoS Protection service on AWS,AWS WAF - SaaS Web Application Firewall service on AWS,AWS WAFv2 - SaaS Web Application Firewall v2 service on AWS,AWS WAF Regional - SaaS Regional WAF service on AWS  | | aws  | Storage  | AWS Backup, Amazon Glacier, AWS Storage Gateway, Amazon S3 - IaaS Object Storage service on AWS, Amazon EBS - IaaS Block Storage service on AWS, Amazon Elastic File System  | | aws  | Migration and Transfer  | Application Migration, Environment Migration  | | aws  | Cryptography & PKI  | AWS KMS - SaaS Key Management service on AWS  | | ibmcloud  | Integration  | Event Streaming, Messages for RabbitMQ  | | ibmcloud  | Compute  | Serverless Functions, Bare Metal Servers, Reserved Capacity, IBM Virtual Servers - IaaS Virtual Servers service on IBM Cloud, Virtual Server for VPC,IBM VPC Dedicated Host - IaaS VPC Dedicated Hosts service on IBM Cloud  | | ibmcloud  | Containers  | Container Service, Red Hat OpenShift on IBM Cloud, IBM VPC Kubernetes Cluster - PaaS VPC Kubernetes Cluster service on IBM Cloud, Code Engine  | | ibmcloud  | Databases  | Cloudant, Databases for Elasticsearch, Databases for MongoDB, Databases for PostgreSQL, Databases for Redis, Databases for MySQL, IBM Db2 Warehouse - PaaS Data Warehouse Storage service on IBM Cloud  | | ibmcloud  | Management and Governance  | Auto Scaling  | | ibmcloud  | Observability  | Cloud Logs, Cloud Monitoring  | | ibmcloud  | Networking and Content Delivery  | Content Delivery Network, Global IP Address, IPSec VPN, Network ACL, Network Gateway, Network Gateway Members, Subnets, VPE Gateway  | | ibmcloud  | Networking  | IBM Cloud Direct Link - IaaS Direct Link service on IBM Cloud, IBM Cloud DNS Services - IaaS DNS Service service on IBM Cloud, Load Balancers for Classic, IBM VPC Load Balancer - IaaS VPC Load Balancer service on IBM Cloud, IBM Virtual Private Cloud - IaaS Virtual Private Cloud service on IBM Cloud, Transit Gateway  | | ibmcloud  | Security  | Hyper Protect Crypto Services, IBM IAM API Keys - IAM API Keys service on IBM Cloud, IBM IAM Access Groups - IAM Access Groups service on IBM Cloud, IBM IAM Policies - IAM Policies service on IBM Cloud, IBM IAM Roles - IAM Roles service on IBM Cloud, IBM IAM Service IDs - IAM Service IDs service on IBM Cloud, IBM IAM Users - IAM Users service on IBM Cloud, Key Protect, IBM Security Groups - IaaS Security Groups service on IBM Cloud  | | ibmcloud  | Storage  | Archive Storage, Block Storage for Classic, Object Storage, Cold Vault Storage, Backup Service, File Storage for Classic, IBM VPC Block Storage - IaaS VPC Block Storage service on IBM Cloud, IBM Cloud Backup for Classic  | # Definitions | **Category** | **Definition** | | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Operating System | A type of software that manages computer hardware, software resources, and provides common services for computer programs. The resources typically include processor, memory, storage, input/output devices, and network connections. | | Operating System Subsystem | A Subsystem is a single, predefined operating environment through which the Operating System coordinates the work flow and resource use. An Operating System can contain several Subsystems, all operating independently of each other. Subsystems manage resources. | | Appliances | Pre-configured hardware devices combined with specialized software designed to perform dedicated functions (e.g., firewall, load balancer) with minimal customization. | | Other Hardware | Supporting physical infrastructure not directly acting as compute, network, or storage. | | LPAR | A logical partition of a physical system that operates as an independent computing environment with allocated processor, memory, and input/output resources. Logical partitioning is the ability to make a physical device run as if it were two or more independent devices. | | Network Hardware | Physical electronic device which is required for communication and interaction between devices on a computer network. Specifically, it mediates data connectivity and traffic in a computer network. | | Server Hardware | Physical machine designed to host and run applications, services, or virtualized workloads. It provides functionality for other programs or devices. | | Storage Hardware | Technology consisting of computer components and recording media that are used to store, manage and retrieve digital data. | | Virtual Machine | A software-based emulation of a physical computer that runs its own operating system and applications on virtualized hardware resources. | | Virtual Machine Cluster | A group of interconnected virtual machines or hosts configured to provide high availability, load balancing, or distributed processing. | | Datacenter | A physical facility that houses computing, networking, and storage infrastructure along with supporting systems such as power and cooling. | | Hypervisor | Software or firmware layer that enables creation and management of virtual machines by abstracting physical hardware resources. | | Virtual Network | A software-defined network that provides isolated connectivity and routing for virtualized workloads independent of physical network infrastructure. | | Virtual Storage | Abstracted storage resources provided to virtualized environments, decoupled from underlying physical storage hardware. | | AWS | *https\://docs.aws.amazon.com/* | | GCP | *https\://docs.cloud.google.com/docs/product-list* | | AZURE | *https\://learn.microsoft.com/en-us/azure/?product=popular* | | IMB Cloud | *https\://cloud.ibm.com/catalog#ibm\_products* | | OCI | *https\://www\.oracle.com/cloud/* | # Use case examples | **Resource** | **Hosting domain** | **Category** | **Subcategory** | | ------------------------------------------------------ | ----------------------------------------------- | ----------------------------------------- | -------------------------------------------- | | Physical x86 server discovered via ITAM / scanner | On-premise | Server | Rack server | | Archived physical server still receiving updates | On-premise | Server | Rack server | | Storage array referenced in location / catalog updates | On-premise | Storage | Block storage | | VMware ESXi host referenced as parent of VMs | On-premise | Operating System | Hypervisor | | Windows Server OS attached to hardware CI | On-premise | Operating System | Windows | | Linux OS discovered by Ansible inventory scanner | On-premise | Operating System | Linux | | Amazon EC2 instance | AWS | Compute | EC2 | | Amazon RDS PostgreSQL | AWS | Database | RDS | | Azure VM | Azure | Compute | Virtual Machine | # AWS & Azure Use Cases  ## 1. Category & Subcategory Classification Validation  Verify that the Category and Subcategory available in the Provider Portal are aligned with the classification sheet shared by the Cloud team.  Identify and document any classification mismatches.  ## 2. Inventory Data Mapping Validation  Verify that the existing Inventory 3.0 data is mapped to the correct Category and Subcategory.  Ensure that inventory records consistently follow the approved classification structure.  ## 3. Mismatch Resolution Validation  Verify that the Category and Subcategory mismatches identified in the Cloud Portal have been corrected.  Confirm that the updated classifications are accurately reflected in the Provider Portal and Inventory 3.0.  ### Expected Outcome  - Consistent Category/Subcategory classification across AWS, Azure, Provider Portal, and Inventory 3.0.  - Accurate mapping of existing inventory data.  - All identified classification mismatches are resolved and validated.  # For more information [Cloud resources classification](https://github.com/kyndryl-cto/bdg-sw-inv-inventory-write-service-v3/blob/development/DDL/data/resource-classification/classification_hyperscaler.csv). [On-premse resouces classification](https://github.com/kyndryl-cto/bdg-sw-inv-inventory-write-service-v3/blob/development/DDL/data/resource-classification/classification_datacenter.csv). [title] [path] Services/Platform Services/Inventory/Infrastructure & Cloud Inventory 3.0/ [title] Agentic Solutions Mode [path] Services/Platform Services/Knowledge & AI/Bridge AI Assist/Bridge AI Assist Overview/Interaction modes/ The Agentic Solutions mode demonstrates the next phase of AI Assist — enabling autonomous agents to perform complex, multi-step reasoning and data retrieval tasks. Each agent starts with a basic set of solutions that can be changed later. Agents follow a specific workflow, which is a sequence of tasks they complete together. The output is in read-only text; no actions or triggers are executed. You can switch configurations between available solutions, like DeepThink or IT Modernization Advisor, if those options are available. ### Frameworks and examples Agentic Solutions is powered by two internal frameworks: - **CrewAI:** a simplified, out-of-the-box drag-and-drop type of framework for creating basic agents and workflows. - **LangGraph:** a developer-oriented framework supporting advanced, customizable agents with coding and integration capabilities. Two example solutions are available during the Alpha phase: - **IT Modernization Agentic Advisor:** an out-of-the-box demonstration of CrewAI. - **DeepThink: **a LangGraph-based custom agentic solution, built by another team and deployed on the Bridge platform for demonstration. ### Capabilities - Demonstrates autonomous, multi-agent reasoning - Allows users to interact with predefined agents for specific use cases (for example, migration planning or RCA document generation). ### Requirements - Must be part of the ACME account - Must belong to at least one of the KAIF access groups: KAIF Admin, KAIF Editor, KAIF Viewer. - The Bridge account must have access to . - Access permissions to relevant operational datasets are required. - Users without access must request authorization before using this capability. ### Limitations - Only English language is supported. - Chat history is not stored. - Performance may vary when multiple users run queries simultaneously; therefore, requests may queue and respond slowly. - The feature is meant primarily for demonstration; configuration screens for creating or managing agents are not yet available. # Uploading files to generate an RCA document   Agentic Solutions mode supports file uploads to generate Root Cause Analysis (RCA) documents after an incident. The system analyzes the content of uploaded files to identify key incident details, contributing factors, and timelines, and compiles them into a structured RCA report. This automation reduces manual effort, speeds up report creation, and helps maintain consistent incident documentation. :::hint{type="info"} This feature is enabled by default for all users. ::: ## Generate an RCA document 1. Log in to the Bridge AI Assist portal. 2. From the right-hand panel, open the RCA Document Generator. 3. In the chat text box, select the **+ **(upload) icon. 4. Upload one or more incident-related files. 5. In the chat, type **Generate RCA for the attached document**. 6. Wait while the system processes the files. This may take a few moments. 7. When processing is complete, download the generated RCA document. ## File upload limits - You can upload up to five files per session. Supported formats include PDF, PPT, and Word. - The maximum total file size is 10 MB per session. :::hint{type="info"} The output is currently generated in PDF format only and is not available in editable formats such as PPT or Word. ::: ## Data handling Uploaded files are used only during the active session to provide context-aware responses. The content is not stored in the knowledge base and is not retained after the session ends. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/ltMaLcGj_W2epjLz3ez0r_image.png" size="60" width="1100" height="716" darkWidth="1100" darkHeight="716" position="center" caption="Uploading file and generating RCA document" showCaption="true"} [title] Single agent [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ # Building a single agent This guide covers building agents using BridgeBaseAgent for sequential, single-pipeline use cases. Use BridgeBaseAgent when your agent: - Follows a linear, sequential flow. - Has a single execution path. - Doesn't need conditional routing between multiple sub-agents. ```javascript from bridge_agent_sdk import BridgeBaseAgent, AgentConfig class MyAgent(BridgeBaseAgent): """Your custom agent.""" CONFIG = AgentConfig( name="my-agent", version="1.0.0", description="My agent description", ) def setup_tools(self) -> list: """Return list of LangChain tools available to the agent.""" return [] def setup_prompt(self) -> str: """Return the system prompt for the agent.""" return "You are a helpful assistant." ``` ## Lifecycle methods | **Method** | **Purpose** | **When Called** | | --------------------------------------- | ---------------------------------------- | -------------------------------------------- | | setup\_tools() | Define available tools | On initialization | | setup\_prompt() | Define system prompt | On initialization | | execute() | Main agent logic | On each invocation | | initialize() | Async init (LLM, resources) | Before first execution | | aclose() | Cleanup resources | After execution | # Add single agent ## Step 1: Define Your Tools :::::WorkflowBlock :::WorkflowBlockItem Create tools in src/tools/my\_tools.py: ```javascript from langchain_core.tools import tool from typing import List, Dict, Any @tooldef search_database(query: str) -> List[Dict[str, Any]]: ``` ::: :::WorkflowBlockItem Search the database for records matching the query. query: The search query string ::: ::::WorkflowBlockItem Returns: List of matching records ```javascript return [{"id": 1, "name": "Result 1"}] @tool def get_metrics(metric_name: str, time_range: str = "1h") -> Dict[str, Any]: ``` Retrieve metrics for the specified metric name. Args:         metric\_name: Name of the metric to retrieve. :::Paragraph{indent="1"} time\_range: Time range (e.g., '1h', '24h', '7d')   :::     Returns: Metric data with timestamps and values ```javascript return {"metric": metric_name, "values": [1, 2, 3]} ``` :::: ::::: ## Step 2: Implement Your Agent ::::WorkflowBlock :::WorkflowBlockItem Create agent in src/agents/my\_agent.py: Import logging ```javascript from typing import Dict, Any, Union, Optional from bridge_agent_sdk import BridgeBaseAgent, AgentConfig, AgentInput from bridge_agent_sdk.execution_context import ExecutionContext from src.tools.my_tools import search_database, get_metrics logger = logging.getLogger(__name__) class MyAgent(BridgeBaseAgent): ``` ::: :::WorkflowBlockItem Search agent data and provide insights This agent:     1. Receives a user query     2. Searches the database for relevant information     3. Analyzes the results using LLM     4. Returns formatted insights ```javascript CONFIG = AgentConfig( name="my-agent", version="1.0.0", description="Data analysis agent", ) def setup_tools(self) -> list: ``` ::: :::WorkflowBlockItem Configure tools available to this agent. ```javascript return [search_database, get_metrics] def setup_prompt(self) -> str: ``` ::: :::WorkflowBlockItem Configure the system prompt for this agent. Your capabilities: - Search databases for relevant information - Retrieve and analyze metrics Guidelines: - Always search for data before making conclusions - Provide specific, actionable insights - Be concise but comprehensive ```javascript async def execute( self, input_data: Union[Dict[str, Any], AgentInput], context: Optional[ExecutionContext] = None, ) -> Dict[str, Any]: """Execute the agent logic. Args: input_data: AgentInput or dict with input data context: Optional ExecutionContext from the platform Returns: Dict with agent output """ if isinstance(input_data, dict): agent_input = AgentInput(**input_data) else: agent_input = input_data         logger.info(f"Executing MyAgent with content: {str(agent_input.content)[:50]}") try: # Create LLM using base class helper state = agent_input.context or {} llm = self._create_llm(state) messages = [ {"role": "system", "content": self.setup_prompt()}, {"role": "user", "content": str(agent_input.content)}, ] response = llm.invoke(messages) return { "content": response.content, "status": "success", } except Exception as e: logger.error(f"Agent execution failed: {{e}}") return { "content": "", "status": "error", "error": str(e), } ``` ::: :::: ## Step 3: Create the entrypoint Create main.py: ```javascript """Application entrypoint.""" import logging from dotenv import load_dotenv load_dotenv(override=False) from bridge_agent_sdk import run_agent from src.agents.my_agent import MyAgent logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(name)s - %(levelname)s - %(message)s" ) AGENTS = {"my_agent": MyAgent} AGENT_NAME_MAP = {"my_agent": "my_agent"} if __name__ == "__main__": run_agent( AGENTS, agent_name_map=AGENT_NAME_MAP, description="My Agent Runner", ) ``` # Adding MCP tools Your agent can use tools from MCP servers: ```javascript import os from bridge_agent_sdk import MCPClient class MyAgent(BridgeBaseAgent): CONFIG = AgentConfig( name="my-agent", version="1.0.0", description="MCP agent" ) def setup_tools(self): return [] def setup_prompt(self): return "You are a helpful assistant." async def execute(self, input_data, context=None): if isinstance(input_data, dict): agent_input = AgentInput(**input_data) else: agent_input = input_data platform_context = (agent_input.context or {}).get("platform_context", {}) mcp = MCPClient( dev_mode=(os.getenv("KAIF_MODE") != "production"), agent_payload=platform_context if os.getenv("KAIF_MODE") != "local_dev" else None, )    # Discover available tools tools = await mcp.discover_tools()    # Execute a query — use call_tool_parsed for bridge_execute_query success, parsed = await mcp.call_tool_parsed( "bridge_execute_query", {"query": 'SELECT * FROM "ITSM".incident LIMIT 10'}, )    rows = parsed.get("data", []) if success else [] return {"content": str(rows), "status": "success" if success else "error"} ``` # Testing your agent Create tests in tests/test\_my\_agent.py: ```javascript """Tests for MyAgent.""" import pytest from unittest.mock import patch, MagicMock from bridge_agent_sdk import AgentInput from bridge_agent_sdk.testing import create_test_execution_context from src.agents.my_agent import MyAgent @pytest.fixture def agent(): """Create agent instance for testing.""" return MyAgent() @pytest.fixture def agent_input(): """Create test AgentInput.""" return AgentInput( content="Show me recent incidents", metadata={"thread_id": "test-session-123"}, context={"agent_payload": {"account_id": "test-account"}}, ) @pytest.mark.asyncio async def test_agent_execution_success(agent, agent_input): """Test successful agent execution.""" mock_response = MagicMock() mock_response.content = "Here are the recent incidents..." with patch.object(agent, '_create_llm') as mock_create_llm: mock_llm = MagicMock() mock_llm.invoke.return_value = mock_response mock_create_llm.return_value = mock_llm  result = await agent.execute(agent_input) assert result["status"] == "success" assert result["content"] is not None @pytest.mark.asyncio async def test_agent_handles_error(agent, agent_input): """Test agent handles LLM errors gracefully.""" with patch.object(agent, '_create_llm') as mock_create_llm: mock_create_llm.side_effect = Exception("LLM unavailable") result = await agent.execute(agent_input) assert result["status"] == "error" assert result["error"] is not None Run tests: pytest tests/test_my_agent.py -v ``` [title] Troubleshooting [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ ## Troubleshooting | **Problem** | **Cause** | **Fix** | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Repository does not exist" | Repo name typo or teams not added | Verify repo name. Ensure bdg-sw-agents-admin team is added as Admin (Step 2). | | Onboarding issue closed immediately | Repo not found | Check the repo name — enter only the repo name, not the full org/repo path. | | Governance validation failed | Signoff files incomplete | Open the issue's failure comment — it lists exactly which fields are missing. Fix in governance/ and open a new issue. | | "Branch already exists" | Release branch already created | A release for this week was already cut. Wait for next week or contact the platform team. | | CI/CD pipeline not running | Secrets not provisioned | Complete the onboarding step first (Step 4). | | /approve not working | Not in required GitHub team | Only members of the required teams (TO, BO, RM) can approve. Contact the platform team to be added to the appropriate team. | | MCP Server Unreachable | ✗ Request failed: Connection refused
 Incorrect BRIDGE\_MCP\_SERVER\_URL or network issues | 1. Verify the MCP URL is correct for your account 2. Check VPN connection (for bridge\_dev mode) 3. URL format: https\://--.bridge.kyndryl.com/kaif/v2/mcp/tools | | Authentication Failures (401) | ✗ Authentication failed: 401. Invalid or expired SERVICE\_API\_KEY | 1) Verify SERVICE\_API\_KEY in your .env file 2) Regenerate the key from Bridge Platform Admin 3) Ensure the key has MCP access permissions | | 403 Forbidden - "Tool not allowed for profile" | \{"detail": "Tool not allowed for profile 'default'", "status\_code": 403}. The tool name you're calling **does not exist** on the MCP server, or it is not assigned to your deployment profile. | 1. Run python scripts/list\_mcp\_tools.py to see all available tools 2. Verify the exact tool name (e.g., servicenow\_search\_incidents, not servicenow\_get\_ticket) 3. Ensure the tool is listed in your deployment-registration.json under mcp\_tools | | 403 Forbidden - "Agent instance not found in default collection" | \{"detail": "Agent instance not found in default collection", "status\_code": 403}
 Missing X-Route-Version: v3 header. | Add the header to your request:
headers\["X-Route-Version"] = "v3" | | Missing x-instance-id Header | If x-instance-id is missing or wrong, the MCP call may succeed at the HTTP level but tools will not be routed to your deployment, resulting in 403 or empty results. |  Ensure x-instance-id matches your deployment name exactly:
headers\["x-instance-id"] = "inc-enrichment-deploy-v1"  # must match deployment-registration.json → name | | 422 Unprocessable Entity — Wrong Payload Format | Status: 422
Body: \{"detail": "Request body is not valid JSON-RPC 2.0"}
You sent a flat JSON payload instead of JSON-RPC 2.0 format. | Wrong (flat):
\{"tool\_name": "bridge\_execute\_query", "arguments": \{"query": "..."}}  | [title] SDK installation [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Developing agents/ This guide focuses only on installing the Bridge Agent SDK package on your local system. To understand how set up the local environment, see [Local set up](docId\:y94jE3XBnoz1pDTynhUOA). # Install Python 3.12 ### macOS 1. Use [Homebrew](https://brew.sh/): brew install python\@3.12 or download the installer from [python.org/downloads](https://www.python.org/downloads/). 2. Verify installation python3 --version ### Windows 1. Download the Python 3.12 installer from [python.org/downloads](https://www.python.org/downloads/) 2. Run the installer 3. Important: Check the box "Add Python to PATH" during installation 4. Click Install Now 5. Verify installation py --version # Generate a JFrog access token 1. Go to [https://kyndryl.jfrog.io](https://kyndryl.jfrog.io/) and log in with your enterprise credentials 2. Click your **profile icon** (top right) → **Edit Profile** 3. Navigate to **Access** **Tokens** → **Generate** **Token** 4. Copy the generated token and store it securely # Configure pip for the private repository ### macOS ```javascript mkdir -p ~/.config/pip cat < ~/.config/pip/pip.conf [global] extra-index-url = https://_:@kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple EOF ``` :::hint{type="info"} Replace \ with the token from Step 2. ::: ### Windows Open PowerShell and create the pip config directory: ```javascript mkdir -p ~/.config/pip cat < ~/.config/pip/pip.conf [global] extra-index-url = https://_:@kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple EOF Replace with the token from Step 2. mkdir "$env:APPDATA\pip" -Force Create the config file: @" [global] extra-index-url = https://_:@kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple "@ | Out-File -Encoding utf8 "$env:APPDATA\pip\pip.ini" ``` :::hint{type="info"} Replace \ with the token from Step 2. ::: # Create a virtual environment It is recommended to use a virtual environment to isolate project dependencies. ### macOS ```javascript python3 -m venv .venv source .venv/bin/activate ``` ### Windows ```javascript py -m venv .venv .venv\Scripts\Activate.ps1 ``` If you get an execution policy error on Windows, run: Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned Then retry the activate command. # Install the SDK ```javascript pip install bridge-agent-sdk ``` To install a specific version: ```javascript pip install bridge-agent-sdk==1.0.23 ``` ### Optional extras The SDK provides optional feature sets you can install: - **CLI tools: ** :::CodeblockTabs{indent="2"} ```javascript pip install "bridge-agent-sdk[cli]" ``` ::: - **Tenant database support (PostgreSQL):** :::CodeblockTabs{indent="2"} ```javascript pip install "bridge-agent-sdk[tenant-db]" ``` ::: - **Everything: ** :::CodeblockTabs{indent="2"} ```javascript pip install "bridge-agent-sdk[all]" ``` ::: # Verify installation ```javascript "import bridge_agent_sdk; print('Bridge Agent SDK installed successfully')" ``` # Upgrading To upgrade to the latest version: ```javascript pip install --upgrade bridge-agent-sdk ``` [title] Bridge Agentic AI Overview [path] Services/Platform Services/Knowledge & AI/Agentic AI/ The Knowledge & AI Foundation facilitates the creation, deployment, and management of AI agents on Kyndryl Bridge. It provides a standardized toolkit for development, integrates with MCP tools for data access and performance monitoring, ensures governance for security and compliance, and offers a scalable Kubernetes infrastructure for managing containers. The Agentic Designer serves as an intelligent co-designer, transforming a simple business idea into a comprehensive, ready-to-build Agentic AI design through guided discovery and structured reasoning. The Agent Registry manages the existing agents, determining who can use them and whether they should continue to exist. In contrast, AgentOps oversees how agents operate during runtime. Lastly, AgentOps acts as the control tower for an enterprise's agent ecosystem. It regulates what agents can do, monitors their activities, and ensures resilience, compliance, and cost control throughout their entire lifecycle. Bridge Agentic AI enables secure real-time searches on the Internet and Bing through its Bridge AI Assist, adhering to the Model Context Protocol (MCP). This MCP-compliant tool lets agents access up-to-date external information dynamically across workflows while maintaining control, audibility, and compliance with enterprise standards. As a result, the platform integrates external search capabilities, accessible to any authorized agent. # # [title] Agent execution [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Enabling agentic solutions/ Users can access the agent deployment page to initiate various deployments, ensuring that agents operate with a configured language model, such as a hosted LLM or OpenAI LLM. This page allows users to set up all necessary configurations, including knowledge bases, policies, and human-in-the-loop (HITL) settings. When a user clicks on **Execute Deployment**, the system displays a dynamic form based on the input schema. The **Execute Deployment Page **displayed the following 3 options**: ** - **Basic Input Mode: **The form-generated payload aligns with the backend JSON schema, allowing the system to run the agent seamlessly in the chosen mode. When an agent requires ten fields, the dynamic form automatically generates them—such as text boxes or dropdown menus. This process streamlines data submission for both developers and users, reducing the likelihood of execution failures that can occur with incorrect payloads, which were more common with the previous manual JSON format. - **Advanced Input Mode: **Add the raw JSON input manually. - **Upload Mode: **Users can upload a JSON file if they choose. Existing agents will continue to support JSON-based execution without changes. [title] Operational Data [path] Services/Platform Services/Knowledge & AI/Bridge AI Assist/Bridge AI Assist Overview/Interaction modes/ The Operational Data mode enables you to analyze operational data using conversational prompts. It’s designed for analytical use cases, allowing you to generate visual and tabular insights without complex setup. Queries are one-time questions; you cannot ask follow-up questions. The interface shows charts and tables directly. It also gives starter prompts to help users begin their analysis. ### Capabilities - Conversational analytics on operational data - Tabular and visual outputs (bar, pie, line charts) - Single-turn interactions ### Requirements - Must be part of the ACME account - Must belong to at least one of the KAIF access groups: KAIF Admin, KAIF Editor, KAIF Viewer. - The Bridge account must have access to . - Access permissions to relevant operational datasets are required. - Users without access must request authorization before using this capability. ### Limitations - No follow-up questions are supported (single-turn interaction only). - Only the English language is supported. - Chat history is not stored. [title] Onboarding AgentVisor [path] Services/Platform Services/Knowledge & AI/Agentic AI/Operate, Orchestrate and Optimize /Agent Visor/ 1. Account onboarded in Bridge with Knowledge and AI Foundation (KAIF) and policy service as per the Bridge onboarding process.  - KAIF service onboarding process: *https\://docs.kyndryl.com/onboarding-the-account*  - Policy service onboarding process: *https\://docs.kyndryl.com/enabling-bridge-policy*  7.2 Developing Agents with Policy Configuration  1. Agent developed as per the KAIF Agent development process -   - **Global policies to be developed and configured** as part of the agent development process. Refer https\://docs.kyndryl.com/developing-policies for defining tenant level policies.   - **Note: **Developing Global policies documentation to be added as part of global policy planned feature release.  - **Configuration \**  - **Account policies to be developed and configured**  # Activating and Customizing Global Policies by Accounts   The global policies defined at the Kyndryl level will be available for account team to activate and customize them as per their business needs. Account users will activate the global policies for account usage.  [title] FinOps [path] Services/Platform Services/Knowledge & AI/Agentic AI/Operate, Orchestrate and Optimize / Monitoring the usage and costs of Large Language Model (LLM) applications is crucial for maintaining financial transparency in Agent Operations (AgentOps). By tracking LLM usage metrics, organizations can identify trends, optimize resource allocation, and ensure alignment with budget and strategic goals. A robust monitoring system enhances reporting and oversight, leading to better management of AI resources and insights into their impact on expenses. Implementing a Financial Operations (FinOps) strategy for LLMs allows organizations to effectively use consumption data. This strategy helps track key performance indicators (KPIs) related to productivity, cost efficiency, and service quality, leading to better-informed decisions. The insights gained enable businesses to refine strategies, ensuring efficient resource allocation and maximizing the benefits of agent technologies. Overall, integrating FinOps into LLM management enhances financial oversight and improves operational performance and value generation. [title] Global Knowledge Base [path] Services/Platform Services/Knowledge & AI/Knowledge Foundation /Untitled/ # Knowledge bases available ### SAP The TMS SAP Knowledge Base is a comprehensive, centralized repository of validated SAP information designed to speed up issue resolution for users and technical teams. By consolidating critical knowledge in one accessible location, it enables faster identification and troubleshooting of challenges that may arise within the SAP environment. This knowledge base significantly improves operational efficiency by providing use-case-driven insights that help teams understand the specific contexts in which particular solutions or approaches apply. It also streamlines access to a wide array of SAP knowledge artifacts, including best practices, reference guides, and troubleshooting procedures, empowering users to leverage existing knowledge effectively. ### UAT UAT Knowledge Base is a comprehensive, centralized repository for the user ID management solution serving customers across multiple regions. This knowledge base covers Discretionary Access Control (DAC) and Role-Based Access Control (RBAC) for efficient access management and provides endpoint automation for major platforms. With instances worldwide, UAT complies with regulations like GDPR, ITAR, HIPAA, and FFIEC. It also supports flexible deployment options, including Kubernetes, on-premises, or hybrid environments, ensuring high availability and scalability. Links used for the UAT knowledge base - [UAT](https://kyndryl.sharepoint.com/sites/UAT) - [Secret server solution](https://kyndryl.sharepoint.com/sites/SecretServerSolution) - [Global IAM](https://kyndrylde.sharepoint.com/sites/globaliam) - [Corporate instructions](https://kyndryl.sharepoint.com/sites/CorporateDocuments/SitePages/Corporate-Instructions.aspx) - [Customer policy](https://kyndryl.sharepoint.com/sites/CustomerPolicyCSD) - [GDPR](https://kyndryl.sharepoint.com/sites/DataGovernanceAssessments/SitePages/GDPR.aspx) - [Data Governance Office](https://kyndryl.sharepoint.com/sites/DataGovernanceOffice) - [DORA guidance](https://kyndryl.sharepoint.com/sites/ebcm/SitePages/DORA-Guidance.aspx) - [HIPAA](https://kyndryl.sharepoint.com/sites/KyndrylHPO/SitePages/Health-Insurance-Portability-and-Accountability-Act.aspx) - [ITAR](https://kyndryl.sharepoint.com/sites/KyndrylTradeComplianceOfficeProgram/SitePages/International-Traffic-in-Arms-Regulations.aspx) - [Kyndryl CTO UAT ](https://kyndryl.gitbook.io/kyndryl-cto/uat) # Adding a global knowledge base To create a global Knowledge Base (KB) in the Kyndryl CTO account on the Kyndryl POC platform, ingest the data from the development environment. For additional details, see [Adding a knowledge base](docId\:J-e10NNUQ9S7Eto-nk-nW). ## Activate a global knowledge base The Global KB is automatically duplicated across all Dev regions/accounts but is **inactive** by default.   1. Look for the recently created knowledge base and select the **Activate** option from the overflow menu.   2. A window message appears. Confirm your action by clicking the **Activate **button. Otherwise, click **Cancel**.   3. A message will indicate whether the action succeeded.  ## Controlled promotion of Global KB to accounts Promoting Global Knowledge Bases (KBs) to target tenant accounts like ACME involves key steps for effective governance and access control: 1. KB Creation: Developed under the Global (CTO) account. 2. Promotion Steps: The promotion process is structured in three stages: Authoring, Validation, and Enablement, which requires formal approval. This ensures a standardized process for promoting content. 3. Account Enablement: You can grant access to Global Knowledge Bases (KBs) for specific accounts, such as ACME. This facilitates a controlled rollout for testing purposes. Once the KB is created, it will appear in active status but partially succeded. 1. Write down the index name for the newly kb to promote it. 2. Go to GitHub> kyndryl-cto>bdg-sw-aifn-bootstrap>config>data\_promoter>config.json 3. Add the information in the target index name variable. Make sure the correct version is included as well. 4. User Access: Role-based access will be provided to selected individuals specifically for testing scenarios. This ensures accurate validation of use cases. 5. Traceability: Details such as KB Name, Source URL, and statuses will be tracked to support audits. This promotes transparency and ensures compliance with SOX regulations. This process supports knowledge sharing while maintaining control. ## [title] Development environment [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Developing agents/ To set up your development environment, configure your IDE, editor settings, and the environment variables required for different runtime modes and LLM providers. - **Recommended IDE Setup: **VS Code with the following extensions: - Python (Microsoft) - Pylance - Python Debugger - Docker - GitLens - GitHub Copilot (optional) - **VS Code Settings:** ```javascript { "python.defaultInterpreterPath": "${{workspacefolder}}/venv/bin/python", "python.analysis.typeCheckingMode": "basic", "editor.formatOnSave": true, "python.formatting.provider": "black" } ``` You will need different environment variables depending on your runtime mode and LLM provider. No OPENAI\_API\_KEY needed in bridge\_dev, the LLM Gateway handles authentication. **Core Variables (all modes)** | **Variable** | **Description** | **Example** | | ----------------------------------------- | -------------------------------------------- | ---------------------------------------- | | KAIF\_MODE | Runtime mode | local\_dev / bridge\_dev / production | | LLM\_MODEL | Model to use | gpt-4.1-mini | **Local\_dev: Choose ONE provider** | **Provider** | **Required variables** | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | OpenAI (default) | LLM\_PROVIDER=openai, OPENAI\_API\_KEY=sk-..., OPENAI\_API\_BASE=https\://api.openai.com/v1 | | Azure OpenAI | LLM\_PROVIDER=azure\_openai, AZURE\_OPENAI\_ENDPOINT, AZURE\_OPENAI\_API\_KEY, AZURE\_OPENAI\_API\_VERSION, AZURE\_OPENAI\_DEPLOYMENT | | Hosted LLM | LLM\_PROVIDER=hosted\_llm, HOSTED\_LLM\_BASE\_URL, HOSTED\_LLM\_AUTH\_HEADER, HOSTED\_LLM\_MODEL | **Bridge\_dev** | **Variable** | **Description** | **Example** | | ----------------------------------------- | -------------------------------------------- | ------------------------------------------------ | | KAIF\_HOST | Bridge Platform URL (required) | https\://dev1-aws-oregon-base.bridge.kyndryl.com | | SERVICE\_API\_KEY | Service ID API key (required) | (from Bridge Admin Console) | | BRIDGE\_ACCOUNT\_ID | Your Bridge account ID (required) | abc123... | # Access and repositories This content covers the GitHub organization, key repositories, and SDK access for Bridge agent development. As an agent developer, you must have access to the **kyndryl-agentic-ai** GitHub organization. :::hint{type="info"} You do NOT need access to kyndryl-cto. All resources required for agent development are available in kyndryl-agentic-ai ::: ## Request access If you do not have access to kyndryl-agentic-ai: 1. Submit a ServiceNow request for GitHub org access. 2. Or contact your team lead to add you to the organization. ### Key repositories **In kyndryl-agentic-ai organization** | **Repository** | **Purpose** | | ------------------------------------------- | --------------------------------------------------------------------------------- | | bdg-sw-agents-bridge-agent-template | Template repo: Start here for new agents (actively evolving - always pull latest) | | bridge-kaif-reusable-workflows | CI/CD GitHub Actions workflows | | Debugging-remediation-help-Agent | Reference agent: debugging and remediation workflow | | bdg-sw-agents-autonomous-doc-creation | Reference agent: autonomous document generation | | bdg-sw-agents-incident-enrichment | Reference agent: multi-step workflow with MCP tools, ChatOps, and audit | **Repository access matrix** | **Repository** | **You need** | | ------------------------------------------- | ----------------------------------------- | | Template repo | Read + Use as template | | Your agent repo | Admin (you create it) | | Reusable workflows | Read (referenced in CI/CD) | The Bridge Agent SDK is distributed through Kyndryl’s JFrog Artifactory PyPI repository. Developers can access the [repository](https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple) and browse the available SDK packages through JFrog Artifactory under **Bridge Agent SDK**. The current SDK version is **bridge-agent-sdk==1.0.23**. :::hint{type="info"} Always check [JFrog Artifactory](https://kyndryl.jfrog.io/ui/repos/tree/General/kyn-cto-kaif-pypi-local/bridge-agent-sdk) for the latest published version and update your requirements.txt accordingly. ::: # Configure pip for Artifactory - **Option 1: In requirements.txt (Recommended)** ```javascript --extra-index-url: https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple bridge-agent-sdk==1.0.23 langchain>=0.3.0 langgraph>=0.2.0 # ... other dependencies ``` - **Option 2: Global pip Configuration** Create or edit your pip configuration file: **Linux/macOS: ** ```javascript ~/.config/pip/pip.conf [global] extra-index-url = https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple trusted-host = kyndryl.jfrog.io ``` **Windows: ** ```javascript %APPDATA%\pip\pip.ini [global] extra-index-url = https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple trusted-host = kyndryl.jfrog.io ``` :::hint{type="info"} **Authentication: **If prompted for authentication, use your Kyndryl SSO credentials or generate an API key from JFrog. ::: # Verify access - Test GitHub access: Clone the template repo (should work if you have access). - Test Artifactory Access: Create a test virtual environment :::CodeblockTabs{indent="2"} ```javascript python -m venv test-env source test-env/bin/activate  # Linux/macOS # .\test-env\Scripts\Activate.ps1  # Windows ``` ::: - Install SDK :::CodeblockTabs{indent="2"} ```javascript pip install bridge-agent-sdk==1.0.23 \ --extra-index-url https://kyndryl.jfrog.io/artifactory/api/pypi/kyn-cto-kaif-pypi-local/simple ``` ::: - Verify installation :::CodeblockTabs{indent="2"} ```javascript python -c "from bridge_agent_sdk import BridgeBaseAgent; print('SDK installed successfully!')" ``` ::: - Clean up :::CodeblockTabs{indent="2"} ```javascript deactivate rm -rf test-env ``` ::: # [title] Registering an agent [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/Enabling agentic solutions/Agent Library/ Agent registration captures the agent’s metadata and intent. This step does not include credentials or runtime configuration. :::hint{type="info"} Registration captures metadata only. Runtime configuration (LLM, connections, and credentials) is defined later during deployment. ::: # Interaction modes You can choose to integrate agents that are native to the platform or use external ones. It also helps you manage, govern, and clearly find and execute your agents. - Define the interaction model of the agent: - Conversational Agents: Designed for user interaction via prompts/questions - Non‑Conversational Agents: Created for background workflows, automation, or API-triggered execution; this is not directly accessible to end users in conversational interfaces. - Define where the agent executes: - Bridge-hosted agents - External-hosted agents (executed via external APIs like WatsonX or others) # Registering and agent from an existing repository  Upload a file for bulk agent registration. Use file upload for registering multiple agents at once. 1. Locate the *manifest.json* file within your repository. This file typically contains essential metadata and configuration details for the agent you wish to import.   :::Paragraph{indent="1"} Source: GitHub kyndryl-agentic-ai org → bdg-sw-agents--base repo → config/ directory  ::: 2. Review the file and update account-specific fields: - tenant\_id — the account's Bridge tenant ID - connection\_ids — map to the connections created - access\_group\_id — map to the access group - service\_id — map to the Service ID - knowledge\_base\_id — map to the knowledge base (if applicable) - llm\_api\_key\_id — map to the API key 3. Once the information is correct, go to the **Agent Library** page, and select **Register** 4. Select the **File Upload **option 5. Select the *manifest.json* file from your local system 6. Click **Upload**  After uploading, the system will process the file, extracting the necessary information to integrate the agent into the library seamlessly.  # Manual registration Single registration is the manual process to register an agent. 1. From the **Agent Library** page, select **Register** 2. Select **Single Registration**  ::::WorkflowBlock :::WorkflowBlockItem ### Basic information - **Type**: Select **Agent** or **Agentic Solution** - **Name**: Enter a unique name for the agent - **Version**: Enter the version number - **Description**: Add a short description  - **Owner**: Enter the agent owner - **Maintaining Team**: Enter the team responsible for updates - **Tags**: Add tags separated by a comma. - **Technology Framework**: Select the framework used - **Summary**: Enter a summary of the agent’s purpose. Select **Next** to continue. ::: :::WorkflowBlockItem ### Skills - **Skill Name**: Enter a unique skill name. - **Skill Description**: Add a short description. Select **Add Skill** to add more or **Next** to continue. ::: :::WorkflowBlockItem ### Configurations - **LLM** - Configuration: Select LLM configuration - LLM Model: Select model - **Knowledge Base** - Configuration: Select Global or Private - Knowledge Base: Select a knowledge base - **MCP** - MCP Server: Select MCP server - MCP Tool: Select MCP tool - **Connector** - Type: Select connector type Select **Next** to continue. ::: :::WorkflowBlockItem ### Schema - Enter input and output schema - Or select **Default** Select **Next** to continue ::: :::WorkflowBlockItem ### Source of agent - **GitHub Repository URL**: Enter GitHub repository URL - **Branch**: Enter repository branch - **Manifest Path**: Enter manifest path. Select **Next** to continue. ::: :::WorkflowBlockItem ### Flow configuration Agentic Solution only - Enter JSON or YAML flow. Select **Next** to continue. ::: :::WorkflowBlockItem ### Review and submit Review all information and select **Submit**.** ** ::: :::: # [title] Scenarios [path] Services/Platform Services/Knowledge & AI/Agentic AI/Operate, Orchestrate and Optimize /Agent Visor/ # A business example of PORC  Consider a case where an operations-focused agent wants to restart a production service.  - **Principal:** an operations engineer, through an approved agent  - **Operation:** restore service availability  - **Resource:** a production service or server  - **Context:** change window, ticket status, business criticality, backup state, and approval state  The result might be to allow the action, require approval, or deny it altogether, depending on policy.  # Scenarios ## Building a Secure AI Agent A developer creates an AI agent for incident diagnosis and checks the code into the approved repository, triggering the standard build pipeline. During this process, Agent Visor validates compliance with security and governance requirements, checking for approved base images and scanning for vulnerabilities. If critical issues or policy violations are found, the build is halted and the developer is notified. If all checks pass, a secure container image is generated and published to the organization's approved image repository. Business Value - Security is embedded into the development lifecycle. - Developers do not need to perform additional governance steps. - Only compliant agents are allowed into production environments. ### Upgrading an Existing Agent with Agent Visor An organization with existing agents wants to implement governance and security controls without starting from scratch. The agent owner rebuilds the agent using the Agent Visor-enabled process, updates the Agent Catalog with the new image version, and the deployment begins automatically, retaining existing configurations and schedules. This allows the agent to benefit from Agent Visor's governance, policy enforcement, audit logging, and observability features. Business Value - Existing agents can be secured quickly. - No need for re-registration or redeployment. - Governance is applied consistently across all agents. ## Deploying the Agent A Patch Compliance Agent is registered once in the Agent Catalog and used by multiple customers with varying operational needs. Operations teams create separate deployments of the same agent—Customer A deploys it weekly with one LLM model, while Customer B uses a different LLM for daily deployments. Each deployment can have distinct schedules, permissions, policy sets, and configurations, ensuring that each customer receives a tailored solution. Business Value - Reuse agents across multiple customers. - Reduce development and maintenance effort. - Support customer-specific governance requirements. ## Enforcing Policies During Agent Execution An agent requests access to an external service while performing a task. Agent Visor evaluates the request against policy rules. If compliant, the request is approved; if not, it's blocked and the reason is logged. This decision is part of the execution audit trail for future review by administrators or compliance teams. Business Value - Provides real-time governance. - Prevents unsafe agent behaviour. - Ensures adherence to corporate policies. ## Visualizing Agent Decisions and Policy Outcomes An account team seeks to understand how governance influenced an agent's actions through a policy evaluation view, which visually outlines the agent's activities. Users can track the request's journey through policy evaluations, decisions made, and their impact on the final outcome, all in a business-oriented workflow that links agent actions, policy decisions, and recommendations, instead of sifting through complex logs. Business Value - Makes governance understandable to non-technical users. - Improves user confidence in agent decisions. - Facilitates operational reviews and compliance discussions. [title] Configuring Tools for Catalog Registration [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/MCP tools discovery/ # Add tool to catalog registration After discovering available tools, add them to your agent-catalog-registration.json: ::::WorkflowBlock :::WorkflowBlockItem **Run Discovery** ```javascript python scripts/list_mcp_tools.py --format catalog ``` ::: :::WorkflowBlockItem **Select required tools** Choose only the tools your agent needs: ```javascript { "tools": [ { "name": "servicenow_mcp", "operations": [ "servicenow_get_all_incidents", "servicenow_search_incidents" ] }, { "name": "bridge_mcp", "operations": [ "bridge_execute_query", "bridge_list_domains", "bridge_list_tables", "bridge_get_table_details" ] } ] } ``` ::: :::WorkflowBlockItem **Update Registration JSON** Copy the tools configuration to your agent-catalog-registration.json file. ::: :::: # Using MCP tools in your agent ## Calling tools with MCPClient ```javascript import os from bridge_agent_sdk import MCPClient # Initialize client — base_url is optional (SDK resolves from KAIF_HOST) mcp = MCPClient( agent_payload=state.get("platform_context", {}), ) # Call a tool result = await mcp.call_tool( tool_name="servicenow_get_all_incidents", arguments={"limit": 10} ) # Process result incidents = result.get("data", []) ``` ## Tool naming convention MCP tool names follow the pattern: \_ | **Pattern** | **Example** | | ---------------------------------------- | ---------------------------------------- | | servicenow\_\* | servicenow\_get\_all\_incidents | | bridge\_\* | bridge\_execute\_query | | azure\_\* | azure\_keyvault | | aiops\_\* | aiops\_ask\_me\_anything | ## Error handling Try the following: ```javascript result = await mcp.call_tool(tool_name="servicenow_search_incidents", arguments={"limit": 10}) if "error" in result: logger.error(f"MCP tool error: {result['error']}") return {"error": result["error"]} return result.get("data", []) except Exception as e: logger.exception(f"MCP call failed: {{e}}") raise ``` ## MCP Wire Protocol (JSON-RPC 2.0) The Bridge MCP server uses the **JSON-RPC 2.0** protocol. While the SDK's MCPClient handles this for you, understanding the wire format is essential for debugging and writing test scripts. ::::WorkflowBlock :::WorkflowBlockItem **Listing Tools - tools/list** ```javascript curl -s -X POST "$BRIDGE_MCP_SERVER_URL" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {} }' | jq '.result.tools | length' ``` **** ::: :::WorkflowBlockItem **Response structure:** ```javascript { "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "servicenow_search_incidents", "description": "Search for incidents...", "inputSchema": { "type": "object", "properties": {{...}}, "required": [...] } } ] } } ``` **** ::: :::WorkflowBlockItem **Calling a Tool - tools/call** ```javascript curl -s -X POST "${{BRIDGE_MCP_SERVER_URL}}?tenant_id=${{ACCOUNT_ID}}&account_id=${{ACCOUNT_ID}}" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "accept: application/json" \ -H "x-instance-id: $DEPLOYMENT_NAME" \ -H "X-Route-Version: v3" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "servicenow_search_incidents", "arguments": { "search_term": "INC0010001", "search_fields": ["number"] } } }' ``` ::: :::: :::hint{type="info"} **Common mistake:** Sending a flat payload like \{"tool\_name": "...", "arguments": } will return 422 Unprocessable Entity. You **must** use the JSON-RPC envelope with jsonrpc, method, and params fields. ::: ## Required headers for MCP calls When calling MCP tools (either directly or via the SDK), the following HTTP headers are required: | **Header** | **Required** | **Value** | **Purpose** | | --------------------------------------- | ----------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Authorization | Yes | Bearer \ | Authentication — obtained from /api/iam/v4/identity/token | | Content-Type | Yes | application/json | Request body format | | x-instance-id | Yes | Your deployment name (e.g., inc-enrichment-deploy-v1) | Routes the call to the correct agent deployment | | X-Route-Version | Yes | v3 | Critical — Tells the MCP gateway to use v3 routing. Without this header you will get 403 — Agent instance not found in default collection | | accept | Recommended | application/json | Response format | ### The X-Route-Version: v3 Header This is the most commonly missed header. The SDK sets it automatically, but when writing test scripts or curl commands you must include it: ```javascript headers = { "Authorization": f"Bearer {{token}}", "Content-Type": "application/json", "accept": "application/json", "x-instance-id": deployment_name,       # your deployment name "X-Route-Version": "v3",                # ← CRITICAL — do not omit } ``` **Without this header**, the MCP gateway falls back to the default routing collection and returns: ```javascript { "detail": "Agent instance not found in default collection", "status_code": 403 } ``` ## Query parameters When making direct HTTP calls, append tenant and account IDs as query parameters: POST ?tenant\_id=\&account\_id= The SDK's MCPClient appends these automatically (you can see it in the logs: Internal route - adding query params: \['tenant\_id', 'account\_id']). # Testing MCP tools ### Method 1: Discovery script Always start by discovering what tools are actually available: ```javascript # List all tools grouped by MCP server python scripts/list_mcp_tools.py # Filter to a specific server python scripts/list_mcp_tools.py --filter servicenow # Export full schemas to JSON python scripts/list_mcp_tools.py --output available-tools.json --format raw ``` ### Method 2: Get full tool schemas ::::WorkflowBlock :::WorkflowBlockItem **Create scripts/get\_tool\_schema.py to inspect exact inputSchema of tools:** ```javascript #!/usr/bin/env python3 """Get the full input schema for specific MCP tools.""" import os, json, requests from dotenv import load_dotenv load_dotenv() kaif_host = os.getenv("KAIF_HOST") service_api_key = os.getenv("SERVICE_API_KEY") mcp_url = os.getenv("BRIDGE_MCP_SERVER_URL") ``` ::: :::WorkflowBlockItem **Get token** ```javascript token = requests.post( f"{{kaif_host}}/api/iam/v4/identity/token", json={"apikey": service_api_key}, headers={"Content-Type": "application/json"}, timeout=30, ).json().get("token") ``` ::: :::WorkflowBlockItem **List tools (JSON-RPC 2.0)** ```javascript resp = requests.post( mcp_url, headers={ "Content-Type": "application/json", "Authorization": f"Bearer {{token}}", }, json={"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}, timeout=60, ) tools = resp.json().get("result", {}).get("tools", []) ``` ::: :::WorkflowBlockItem **Filter and print (change the prefix to inspect other servers)** ```javascript for t in tools: if "servicenow" in t.get("name", ""): print(json.dumps(t, indent=2)) print("---") ``` ::: :::: ### Method 3: Direct tool call (test script) ::::WorkflowBlock :::WorkflowBlockItem **Test a specific tool call with all required headers** ```javascript #!/usr/bin/env python3 """Test a single MCP tool call with full headers.""" import os, json, requests from dotenv import load_dotenv load_dotenv() kaif_host       = os.getenv("KAIF_HOST") service_api_key = os.getenv("SERVICE_API_KEY") account_id      = os.getenv("BRIDGE_ACCOUNT_ID") mcp_url         = os.getenv("BRIDGE_MCP_SERVER_URL") deployment_name = "inc-enrichment-deploy-v1"   # ← your deployment name ``` ::: :::WorkflowBlockItem **Authenticate** ```javascript token = requests.post( f"{{kaif_host}}/api/iam/v4/identity/token", json={"apikey": service_api_key}, headers={"Content-Type": "application/json"}, timeout=30, ).json()["token"] ``` ::: :::WorkflowBlockItem **Build request ** ```javascript headers = { "Authorization": f"Bearer {{token}}", "Content-Type": "application/json", "accept": "application/json", "x-instance-id": deployment_name,    # routes to your deployment "X-Route-Version": "v3",             # ← CRITICAL } payload = { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "servicenow_search_incidents", "arguments": { "search_term": "INC0010001", "search_fields": ["number"], }, }, } full_url = f"{{mcp_url}}?tenant_id={{account_id}}&account_id={{account_id}}" ``` ::: :::WorkflowBlockItem **Call** ```javascript resp = requests.post(full_url, headers=headers, json=payload, timeout=30) print(f"Status : {{resp.status_code}}") print(f"Body   : {json.dumps(resp.json(), indent=2)}") ``` ::: :::: ### Method 4: Curl one-liner ::::WorkflowBlock :::WorkflowBlockItem **Get token** ```javascript TOKEN=$(curl -s -X POST "$KAIF_HOST/api/iam/v4/identity/token" \ -H "Content-Type: application/json" \ -d "{\"apikey\": \"$SERVICE_API_KEY\"}" | jq -r '.token') ``` ::: :::WorkflowBlockItem **Call tool ** ```javascript curl -s -X POST "${{BRIDGE_MCP_SERVER_URL}}?tenant_id=${{BRIDGE_ACCOUNT_ID}}&account_id=${{BRIDGE_ACCOUNT_ID}}" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "accept: application/json" \ -H "x-instance-id: inc-enrichment-deploy-v1" \ -H "X-Route-Version: v3" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "bridge_execute_query", "arguments": { "query": "SELECT number, short_description FROM \"ITSM\".incident LIMIT 5" } } }' | jq . ``` ::: :::: [title] [path] Services/Platform Services/Inventory/Infrastructure & Cloud Inventory 3.0/ [title] Agent onboarding [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ Once your agent runs successfully in bridge\_dev mode - with all MCP tool calls returning 200 OK, LLM working, and audit logging active - you are ready to **onboard the agent image** to the Bridge Platform. :::hint{type="info"} **Important - Canonical Reference:** The complete, authoritative guide with every detail, YAML snippet, and parameter table is here. This page is a summary. If anything below seems incomplete, refer to the full guide above — it is the source of truth. ::: # Prerequisites Before starting onboarding, confirm: | **Checkpoint** | **How to verify** | | ------------------------------------------- | --------------------------------------------------------------------------- | | Agent runs end-to-end in bridge\_dev | python main.py completes with "status": "success" | | MCP tool calls return 200 OK | Logs show HTTP/1.1 200 OK for every MCP call | | LLM calls succeed | Logs show 200 OK on /chat/completions | | Audit records created | Logs show 201 Created on /api/audit/v4/records | | Agent registered in catalog | agent-catalog-registration.json submitted via /kaif/v3/agent-catalog/agents | | Deployment created | deployment-registration.json submitted via /kaif/v3/deployment/agentic | | Governance signoffs complete | All 4 files in governance/ set to approved: true | **** # Quick summary of each step ## Step 1: Create repo from template Browse templates in [kyndryl-agentic-ai](https://github.com/kyndryl-agentic-ai) org → click **"Use this template"** → name it bdg-sw-agents-your-agent → keep **Private**. ## Step 2: Add required teams | **Team** | **Role** | | ------------------------------------- | ---------------------------------------------------- | | bdg-sw-agents-admin | Admin — provisions secrets, creates release branches | | bdg-sw-agents-read-write | Write — developers who push code | | bdg-sw-agents-read-only | Read — stakeholders and reviewers | Without these teams, onboarding and release cut **will fail**. ## Step 3: CI/CD — Build & Security Orchestrator Create .github/workflows/build-and-security.yml using the reusable orchestrator: **Input parameters:** | **Parameter** | **Required** | **Default** | **Description** | | ------------------------------------------ | ----------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | python-version | No | "3.12" | Python version for unit tests and quality checks | | test-framework | No | "pytest" | "pytest" or "unittest" | | test-directory | No | "tests" | Directory where test files are located | | use-private-registry | No | false | Set true if requirements.txt has private packages from JFrog. Requires pyinstall.sh in repo root. | | docker-build-args | No | "" | Docker build arguments (--build-arg KEY format). When using pyinstall.sh, pass "--build-arg DEVOPS\_ARTIFACTORY\_USER --build-arg DEVOPS\_ARTIFACTORY\_APIKEY". | | codeql-language | No | "python" | Language for CodeQL static analysis | ** ** **Secrets (required):** | **Secret** | **Purpose** | | --------------------------------------- | ---------------------------------------- | | SECURITY\_TOKEN | GitHub PAT for security scanning | | AFAAS\_USER | JFrog Artifactory username | | AFAAS\_TOKEN | JFrog Artifactory access token |   These secrets are **provisioned automatically** during onboarding (Step 4). You do not need to create them manually. **Four gates enforced in sequence:** | **Gate** | **What** | | ------------------------------------- | ------------------------------------------------- | | 🧪 Quality | Unit tests with ≥85% code coverage enforced | | 🔍 CodeQL | Static security analysis | | 🔒 Security | Dependency + code + secret scanning | | 🐳 Docker | Build → JFrog Xray CVE scan → push to Artifactory |   **Note:** Do **not** call individual workflows (e.g. docker-build.yml) directly — the orchestrator is the only supported entry point. Direct calls will be blocked. ## Step 4: Request onboarding 1. Open issue at [bdg-sw-agents-images-onboarding → New Issue](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-images-onboarding/issues/new/choose) 2. Select **"Repo onboarding: configure Docker Credentials"** 3. Enter **repo name only** (e.g. bdg-sw-agents-my-agent, not kyndryl-agentic-ai/bdg-sw-agents-my-agent) 4. A **Technical Owner** and **Business Owner** comment /approve 5. Bot provisions secrets (SECURITY\_TOKEN, AFAAS\_USER, AFAAS\_TOKEN) automatically ## Step 5: Develop & push Your repo comes pre-configured with: | **What** | **Where** | | ------------------------------------- | ----------------------------------------------------------- | | Agent logic | src/agents/ | | Tools | tools.py | | Configuration | settings.py, config.py | | Docker build | Dockerfile | | CI/CD pipeline | .github/workflows/build-and-security.yml (set up in Step 3) | | Unit tests | tests/ | Push code → CI/CD triggers automatically on pushes and pull requests to main, master, and release-\* branches. All security and quality gates are **enforced centrally** — individual repos cannot skip any gate. :::hint{type="info"} **Unit tests are mandatory: ** The CI/CD pipeline enforces **≥85% code coverage**. Your tests/ directory must contain meaningful test cases for the build to pass. Teams can use **GitHub Copilot** to help write test cases for their agent workflows, tools, and nodes. ::: ## Step 6: Governance signoffs Complete all 4 files in governance/: | **File** | **What to review** | | ------------------------------------- | ---------------------------------------------------------------- | | SECURITY\_SIGNOFF.yaml | Secrets management, authentication, data protection, AI security | | OSSC\_LEGAL\_SIGNOFF.yaml | Open-source compliance, license review | | BUSINESS\_FUNCTIONAL\_SIGNOFF.yaml | Business requirements, functional validation | | TECHNICAL\_SIGNOFF.yaml | Architecture review, technical approval | **For each file:** 1. Set approved: true 2. Fill in the approver block: yaml approver: name: Your Name email: your.email\@kyndryl.com date: "2026-03-06" 3. Set **all** checklist items to true 4. Fill in agent\_name and version 5. Commit and push to main :::hint{type="info"} **Note:** If any signoff is incomplete, the release cut request will be **automatically rejected** with a detailed report of what's missing. ::: ## Step 7: Request release cut 1. Go to [bdg-sw-agents-images-onboarding → New Issue](https://github.com/kyndryl-agentic-ai/bdg-sw-agents-images-onboarding/issues/new/choose) 2. Select **"Release cut: create release branch"** 3. Enter your **repo name only** 4. Submit the issue **What happens next:** | **Step** | **Automated Action** | | ------------------------------------- | ---------------------------------------------------------------------------- | | 1 | Bot validates your repo exists | | 2 | Bot checks if a release branch already exists (duplicate guard) | | 3 | Bot clones your repo and validates all 4 governance signoff files | | 4 | If governance passes → 🤖 Copilot reviews your repo's structure and security | | 5 | Bot posts the Copilot review findings and RM approval instructions | | 6 | A Release Manager (RM) reviews the Copilot analysis and comments /approve | | 7 | Bot creates a release-YYYY.MM.DD branch (targeting next Wednesday) | | 8 | Issue is closed with the branch details and deployment payload | **Copilot Review** - After governance passes, the platform runs an AI-powered review: | **Review** | **What it checks** | | --------------------------------------- | ------------------------------------------------------------------------- | | Structure Review | Project layout, Dockerfile, dependencies, CI/CD readiness | | Security Review | Hardcoded secrets, dependency security, Docker security, input validation | The review is **informational only** — it does not block approval, but gives the RM context. It runs within your Copilot Business licence boundary — code is not retained. :::hint{type="info"} **After release cut:** - A release-YYYY.MM.DD branch is created on your repo - The CI/CD pipeline auto-triggers for the release branch - Docker image is built, scanned, and pushed to JFrog Artifactory ::: ## Step 8: Get the image tag and complete registration After the CI/CD pipeline finishes on the release branch: 1. Go to your repo → **Actions** → click the latest build run 2. Open the **docker-build-and-push** job logs 3. Find the success line: Notice: ✅ Pushed kyndryl.jfrog.io/kyn-cto-kaif-docker-local/bdg-sw-agents-your-agent\:release-YYYY.MM.DD--\-\ 4. **Copy the full image tag** (e.g. kyndryl.jfrog.io/kyn-cto-kaif-docker-local/bdg-sw-agents-your-agent\:release-2026.03.27--5d45dd2-1774525017) 5. **Update your catalog registration** — set the image field in your agent-catalog-registration.json to the new image tag, then call the **PUT** or **PATCH** API 6. **Create a fresh deployment registration** — submit a new deployment via /kaif/v3/deployment/agentic with the updated agent\_catalog\_id. The platform will now run your agent from this Docker image. :::hint{type="info"} **Updates: **Every time you cut a new release, grab the new image tag from the build logs, update the catalog registration, and create a fresh deployment. ::: **Complete checklist:** 1. Created repo from a template (Step 1) 2. Added **bdg-sw-agents-admin** (Admin), **bdg-sw-agents-read-write** (Write), and **bdg-sw-agents-read-only** (Read) teams (Step 2) 3. Created .github/workflows/build-and-security.yml using the orchestrator (Step 3) 4. Submitted **\[Onboard]** issue and got secrets provisioned (Step 4) 5. Pushed code and CI/CD pipeline is passing (Step 5) 6. Completed all 4 governance signoff files with approved: true (Step 6) 7. Submitted **\[Release Cut]** issue and got release branch created (Step 7) **Issue Labels Reference** | **Label** | **Meaning** | | -------------------------------------- | ---------------------------------------- | | onboarded 🔵 | Secrets provisioned | | release-cut-done 🟢 | Release branch created | | invalid-request 🔴 | Repo doesn't exist | | governance-failed 🔴 | Signoffs incomplete | | duplicate-release 🟠 | Release branch already exists |   ## [title] Workflow agent [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ This guide covers building multi-agent workflows using BridgeBaseWorkflowAgent and LangGraph. # When to use BridgeBaseWorkflowAgent Use BridgeBaseWorkflowAgent when your agent: - Has multiple processing steps with conditional routing - Needs multiple specialized sub-agents - Has complex state management requirements - Needs retry loops or fan-out patterns # Base Class Overview ```javascript from bridge_agent_sdk import BridgeBaseWorkflowAgent, WorkflowConfig from langgraph.graph import StateGraph, END class MyWorkflow(BridgeBaseWorkflowAgent): """Your custom workflow agent.""" CONFIG = WorkflowConfig( name="my-workflow", version="1.0.0", description="My workflow agent", ) def define_state(self) -> type: """Return the TypedDict class defining workflow state.""" return MyState def setup_nodes(self, graph: StateGraph): """Add nodes to the workflow graph.""" pass def setup_edges(self, graph: StateGraph): """Define edges and routing between nodes.""" pass ``` # Lifecycle Methods | **Method** | **Purpose** | **When Called** | | --------------------------------------- | ---------------------------------------- | -------------------------------------------- | | define\_state() | Define state schema (TypedDict) | On graph construction | | setup\_nodes() | Add processing nodes | On graph construction | | setup\_edges() | Define flow routing | On graph construction | | prepare\_initial\_state() | Build initial state from AgentInput | Before graph execution | | extract\_output() | Extract output from final state | After graph execution | | execute() | Orchestrates the full lifecycle | On each invocation | :::hint{type="info"} There is no build() or run() method. The execute() method handles graph compilation and invocation automatically. Call await workflow\.execute(agent\_input). ::: # Add workflow agent ## Step 1: Define Workflow State Create state in src/agents/state.py: ```javascript """Workflow state definitions.""" from typing import TypedDict, Optional, List, Dict, Any, Annotated from operator import add class WorkflowStatus: """Canonical workflow status values.""" PENDING = "pending" IN_PROGRESS = "in_progress" SUCCESS = "success" ERROR = "error" class WorkflowState(TypedDict, total=False): """State shared across all workflow nodes. All nodes can read and write to this state. LangGraph manages state persistence and transitions. """ # Input raw_input: dict platform_context: dict # Processing status: str current_node: str # Results output: Optional[str] error: Optional[str] error_message: Optional[str] # Tracking (use Annotated for append-only lists) messages: Annotated[List[Dict[str, Any]], add] ``` ## Step 2: Create the Workflow Agent Create agent in src/agents/orchestrator.py: ```javascript """Orchestrator workflow agent using LangGraph.""" import logging import os from typing import Dict, Any, Literal from bridge_agent_sdk import ( BridgeBaseWorkflowAgent, WorkflowConfig, AgentInput, MCPClient, ) from langgraph.graph import StateGraph, END from src.agents.state import WorkflowState, WorkflowStatus logger = logging.getLogger(__name__) class OrchestratorWorkflow(BridgeBaseWorkflowAgent): """Multi-agent workflow that routes queries to specialized handlers. Flow: 1. Classifier → Determines query type (SQL, RAG, Action) 2. Route to appropriate handler 3. Responder → Formats final response """ CONFIG = WorkflowConfig( name="orchestrator", version="1.0.0", description="Multi-agent query orchestrator", ) CLASSIFIER_PROMPT = """Classify the user query into one of these categories: - SQL: Data queries, metrics, reports, statistics - RAG: Knowledge questions, how-to, documentation Respond with JSON: {"type": "sql|rag", "confidence": 0.0-1.0}""" ``` ```javascript # ───────────────────────────────────────────────────────────── # Required Overrides # ───────────────────────────────────────────────────────────── def define_state(self) -> type: """Define the state schema for this workflow.""" return WorkflowState def setup_nodes(self, graph: StateGraph): """Add processing nodes to the workflow graph.""" graph.add_node("classifier", self.classifier_node) graph.add_node("sql_agent", self.sql_agent_node) graph.add_node("rag_agent", self.rag_agent_node) graph.add_node("responder", self.responder_node)     def setup_edges(self, graph: StateGraph): """Define edges and routing between nodes.""" graph.set_entry_point("classifier") graph.add_conditional_edges( "classifier", self.route_query, { "sql": "sql_agent", "rag": "rag_agent", } ) graph.add_edge("sql_agent", "responder") graph.add_edge("rag_agent", "responder") graph.add_edge("responder", END) ``` ```javascript # ───────────────────────────────────────────────────────────── # Node Implementations # ─────────────────────────────────────────────────────────────     def classifier_node(self, state: WorkflowState) -> Dict[str, Any]: """Classify the user query to determine routing.""" logger.info("Classifying query...") # self.llm is auto-created by the SDK's execute() method. # Use self._create_llm(state) only if you need a fresh client # with different settings (e.g., different temperature). response = self.llm.invoke([ {"role": "system", "content": self.CLASSIFIER_PROMPT}, {"role": "user", "content": str(state.get("raw_input", {}).get("query", ""))}, ]) classification = self._parse_classification(response.content) return { "status": WorkflowStatus.IN_PROGRESS, "current_node": "classifier", "messages": [{"role": "classifier", "content": response.content}], } async def sql_agent_node(self, state: WorkflowState) -> Dict[str, Any]: """Process SQL/data queries via MCP.""" logger.info("Processing SQL query...") platform_context = state.get("platform_context", {}) mcp = MCPClient( dev_mode=(os.getenv("KAIF_MODE") != "production"), agent_payload=platform_context if os.getenv("KAIF_MODE") != "local_dev" else None, ) result = await mcp.call_tool_parsed( "bridge_execute_query", {"query": 'SELECT * FROM "ITSM".incident LIMIT 10'}, ) success, parsed = result return { "output": str(parsed.get("data", []) if success else []), "status": WorkflowStatus.IN_PROGRESS, "current_node": "sql_agent", } def rag_agent_node(self, state: WorkflowState) -> Dict[str, Any]: """Process knowledge/RAG queries.""" logger.info("Processing RAG query...")         query = str(state.get("raw_input", {}).get("query", ""))       response = self.llm.invoke([ {"role": "system", "content": "Answer the question based on your knowledge."}, {"role": "user", "content": query}, ])         return { "output": response.content, "status": WorkflowStatus.IN_PROGRESS, "current_node": "rag_agent", } def responder_node(self, state: WorkflowState) -> Dict[str, Any]: """Format the final response.""" logger.info("Generating final response...") return { "status": WorkflowStatus.SUCCESS, "current_node": "responder", } ``` ```javascript # ───────────────────────────────────────────────────────────── # Routing Function # ───────────────────────────────────────────────────────────── def route_query(self, state: WorkflowState) -> Literal["sql", "rag"]: """Route query to appropriate handler based on classification.""" messages = state.get("messages", []) if messages: last = messages[-1].get("content", "") if '"sql"' in last.lower(): return "sql" return "rag" ``` ```javascript # ───────────────────────────────────────────────────────────── # Helpers # ───────────────────────────────────────────────────────────── def _parse_classification(self, response: str) -> Dict[str, Any]: import json try: return json.loads(response) except json.JSONDecodeError: return {"type": "rag", "confidence": 0.0} ``` ## Step 3: Create the Entrypoint Create main.py: ```javascript """Application entrypoint for workflow agent.""" from dotenv import load_dotenv load_dotenv(override=False) import logging from bridge_agent_sdk import run_agent from src.agents.orchestrator import OrchestratorWorkflow logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(name)s - %(levelname)s - %(message)s" ) WORKFLOWS = { "orchestrator": OrchestratorWorkflow, } AGENT_NAME_MAP = { "orchestrator": "orchestrator", } if __name__ == "__main__": run_agent( WORKFLOWS, agent_name_map=AGENT_NAME_MAP, description="Multi-Agent Query Orchestrator", ) ``` # How Execution Works When you call await workflow\.execute(agent\_input), the base class: 1. Calls define\_state() to get the TypedDict schema 2. Creates a StateGraph and calls setup\_nodes() + setup\_edges() 3. Compiles the graph 4. Calls prepare\_initial\_state(agent\_input) to build the initial state dict 5. Creates the LLM client and assigns it to self.llm (via self.\_create\_llm(state)) now that platform\_context is available 6. Activates automatic CADF audit hooks (if enable\_audit=True, the default) 7. Invokes the compiled graph with Langfuse callbacks (if enable\_langfuse=True, the default) 8. Calls extract\_output(final\_state) to build the return value 9. Deactivates audit hooks in the finally block **prepare\_initial\_state() — Default State Keys** The SDK's default prepare\_initial\_state() auto-decomposes ExecutionContext into: | **State Key** | **Source** | **Description** | | ------------------------------------------ | --------------------------------------- | ---------------------------------------------- | | input | agent\_input.content | Primary input content | | metadata | agent\_input.metadata | Execution metadata (thread\_id, etc.) | | context | agent\_input.context | Additional context | | previous\_outputs | agent\_input.previous\_outputs | Outputs from previous agents | | platform\_context | Extracted from ExecutionContext | Auth, account\_id, workflow\_id, etc. | | agent\_payload | Same as platform\_context | Deprecated alias | | raw\_input | Extracted from ExecutionContext | content, input, parameters, runtime\_data | | connection\_details | From platform\_context | List of connection dicts for external services | Override prepare\_initial\_state() to add custom keys while keeping the SDK's auto-decomposition. Always call super() to get the base state: ```javascript # AgentBaseWorkflow is your project's base class from base.py (extends BridgeBaseWorkflowAgent) class MyWorkflow(AgentBaseWorkflow): def prepare_initial_state(self, agent_input: AgentInput) -> Dict[str, Any]: """Extend the SDK's default state with custom keys.""" base_state = super().prepare_initial_state(agent_input) # base_state already has: platform_context, raw_input, connection_details, etc. base_state.update({ "status": WorkflowStatus.PENDING, "messages": [], }) return base_state def extract_output(self, final_state: Dict[str, Any]) -> Any: """Customize how final state maps to output.""" return { "content": final_state.get("output", ""), "status": final_state.get("status", WorkflowStatus.ERROR), } ``` :::hint{type="info"} Do not build platform\_context manually. The SDK's super().prepare\_initial\_state() extracts it from ExecutionContext and validates all required fields. If you skip super(), auth will fail in bridge\_dev and production modes. ::: # Advanced patterns ## Retry Loops ```javascript def setup_edges(self, graph: StateGraph): graph.set_entry_point("attempt") graph.add_conditional_edges( "attempt", self.check_result, { "success": "finalize", "retry": "attempt", "fail": END, } ) graph.add_edge("finalize", END) def check_result(self, state) -> str: if state.get("success"): return "success" elif state.get("retry_count", 0) < 3: return "retry" else: return "fail" ``` ## Sub-Workflow Orchestration (Pipeline Pattern) Use run\_sub\_workflow\_sync to call sub-workflows from LangGraph nodes (which are synchronous). Create sub-workflow instances once in \_\_init\_\_, not per-invocation: ```javascript from bridge_agent_sdk import run_sub_workflow_sync, AgentInput class PipelineWorkflow(BridgeBaseWorkflowAgent): def __init__(self): super().__init__() self._debug_workflow = DebugWorkflow() self._remediation_workflow = RemediationWorkflow() def node_run_debug(self, state): agent_input = AgentInput( content="debug task", metadata={ "thread_id": state.get("metadata", {}).get("thread_id", "sub-debug"), "execution_id": state.get("metadata", {}).get("execution_id", "unknown"), }, context={ "platform_context": state["platform_context"], "raw_input": state["raw_input"], }, ) result = run_sub_workflow_sync(self._debug_workflow, agent_input) return { "debug_report": result.get("content", ""), "debug_status": result.get("status", "unknown"), } ``` # WorkflowConfig reference Key WorkflowConfig fields and their defaults: | **Field** | **Type** | **Default** | **Description** | | -------------------------------------- | ------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------- | | name | str | required | Workflow name | | version | str | "1.0.0" | Workflow version | | description | str | required | Workflow description | | llm\_provider | str | os.getenv("LLM\_PROVIDER", "openai") | LLM backend: openai, azure\_openai, hosted\_llm, anthropic | | llm\_model | str | os.getenv("LLM\_MODEL", "gpt-4.1-mini") | Model name (reads from env at class load) | | llm\_temperature | float | 0.7 | Sampling temperature | | max\_iterations | int | 20 | Max workflow iterations | | recursion\_limit | int | 200 | Max LangGraph recursion depth | | enable\_langfuse | bool | True | Enable Langfuse tracing for all LLM calls | | enable\_audit | bool | True | Enable automatic CADF audit hooks (start/stop events) | | enable\_tenant\_db | bool | False | Enable multi-tenant database isolation | | account\_code | str | None | Tenant code for DB isolation (required when enable\_tenant\_db=True) | ** ** ## Automatic Audit Hooks (v1.0.16+) When enable\_audit=True (the default), the SDK automatically wraps execute() with CADF audit events. You do NOT need to manually call \_post\_audit() for start/stop — the SDK emits: - **Start event:** when execute() begins - **SDK-level events:** on LLM calls, auth operations, connection lookups - **Stop event:** when execute() completes (or fails) To opt out, set enable\_audit=False in WorkflowConfig. ## GuardrailsService (v1.0.16+) The SDK includes GuardrailsService for PII/DLP redaction in audit logs and Langfuse traces. It is initialized automatically on BridgeBaseWorkflowAgent when the guardrails endpoint is configured: GUARDRAILS\_ENDPOINT=https\://your-bridge-host/kaif/v2/guardrails GUARDRAILS\_PII\_PROVIDER=azure    # or "google" GUARDRAILS\_DEFAULT\_CONFIG\_NAME=genaiassist-default The \_guardrails attribute is automatically passed to AuditService and Langfuse callbacks to redact PII from logged data. ## Tenant Database (v1.0.16+) For agents that need per-account data storage with schema isolation: ```javascript CONFIG = WorkflowConfig( name="my-agent", description="...", enable_tenant_db=True, account_code="ACME", ) # In workflow nodes, access via self.db: async def store_results_node(self, state): await self.db.insert("execution_log", {"status": "completed", "result": "..."}) rows = await self.db.select("execution_log", where={"status": "completed"}) return {"stored": True} Requires ACCOUNT_POSTGRES_* environment variables. See TenantDatabaseManager docs for schema isolation, RLS, and restricted roles. ``` # Testing Workflows ```javascript """Tests for OrchestratorWorkflow.""" import pytest from unittest.mock import patch, MagicMock from bridge_agent_sdk import AgentInput from src.agents.orchestrator import OrchestratorWorkflow from src.agents.state import WorkflowStatus @pytest.fixture def workflow(): """Create workflow instance.""" return OrchestratorWorkflow() def test_classifier_routes_correctly(workflow): """Test that classifier produces expected state updates.""" state = { "raw_input": {"query": "Show me incidents from last week"}, "platform_context": {}, "status": WorkflowStatus.PENDING, "messages": [], }  mock_response = MagicMock() mock_response.content = '{"type": "sql", "confidence": 0.95}' # self.llm is set by execute() at runtime; in unit tests, set it directly workflow.llm = MagicMock() workflow.llm.invoke.return_value = mock_response result = workflow.classifier_node(state) assert result["status"] == WorkflowStatus.IN_PROGRESS assert len(result["messages"]) == 1 @pytest.mark.asyncio async def test_full_workflow_execution(workflow): """Test complete workflow execution via execute().""" agent_input = AgentInput( content="What is our SLA policy?", metadata={"thread_id": "test-456"}, context={"agent_payload": {"account_id": "test-account"}}, ) mock_response = MagicMock() mock_response.content = '{"type": "rag", "confidence": 0.9}' with patch.object(workflow, '_create_llm') as mock_create_llm: mock_llm = MagicMock() mock_llm.invoke.return_value = mock_response mock_create_llm.return_value = mock_llm result = await workflow.execute(agent_input) assert result is not None ``` [title] MCP tools discovery [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ This guide explains how to discover and use MCP (Model Context Protocol) tools available on the Bridge Platform. MCP tools provide your agent with capabilities to interact with external services like ServiceNow, Azure, Dynatrace, and the Bridge Data platform. Before registering your agent in the Bridge Catalog, you need to: 1. **Discover** available MCP tools on your Bridge Platform instance 2. **Select** the tools your agent requires 3. **Configure** the tools in your agent-catalog-registration.json The Bridge Platform provides a centralized MCP server that exposes tools from multiple backend services. # Prerequisites - Bridge Platform access with KAIF\_HOST URL - Service API Key (SERVICE\_API\_KEY) - MCP Server URL (BRIDGE\_MCP\_SERVER\_URL) — **optional**; SDK auto-resolves from KAIF\_HOST - Python 3.12+ with requests and python-dotenv packages # Discovery Script Use the scripts/list\_mcp\_tools.py utility to discover available MCP tools. ## Installation Copy the script to your agent project: ```javascript mkdir -p scripts # Copy from template or sample agent repository ``` ## Configuration Ensure your .env file contains the required variables: ```javascript # Bridge Platform host KAIF_HOST=https://your-instance.bridge.kyndryl.com # Service API Key (from Bridge Platform Admin) SERVICE_API_KEY=your-service-api-key # MCP Server URL (optional — SDK auto-resolves from KAIF_HOST in bridge_dev) # BRIDGE_MCP_SERVER_URL=https://your-account-us-accountid.bridge.kyndryl.com/kaif/v2/mcp/tools ``` ## Usage ```javascript # Activate virtual environment source venv/bin/activate # List all available tools (summary view) python scripts/list_mcp_tools.py # Export tools to JSON file python scripts/list_mcp_tools.py --output available-tools.json # Format for catalog registration python scripts/list_mcp_tools.py --format catalog --output catalog-tools.json # Filter specific MCP servers python scripts/list_mcp_tools.py --filter servicenow,bridge # Quiet mode (for CI/CD) python scripts/list_mcp_tools.py --quiet --output tools.json ``` ## Command options | **Option** | **Description** | | --------------------------------------- | ---------------------------------------------- | | --output, -o | Output file path (JSON format) | | --format, -f | Output format: raw, catalog, summary (default) | | --filter | Comma-separated MCP server prefixes to filter | | --quiet, -q | Suppress progress messages | # Available MCP servers The Bridge Platform typically provides these MCP servers: ### Core platform tools | **MCP Server** | **Description** | **Common Operations** | | ------------------------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------- | | servicenow\_mcp | ServiceNow ITSM integration | servicenow\_get\_all\_incidents, servicenow\_create\_incident, servicenow\_search\_incidents | | bridge\_mcp | Bridge Data Platform | bridge\_execute\_query, bridge\_list\_domains, bridge\_get\_table\_details | | aiops\_mcp | Analytics | aiops\_ask\_me\_anything, aiops\_nlq\_service | ### Cloud provider tools | **MCP Server** | **Description** | **Example Operations** | | ------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------- | | azure\_mcp | Azure services (50+ tools) | azure\_aks, azure\_keyvault, azure\_monitor, azure\_cosmos | ### Observability tools | **MCP Server** | **Description** | **Example Operations** | | ------------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | | dynatrace\_mcp (if configured) | Dynatrace monitoring | execute\_dql, list\_problems, get\_environment\_info | | mock\_mcp | Mock data for testing | mock\_datadog\_metrics, mock\_servicenow\_changes | ### Utility tools | **MCP Server** | **Description** | **Operations** | | ------------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | search\_mcp | Web search | search\_web, search\_news, search\_images | | file\_mcp | File operations | file\_read, file\_write, file\_list\_directory | | db\_mcp | MongoDB operations | db\_mongo\_query, db\_mongo\_insert | | api\_mcp | HTTP requests | api\_get, api\_post, api\_request |   ### Tool definition structure Each MCP tool has this structure: ```javascript { "name": "servicenow_get_all_incidents", "description": "Get all incidents from ServiceNow ITSM platform...", "inputSchema": { "type": "object", "properties": { "limit": { "type": "integer", "description": "Maximum number of incidents to return", "default": 100 } }, "required": [] } } ``` ### Key fields | **Field** | **Description** | | -------------------------------------- | ------------------------------------------------- | | name | Tool identifier (used in call\_tool()) | | description | What the tool does | | inputSchema | JSON Schema defining required/optional parameters | | inputSchema.required | List of mandatory parameters | [title] [path] Services/Platform Services/Knowledge & AI/ [title] Bridge AI Assist Configuration [path] Services/Platform Services/Knowledge & AI/Bridge AI Assist/Onboarding Bridge AI Assist/ # Accessing Bridge AI Assist Configuration This guide explains the steps to create, modify, and manage Bridge AI Assist configurations.  From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="28" height="28"}, go to **Services** → **Platform Services** → **Bridge AI Assist Configuration**. :::hint{type="info"} Support for visualizing logs and cross-account reports in a dashboard is planned for a future release. ::: # Creating a configuration Select **Add New Configuration**. :::::WorkflowBlock ::::WorkflowBlockItem ## General - **Configuration name:** Enter a unique name for the AI experience (e.g., *Bridge AI Assist for Developers, Bridge AI Assist for Solution Architects, Bridge AI Assist for Consult Partners*).  - **Description:** Add a short description of the configuration purpose.  - **Knowledge base:** Multi-select knowledge bases from available options ([global](docId\:IyFkGLNydeWdpbg2b0eIZ) or [private](docId\:IyFkGLNydeWdpbg2b0eIZ)).  - **Access group:** Assign access groups to define which users can view this knowledge base.  Select **Save and Next** to continue.  :::hint{type="info"} - Pick names that make sense to your users. Role-specific names help them to quickly find the right AI experience.  - Keep configuration names unique.  - Only include knowledge bases that matter to the user roles.  - You can combine multiple knowledge bases for richer responses.  ::: :::: ::::WorkflowBlockItem ## Prompts For each knowledge base selected:  - **Prompt name:** Enter a unique name for the conversation starter  - **Template variable:** Context, query (Text field)  - **Description:** Add details to guide AI responses based on context and query.  Select **Save and Next** to continue. :::hint{type="info"} - Use starter questions that guide AI consistently. Think like a user: what would they ask first?  - Clear and concise descriptions help maintain context and accuracy in AI responses.  ::: :::: ::::WorkflowBlockItem ## Guardrails For each category: - Select the [Data Loss Prevention](docId\:JEzbI23u0cu_RvFbaF1YR) (DLP) checks of your choice to prevent exposure of sensitive information. :::hint{type="info"} * Guardrails are your safety net; don’t skip them. Default values are good, but tweak if needed for your account. * Remember: sensitive data comes in many forms (PII, SPI, biometric, demographic). Always double-check the categories. * Categories are mapped to Azure compliance fields. ::: :::: :::WorkflowBlockItem ## Advanced activity - **Large language model:** Choose from the [onboarded AI models](docId\:JEzbI23u0cu_RvFbaF1YR) (GPT 4.1, GPT 5, nano, mini and more). - **Retrieval configuration parameters: **Adjust temperature, top-P, and top-K to control answer spread and accuracy. - **Additional configurations:** - **Context awareness:** Track prior questions for session continuity (enabled by default) - **Language support:** Enable responses in multiple languages (disabled by default) - **Analytics enablement:** Optional data queries (disabled by default) Select **Save **to add the new configuration. ::: ::::: # Configuration page The Configuration page lists all configurations added to the account and their information. ## Available actions From the overflow menu next to each configuration, you can:  - **View:** See details for the knowledge base.  - **Edit: **Update the parameters. - **Delete: **Permanently remove a configuration that is no longer required. # [title] Bridge catalog registration [path] Services/Platform Services/Knowledge & AI/Agentic AI/Design, Build, Catalog and Deploy/New agent development/ After completing local development and testing, the next step is to register your agent in the **Bridge Catalog**. This registration creates a draft version that can be reviewed, tested, and eventually published for production use. The Bridge Catalog is the central registry for all agents on the Kyndryl Bridge Platform. Registration involves: 1. **Building and publishing** your container image to JFrog Artifactory 2. **Discovering available MCP tools** using the discovery script 3. **Registering** the agent definition in the Bridge Catalog 4. **Configuring** skills, tools, knowledge bases, and schemas 5. **Keeping as draft** until ready for production deployment # Prerequisites Before registering your agent: - Agent code is complete and tested locally (local\_dev mode) - Ready to test with Bridge Platform (bridge\_dev mode) after registration + deployment - Container image built and pushed to JFrog Artifactory - MCP tools discovered using MCP Tools Discovery - Input/output schemas defined - Access to Bridge Platform Admin UI or API :::hint{type="info"} **Best practice for bridge\_dev:** Create both **catalog registration** and **deployment registration** before you start bridge\_dev testing. This applies even when using a temporary testing image like under-development-for-bridge-dev-test\:release-.... ::: # To register a catalog ## Step 1: Build and push container image Before registration, your agent must be containerized and published to JFrog Artifactory. :::hint{type="info"} **Do NOT use python:3.12-slim or other public Docker Hub images.** All production agent images must use the kaif-pythoncompileimage base image. ::: **Build and Push Commands** ```javascript # Set variables export IMAGE_NAME="bdg-sw-agents-incident-enrichment" export IMAGE_TAG="release-$(date +%Y.%m.%d)-$(git rev-parse --short HEAD)-$(date +%s)" export REGISTRY="kyndryl.jfrog.io/kyn-cto-kaif-docker-local" # Build the image docker build -t ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}} . # Login to JFrog (use your credentials) docker login kyndryl.jfrog.io # Push the image docker push ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}} # Note the full image path for registration echo "Image: ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}}" ``` ## Step 2: Registration methods There are two ways to register your agent in the Bridge Catalog: ### Option A: UI Registration (Manual) 1. Navigate to **Bridge Platform Admin Console** 2. Go to **Catalog** → **Agents** → **Create New Agent** 3. Fill in the required fields: - Agent Name - Description - Agent Type - Container Image - Resource Requirements 4. Configure Skills, Tools, and Knowledge Bases 5. Define Input/Output Schemas 6. Save as **Draft** ### Option B: JSON upload 1. Prepare your agent definition JSON file 2. Navigate to **Catalog** → **Agents** → **Import Agent** 3. Upload the JSON file 4. Review and confirm the configuration 5. Save as **Draft** ### Option C: API registration (Programmatic) You can register your agent programmatically using the **Agent Catalog REST API**. API Endpoint POST /kaif/v3/agent-catalog/agents Host: Use KAIF\_HOST (for example, https\://dev1-aws-oregon-base.bridge.kyndryl.com) **Authentication** The API requires a **Bearer token** obtained from the token endpoint: POST /api/iam/v4/identity/token The response contains a token field, use it as Authorization: Bearer \. :::hint{type="info"} Save the agent\_catalog\_id from the response — you will need it in your EXECUTION\_CONTEXT for bridge\_dev testing and production deployments. ::: **Programmatic Registration Script** The project includes a helper script at scripts/register\_agent.py: ```javascript # Ensure .env has KAIF_HOST, SERVICE_API_KEY, and BRIDGE_ACCOUNT_ID set python scripts/register_agent.py ``` The script: 1. Fetches an token using SERVICE\_API\_KEY 2. Reads agent-catalog-registration.json from the project root 3. POSTs to /kaif/v3/agent-catalog/agents on the account-specific host 4. Prints the agent\_catalog\_id on success ## Step 3: Agent definition JSON Structure The agent definition JSON contains all metadata required for registration. Below is the complete structure with explanations. **JSON Schema Reference** | **Field** | **Type** | **Required** | **Description** | | -------------------------------------- | ------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------- | | name | string | Yes | Unique agent identifier (lowercase, hyphens allowed) | | description | string | Yes | Human-readable description of the agent | | agent\_type | string | Yes | Type: agentic\_solution, chatops, workflow | | flow | object | Yes | Container execution configuration | | metadata | object | Yes | Tags and ownership information | | skills | array | Yes | List of capabilities the agent provides | | tools | array | No | MCP tools and connectors required (each with type, operations) | | knowledge\_bases | array | No | Knowledge bases the agent uses | | llm | array | Yes | LLM provider and model configuration | | schemas | object | Yes | Input/output JSON schemas | | source | object | No | Source code repository (agent\_code\_url, branch, manifest\_path) | | is\_latest | boolean | Yes | Whether this is the latest version | | is\_published | boolean | Yes | Publication status (false for draft) | | canCreateDeployment | boolean | Yes | Whether deployments can be created | ## Step 4: Incident enrichment agent registration Below is the complete registration JSON for the bdg-sw-agents-incident-enrichment agent: **Agent Definition JSON** ```javascript { "name": "incident-enrichment-agent", "description": "AI agent that enriches incident tickets with contextual data from ServiceNow and Bridge Data platform for faster resolution", "agent_type": "agentic_solution", "flow": { "name": "incident-enrichment", "description": "Multi-step workflow for incident analysis and enrichment", "steps": [ { "name": "inc-enrich-step", "image": "kyndryl.jfrog.io/kyn-cto-kaif-docker-local/under-development-for-bridge-dev-test:release-2026.03.27-abc1234-1774333268", "command": [ "python3 main.py" ] } ] }, "metadata": { "tags": [ "incident", "enrichment", "servicenow", "operations" ], "owner_team": "platform-operations", "maintaining_team": "kaif-agents-team" }, "skills": [ { "name": "Incident Retrieval", "description": "Retrieves incident details from ServiceNow using ticket ID" }, { "name": "Asset Lookup", "description": "Looks up related CI/asset information from Bridge Data platform" }, { "name": "Change History Analysis", "description": "Analyzes recent change records that may be related to the incident" }, { "name": "Contextual Enrichment", "description": "Synthesizes data from multiple sources to provide comprehensive incident context" }, { "name": "Resolution Recommendations", "description": "Generates AI-powered recommendations based on enriched incident data" } ], "tools": [ { "name": "servicenow_mcp", "type": "mcp", "description": null, "operations": [ "servicenow_search_incidents", "servicenow_search_change_requests", "servicenow_create_incident" ], "endpoint": null, "auth_required": false }, { "name": "bridge_mcp", "type": "mcp", "description": null, "operations": [ "bridge_execute_query", "bridge_get_domain_details", "bridge_get_table_details", "bridge_list_catalogs", "bridge_list_domains", "bridge_list_tables" ], "endpoint": null, "auth_required": false }, { "name": "ChatOps", "type": "connector", "description": null, "operations": [], "endpoint": null, "auth_required": false }, { "name": "Elasticsearch", "type": "connector", "description": null, "operations": [], "endpoint": null, "auth_required": false } ], "knowledge_bases": [ { "name": "incident-runbooks", "description": "Knowledge base containing incident resolution runbooks and procedures", "type": "global" }, { "name": "infrastructure-docs", "description": "Infrastructure documentation and architecture diagrams", "type": "account" } ], "llm": [ { "provider": "hostedllm", "model": "bring_your_own" } ], "schemas": { "default": false, "input": { "type": "object", "required": ["query", "parameters", "input"], "properties": { "query": { "type": "string", "description": "Natural language query or instruction for the agent" }, "parameters": { "type": "object", "additionalProperties": true, "description": "Additional parameters for agent execution" }, "input": { "type": "object", "required": ["data", "channel", "account_settings"], "properties": { "data": { "type": "object", "required": ["incident_id"], "properties": { "incident_id": { "type": "string", "description": "ServiceNow incident ticket ID (e.g., INC0012345)" }, "include_changes": { "type": "boolean", "default": true, "description": "Whether to include related change records" }, "lookback_days": { "type": "integer", "default": 7, "description": "Number of days to look back for related changes" } }, }, "channel": { "type": "object", "required": ["channelId", "workspaceName"], "properties": { "channelId": { "type": "string", "description": "Slack channel ID for notifications" }, "workspaceName": { "type": "string", "description": "Slack workspace name" } }, }, "account_settings": { "type": "object", "required": ["servicenow", "bridge_data"], "properties": { "servicenow": { "type": "object", "required": [ "SERVICENOW_INSTANCE", "SERVICENOW_USER", "SERVICENOW_PASSWORD" ], "properties": { "SERVICENOW_INSTANCE": { "type": "string", "format": "uri", "description": "ServiceNow instance URL" }, "SERVICENOW_USER": { "type": "string", "description": "ServiceNow API username" }, "SERVICENOW_PASSWORD": { "type": "string", "description": "ServiceNow API password" } }, }, "bridge_data": { "type": "object", "required": [ "BRIDGE_DATA_ENDPOINT", "BRIDGE_DATA_API_KEY" ], "properties": { "BRIDGE_DATA_ENDPOINT": { "type": "string", "format": "uri", "description": "Bridge Data platform endpoint" }, "BRIDGE_DATA_API_KEY": { "type": "string", "description": "Bridge Data API key" } }, } }, } }, } }, }, "output": { "type": "object", "properties": { "incident": { "type": "object", "description": "Original incident details from ServiceNow" }, "enrichment": { "type": "object", "properties": { "related_assets": { "type": "array", "description": "List of related CIs/assets" }, "recent_changes": { "type": "array", "description": "Recent change records that may be related" }, "similar_incidents": { "type": "array", "description": "Similar past incidents" } } }, "recommendations": { "type": "array", "items": { "type": "object", "properties": { "action": { "type": "string" }, "confidence": { "type": "number" }, "reasoning": { "type": "string" } } }, "description": "AI-generated resolution recommendations" }, "summary": { "type": "string", "description": "Natural language summary of the enriched incident" } } } }, "source": { "agent_code_url": "https://github.com/kyndryl-agentic-ai/bdg-sw-agents-incident-enrichment", "branch": "main", "manifest_path": "." }, "is_latest": true, "is_published": false, "canCreateDeployment": false } ``` **Save as File** Save this JSON to your project for easy upload ## Step 5: Field configuration details :::::WorkflowBlock :::WorkflowBlockItem **Flow Configuration** The flow section defines how your agent container runs: ```javascript "flow": { "name": "incident-enrichment", "description": "Multi-step workflow for incident analysis and enrichment", "steps": [ {      "name": "inc-enrich-step", "image": "kyndryl.jfrog.io/kyn-cto-kaif-docker-local/bdg-sw-agents-incident-enrichment:release-2026.03.27-abc1234-1774333268", "command": ["python3 main.py"], "resources": { "cpu": "900m",      // 0.9 CPU cores "memory": "2Gi"     // 2 GB RAM } } ] } ``` **Constraints:** - **Step name**: Maximum **18 characters** (e.g., inc-enrich-step ✅, incident-enrichment-step ❌) - **Image tag**: Must use the release- prefix (e.g., release-2026.03.27-abc1234-1774333268 ✅, main-abc1234-... ❌) - **Resources**: **Optional** — if omitted, the platform applies default resource limits. Add only if your agent needs specific CPU/memory allocations. ::: :::WorkflowBlockItem **Bridge\_dev-only Image Pattern (Important)** 1. You can register with a bridge\_dev testing image such as: kyndryl.jfrog.io/kyn-cto-kaif-docker-local/under-development-for-bridge-dev-test\:release-2026.03.27-abc1234-1774333268 2. Use this pattern **only for bridge\_dev validation**. 3. For bridge\_dev testing, first complete: 1. Catalog registration (POST /kaif/v3/agent-catalog/agents), and 2. Deployment registration (POST /kaif/v3/deployment/agentic). 4. Then execute your bridge\_dev tests against that deployment. 5. After testing is complete, do a proper **release cut** and switch to the released image tag/repository for ongoing deployments by either: 6. Updating the existing catalog registration (PATCH/PUT) with the new released image tag, or 7. Creating a new registration version and deploying that version. Then create a **fresh deployment** so runtime points to the released image. ::: ::::WorkflowBlockItem **Skills Configuration** Skills describe what your agent can do. These appear in the UI and help users understand capabilities: ```javascript "skills": [ { "name": "Incident Retrieval", "description": "Retrieves incident details from ServiceNow using ticket ID" }, { "name": "Asset Lookup", "description": "Looks up related CI/asset information from Bridge Data platform" } ] ``` :::hint{type="info"} Use clear, action-oriented names - Keep descriptions concise (\< 100 characters) - Map skills to your workflow nodes - Include all capabilities users should know about ::: :::: :::WorkflowBlockItem **Tools Configuration** The tools section declares MCP tools your agent requires. **First, discover available tools** using the MCP Tools Discovery script: 1. Discover available MCP tools on your Bridge instance: python scripts/list\_mcp\_tools.py 2. Export in catalog format: python scripts/list\_mcp\_tools.py --format catalog --output available-tools.json 3. Then configure only the tools your agent needs. For MCP tools, use the **minimal valid object** by default (name + type + operations): ```javascript "tools": [ { "name": "servicenow_mcp", "type": "mcp", "operations": [ "servicenow_search_incidents", "servicenow_create_incident" ] }, { "name": "bridge_mcp", "type": "mcp", "operations": [ "bridge_execute_query", "bridge_get_table_details" ] } ] ``` Use extended optional fields (description, endpoint, auth\_required) only when your platform workflow explicitly requires them. ::: ::::WorkflowBlockItem **Connector type tools ** (e.g., ChatOps, Elasticsearch) use "type": "connector" with empty operations: \[]. They represent platform-managed integrations where the credentials are injected via the Connection Manager: :::hint{type="info"} Tool names must match MCP server names exactly - type is required and must be valid (for MCP entries use "mcp") - Operations must use underscores (not hyphens) - Only list operations your agent actually uses (least privilege) - Run the discovery script to see available tools on your instance - This affects permission requests during deployment ::: :::: :::WorkflowBlockItem Schema-driven validation (registry truth): Agent registration payloads are validated against registry Pydantic models and enums. If type is missing or an operation is not allowed for the selected tool name, registration is rejected. ::: :::WorkflowBlockItem **Knowledge Bases Configuration** If your agent uses RAG capabilities: ```javascript "knowledge_bases": [ { "name": "incident-runbooks", "description": "Knowledge base containing incident resolution runbooks", "type": "global"        // Available to all accounts }, { "name": "infrastructure-docs", "description": "Infrastructure documentation", "type": "account"       // Account-specific } ] ``` ::: :::WorkflowBlockItem **Knowledge Base Integration (Registration + SDK Runtime)** If you declare knowledge\_bases in catalog registration, integrate retrieval in code using KBSearchService. SDK-aligned usage pattern: ```javascript import logging from bridge_agent_sdk import KBSearchService logger = logging.getLogger(__name__) async def node_search_kb(self, state: dict) -> dict: # state must contain platform_context (agent_payload) kb = KBSearchService(logger, state)   # KBSearchService.search is sync and accepts (query, k) articles = kb.search( query=state.get("short_description", ""), k=5, ) return {**state, "kb_articles": articles} ``` ::: :::WorkflowBlockItem **LLM Configuration** Specify the LLM provider and model(s) your agent uses: ```javascript "llm": [ { "provider": "hostedllm", "model": ["gpt-4.1"] } ] ``` ::: ::::WorkflowBlockItem **Schemas Configuration** Define your agent's input/output contract: ```javascript "schemas": {   "default": false,         // false = custom schema "input": { ... },         // JSON Schema for input "output": { ... }         // JSON Schema for output } ``` :::hint{type="info"} **Schema Best Practices:** - Use "additionalProperties": false for strict validation - Include "description" for all properties - Set appropriate "default" values - Mark required fields explicitly ::: :::: ::::: **Resource Guidelines (optional):** | **Agent Complexity** | **CPU** | **Memory** | | ------------------------------------------------- | ------------------------------------ | --------------------------------------- | | Simple (single tool) | 500m | 1Gi | | Medium (2-3 tools) | 900m | 2Gi | | Complex (workflow) | 1500m | 4Gi | | Heavy (RAG + multiple MCPs) | 2000m | 8Gi | **Tool Entry Fields:** | Field | Type | Required | Description | | ---------------------------------- | --------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------- | | name | string | Yes | MCP server name or connector name (e.g., bridge\_mcp, servicenow\_mcp) | | type | string | Yes | "mcp" for MCP tool servers, "connector" for platform connectors (e.g., ChatOps, Elasticsearch) | | description | string | No | Optional description (set to null if not needed) | | operations | array | Yes (for mcp) | List of tool operation names. Empty \[] for connectors | | endpoint | string | No | Custom endpoint override (set to null for platform-managed) | | auth\_required | boolean | No | Whether the tool requires explicit auth (false = platform handles auth) | **Runtime notes (important):** - local\_dev: KB search returns an empty list by design (no Bridge KB backend). - bridge\_dev / production: endpoint resolves from KAIF\_HOST; auth is handled via SDK token flow. - state should include platform\_context.account\_id and platform\_context.instance\_name for correct scoping. **Providers:** | **Provider** | **Description** | **Example Models** | | ----------------------------------------- | -------------------------------------------- | ----------------------------------------------- | | hostedllm | Self-hosted / bring-your-own LLM | bring\_your\_own | :::hint{type="info"} 💡 **Tip:** Check the Bridge Platform Admin Console UI for the latest list of supported providers and models — the platform team adds new models regularly. ::: ## Step 6: Keeping agent in draft status **Draft Status Benefits** - **Testing**: Deploy to test environments without affecting production - **Review**: Team can review configuration before publishing - **Iteration**: Make changes without versioning concerns - **Validation**: Platform validates configuration before publish When registering, ensure these flags are set to keep the agent as a draft: ```javascript { "is_latest": true, "is_published": false, "canCreateDeployment": false } ``` | **Flag** | **Draft Value** | **Production Value** | | ------------------------------------- | -------------------------------------------- | ------------------------------------------------- | | is\_latest | true | true | | is\_published | false | true | | canCreateDeployment | false | true | ## Step 7: Validation checklist Before uploading your registration JSON, verify: **Required Fields** - \[ ] name - Unique, lowercase, alphanumeric with hyphens - \[ ] description - Clear, concise explanation - \[ ] agent\_type - Valid type (agentic\_solution, chatops, workflow) - \[ ] flow\.steps\[].image - Valid, accessible container image - \[ ] flow\.steps\[].resources - Appropriate CPU/memory - \[ ] schemas.input - Valid JSON Schema - \[ ] llm\[].model - Supported model names **Optional but Recommended** - \[ ] metadata.tags - Relevant search tags - \[ ] metadata.owner\_team - Team ownership - \[ ] skills - At least one skill defined - \[ ] tools - All required MCP tools listed - \[ ] source.url - Source repository link **Common Validation Errors** | **Error** | **Cause** | **Solution** | | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------- | | Image ... is invalid. Image must be hosted on kyndryl.jfrog.io and tagged with a release tag | Image tag uses main- or other prefix instead of release- | Change tag to release-YYYY.MM.DD-\-\ format | | Step name '...' is N chars — max is 18 | Step name exceeds 18-character limit | Shorten the step name (e.g., inc-enrich-step) | | Invalid image reference | Image not in JFrog | Push image to kyndryl.jfrog.io first | | Unknown tool operation | Typo in operation name | Run MCP discovery script to get exact names | | Schema validation failed | Invalid JSON Schema | Validate with jsonschema | | Duplicate agent name | Name already exists | Use a unique name — the API appends a hash suffix automatically | ## Step 8: Create a deployment After registering the agent in the catalog, the next step is to **create a deployment**. A deployment binds your registered agent to a specific environment with its tool connections, LLM configuration, and access groups. ### Deployment API endpoint POST /kaif/v3/deployment/agentic **Host**: Use KAIF\_HOST (for example, https\://dev1-aws-oregon-base.bridge.kyndryl.com) Authentication is the same as catalog registration — use a Bearer token from the endpoint. **Deployment payload structure** | **Field** | **Type** | **Required** | **Description** | | -------------------------------------- | ------------------------------------- | ----------------------------------------- | -------------------------------------------- | | agent\_catalog\_id | string | Yes | The catalog ID returned from registration | | agent\_service\_id | array | Yes | Service ID(s) for the agent runtime | | deployment\_name | string | Yes | Unique name for this deployment | | application | string | Yes | Application context (e.g., "KAIF") | | displayname | string | Yes | Human-readable name shown in UI | | description | string | Yes | Deployment description | | type | string | Yes | Agent type: "customagent" | | status | string | Yes | "active" or "draft" | | profiles | array | Yes | Connection profiles (tools, LLM, KB) | | timeout | integer | Yes | Execution timeout in seconds | | starter\_message | string | No | Default greeting message | | starter\_questions | array | No | Suggested starter prompts | | flags | object | No | Feature flags | ### Key configuration notes **Profiles → Tools & the connection Field** The profiles\[].tools section maps MCP tool providers to their operations. Each entry has a connection field that references a named connection from the Bridge Connection Manager: ```javascript "tools": { "": { "connection": "", "mcp_tools": [ "::" ] } } ``` :::hint{type="info"} Tool references use the provider\::operation format with double colons. ::: ### Understanding the connection field The "connection" value (e.g., "servicenow\_mcp", "bridge\_mcp") is not a URL or credential — it is a logical name that points to a connection configured in the Bridge Connection Manager.  **How it works at runtime:** 1. When your agent makes an MCP call (e.g., servicenow\_search\_incidents), the SDK looks up the connection name from the deployment profile 2. The platform resolves that name to a connection record in the Connection Manager - which holds the credentials, endpoint URL, and access policies for the target account 3. The credentials are injected into the MCP request automatically - your agent code never sees or handles raw credentials ### Setting up connections in Bridge Connection Manager Connections are created by your **Bridge Platform Admin** in the admin UI. **Steps:** 1. Navigate to **Bridge Admin Console** → **Connections Manager** 2. Click **Create Connection** 3. Fill in the connection details: | **Field** | **Example** | **Description** | | -------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------- | | Name | bridge\_mcp | Logical name — must exactly match the "connection" value in your deployment JSON | | Type | mcp | Connection type (mcp, llm, cloudProvider, etc.) | | Provider | bridge\_mcp | The backend provider | | Credentials | (managed by UI) | API keys, tokens, service accounts — stored securely by the platform | 4. Save → note the **Connection ID** (e.g., 69ae501f8a52a9dfa40a3f7a) 5. Use that Connection ID in connection\_details\[] in your deployment JSON :::hint{type="info"} **Note:** The connection name you set here is what gets referenced in your deployment-registration.json. When the agent runs, the platform pulls the credentials from this connection record and injects them into MCP / LLM requests automatically — your agent code never handles raw credentials. ::: **Common Connection Names** These are the standard connection names used across Bridge agents: | **Connection Name** | **Type** | **Provider** | **Purpose** | | ------------------------------------------------ | ------------------------------------- | ----------------------------------------- | -------------------------------------------------------- | | bridge\_mcp | mcp | bridge\_mcp | Bridge Data Platform — SQL queries, domain/table listing | | servicenow\_mcp | mcp | servicenow\_mcp | ServiceNow ITSM — incident search, create | | openai-connection | llm | openai | Azure OpenAI — LLM chat completions | | dynatrace\_mcp | mcp | dynatrace\_mcp | Dynatrace monitoring — metrics, problems | | azure\_mcp | mcp | azure\_mcp | Azure cloud operations | :::hint{type="info"} The connection name in "tools" → "connection" must **exactly match** a connection configured in the Connection Manager for your account. If it doesn't match, MCP calls will fail with 403 — Agent instance not found. ::: **Profiles → Connection Details** The connection\_details array defines the actual connections the agent will use at runtime. Each entry references a connection from the Connection Manager by its connection\_id: ```javascript "connection_details": [ { "type": "llm", "provider": "openai", "name": "openai-connection", "connection_id": "69af9c4b8a52a9dfa40a3f8f", "model": ["gpt-4.1"], "policy": {} }, { "type": "mcp", "provider": "bridge_mcp", "name": "bridge_mcp", "connection_id": "69ae501f8a52a9dfa40a3f7a", "tools": ["bridge_execute_query", "bridge_list_tables"], "policy": {} } ] ``` - **connection\_id** — The unique ID of the connection record in the Connection Manager. Get this from your admin or the Connections page in the admin UI. - **name** — Must match the connection name used in tools → connection and in connections block. - **LLM connection**: Links to the LLM provider (OpenAI, etc.) with model selection — the platform injects the API key and endpoint at runtime - **MCP connection**: Links to the Bridge MCP server — the platform injects auth tokens and routes requests through the MCP gateway These connection IDs are provisioned in the Bridge Admin UI under **Connections**. Your agent code never needs to know the underlying credentials — the platform handles credential injection automatically based on the connection name. **Successful Response** ```javascript { "message": "Instance deployed successfully", "$KAIF_HOST/api/iam/v4/identity/token" \ } ``` **Programmatic Deployment Script** ```javascript "$KAIF_HOST/kaif/v3/agenticsolution/execution-context/" \ # Ensure .env has KAIF_HOST, SERVICE_API_KEY, and BRIDGE_ACCOUNT_ID # Ensure deployment-registration.json exists with the correct agent_catalog_id python scripts/deploy_agent.py ``` ### Two-step registration summary | **Step** | **API Endpoint** | **Payload File** | **What It Does** | | ------------------------------------- | --------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------- | | 1. Catalog | POST /kaif/v3/agent-catalog/agents | agent-catalog-registration.json | Registers agent definition (skills, tools, schemas) | | 2. Deployment | POST /kaif/v3/deployment/agentic | deployment-registration.json | Creates a runnable deployment with connections and profiles | ## Step 9: Post-Deployment steps After successful deployment: ::::WorkflowBlock :::WorkflowBlockItem Verify Deployment \# Check in Bridge Admin UI \# Deployments → Search for your deployment name ::: :::WorkflowBlockItem Update EXECUTION\_CONTEXT for bridge\_dev Testing After deployment, you can get a real execution context from the platform to test locally. This is the **recommended approach** because it includes real connection details and credentials. **Fetch from the Platform** ```javascript # Get Bridge Access Management token TOKEN=$(curl -s -X POST \ "$KAIF_HOST/api/iam/v4/identity/token" \ -H "Content-Type: application/json" \ -d '{"apikey": "'"$SERVICE_API_KEY"'"}' | jq -r '.token') ``` ```javascript # Fetch the execution context for your deployment curl -X POST \ "$KAIF_HOST/kaif/v3/agenticsolution/execution-context/" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"content": "test query", "parameters": {"accountCode": "BAC000ACME"}}' \ -o test_exec_ctx.json ``` ```javascript # Run locally KAIF_MODE=bridge_dev python main.py \ --agent_name my_agent \ --execution_context "$(cat test_exec_ctx.json)" ``` **Security:** The response contains live credentials. Add test\_exec\_ctx.json to .gitignore. **Update Manually** If you prefer to update your existing test\_exec\_ctx.json by hand, ensure these fields match your deployment: - system\_data.metadata.deployment\_name → your deployment name - system\_data.metadata.agent\_catalog\_id → your catalog ID - system\_data.connection\_details → connection details from your deployment profile ::: :::WorkflowBlockItem Run Integration Tests - Use bridge\_dev mode locally pointing to the deployment - Validate all MCP tools work correctly - Test error handling scenarios ::: :::WorkflowBlockItem Request Review - Submit for team review - Document any special configuration requirements - Update runbooks with deployment instructions ::: :::WorkflowBlockItem Publish (When Ready) - Update is\_published: true - Update canCreateDeployment: true - Create production deployment  ::: :::: ### Updating an existing registration You can update your catalog registration at any time — for example, to change the Docker image tag after a new release, update tool lists, or modify schemas. If your current registration uses under-development-for-bridge-dev-test, treat it as bridge\_dev-only. After release cut, update to the released image (or create a new registration version) before non-bridge\_dev usage. 1. **API Methods** | **Method** | **Endpoint** | **Purpose** | | --------------------------------------- | ----------------------------------------- | ----------------------------------------------- | | PUT | /kaif/v3/agent-catalog/agents/ | Full replacement — send the entire updated JSON | | PATCH | /kaif/v3/agent-catalog/agents/ | Partial update — send only the fields to change | ** **After updating the catalog, create a **fresh deployment** via /kaif/v3/deployment/agentic so the platform runs the updated image. 2. **Using the UI** All catalog and deployment operations (create, update, delete) can also be done through the **Bridge Platform Admin Console UI**: 1. Navigate to **Catalog** → **Agents** → find your agent 2. Click **Edit** to update any field (image, tools, schemas, LLM models, etc.) 3. Save changes The UI also allows you to: - Browse available **LLM models** when configuring the llm section - Create and manage **deployments** visually - View agent execution history and logs 3. **LLM Models** The available LLM models can be browsed in the **Bridge Platform Admin Console UI** when configuring the llm section of your agent registration. The UI shows all models currently available on the platform. In the registration JSON, specify the provider and model(s) your agent uses: ```javascript "llm": [ {"provider": "openai", "model": ["gpt-4.1"]} ] ``` :::hint{type="info"} Check the UI for the latest list of supported models — the platform team adds new models regularly. ::: ### Triggering your agent in production Once deployed, your agent can be triggered in two ways: **1. Via API** Call the agent execution endpoint with a payload that **strictly matches the input schema** you defined during catalog registration: POST /kaif/v3/agenticsolution/ :::hint{type="info"} The payload must conform to the input schema registered in the catalog. If the schema has required fields, they must be present — otherwise the platform will reject the request. ::: **2. Via the Bridge UI** Users can trigger agents directly from the Bridge Platform UI by selecting the agent, filling in the input form (auto-generated from your input schema), and clicking **Run**. [title] [path] Services/Platform Services/Knowledge & AI/ [title] Advisor Mode [path] Services/Platform Services/Knowledge & AI/Bridge AI Assist/Bridge AI Assist Overview/Interaction modes/ The Advisor mode allows you to query your organization’s knowledge foundation using natural language. It retrieves answers directly from the connected knowledge base, offering clear and contextual responses. You always have a default knowledge base selected, and you can change it at any time. Chat sessions facilitate dynamic and ongoing conversations. The Advisor leverages your existing knowledge indexes connected to Bridge. Results are always derived from approved and trusted information. ### Capabilities - Conversational, multi-turn Q\&A - Multilingual support - Citation-backed answers - Role and context-aware retrieval - Chat history supported ### Requirements - Must be part of the ACME account - Must belong to at least one of the KAIF access groups: KAIF Admin, KAIF Editor, KAIF Viewer. ### Limitations - Not all features are production-ready. Known issues include feedback text limits and occasional duplicate links. - Some responses may depend on the completeness of the knowledge foundation. - Responses are text-only; images, charts, and graphs are not displayed. # Settings The Settings menu allows you to personalize your experience. ## Language selection 1. Open the left sidebar and select the settings (gear) icon. 2. Choose your preferred language: - English (default) - Spanish - French - German - Japanese Bridge AI Assist responds in the selected language immediately. You can change languages at any time. :::hint{type="info"} Language availability depends on account configuration. ::: ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/fNEeV2bO-J-V0NK1eH_VR/zSDO7ThYd-QGxHdfPVUFu_image.png" size="60" width="1100" height="716" darkWidth="1100" darkHeight="716" position="center" caption="Settings - Language selection" showCaption="true"} [title] Google Deployment templates [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ For to pull data from Google Deployment Templates, you must configure a Google Deployment Templates account or project. **Access Rights:** The project (Account) should have a service account of that particular project and have access/role at least as Project Viewer and Create New key in JSON Format, which is used to create/configure an account so that can pull data from Google Cloud Platform. The Google Cloud Platform requires the following steps to Create a Key respective Service Account. 1. Log in to the Google Cloud Platform console. 2. Select the project that you want to monitor. Note down the **Project ID**.  3. Your selected project opens in the dashboard; please verify it is the same. 4. Then, from the left navigation pane, select **IAM & Admin** → **Service Accounts** 5. On the menu that displays, click on **Service Accounts**, and then select **Create Service Account**. The **Create service account** dialog box is displayed. This is where the user must enter the account name, along with the following service account details: 6. Service Account details: 1. Service Account name 2. Service Account ID 3. Service Account Description 7. Then, select the **Create** button. - Next, on the **Service Accounts** page also from the left navigation pane, in the **Select a Role** field, select → **Project** → **Viewer** role. - On the **Service Accounts** page, grant users access to this service account (optional) under **Grant this service account access to project** and click on **Continue**. - Select the newly created service account and create a new private key using the **Add Key** button and then selecting **Create Key**. - Then, a dialog box will appear that shows **Create New key file** for your account, here, you must select **JSON** format from the options displayed under **Key Type**. After this, click on **Create**. - Now, save the projectIDXXXXXX.json file at your respective location. This file is used to configure Google account in Kyndryl and it contains the public key. - After the JSON is downloaded on the computer, ensure that the following APIs are be enabled on the **Google Cloud Platform**. - Enable API V2 using **projectID** in the APIs console at the following link: https\://console.developers.google.com/apis/api/deploymentmanager.googleapis.com/project=xxxxxxxxxprojectid [title] Post Cutoff [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ After the cut-off process is complete, review access assignments and begin building new automation natively in Service (BAS). ## Assign authorization for CACF workloads If workflows use the Cloud Automation Community Framework (CACF), ensure that catalog activation and user authorization follow the CACF governance model. CACF requirements: To ensure secure access and governance of CACF-based catalog items, the following requirements must be met before catalog items can be activated, managed, or executed. - Catalog activation should be performed by an authorized persona, such as a Delivery Program Executive (DPE). - Users must be granted the appropriate roles before they can activate or manage catalog items. - The DPE must approve any tenant user who requires permission to run CACF-based catalog items. Catalog activation is supported by the following Bridge roles: - Platform Administrator - Platform Editor - Catalog Administrator - Catalog Editor - Any future roles that provide equivalent catalog management permissions - Assign the appropriate role based on the user's responsibilities and level of access :::hint{type="info"} * The DPE must approve any tenant user who is authorized to execute CACF-based catalog items. * Existing content and user authorizations that were migrated from the tenant are considered approved by the DPE unless otherwise reviewed. ::: ## Build new automation in After migrated automation assets have been validated, new automation can be created directly in BAS. provides a low-code authoring experience that enables users to: - Design and manage workflows - Configure workflow execution parameters - Publish reusable catalog items - Test and validate automation before publication - Manage automation lifecycle activities The following resources provide additional information about automation authoring: - [Design workflows using the Workflow Builder](https://kyndryl.sharepoint.com/sites/CTO/_layouts/15/stream.aspx?id=%2Fsites%2FCTO%2FShared%20Documents%2FProduct%20Management%2FCore%20Services%20FY%2726%2FAutomation%20%26%20Policy%2FAgentic%20AI%2FVisual%20workflow%20builder%2Emp4\&ga=1\&referrer=StreamWebApp%2EWeb\&referrerScenario=AddressBarCopied%2Eview%2E1c7b70af%2D44f0%2D4d7d%2Db500%2De328283d6c73) - [Orchestration channels](docId\:E6id_mc9E6czPf_5kR6Id) - [DSL specification](docId\:mV0skTdiQtJyeLkLlgzVQ) - [Orchestration Catalog](docId\:P_Y-G8UeBmj0Cu52Lv1xC) [title] GitLab SAST configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ If you are using GitLab CI/CD, you can use Static Application Security Testing (SAST) to check your source code for known vulnerabilities. You can run SAST analyzers in any GitLab tier. The analyzers produce JSON-formatted reports as job artifacts. Use the following procedure to configure GitLab SAST: # Configuring for GitLab SAST, recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June 2024 or after. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with GitLab SAST as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure GitLab SAST or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Develop row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select GitLab SAST for **Tool Engine**. 6. Click **Submit**. # Onboarding GitLab SAST After configuring GitLab SAST, you must onboard it as a technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Secure** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **GitLab SAST** for **Tool Engine**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the Repository Name field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that GitLab SAST has been fully configured. # Deleting GitLab SAST as a technical service The administrator may, at will, delete the GitLab technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Develop**. 4. Click **Delete Technical Service**. 5. Click GitLab for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. [title] ArgoCD configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ ArgoCD enables you to use GitOps repositories to develop and deploy cloud-native applications and processes on Kubernetes declaratively. ArgoCD can instantly extract updated code from Git repositories and publish it to Kubernetes services. It allows developers to handle infrastructure settings and application upgrades in a given system. You must configure an Argo account for to sync data from ArgoCD. **Access rights:** The account should have at least read rights on the pipelines you intend to sync. # Pre-requisites - Application requires the following information: - Connection Name - Local connection name. It could be any string and is used only for reference. - Host - ArgoCD Host URL. e.g., https\://dev1-aws-oregon-argocd.multicloud-ibm.com/ - User/Passcode - User name and ArgoCD passcode. # Configuration steps For adding connections: 1. Select Admin from the menu, then choose IAM, and then Connections. 2. Select Add New. 3. Choose the Add Connection option. You must select the Connection, Cloud provider, Release format (e.g., release-YYYY.MM.DD), Environment, Project, is Prod for production or non-production environments, and Application you need to track through the DevOps Intelligence Application. Here Application is optional; it will track all the applications in the project if not provided. [title] CodeQL configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ # Configuring Git CodeQLis an industry-leading semantic code analysis engine that enables the discovery of vulnerabilities across your codebase. Configure  to connect to CodeQL to pull security and vulnerability data from the security the security tool. Use the following guide. Before configuring for Code QL, you must first configure your Git applications. ## GitHub - **Name:** Local account name. It could be any string and is used only for reference. - **User:** Username for Git. Generally, the login email ID. - **Token:** Personal access token. Can be generated from the following\:settings --> developer options --> personal access token. Scope type Name Description repo - repo\:status - repo\_deployment - public\_repo - repo\:invite - security\_events - **Full control of private repositories** write\:packages read\:packages Download packages from GitHub Package Registry admin\:org read\:org Read organization and team membership, read organization projects admin\:repo\_hook read\:repo\_hook Read repository hooks admin\:public\_key read\:public\_key Read user public keys write discussion read\:discussion Read team discussions user - read\:user - user\:email - user\:follow :::Paragraph{indent="1"} Update ALL user data ::: - Provide repository permissions by navigating GitHub repository main page --> Settings --> Code security and analysis --> Access to alerts and typing the user's name in the search field, and click the correct user from the display list. ## GitHub Enterprise - **Name:** Local account name. Any string is valid; only for reference. - **Host:** Git API URL of the Git Host. For example, API url such as https\://github.abc.net/ - **User:** Username for GIT. Generally the email ID with which user logged in to Git. - **Token:**Personal access token. Can be generated from the following: Settings --> developer options --> personal access token The personal access token requires the following permissions: | **Scope type** | **Name** | **Description** | | ------------------------------------------- | --------------------------------------------------------------- | -------------------------------------------------------------------------- | | repo | * repo\:status * repo\_deployment * public\_repo * repo\:invite | Full control of private repositories | | admin\:org | read\:org | Read organization and team membership | | admin\:repo\_hook | - write: repo\_hook - read\:repo\_hook | Full control of repository hooks | | admin\:org\_hook | admin\:org\_hook | Full control of organization hooks | | notifications | notifications | Access notifications | | write discussion | read\:discussion | Read team discussions | | admin\:pre\_received\_hook | admin\:pre\_received\_hook | Control enforcement of pre-receive hooks for an organization or repository | - For both GitHub and GitHub Enterprise you must add a connection.  Click Admin --> IAM --> Connections --> **Add New** button. Select **Add Connection**. ## GitLab - **Name:** Local connection name. It could be any string and is used only for reference. - **User:** Username for GIT. Generally the email ID with which user logged in to GIT. - **Token:** Personal access token. Generated using the following: Settings --> access token The personal access token requires the API permissions ## GitLab Enterprise - **Name:** Local connection name. It could be any string and is used only for reference - **Host** Git API URL of the Git Host. For example, API url such as https\://github.abc.net/ - **User** Username for GIT. Generally the email ID with which user logged in to GIT - **ProxyID:**(Optional) Use UUID for Proxy Adapter - **Token:** Personal access token. Generate from settings --> access tokens The personal access token requires the API permission - For both GitLab and GitLab Enterprise you must add a DevOps Intelligence connection.  Click Admin --> IAM --> Connections --> **Add New** button. Select **Add Connection**. When the syncall is enabled, all the organization and repositories for which the user has access will be synced. # Configuring for Code QL, recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June 2024 or after. Procedures for legacy customers are provided in the subsequent section *Configuring * * for Code QL, legacy customers*. ::: Use the following procedure to configure the for Code QL: :::hint{type="info"} Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with Azure Pipeline as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure Azure Pipelines or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Build row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select **Scan** for **Secure Categories**. The service displays the **Tool Engine** field. 6. Select Code QL for **Tool Engine**. The service displays the release ID fields, which are prepopulated. 7. Click **Submit**. # Onboarding the Code QL technical service After configuring for Code QL, you must onboard Code QL as a technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Static Scan** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **Code QL** for **Tool Engine**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the Repository Name field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that has been fully configured for CodeQL. # Deleting Code QL as a technical service The administrator may, at will, delete the Code QL technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Secure**. 4. Click **Delete Technical Service**. 5. Click **Code QL** for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. # Configuring for Code QL, legacy customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded before 6 June 2024. ::: Prerequisite: Before configuring for CodeQL, ensure the proper roles have been assigned. The user must have the **view, create, update,** and **delete** roles respectively to view, create, update and delete the BYO template data. These roles are provided by default to the Editor. Only viewer role will be provided to the Viewer. Select the Organization name and Repository name to fetch the vulnerabilities from and Additional configurations for customizations, to create the configuration. Only organizations and repositories owned by user will be displayed in the dropdown. If there are no vulnerabilities in any repository or if code-scanning is not configured for that repository, then sync page shows error indicating that the "Endpoint data not found". [title] Appendix [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ # Glossary The following table describes common terms used in Service (BAS) and during the Automation Service (AS) to BAS migration process. | **Term** | **Definition** | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Catalog** | A published automation that can be executed on demand, through a schedule, or by an event trigger. | | **Category** | A logical grouping used to organize catalog items within the Orchestration Catalog. | | **Connection** | A configured endpoint and credential set that enables workflows to communicate with external systems, platforms, or services. | | **Domain-Specific Language (DSL)** | A JSON-based workflow definition that describes orchestration logic, workflow activities, execution flow, inputs, and outputs. | | **Event** | A trigger that automatically initiates a workflow when a predefined condition or notification is received from an external system. | | **Execution History** | A record of workflow executions that includes execution status, logs, timestamps, activity details, and outputs. | | **Input Parameter** | Information provided by a user or calling system when executing a catalog item or workflow. | | **Orchestration** | The coordinated execution of multiple automation activities to automate and manage business or operational processes. | | **Migration Report** | A report generated during the migration process that summarizes migrated, skipped, failed, and partially migrated assets. | | **Role** | A collection of permissions assigned to users that determines the actions they can perform within BAS. | | **Schedule** | A time-based trigger that automatically executes a catalog item or workflow at predefined intervals. | | **Tenant** | An isolated customer environment within BAS that contains its own users, roles, catalogs, workflows, schedules, event rules, and configurations. | | **Workflow** | A sequence of connected activities executed by BAS to automate a process or operational task. | | **Workflow Builder** | The visual authoring tool used to create and manage workflows without manually writing DSL code. | [title] [path] Services/Platform Services/ [title] Azure Resource Manager configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ # Access rights for Azure The account should have registration of the application of that particular subscription and have at least the **Read** access/role. For that purpose, a new key should be created. Then, the client Secret Key, Client ID and Tenant ID are used to create/configure an account in to pull data from Azure Cloud. Use the following procedure to create a client Secret Key respective Application Account for Azure Cloud: 1. Log in to the Azure portal using your Azure account: 2. Select **Azure Active Directory** from the left navigation. 3. Select the **App registrations** from the left panel on the **Default directory** page. 4. Select the **New Registration** option from the **App Registration** pane. 5. Type in the following information regarding the **Create** pane: | **Field** | **Description** | **Sample** | | ----------------------- | ---------------------------------------------------------------------------- | ---------------------------------------- | | Name | Name for the new application. Type in the desired application name. | GraphConnectorApp | | Redirect URI (optional) | Returns an authentication response after successfully authenticating a user. | [https://office.com](https://office.com) | 6. Select **Register**. The recently created application will be shown. 7. Edit the manifest file and change the value of the **oauth2AllowImplicitFlow** parameter to **true** after the application is created. 8. Select **Save**. 9. Add permissions. :::hint{type="info"} Note: The status for all permissions will turn green on adding the required permissions. ::: 10. Select the **Add** button of the **Create a Custom Role** section. 11. Create a **Custom role** and **Add** permissions according to his requirements. 12. Selects the **resource type**, **resource** and **Add Permissions** according to his requirements. 13. Selects **Review+Create.** # Generate secret key Use the following procedure to generate a secret key: 1. From **Azure Active Directory Admin Centre**, select the created Application from the list of App Registrations and **Create Certificates and Secrets **for the completed Application. 2. Log in to the Azure portal and select the created application name. 3. From the **Settings** pane, he selects the **Keys** option. 4. From the Keys pane, he types in the **Description**, selects the **Expiration** period and then selects the **Save** button. 5. From the **Keys** pane, copy the encoded key value, and select save. This key value cannot be retrieved after leaving this pane. This encoded key value is the client's Secret Key that will be a part of the authentication credential. 6. Add the **Created custom role** to the created Application. # Get tenant ID Use the following procedure to acquire the Tenant ID: 1. From Azure **Active Directory Admin Center**, navigate to the App Registrations pane. 2. Log in to the Azure portal and select the following menu selection: **Azure Active Directory** → **App Registrations**. 3. From **App Registrations** pane, click **Endpoints** option. 4. From the **Endpoints** pane, select the copy icon next to the **OAuth 2.0 Token Endpoint** option and **Save** the value. 5. Copy the value between microsoftonline.com/ and /oauth2/token from the copied endpoint URL. This is the Tenant ID that is part of the authentication credential. # Get the Client ID Use the following procedure to acquire the Client ID: 1. From **Azure Active Directory Admin Center**, open the created application. 2. Select the **Settings** option. 3. Log in to the Azure portal and select the created application name. 4. From the **Settings** pane, copy the **Application ID** value. This is the Client ID that will be part of the authentication credential. # Kyndryl connection 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → 2. On the dashboard, click the **Connections** tab from the left panel. 3. Select the **Add New** Drop-down menu. 4. Select the **Add a Connection**. 5. Select the Technology Category as **Cloud Provider**. 6. Select **Azure Cloud**. 7. Enter the *Account Number*, *Access Key Id*, and *Access Secret Key* from the Azure account referred to in the previous section. 8. Validate your credentials by selecting **Test connection**. 9. Once the connection is successful, select **Add** to create a connection. :::hint{type="info"} Even though it is shown as optional in the picture above, the "subscriptionId" column, along with the other obligatory values, is required to bring data for Azure clusters. ::: [title] Migration [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ This section describes how to migrate automation assets from Automation Service (AS) to Service (BAS) and validate the migrated content. ## Initiate the AS to BAS migration ### Prerequisites Before starting the migration, ensure that: 1. Dedicated CACF credentials have been created and configured in **Connections Management** as described in **Pre-migration**. 2. Automation service access groups have been migrated to Bridge IAM, and the corresponding BAS roles have been assigned to maintain the same level of access. | **Automation Service role** | **Bridge Automation Service role** | | --------------------------- | ---------------------------------- | | Administrator | Orchestration administrator | | Editor | Orchestration editor | | Operator | Orchestration operator | | Viewer | Orchestration viewer | ### Migrate Catalogs, Schedules, and Events from AS to BAS **Prerequisite:** Ensure that the user performing the migration has the Orchestration Administrator or Bridge Administrator role. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Catalogs** → **Orchestration Catalog **→ **Operations**. 2. In the **AIOPS Automation Services - Convergence** section, select **AIOPS Automation Services Migration** catalog item. 3. Run the catalog item to migrate the following AS assets to BAS: - Public catalogs - Private catalogs - Schedules - Events 4. Monitor the workflow execution and verify that the migration completes successfully. :::hint{type="info" indent="1"} Do not run multiple migration jobs simultaneously. Wait for the current migration job to complete before starting another migration. ::: ### Run the migration catalog item 1. Select **More actions** menu (**...**) from the **AIOPS Automation Services Migration** catalog item and select **Run**. 2. Select the appropriate version and connection. :::hint{type="info" indent="1"} Select the connection that was created using the dedicated CACF credentials in Bridge connections manager. ::: 3. On the **Parameters** page, click **Next** without entering any values. 4. On the **Target & Hosts** page, click **Next** without selecting targets or hosts. 5. On the **Review & Submit **page, click **Run.** ### Verify migration status 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Locate the **AIOPS Automation Services Migration** workflow, review the **Status** column to determine whether the migration is: Completed, Running and Failed. 3. To view execution details, select the **More actions** menu (**...**) and then select **View Details**. 4. Review the list view to view the status of migration steps. 5. The **Activities** tab helps identify completed, in-progress, and failed migration tasks. :::hint{type="info" indent="1"} If a migration activity fails, see [Troubleshooting and FAQ](docId\:MGuTf6Fg7sjvXHTN0eFHt). After the migration workflow completes successfully, the supported automation assets are available in BAS. ::: ## Public catalogs Public catalogs from AS are migrated to BAS, and: - Catalogs enabled in AS are automatically enabled in BAS. - All associated catalog configurations are migrated. - Migrated public catalogs appear in **Orchestration Catalog** with the **Global** label. - To activate a catalog, select the **More actions** menu (**...**) and then select **Activate**. ## Private catalogs Private catalogs from AS are migrated to BAS and enabled by default, and: - All associated catalog configurations are migrated. - Migrated catalogs are placed in the **Advanced Delivery – Single Owner Asset** category. - Catalogs are available from **Orchestration Administration**. ## Schedules Schedules from AS are migrated to BAS and are disabled by default. After migration: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to Services → **Schedules**. 2. Review the migrated schedule configuration. 3. Validate execution details, parameters, and target information. 4. Enable schedules only after validation is complete. 5. To view schedule details, select the **More actions** menu (**...**) and then select **View**. ## Events Event triggers from AS are migrated to BAS and are disabled by default. After migration: - Review each event configuration. - Verify trigger conditions. - Validate associated workflows and catalog mappings. - Enable events only after validation is complete. ### Migration behavior and limitations :::hint{type="info"} - Subsequent migration executions skip previously migrated items and migrate only newly added or changed assets from AS. If a migrated catalog must be recreated, retire the catalog before rerunning the migration. - All content and user authorizations that exist in the AS tenant are considered approved by the Delivery Platform Engineer (DPE). - Only GEMU-based automation content is migrated to BAS. ::: The following items are not migrated: - Legacy Automation Service content - GHES-based content - Schedules associated with excluded content - Events associated with excluded content This behavior is part of the content sanitization process defined by the Delivery COE. ## Verify migrated content After migration, verify that all expected assets are available and function correctly. ### Verify catalogs After migration, verify that all expected public and private catalogs have been migrated correctly and are available in Service (BAS). Validation helps ensure that catalog configurations were migrated successfully and that catalog items can be executed as expected. **Compare catalog counts** 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **My Automations, **record the number of Private catalogs and Public (Certified) catalogs. 2. In Bridge Automation Service, go to **Orchestration Catalog **and record the number of Catalogs in Advanced Delivery – Single Owner Asset (private catalogs) and Catalogs in Components with the Global - Enforced label (public catalogs). 3. Verify that the BAS catalog counts match the AS catalog counts. **Test migrated catalogs** 1. Open a migrated catalog. 2. Select **Run**. 3. Select the appropriate connection. 4. Provide credentials and inventory information as required. 5. Review any migrated parameter values. 6. Select **Run**. **To verify execution:** 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Select the **More actions** menu (**...**) and then select **View Details**. 3. Open the **Output Parameters** tab. 4. Verify that all activities completed successfully and produced the expected results. ### Verify schedules After migration, verify that all schedules have been migrated successfully and retain their expected configuration. Validation helps confirm that schedule counts, frequencies, and execution settings in BAS match those in Automation Services before schedules are enabled. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to Services → **Schedules**, record Schedule count and Schedule frequency. 2. Compare Schedule count and Schedule frequency. 3. Verify that Schedule counts and frequencies match. 4. Migrated schedules remain disabled until validated and approved. ### Verify events After migration, verify that all event-driven automations have been migrated correctly to BAS. Validation helps ensure that event rules, trigger conditions, workflow mappings, and input configurations are preserved and function as intended before event rules are enabled. 1. In the Automation Service main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Settings**. 2. Open the **Event Settings** section to review the DSS topics configured for event processing. 3. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **My Automations**. 4. Locate an automation that contains event-based execution settings, and then select **Set up**. 5. Open the **Automated Execution** section. 6. Review the event configuration and record the following information: - Trigger conditions - Associated automation - Input mappings - Event processing configuration 7. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to Services → **Event Rules**. 8. Locate the migrated event rule. 9. Select **View** to review the event rule configuration. 10. Verify that: - All expected event configurations have been migrated. - The trigger conditions match the original configuration in AS. - The associated workflow or catalog is correct. - Input mappings have been migrated correctly. - Migrated event rules are in the **Disabled** state, where applicable. :::hint{type="info" indent="1"} - Do not enable migrated event rules until the corresponding event-driven automation in Automation Service has been retired. Enabling event processing in both platforms can result in duplicate automation executions. - If any expected event rules are missing or configuration discrepancies are identified, document the details and notify the migration support team for further investigation before enabling the event rules for production use. For more information, see **Support**. ::: ## Migration reports ### Account eligibility and executive summary report The migration service validates each Automation Service account and its associated CACF instance to determine migration eligibility. The report includes account information such as: | Field | Description | | --------------------------------------- | ---------------------------------------------------------- | | Account Name | Account registered in | | ID | Unique account identifier | | ID | Unique account identifier | | Automation GSMA Code | GSMA code associated with the account | | BAC ID | BAC code associated with the account | | Country Name | Country or region associated with the account | | Active Runner Set (Y/N) | Indicates whether an execution platform is configured | | Convergence Eligibility (Y/N) | Indicates whether the account meets migration requirements | | Convergence Catalog Item Creation (Y/N) | Indicates whether the migration catalog item was created | **Migration execution results** The Migration execution results table provides a summary of migration and convergence activities. It includes details about execution history, workflow identifiers, request information, migration status, and the results of migrated assets such as access groups, catalogs, schedules, and events. | **Field** | **Description** | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Total Executions | Number of migration execution attempts | | Last Convergence Workflow ID | Most recent convergence workflow identifier | | Request Date | Date and time of the latest convergence request | | Requested By | User who initiated the convergence | | Status | Current or final migration status | | Converged Item Details | Results for access groups, public catalogs, private catalogs, schedules, and events.
For each migrated asset type, the report provides:
* Total * Success * Skipped * Error | **Cut-off workflow results** The Cut-off workflow results table provides information about the most recent cut-off workflow execution. It includes request details, workflow status, and the status of actions performed during the cut-off process, such as disabling Automation Service event settings and schedules, and enabling corresponding event rules and schedules. | **eld** | **Description** | | ----------------------------------- | ----------------------------------------------------- | | Last Cut-off Workflow ID | Most recent cut-off workflow execution | | Request Date | Date and time of the request | | Requested By | User who initiated the request | | Status | Current or final status | | Event Settings Disabled in AS (Y/N) | Indicates whether all AS event settings were disabled | | Schedules Disabled in AS (Y/N) | Indicates whether all AS schedules were disabled | | Event Rules Enabled in BAS (Y/N) | Indicates whether BAS event rules were enabled | | Schedules Enabled in BAS (Y/N) | Indicates whether BAS schedules were enabled | This report helps delivery teams and leadership validate migration readiness and track progress across migration phases. ### View detailed migration results Detailed migration results are available in the **Output Parameters** tab of the latest **AIOPS Automation Services Migration** workflow execution. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Open the latest migration workflow. 3. Select **View Details**. 4. Open the **Output Parameters** tab. Users can copy the output directly from the interface for further analysis or reporting. **Migration result statuses** For detailed information about migrated items, review the migration results in the following table. The table describes the migration status values and error conditions that can appear in the **Converged Items Details** section of the migration report. | **Status** | **Description** | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Total | Total number of migration-eligible items. Obsolete GHES-based Private and/or Public Catalog are excluded. | | Success | The item was successfully created in BAS. | | Skipped | The item already exists and was not recreated during the current migration execution.
**Examples:**
`"reason": "catalog_item_already_exists"`
`"reason": "schedule_already_exists"` | | Error | The item could not be migrated due to an error. Detailed error information is retained for troubleshooting.
**Examples:**
:::BlockQuote outcome failure: public catalog item "catalog\_item\_name" not found - it may not have synced down from KPC yet :::
:::BlockQuote outcome failure: catalog item "catalog\_item\_name" not found for automation "catalog\_item\_name" "reason": "unknown" ::: | [title] AWS CodeDeploy configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ Learn how to configure to retrieve data generated by AWS CodeDeploy, extending the single pane of glass DevOps Intelligence affords in your hybrid IT estate. Setting up and configuring an AWS connection is crucial to empowering to retrieve data from AWS CodeDeploy. This essential step bridges the two platforms, granting the capability to access and utilize the information stored within AWS CodeDeploy for subsequent analysis and operational enhancements. **Access rights**: The connection must have the following access roles: - **Create** - **Delete** - **Update** - **View** To access templates, you must have specific roles; please see: [User and role management](docId\:vy_2iguh1sL9qJU_qE6t_) # Configuration To establish the configuration, you must choose an Application Name, Deployment Group Name, and Additional Configurations for personalized settings. dashboards use specific terminology to indicate status: **Passed**, **Failed** and **In Progress**. However, you have the flexibility to introduce your own terms for these statuses. For instance, any term you input under the **Passed** category will be displayed as **Passed** on the dashboard. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Settings & Utilities **→ **Tools Configuration **→**Add configuration.** 2. The **Add tool configuration** form will be displayed; here, you will select: - **AWS CodeDeploy** from the **Tool Engine** dropdown menu. - Connection - Provider - Release name - Environment - Incident host URL 3. You must select **toggle on **or **off** if the configuration is for a **production environment.** 4. Select the **Application name** and the **Deployment group name.** 5. You can fill in the** Additional configuration for customization** section at the bottom of the form if you would like to personalize it with custom terms for **Passed**, **Failed** or **In progress** statuses. After completing the configuration, you can view the configuration details in the table on the configuration page. [title] Overview [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ provides a centralized view of software delivery, engineering performance, security posture, and operational insights across the lifecycle. By integrating data from development, build, test, deployment, repository, and security tools, the service enables teams to monitor software delivery processes, identify risks, and make informed decisions through a single, unified experience. With real-time visibility into key metrics, quality indicators, deployment activities, and security findings, helps organizations improve software quality, strengthen governance, and accelerate delivery. By eliminating information silos and consolidating critical data into actionable dashboards, the service enables teams to work more efficiently, respond faster to issues, and continuously optimize software development outcomes. # Accessing the DevOps Intelligence From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → ****. The service presents an overview page with graphics displaying the state of the following: - Secure alerts - DevOps performance metrics: - Change lead time - Deployment frequency - Security posture - Develop - Issues and defects - Build - Test - Deploy - Deployment status :::hint{type="info"} Depending on your selections from these filters, the data displayed in the widgets varies and some widgets may show the message *“No Data Available”*, which means there is no recent data available for your selection. ::: Refer to the [Connections Management](docId\:hR8jAv4KVMPk5N8nuq1Sf) page for details on how to configure the connections that will allow data to be viewed in the aforementioned displays. More detailed information is available at the following modules, which are documented at the respective links for each: - [Secure module](docId\:Sb6Uv3yvrY0W4mrfBWQBG) - [Develop module](docId\:CEPYZGy-76ZC-RJsnZ6qa) - [Dora metrics](docId\:I2CiIGRS_sU6uk7IRDGBE) - [Build module](docId\:asbV8eUZsMJWgNBB0t38L) - [Test module](docId\:nze11GYc6K54iLPImbmPY) - [Deploy module](docId:7rL1T7L4pAbzWS84eXcfE) # user interface elements The header provides quick access to navigation, filtering, and dashboard management tools. These controls help you customize the information displayed on the page, focus on a specific time period, and save personalized views for future use. The header is available throughout the service, allowing you to easily navigate between pages, refine the displayed data, and manage dashboard configurations without leaving your current view. The header contains the following elements: - **Breadcrumbs**: Show your current location within and enable you to quickly navigate back to previous pages. - **Page title**: Identifies the dashboard or module currently being viewed. - **Duration filter**: Lets you select the time range used to display historical data. Available options include 1, 7, 14, 30, 60, 90, and 180 days, as well as a custom date range. - **Date and Time stamp** (corresponding to the duration selected). - **Dashboard view**: The dashboard view enables viewing control of the landing page. Among other options, you can choose the amount of data to display: - **All Data:** choose this option to view all the data in accordance with the historical time frame you selected in **Selection duration**. - **60 days:** The overview page displays up to **60 days** of the data you selected in **Selection duration**. If you selected 60 days or fewer, the page displays all data. If you selected more than 60 days, only the last 60 days are displayed. - **AC-Duration Test:** All data in the acceptance test pipeline. - Dashboard view filter (toggle icon): As you filter data in the page, you have the option of saving the current dashboard view. When the view is saved you can click the toggle icon on the Dashboard view to display dashboard options from a drop-down list and further filter it by application: - **Dashboards:** Select a dashboard to view data specific to applications. - **Applications:** Select the applications you want to view for the selected dashboard. Comprehend the health of cloud services such as CAM and Enterprise Marketplace. - **View settings (dashboard view controls**): - **Delete View**: After saving a dashboard view, you can delete it by selecting the Dashboard view and then clicking the **Delete View** button. - **Clear View**: After filtering data in the current view, you can clear the filters and return the dashboard to the default view by clicking **Clear View**. - **Update View**: After changing the filter settings in the current dashboard, you can you can update the current dashboard view by clicking **Update View**. - **Save New View**: After filtering data you can save the current dashboard view with a name for later reference using the previously described **Dashboard View** feature by clicking **Save New View**. - **Display details**: Each display contains an arrow in the upper right corner. Click the arrow to display a detailed data presentation. To return to the previous view, click the page title in the breadcrumbs or the page listing in the left navigation bar. # Table views In some detail views, the application displays tabular data and, in that circumstance, table controls, labeled table settings, are available. The application displays a settings **Toggle** icon (gear) above the top right corner of the of the table. Click the **Toggle** icon to display the available table settings. The table settings comprise a matrix of check boxes, which are filters that determine what data is displayed in the table, including whole columns. click the checkboxes to make any necessary adjustments and click one of the following buttons: - **Cancel** to abort your selections - **Reset** to return the settings to their default values - **Apply** to apply your changes A search icon (magnifying glass) is available directly to the left of the gear icon. To search the table for a string, click the search icon. The application displays a search field in which you can enter a search string such as an application name. Enter a string. The table automatically display only entries containing that string. To terminate the search display, click the **x**, which has replaced the **Search**, next to the **Toggle** icon. # Navigation panel (left navigation bar) is the access point for the seven modules enumerated in the Introduction of this page. To access these modules, hover the mouse cursor over the home icon, to reveal navigation options within . - [Glossary of terms](docId:0L7sCt0lDQ0pmp0zDMTSG) Learn definitions of critical terms used throughout the DevOps user documentation. [title] Mapper configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Supported tools/Tools Configuration/ A mapper is a configuration mechanism used to map data fromsecurity and development tools into so that scan results, vulnerability data, andrelated information can be accurately processed and ingested. Mappers define how tool-specific data is interpreted, including required configuration fields, supported formats, andoptional parameters that customize integrations and vulnerability data processing. this guide contains the available mapper-supported phases, supported secure tool subcategories, and the required configuration details for each type. It also describes optional fields and additional parameters that can be used to customize integrations and vulnerability data processing. Use this information to ensure accurate tool mapping andsuccessful ingestion of scan results. supports mappers for the following phases: supports the mappers for the following phases: - Secure - Build - Deploy - Test These selections are made from a dropdown menu in the Tool Category field. Develop category of tools as supports most of the leading tools in this category out of the box. Develop doesnot support mappers through the service user interface, but can accommodate them through the use of private APIs. To add a Develop wrapper, please contact your Kyndryl representative. # Secure The Secure category requires the specification of a tool subcategory that is associated with the type of activity being performed. The following tool subcategories are supported: - Dependency Check - Static Scan - Image Scan - License Scan The required procedure varies with each subcategory. Subsequents sections provide the required procedure. ## Dependency Check The user is required to populate the Technical Service Name field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional Option field contains is not required but supports two options: - **PROVIDER HREF**: This field is for the user to enter the URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing Dependency Check scans. In the `Dependency Check Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. ## Static Scan The user is required to populate the `TECHNICAL SERVICE NAME` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional Option field contains is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing Dependency Check scans. In the `Static Scan Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. ## Image Scan The user is required to populate the `IMAGE NAME` and `TECHNICAL SERVICE NAME` fields. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional option info field is not requrired, but it supports four options: - **RELEASE NAME**: This field is for the user to enter the name of the release that is being scanned. - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **SCANNED TIME**: This field is for the user to enter the time when the scan was performed. These fields provide additional information about the scan and can be useful for tracking and managing vulnerabilities. In the `Imagescan Run` body, the user can copy and paste the complete vulnerabilities response. This allows the system to process the entire set of vulnerability data at once. ## License Scan For the 'Tool Sub Category' is `License Scan`. The user is required to populate the `TECHNICAL SERVICE NAME` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional option info field is not required, but it supports three options: - **PROVIDER HREF**: This field is for the user to enter URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **SCANNED TIME**: This field is for the user to enter the time when the scan was performed. :::hint{type="info"} If the status from the tool is not provided or does not match any of the known statuses, it will be mapped to "UNKNOWN" on the DI Dashboard. ::: These fields provide additional information about the scan and can be useful for tracking and managing License scans. In the `License Scan Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. # Build The user is required to populate the `Technical Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their build data. Completing the `Additional option info` is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing build runs. In the `Build Run` body, the user can copy and paste the complete build runs response. This allows the system to process the entire set of vulnerability data at once. # Deploy The user is required to populate the `Technical Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their deployment data. Completing the `Additional option info`, but it supports seven options: - **PROVIDER**: This field is for the user to enter the name of the provider, which can be a comma-separated list if there are multiple providers. - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **ISPRODUCTION**: This field is for the user to specify whether the environment is a production environment (`true`) or not (`false`). - **ENVIRONMENT NAME**: This field is for the user to enter the name of the environment, which can be a comma-separated list if there are multiple environments. - **RELEASE NAME**: This field is for the user to enter the name of the release. - **INCIDENT HOST URL**: This field is for the user to enter the URL of the host where the incident occurred. These fields provide additional information about the Deployment and can be useful for tracking and managing Deployment data. In the `Deployment Run` body, the user can copy and paste the complete deployment runs response. This allows the system to process the entire set of vulnerability data at once. # Test The user is required to populate the `Techincal Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their deployment data. Completing the `Additional option info` is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing test cases. In the `Test Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. # Develop No UIsupport is available for Devlop mappers. Users can directly select the `Tool Sub Category` and map the endpoint response body values to the keys provided in the `Develop Run` body. This means that the user must manually ensure that the values in the endpoint response match the keys described in the `Develop Run` body. The tool subcategory dropdown presents three selections: - Issues - Pull Request - Commit ## Issues The following keys are supported: - **assignees**: An array of usernames who are assigned to the issue. - **category**: The category of the issue (e.g., "bug", "issue", etc.). - **created\_at**: The date and time when the issue was created. - **created\_by**: The username of the person who created the issue. - **description**: A brief description of the issue. - **endpoint\_hostname**: The hostname of the endpoint where the issue is located. - **fixed\_releases**: An array of release versions where the issue has been fixed. - **found\_releases**: An array of release versions where the issue was found. - **issue\_engine**: The engine used to track the issue. - **issue\_type**: The type of the issue (e.g., "Story", "Task", etc.). - **labels**: An array of labels associated with the issue. - **priority**: The priority of the issue (e.g., "High", "Medium", "Low"). - **provider\_engine**: The engine of the provider. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **provider\_url\_key**: The URL key of the provider. - **scmhost\_url**: The URL of the source code management host. - **severity**: The severity of the issue. - **state**: The current state of the issue (e.g., "open", "closed"). - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. - **title**: The title of the issue. - **updated\_at**: The date and time when the issue was last updated. :::hint{type="info"} Ensure that the values in issues response match the keys described above. Each key-value pair in response should correspond to a field in the issue. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `issue_creator`, you should map it to the `created_by` key in the list above. This means that the value of `issue_creator` in your response becomes the value for created\_by in the final data that you post here. ::: ## Pull Request The following keys are supported: - **created\_at**: The date and time when the pull request was created. - **created\_by**: The username of the person who created the pull request. - **description**: A brief description of the pull request. - **endpoint\_hostname**: The hostname of the endpoint where the pull request is located. - **endpoint\_technical\_service\_id**: The ID of the technical service at the endpoint. - **ischerrypick**: A boolean value indicating whether the pull request is a cherry-pick. - **merge\_commit\_sha**: The SHA of the merge commit for the pull request. - **merged\_at**: The date and time when the pull request was merged. - **pr\_engine**: The engine used to track the pull request. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **pull\_number**: The number of the pull request. - **release\_name**: The name of the release that the pull request is associated with. - **state**: The current state of the pull request (e.g., "open", "closed"). - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. - **title**: The title of the pull request. - **updated\_at**: The date and time when the pull request was last updated. :::hint{type="info"} Ensure that the values in the pull request response match the keys described above. Each key-value pair in the response should correspond to a field in the pull request. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `pr_creator`, you should map it to the `created_by` key in the list above. This means that the value of `pr_creator` in your response becomes the value for `created_by` in the final data that you post here. ::: # Commit The following keys are supported: - **comments**: The comments associated with the commit. - **commit\_url**: The URL of the commit. - **created\_at**: The date and time when the commit was created. - **created\_by**: The username of the person who created the commit. - **endpoint\_hostname**: The hostname of the endpoint where the commit is located. - **endpoint\_technical\_service\_id**: The ID of the technical service at the endpoint. - **parent\_ids**: An array of IDs for the parent commits. - **provider\_engine**: The engine used to track the commit. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **release\_names**: An array of names of the releases that the commit is associated with. - **scm\_engine**: The engine used for source code management. - **sha**: The SHA of the commit. - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. :::hint{type="info"} Ensure that the values in the commit response match the keys described above. Each key-value pair in the response should correspond to a field in the commit. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `commit_creator`, you should map it to the `created_by` key in the list above. This means that the value of `commit_creator` in your response becomes the value for `created_by` in the final data that you post here. ::: [title] GitHub Actions configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ GitHub Actions enables the automation of tasks and processes in their Build and Deploy workflows, providing insights into these phases of the DevOps lifecycle. Developers can define custom workflows using YAML syntax, which can be triggered by events such as code pushes, pull requests, or scheduled intervals. captures all workflows in Github Actions and retrieves them. This data is then processed and displayed in the form of graphs and tables on the Build and Deploy pages. # Integration of GitHub Actions in pulls data from GitHub Actions such as Build and Deploy details, including its unique identifier, status, time stamp, duration and cause. The process for onboarding GitHub actions comprises the following steps, each of which is a multistep procedure: 1. Crate a Personal Access Token. 2. Create a connection. 3. Configure the application for two supported DevOps phases: 1. Build 2. Deploy 4. Onboard the GitHub Actions technical service. ## Create a personal access token Use the following procedure to create a Personal Access Token: 1. Navigate to your GitHub homepage. 2. Go to **User settings** → **Developer settings** → **Personal Access Tokens** → **Generate new token**. 3. Ensure the token has read permissions on the org/repo intended to sync. ## Create a connection To pull data from GitHub Actions, you must establish a connection between DevOps Intelligence and GitHub Actions. Use the following procedure: 1. **Click on Settings** → **Service IAM** → **Connections** → **Add New** → **Add connection**. :::Paragraph{indent="1"} Complete the form: ::: :::Paragraph{listStyleType="decimal" listRestartPolite="1" indent="2"} For Content Provider, select GitHub. ::: :::Paragraph{listStyleType="decimal" listStart="2" indent="2"} For Name, enter local account name for reference. ::: :::Paragraph{listStyleType="decimal" listStart="3" indent="2"} For Name, enter local account name for reference. ::: :::Paragraph{listStyleType="decimal" listStart="4" indent="2"} For Host Git API, enter the URL of the Git Host (e.g., https\://github.test.net). ::: :::Paragraph{listStyleType="decimal" listStart="5" indent="2"} For User, Populate this field with the same username that you use for your GitHub account. ::: :::Paragraph{listStyleType="decimal" listStart="6" indent="2"} For User, Populate this field with the same username that you use for your GitHub account. ::: :::Paragraph{listStyleType="decimal" listStart="7" indent="2"} For User, Populate this field with the same username that you use for your GitHub account. ::: :::Paragraph{listStyleType="decimal" listStart="8" indent="2"} For Token, use the PAT token created in Create Token step. ::: :::Paragraph{listStyleType="decimal" listStart="9" indent="2"} If you are using a Proxy Adapter to access through an intermediary layer, Enter the UUID for the adapter in the Proxy ID field. ::: :::hint{type="info"} When Archive is enabled, the connection is archived for future use. ::: ## Configuring for GitHub Actions and recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent section Configure for GitHub, legacy customers. ::: supports GitHub Actions for two DevOps phases: - Build - Deploy ### Build Use the following procedure to configure GitHub Actions for the Build phase: 1. **Click on Settings & Utilities** → **Application Configuration**. 2. Navigate to the **Add Tools** step. 3. Select the phase as **Build**. 4. Press **Add Tool Configuration**. 5. For **Tool engine**, select **GitHub Actions**. Complete the form for both tabs (Refer to **Note** directly following this list: 1. **Workflow Jobs** 2. **Status** 3. Click **Add Configuration**. :::hint{type="info"} - Enable **Workflow Jobs** to builds from all workflow jobs irrespective of workflow job name. - Enable **Workflow Job Names** to enable job names for which build data is needed. - The **Status** data from the source is mapped to the specific categories as **Passed**, **Failed** and **In Progress**. ::: ### Deploy Use the following procedure to configure GitHub Actions for the Build phase: 1. **Click on Settings & Utilities** → **Application Configuration**. 2. Navigate to the**Add Tools** step. 3. Select the phase as **Deploy**. 4. Press **Add Tool Configuration**. 5. For **Tool engine**, select **GitHub Actions**. 6. Complete the form for the three tabs (Refer to **Note** directly following this list: 1. **Release and Environment** 2. **Status** 3. **Incident mapping** 7. Click **Add Configuration**. - For **Release and Environment**: - Release Prefix signifies the starting sequence of characters for releases, with the default value being empty. - Release Variable signifies the starting sequence of characters for releases, with the default value being empty. - Environment Prefix signifies the starting sequence of characters for environment, with the default value being empty. - Environment Name environment name where your application is deployed. - Environment Field signifies the field from where environment name has to be picked from. Ex: env - Release Field signifies the field from where incident release name has to be picked from. Ex: env - Map your production environment signifies the environment used for production deployments. :::Paragraph{indent="1"} The tool configuration inherits the release prefix, variable & Environment prefix, name from the application. To override these values only for this configuration, click the Edit button and make the necessary changes. Please note that changing the values here will not impact the release prefix and variable set in the application. ::: - The **Status** data from the source is mapped to the specific categories as **Passed**, **Failed** and **In Progress**. - For **Incident Mapping**, the Host URL of Incident management tool used to monitor incidents if any arising out of application deployment issues. For example ServiceNow ## Onboard the GitHub Actions technical service You must now onboard the technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application and click on **Onboard Technical Service**. 3. Select the phase for which you want to configure **GitHub Actions**. The page displays only the phases for which this tools has been configured for the application. 4. Select the tool engine as **GitHub Actions**. 5. For **Connection**: Select the appropriate connection name from the drop down. :::hint{type="info"} Select **Provider** only in the Deploy phase for the current deployment. ::: supports the following types of GitHub tracking: - Organization - Repository ### Organization Tracking To track Organizational data, use the following procedure: 1. Select Tracking Type **Organization**. 2. Select the appropriate organization. 3. Click**Onboard** to onboard the technical service. ### Repository Tracking To track Organizational data, use the following procedure: 1. Select Tracking Type - **Organization** and **Repository**. 2. Select the appropriate organization. 3. Select the appropriate repository. 4. Click **Onboard** to onboard the technical service. :::hint{type="info"} For GitHub Enterprise accounts, if the administrator has set a limit on API calls, will optimize its process of fetching data and will execute approximately 1000 calls each hour. This is to make sure no other task using the credentials are hampered. Once the limit is exceeded display a message on the GitHub`sync` page. ::: ## Deleting the GitHub Actions technical service The administrator may, at will, delete the GitHub technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configurations.** 2. Expand the application to see all the associated phases. 3. Click the Overflow menu associated with the phase (**Build** or **Deploy**). 4. Click **Delete Technical Service**. The service responds by displaying a form. 5. Completed the form. 6. For Tool engine, select GitHub Actions. 7. Select the appropriate Organization. 8. Select the appropriate repository. 9. Click **Delete** at the bottom of the form. # Configuring for GitHub Actions and legacy customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded before 6 June, 2024. ::: Use the following procedure to configure for SonarQube: 1. Navigate to → **Settings & Utilities** → **Tools Configuration** → **Add Configuration**. 2. Select GitHub Actions as the **Tool Engine**. 3. Under **Connection**, select the appropriate connection name. 4. Select the project and metrics you want to track in Note: Additional configurations are provided to manage the status, including **Passed**, **Failed** and **In Progress**. [title] Bring your own license [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ Secure Page displays vulnerability information for static scans and licensing compliance. Static scan displays vulnerabilities from SonarQube and licensing data from license finder. The secure feature is only available in premium package. Licenses may also be submitted from other tools to Secure using the APIs described in subsequent sections. # Bringing data into To bring your own Deploy tools complete the following steps: 1. Go to the  Tools Configuration page and navigate to the Tokens tab. 2. Click on Create Token and give a unique Token name. 3. Select Token Type as Develop, then click on the Create button. 4. A new entry will be added to the table. In the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example:** ```javascript TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX ``` **Step 2:  API Reference** **API : /services/licenses?scannedBy=license\_finder\&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37** **URL: https\://\{devops-intelligence-host}/dash/api/build/v1/services/licenses?scannedBy=license\_finder\&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37** **Parameters** | **Parameter** | **Type** | **Exaplanation** | **Example Value** | | ------------------------------------------ | ------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | | scannedBy\* | Query Parameter | Tool which is used to scan the Licenses of the repositories | license\_finder | | scannedTime\* | Query Parameter | The time at which Licenses are scanned and time(2006-01-02T15:04:05.999999999Z07:00) should be URL encoded | 2021-06-28T12%3A07%3A29.104834%2B05%3A37 | | build \* | BODY | Build Data in Json | | ```javascript [{ "dependency_name": "github.com/Luzifer/go-openssl/v3", "dependency_version": "v3.1.0", "dependency_homepage": "github.com/Luzifer/go-openssl", "dependency_install_path": "/Users/anilsahu/go/pkg/mod/github.com/!luzifer/go-openssl/v3@v3.1.0", "dependency_package_manager": "Go", "license_name": "Apache 2", "status": "Allowed", "license_link": "http://www.apache.org/licenses/LICENSE-2.0.txt", "provider_href": "https://github.kyndryl.net/", "service_name": "MCMP-DevOps-Intelligence/dev_secops", "serviceoverride": true }] ``` ## cURL example **Request** ```curl curl --location --request POST 'https://{devops-intelligence-host}/dash/api/build/v1/services/{serviceName}/licenses?scannedBy=license_finder&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37' \ --header 'Authorization: TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX' \ --header 'Content-Type: application/json' \ --data-raw '[{ "dependency_name": "github.com/Luzifer/go-openssl/v3", "dependency_version": "v3.1.0", "dependency_homepage": "github.com/Luzifer/go-openssl", "dependency_install_path": "/Users/anilsahu/go/pkg/mod/github.com/!luzifer/go-openssl/v3@v3.1.0", "dependency_package_manager": "Go", "license_name": "Apache 2", "status": "Allowed", "license_link": "http://www.apache.org/licenses/LICENSE-2.0.txt", "provider_href": "https://github.kyndryl.net/", "service_name": "MCMP-DevOps-Intelligence/dev_secops", "serviceoverride": true }]' ``` **Response 200** ```curl "Total Number of records inserted successfully is 1" ``` ## Secure-License request body explained | **Field** | **Data Type** | **Exaplanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | dependency\_name | string | Name of the package | github.com/Luzifer/go-openssl/v3 | | dependency\_version | string | Version of the package used | v3.1.0 | | dependency\_homepage | string | Home URL of the package | github.com/Luzifer/go-openssl | | status | strin | Status of license | Allowed, Denied, NeedApproval | | dependency\_install\_path | string | Location of package installed in system | /Users/anilsahu/go/pkg/mod/github.com/!luzifer/go-openssl/v3\@v3.1.0 | | dependency\_package\_manager | string | Package manager of dependency | Go | | license\_name | string | License which is used by package | Apache 2 | | license\_link | string | URL of license home page | http\://www\.apache.org/licenses/LICENSE-2.0.txt | | provider\_href | string | Provider URL on which license is scanned | https\://github.kyndryl.net/ | | details | string | Additional details if any to be provided with the build(raw json file contents) | Raw JSON | | service\_name\* | string | serviceName is a repository in on which License scan runs(repo name) | MCMP-DevOps-Intelligence/dev\_secops | | serviceoverride | boolean | Override flag for the service | true | [title] Post Migration [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ ## Cutoff Process The cut-off is the final step in migrating an account from Automation Services (AS) to Services (BAS). It should be performed only after all migrated workloads have been reviewed and validated and the account has provided migration sign-off. ### Prerequisites Before initiating the cut-off process, ensure that: 1. You have permission to execute the **Automation Services Cut Off** catalog item. 2. Migrated public and private catalogs have been validated successfully. 3. Migrated schedules and event-driven automations have been validated. 4. Migration results have been reviewed. 5. The account has provided migration sign-off. 6. Migration readiness and validation status have been updated in the customer migration tracker. The tracker includes stages for content validation, schedules and events validation, migration report validation, and cutover readiness. :::hint{type="info"} The cut-off process transitions automation operations from Automation Services to Service. After cut-off is completed, legacy schedule-based and event-driven automation capabilities in AS are disabled. ::: ### Initiate the Cut-Off When the **AIOPS Automation Services migration** catalog item is executed for the first time, the **AIOPS Automation Services Cut Off** catalog item is automatically created and activated for the account. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Catalogs** → **Orchestration Catalog**. 2. Locate **AIOPS Automation Services Cut Off**. 3. Select the catalog item. 4. Select **Run**. 5. Review the execution details. 6. Click **Submit** to start the cut-off process. :::hint{type="info"} The cut-off operation runs at the account level and affects all migrated automation assets associated with the account. ::: ### Verify the Cut-Off When the cut-off process starts, a new workflow execution record is created in **Workflow Executions**. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Locate the **AIOPS Automation Services Cut Off** workflow execution. 3. Monitor the execution status until the workflow completes. 4. Review workflow logs, activities, and output parameters. 5. Verify that all cut-off activities completed successfully. For detailed instructions on viewing workflow execution details, see **Verify migration status**. ### Validate Cut-off results After the workflow completes successfully, verify that: - Migrated schedules are enabled and operational in BAS. - Migrated event rules are enabled and operational in BAS. - Legacy schedules in AS are disabled. - Legacy event-driven automation capabilities in AS are disabled. - Migration reports reflect the account's cut-off status. The cut-off status and execution information are also reflected in the migration report. :::hint{type="info"} The cut-off does not affect the **EPSA** or **KIRS** programs. API requests to Automation Services continue to function normally. ::: [title] Visual Workflow Builder [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/ ## Overview Visual Workflow Builder is used to create automation workflows through a visual interface without manually writing Domain-Specific Language (DSL) code. Add triggers and activities to the workflow canvas, configure their properties, review the generated DSL, and publish the workflow as a reusable catalog item. Benefits The Visual Workflow Builder helps you: - Create workflows without extensive DSL knowledge. - Add and configure workflow steps through a visual interface. - Generate DSL automatically from the workflow configuration. - Review the generated DSL before publishing. - Publish workflows as reusable catalog items for tenant users. ## Prerequisites Before you create a workflow, make sure that: - You have access to Bridge Automation Service. - You have the required permissions to create and publish workflows. - The required provider connection is available for the activities that you want to use. - You have the parameter values required by the selected activities. ## Access the visual workflow builder 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Bridge Automation **→ **Orchestration Administration → Visual Workflow Builder**. 2. The Workflow Builder page opens. ## Visual workflow builder interface The Workflow Builder provides a workflow canvas and a library of available workflow components. The following table describes the main interface elements: | **Interface element** | **Description** | | --------------------- | ------------------------------------------------------------------------------------------------ | | **Workflow name** | Displays the name of the workflow. A new workflow can initially appear as **Untitled Workflow**. | | **Step Library** | Contains the available triggers, control-flow elements, catalogs, and activities. | | **Search** | Helps you find an item in the Step Library. | | **Filter** | Filters the items displayed in the Step Library. | | **Workflow canvas** | Provides the workspace where you add and connect workflow components. | | **Publish** | Publishes the configured workflow as a catalog item. | | **Save for Later** | Saves the workflow as a draft so that you can continue editing it later. | :::hint{type="info"} The availability of library items can depend on the configured providers and connections. ::: ## Workflow components A workflow consists of a trigger followed by one or more activities. You can also add control-flow elements to define conditional processing. - **Triggers:** A trigger defines how a workflow starts. A trigger can represent: - A human action - An event - A schedule - The completion of another workflow :::Paragraph{indent="1"} When you add a trigger, configure the applicable properties, such as: ::: :::Paragraph{listStyleType="disc" indent="2"} Name ::: :::Paragraph{listStyleType="disc" indent="2"} Label ::: :::Paragraph{listStyleType="disc" indent="2"} Description ::: :::Paragraph{listStyleType="disc" indent="2"} Input parameters ::: :::Paragraph{listStyleType="disc" indent="2"} Default values ::: :::Paragraph{listStyleType="disc" indent="2"} Required connections ::: :::hint{type="info" indent="1"} Add a trigger before adding an activity. Activities remain unavailable until the workflow contains a trigger. This requirement prevents the creation of an activity that does not have a valid starting point. ::: - **Control flow: **Control-flow elements define how a workflow proceeds based on configured conditions. Use these elements to add conditional routing or branching to a workflow. - **Catalogs: **The Catalog section provides reusable catalog components when applicable catalog items are available. - **Activities:** An activity performs an automation operation. The available activities are organized by supported channels or providers, which can include: - AWS - Azure - GitHub - Terraform :::Paragraph{indent="1"} Drag an activity from the Step Library to the workflow canvas, and then configure its required parameters. ::: ## Create a workflow Create a workflow by adding a trigger to the canvas, configuring the trigger, and then adding the required activities: 1. Add and configure a trigger 2. Open Workflow Builder. 3. Create a new workflow. 4. In the Step Library, expand Triggers. 5. Drag the required trigger to the workflow canvas. 6. Enter the trigger name, label, and description. 7. Configure the required input parameters and default values. 8. Select the required connection, if applicable. 9. Save the trigger configuration. After you configure the trigger, the applicable activities become available in the Step Library. **Add an activity** 1. In the Step Library, locate the required activity. 2. Drag the activity to the workflow canvas. 3. Place the activity after the trigger or the preceding workflow step. 4. Configure the required activity properties. 5. Select the connection that the activity uses. 6. Configure the failure behavior. 7. Save the activity configuration. Repeat these steps to add other activities or control-flow elements to the workflow. :::hint{type="info"} Use meaningful names and descriptions for the workflow and its components. Clear names help other users understand the purpose of each step. Example: Create an AWS S3 bucket workflow. ::: This example uses a human trigger and an AWS activity to create an Amazon S3 bucket. 1. Add a human trigger 2. In the Step Library, expand Triggers. 3. Drag the human trigger to the workflow canvas. 4. Configure the trigger name, label, description, and required inputs. 5. Save the trigger configuration. 6. Add the AWS S3 bucket activity 7. Locate the AWS S3 bucket creation activity in the Step Library. 8. Drag the activity to the workflow canvas. 9. Add the activity after the human trigger. 10. Configure the activity properties. The following table describes the demonstrated properties: | **Property** | **Description** | | -------------------- | ------------------------------------------------------- | | **Bucket name** | Specifies the name of the S3 bucket to create. | | **AWS region** | Specifies the AWS region in which to create the bucket. | | **Activity ID** | Identifies the activity within the workflow. | | **Failure behavior** | Defines the workflow behavior if the activity fails. | | **Connection** | Specifies the account in which the activity runs. | The selected connection determines the target account. The selected AWS region determines where the S3 bucket is created. :::hint{type="info"} Verify the connection and region before you publish or run the workflow. An incorrect connection or region can direct the operation to an unintended account or location. ::: ## Review the generated DSL The Visual Workflow Builder automatically translates the visual workflow configuration into DSL. Use the code view to verify that the generated definition contains the expected values. To review the generated DSL: 1. Complete the trigger and activity configuration. 2. Open the code view. 3. Review the generated DSL. 4. Verify that values such as the S3 bucket name and AWS region match the visual configuration. 5. Return to the visual view to correct any configuration, if required. Note: You do not need to write the DSL manually when creating the workflow visually. 6. Save a workflow as a draft 7. Use Save for Later when the workflow is not ready to publish. 8. Configure the available workflow components. 9. Select Save for Later. 10. The workflow remains in Draft status so that you can continue editing it. ## Publish a workflow Publish a completed workflow to make it available as a catalog item: 1. Complete the workflow configuration. 2. Review the generated DSL. 3. Select Publish. 4. Enter the catalog name. 5. Enter the version. 6. Select a catalog type: - Provisioning - Operations 7. Select an existing category. 8. Enter a description. 9. Complete the publish action. After publishing, the workflow appears in Orchestration Administration with information such as: - Catalog item type - Access scope - Category - Default version - Onboarding date - Publication status A successfully published workflow displays the Published status and becomes available for use by other authorized users in the tenant. ## Edit a published workflow 1. Open a published catalog item to update its workflow configuration. 2. Open Orchestration Administration. 3. Locate the published catalog item. 4. Open the item for editing. 5. Update the workflow parameters or related configuration. 6. Update the version, if required. 7. Save and publish the updated item. :::hint{type="info"} Confirm the versioning requirements before updating a published workflow. The meeting notes indicate that users can change versions, but they do not define the required versioning convention. ::: [title] Build [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Build supported tools provide visibility into the overall health and performance of your build processes by tracking build status, success rates, and related metrics across supported integrations. Using configurable filters such as Organization, Applications, and Teams, you can analyze build data across service providers and gain centralized insights into your development and delivery workflows. # Supported tools - [AWS CodeBuild](docId\:ETrkyCUWzAo2X5FcmI-Gd): Monitor build jobs, execution status, and build performance from AWS CodeBuild to gain visibility into your CI workflows. - [Azure Pipeline Build](docId\:unXS32Nf4Sg6NxynH43qj): Track build executions, success rates, and pipeline metrics from Azure Pipelines Build. - [Jenkins Plugin](docId\:yTBqyzjCxLqaw8gRQW2ZV): Collect build and pipeline data from Jenkins to monitor build health and analyze CI performance. - [JFrog Artifactory](docId\:m2QAQnjRQbXqvVzUoj5Zq): Integrate artifact repository data to improve visibility into build artifacts and package management. - [GitHub Actions](docId\:W8Cz7-szyCTIJXC6-7fiQ): Monitor workflow runs, build results, and automation metrics from GitHub Actions. # Configuration guides - [AWS CodeBuild configuration](docId\:ETrkyCUWzAo2X5FcmI-Gd): Configure the AWS CodeBuild integration to collect build data and monitor build performance in DevOps Intelligence. - [AWS CodePipeline configuration](docId\:pLUvy2ZVxQd_s0C0MwTUt): Configure the AWS CodePipeline integration to track pipeline execution, delivery status, and deployment metrics. - [Azure Pipelines configuration](docId\:unXS32Nf4Sg6NxynH43qj): Configure the Azure Pipelines integration to collect build and pipeline metrics for centralized visibility. - [Azure Release Pipelines configuration](docId\:L_TVePMo5lsOSe3ycUuDM): Configure the Azure Release Pipelines integration to monitor release execution and deployment activity across environments. - [Jenkins Plugin configuration](docId\:yTBqyzjCxLqaw8gRQW2ZV): Configure the Jenkins Plugin to send build and pipeline data to DevOps Intelligence for centralized reporting and analysis. - [GitHub Actions configuration](docId\:W8Cz7-szyCTIJXC6-7fiQ): Configure the GitHub Actions integration to collect workflow, build, and deployment metrics from your GitHub repositories. - [SonarQube Enterprise Edition configuration](docId\:l6KMPPnIuAPFxsi9MEE_7): Configure the SonarQube Enterprise Edition integration to import code quality, security, and technical debt metrics into DevOps Intelligence. [title] GCP Cloud Build configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ GCP Cloud Build is a serverless CI/CD build platform requiring no infrastructure to create. the leading tool for continuously inspecting the Code Quality and Security of codebases and guiding development teams during Code Reviews. For  to pull data from SonarQube, you must configure a SonarQube account. # Configuring GCP Cloud Build, recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June 2024 or after. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Tools must be configured for a specific application in a specific phase. In step 2 of the following procedure, you are choosing the application and phase to associate with GCP Cloud Build as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure GCP Cloud Build or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Build row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select **Build** for **Build Categories**. The service displays the **Tool Engine** field. 6. Select Azure Pipelines for **Tool Engine**. The service displays the **Status** field. 7. Enter the current statuses of the builds of the GCPCloud Build (Passed, Failed and In Progress and multiselect). 8. Click **Submit**. # Onboarding GCP Cloud Build After configuring Azure Pipeline, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Build** for **DevOps Phase**. The service displays the Build Categories field. 4. Select **Build** for **Build Categories**. The service displays the Tool Engine field. 5. Select **GCP Cloud Build** for **Tool Engine**. The service displays the **Select Connection** field. 6. Select the appropriate connection. The service displays the **Select Organization** field. 7. Select the appropriate organization. The service displays the **Project** field. 8. Click **Onboard**. The service navigates to the Application Configuration page. 9. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that Azure Pipelines has been fully configured. # Deleting Azure Pipelines as a technical service The administrator may, at will, delete the Azure Pipeline technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Build**. 4. Click **Delete Technical Service**. 5. Click Azure Pipelines for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. [title] Secure [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Secure supported tools assist team members in obtaining data that displays details of the vulnerability in the environment. These tools provide scores for overall risk, security-related build delays, and security findings during the build process with services like Static Scan that show vulnerabilities aggregated according to the day-month timeline, Open Source License Compliance to show all Licenses detected, and a compliance detail table to find dependencies between applications this provides an overall real-time estimation of the security data of the organization or a specific team. Follow these steps to access the Tools Configurations page: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Toolchain & Pipeline **→ **DevOps Intelligence **→ **Settings & Utilities **→ **Tools Configuration**. For more information, see [Supported tools](docId\:cRuTgj1F0ko53NYZhEIXu). **Tools supported in Secure:** - [Qualys Container security tool configuration](docId\:iisktx7GQKV8hwPI9s8Nb): Provides centralized, continuous discovery and tracking for containers and images. - [Dependency Track configuration](docId\:H73fhs8PJ-oKDOPoVvZwd): Scans components for known flaws. - [SonarQube Enterprise Edition configuration](docId\:l6KMPPnIuAPFxsi9MEE_7): Inspects the code quality and security of codebases and guiding development teams during Code Reviews. - [CodeQL configuration](docId\:MQ6-Wog8o1L9vpT5cjyKO): Enables the discovery of vulnerabilities across your codebase. - [GitLab SAST configuration](docId:2DJmIn8WXBpQ8GtuAouUn): Checks your source code for known vulnerabilities - [JFrog configuration](docId\:m2QAQnjRQbXqvVzUoj5Zq): The process of setting up a connection between your platformand JFrog tools such as JFrog Artifactory and JFrog Security Essentials (Xray and JFrogOSS). - [Mend.io configuration](docId\:ylp2rkaXmQWTMAoZO5uK3): Securely manage open-source risks, license compliance, and AI-generated code. - [GCP Cloud Build configuration](docId\:PuMeSYVf67mJYI49-3-JV): Inspects the code quality and security of codebases and guiding development teams during code reviews. - [CodeQL configuration](docId\:MQ6-Wog8o1L9vpT5cjyKO): Semantic code analysis engine that enables the discovery of vulnerabilities across your codebase. - [GitLab SAST configuration](docId:2DJmIn8WXBpQ8GtuAouUn): Reviews your source code for known vulnerabilities. [title] Secure alerts [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ Secure alerts are an invaluable tool in your security arsenal. Beyond trendlines, these notifications address the dynamic nature of threats as they occur, providing an immediate understanding of your hybrid IT estate. The data they represent is also fed to charts and graphs to help you understand your vulnerabilities over days, weeks, and months, but there is not substitute for comprehension of your current circumstance. They can help you preempt a mission disruption rather than addressing it after the fact, when it might be too late. The Secure module contains the tools you need to provide the assurance enabled by alerts as your circumstance changes. # Secure module composition Secure alerts data can be filtered by three criteria: - **Dashboards:** Select a dashboard to view development data specific to that dashboard. - **Applications:** Comprehend the issues and health of cloud services such as CAM and Enterprise Marketplace - **Release:** You can select a specific release and view secure alerts limited to that release. Use the following procedure: 1. Click the Application dropdown, which initially displays **All data.** 2. Select the application from the dropdown list. 3. Select the release from the Releases dropdown. 4. Select the environment from the Environments Dropdown The Secure alerts dashboard displays two widgets and a table view that provide a graphic representation of development activities and applications: - Severities trend - Vulnerable applications - Technical service alerts # Severities trend This graph depicts the trend of security alerts based on the day filter option, further divided into critical, high, medium, and low severity levels. It also displays the total number of active and closed alerts for all technical services. Currently, dismissed alerts come under open state. # Vulnerable applications This is a Bar graph with the name of the application and the severity (critical and high) shown in red and orange, respectively. The function of this graph is to show which apps are the most vulnerable in terms of severity. # Technical services alerts The Technical service alerts table is located at the bottom of the Secure alerts dashboard that provides vulnerability alerts from dependent packages in a tabular form and enables a detailed view of each service. Each row in the table displays information for a specific service, separated by columns of information type: - **Technical services:** Name of the technical service. - **Application:** Name for the application. - **Total alerts:** Total number of alerts. - **Critical:** Number of critical status alerts. - **High:** Number of High-status alerts. - **Medium:** number of Medium-status alerts. - **Low:** Number of Low-status alerts. - **Latest alert opened:** Time that the alert was last opened. # Technical services alert details The Technical services alert details table provides detailed secure alert data in a tabular form and enables a detailed view of each package alert. This page displays the following elements: Breadcrumbs to go *Back to secure alerts*. - A subheader displaying information regarding: - Application name - Technical service name - Source - Severity count: - Critical - High - Low - Total - Three radio buttons to filter the table data into Open, Dismissed, and Closed alerts. A table view for the specified technical service, presenting information on multiple alerts organized in the following columns: - **Package:** Name of the package where the alert was generated. - **Severity:** Classification of the severity category. - **CVE ID:** Classified vulnerability ID. - **Affected version:** Affected version that generated the alert. - **Patched version:** Fixed version where the alert was generated. - **Alert URL:** Link to the repository containing more information for the alert. - **Created at:** Time when the alert was created. By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applictions, regardless of vulernability. [title] AWS CodePipeline configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ Learn how to configure for the integration of AWS CodePipeline to broaden the observability of your hybrid IT estate. To enable to extract data from AWS CodePipeline, it's essential to establish and configure an [AWS configuration](docId\:DhPVyu9tCpJH0zlRpuLVr). This process forms a vital link between the two systems, allowing to access and leverage the data stored within AWS CodePipeline for further analysis and operations. **Access rights**: The connection must have the following access rights: - **Connection**: Read access rights are required on the project or work items you intend to sync. To access templates, you must have specific roles; please see: [Roles required](docId\:pLUvy2ZVxQd_s0C0MwTUt) # Configuration You must choose the Pipeline name, add a Technical Service and additional configurations for customizations to establish the configuration. Extra settings are available to handle the states of **Passed**, **Failed**, and **In Progress**, which are terms employed in the dashboards. You have the flexibility to introduce custom terms for these states. For instance, any value input under the **Passed** category will be interpreted as **Passed** when displayed on the dashboard. Once you have made these selections complete the following steps to configure AWS CodePipeline: 1. Within Kyndryl application, select the **Open** menu icon from the top left corner, navigate to and expand the menu. 2. Expand **Settings & Utilities,** then select **Tools Configuration.** 3. Select **Add configuration +** and a **Add tool configuration** form will be displayed; here, you will select: 4. **AWS CodePipeline** from the **Tool Engine** dropdown menu. 5. The **Connection**, **Provider**, **Release name**, **Environment, **and the **Incident host URL **each one from its dropdown menu. 6. You must select toggle on or off if the configuration is for a **production environment.** 7. And you can fill in the** Additional configuration for customization** section at the bottom of the form if you would like to personalize it with custom terms for **Passed**, **Failed** or **In progress** statuses. 8. Select the **Add configuration** button at the bottom of the form. After completing the configuration, you can view the configuration details in the table on the configuration page. A sample image showcasing this is provided below for your reference. [title] Azure Release Pipelines configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ To enable effective data synchronization from Azure Release Pipelines into DevOps Intelligence, it's crucial to establish an adequately configured Azure DevOps connection. This connection is a secure bridge between the two platforms, allowing seamless data transfer and management. Establishing this connection enables DevOps Intelligence to leverage Azure Pipeline's robust capabilities, enhancing its monitoring and reporting features. This configuration enhances the accuracy and efficiency of data handling and amplifies the overall functionality of the DevOps Intelligence tool. **Access rights**: The connection must have the following access rights: - **Build and Deploy**: Read access right. - **User profile**: Read access right. To access templates, you must have specific roles; please see: # Roles required As a user, your permissions determine the actions you can perform on the bring-your-own (BYO) template data. You must view, create, update and delete roles to perform the respective actions. By default, these permissions are granted to the Editor. The Viewer, on the other hand, is only endowed with the view role. # Configuring Azure Release Pipelines for recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June 2024 or after. Procedures for legacy customers are provided in the subsequent section *Configuring Azure Release Pipelines for * &#xNAN;*, legacy customers*. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Note: Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with Azure Release Pipelines as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure Azure Release Pipeline or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Deploy row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the Add Tool Configuration form. 5. Select Azure Release Pipelines for **Tool Engine**. 6. Click **Submit**. # Onboarding Azure Release Pipelines After configuring Azure Release Pipeline, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Deploy** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **Azure Release Pipelines** for **Tool Engine**. The service displays the **Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the **Repository Name** field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that Azure Repo has been fully configured. # Deleting Azure Pipelines as a technical service The administrator may, at will, delete the Azure Pipeline technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Deploy**. 4. Click **Delete Technical Service**. 5. Click Azure Pipelines for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. # Configuring Azure Release Pipelines for , legacy customers You must choose the Pipeline name, add a Technical Service and additional configurations for customizations to establish the configuration. Extra settings are available to handle the states of **Passed**, **Failed**, and **In Progress**, which are terms employed in the dashboards. You have the flexibility to introduce custom terms for these states. For instance, any value input under the "Passed" category will be interpreted as "Passed" when displayed on the dashboard. Once you have made these selections complete the following steps to configure AWS CodePipeline: 1. Within Kyndryl application, select the Open menu icon from the top left corner, navigate to and expand the menu. 2. Expand **Settings & Utilities,** then select **Tools Configuration.** 3. Select **Add configuration +** and a **Add tool configuration** form will be displayed; here, you will select: 4. **Azure Pipeline - Build** from the **Tool Engine** dropdown menu. 5. The **Connection**, **Test type**, **Technical service**, **Organization** and **Project** each one from its dropdown menu. 6. And you can fill in the** Additional configuration for customization** section at the bottom of the form if you would like to personalize it with custom terms for **Passed**, **Failed** or **In progress** statuses. 7. Select the **Add configuration** button at the bottom of the form. After completing the configuration, you can view the configuration details in the table on the configuration page. A sample image showcasing this is provided below for your reference. [title] Technical services configuration page [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Learn how to use the *Configure technical services* page. The Configuring technical services page enables configuring the following details: - How to associate and disassociate technical services with applications and how to link technical services with each other using different tools (Associate technical services tab). - How to create applications and associate them (Applications tab). - How to configure release parameters (Release Management Configurations tab). # Associating technical services The technical services table presents all Technical services available for association with any given application. The table enables a detailed view of each technical service. Each row in the table displays information for a specific technical service, separated by columns of information type: - Technical service - Application - Develop - Build - Test - Deploy - Static Scan - Container vulnerability scan - Dependency check - Secure alerts - Discovered at :::hint{type="info"} Note\:Only *Technical service* and *Discovered at* columns can be sorted. Above this table, you will find a search box that allows searching technical services by name and a Gear icon that allows changing the table settings to show or hide pre-selected columns. ::: Selecting the vertical ellipsis located to the right of each technical service in the table, you will be presented with the option to *Link technical services* or to *View linked technical services* By selecting *Link technical services*, you will access the *Configure technical service Details* page. Here, you will link one technical service to other technical services using different tools. From the Settings & Utilities menu, navigate to **Configure technical services:** 1. The **Associate technical services** the tab is selected by default. 2. Select one or more technical services that you want to associate from the *Technical services* table. 3. Select the *Associate* button on the right side of the table. 4. Select one or more applications to associate the technical service from the *Application* drop-down menu. 5. Confirm the association by selecting the *Associate* button. A success message will be displayed at the upper right corner of the screen. # Disassociating technical services Technical services can also be disassociated (**De-linked**) from each *Application*. To disassociate technical services, navigate to the **Applications** tab: 1. Search and locate the *Application* you would like to disassociate. 2. Select the **Edit** icon from the *Actions* column. The *Edit Technical service details* a window will open. 3. From the *Associate technical services* table, select one or more services to disassociate. 4. Select the **Disassociate technical services** button and confirm the technical service disassociation with a *Yes*. A success message will be displayed in the upper right corner of the screen. # Creating applications From the Settings & Utilities menu, navigate to **Configure technical services** there, you will be presented with two tabs: Associate technical services and Applications. 1. Select the **Applications** tab. 2. Enter a suitable name for the application, i.e., "DemoCT1" and select **Create**. A "Success; Application "DemoCT1" is created successfully!" message will be displayed in the upper right corner of the screen. :::hint{type="info"} Note: An error message will indicate that you must contact the system administrator and review your user permissions. ::: Once your application is created, it will be displayed under the *Associated applications* table. This table will show information in the following columns: - **Application:** Name of the application created. - **Created by:** The user that created the application. - **Total technical services:** The total number of technical services associated with this application. - **Actions:** Editing or deleting options for the application. # Action button Selecting the **Edit** icon, you will access the *Edit Technical service details* page; here, you can update the current application's name and disassociate technical services. To disassociate technical services, complete the following steps: 1. Select one or more technical services from the *Associate technical service* table. 2. Once you have made your selection, navigate to the *Disassociate technical service* button and select it. 3. Confirm the Technical service deletion by selecting **Yes** on the emerging window. A "Success; Services dissociated successfully. It may take up to 10 minutes to reflect the changes across dashboards." message will be displayed at the upper right corner of the screen. By selecting the **Trash can** icon, you will see a confirmation of the Application deletion; Confirm delete to proceed with the process. A success message will be displayed in the upper right corner of the screen. # Release Management Configuration The **Release Management Configuration** tab navigates to the **Global Configuration** page. The page enables administrators to set values (tenant thresholds) for release parameters which are then displayed on the **Release Management** page so release managers determine whether to allow a given release (*go/no go* decision). Example: the administrator sets the release threshold for failed unit tests at 5%. If the current release is at 4%, and all other thresholds are within the specified levels, the release manager is informed that the release can proceed. But if the failed unit tests parameter is at 6%, the release manager is informed that the parameter is out of acceptable range and he should withold the release. The Global Configuration page presents a Tenant Parameters table containing all supported release parameters, and their associated tenant thresholds. Use the following procedure to set the thresholds: 1. Click the **Edit Configuration** button located above the table on the right. The service displays the Edit Configurations list. The list contains all supported parameters, each of which has an associated field for the threshold. 2. Edit the threshold field to set the appropriate threshold. 3. Click **Save configuration** to commit the thresholds or **Cancel** to abort the operation. :::hint{type="info"} Note: The releases that are available for assessment are limited to those that have occurred in the previous 180 days. ::: As the administrator you can also edit which columns the table displays. Click the gear icon located to the left of the Edit configuration button to display the column selection array. The array contains three check boxes: - **All columns:** Display all available columns. - **Parameters:** Display the supported release parameters. - **Tenant threshold:** Display the set threshold for the associated parameter. Click **Apply** to save your selections, **Reset** to reset the selection (all columns) or **Cancel** to abort your selections. A search feature is also available. Click the hour glass icon located next to the gear icon to display the search field. Enter all or part of the parameter name in the search field to filter out all parameters except those you are seeking. You can delete parameters from the table. Click the checkbox next to each parameter you want to delete and click the **Delete** button to continue or **Cancel** to abort the deletion. If you click the **Delete** button, the service displays a confirmation dialog requesting a reason for deleting the parameter (required). Enter a reason in the **Reason for Deletion** field or click **Delete** to delete the parameter of **Cancel** to abort the deletion. After deleting a parameter, you can restore it using the **Edit configuration **feature. Perform the following procedure: 1. Click the **Edit Configuration** button. The service displays the Edit configurations list. 2. Scroll to the bottom of the list. The service displays all the deleted parameters at the bottom of the list with an **Undo Delete** link next to each parameter. 3. Click **Undo Delete** for each parameter you want to restore. 4. Click **Save Configuration**. [title] Qualys Container configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ Qualys Container Security provides centralized, continuous discovery and tracking for containers and images. Configure to connect to Qualys Container for the purpose of pulling security and vulnerability data from the security tool. # Prerequisites The connection requires the following access rights: - Read access to the image you intend to sync. Provide the following information: - Connection Name – Local connection name. It could be any string and is used only for reference. - Host – Qualys host URL. For example:`https://qualys.kyndryl.net` - Username – Username for Qualys. Generally, the email ID with which user logged in to Qualys. - Password – Password for Qualys. Generally, the password with which user logged in to Qualys. # Configuring Qualys Container security tool Perform the following procedure to create the connection: - Go to **Admin** --> --> **Connections** --> **Add New** button. Select **Add Connection** and complete the **Add tool **configuration form: - **Connection:** qualysConn. - **Release name:** provide a release name (any name is permitted). - **Dynamic.imagename:** Select the image name that you want to track using  . - **Additional configurations:** include additional configurations from the drop-down menus. When the Configuration is successful the configuration is present in the table on the configuration page. [title] Static scan [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ Understand how Kyndryl enables you to protect your code from security vulnerabilities from the Secure dashboard. Static Application Security Testing (SAST), also known as static code analysis, is a method used to analyze source code for potential security vulnerabilities without executing the code. The Static Scan page provides vulnerability information from SonarQube, enabling development managers and security and compliance officers to assess the reliability and security of their applications.The Security Rating widget features a donut chart that represents the security rating for all the projects based on the latest analysis scan date. The rating is categorized into five scales: A, B, C, D and E. Currently, three projects are synced with SonarQube and the latest scan indicates an A rating, signifying a high level of security. captures information from all synced projects, and if any critical vulnerabilities are detected, they will be flagged in the **Vulnerability by Severity** widget. Selecting Static scan will open the Static scan dashboard displaying graphs that enables an in-depth comprehension of the source code vulnerabilities detection, under the following criteria: - [Security rating](docId:067iAwEsTno9_iOpmeCh1) - [Vulnerability by severity](docId:067iAwEsTno9_iOpmeCh1) - [Top critical technical services and vulnerability density](docId:067iAwEsTno9_iOpmeCh1) - [Vulnerability density](docId:067iAwEsTno9_iOpmeCh1) - [Secure static scan details](docId:067iAwEsTno9_iOpmeCh1) ## Security rating The Security Rating widget features a Security Rating donut chart that represents security rating only for technical services with the latest analysis scan date. The chart displays percentages for data based on the following ratings: - **A Rating**: Green color. - **B Rating**: Yellow color. - **C Rating**: Orange color. - **D Rating**: Red color. - **E Rating**: Dark red color. Security rating is classified based on the following criteria: - **A** = 0 Vulnerabilities. - **B** = at least 1 Minor Vulnerability. - **C** = at least 1 Major Vulnerability. - **D** = at least 1 Critical Vulnerability. - **E** = at least 1 Blocker Vulnerability. :::hint{type="info"} Note: The total number of technical services in a given rating is shown by hovering over the chart. ::: ## Vulnerability by severity The Vulnerability by severity graph represents the total number of vulnerabilities aggregated according to day-month timeline selection. Graph data supports selecting predetermined Applications and Dashboards from the Drop-down menu. By default, it is for all applications and technical services and represents data for the last 7 days. Severities are classified according to their criticality: - **Critical**: Dark red color - **High**: Red color - **Medium**: Orange color - **Low**: Sky blue color - **Info**: Green color The Vulnerability by severity widget provides details about any detected vulnerabilities by means of a bar graph that presents two axis, described as follows: - X-Axis (**Duration**): The X-axis corresponds to the months and dates from the period selected to show data. Each bar contains data for 1 month - Y-Axis (**Total Vulnerabilities**): The Y-axis corresponds to the number of vulnerabilities detected in the selected period By hovering over the bars in the graph, you can view data about the total number of vulnerabilities detected and the severity they belong to, as follows: - **Group**: The severity to which the vulnerabilities belong. - **Range**: The cut-out date for the vulnerabilities detected. - **Value**: The total number of vulnerabilities detected. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Range**: The cutout date for detected Vulnerabilities. - **Critical**: Total number of vulnerabilities detected and classified as Critical severity. - **High**: Total number of vulnerabilities detected and classified as High severity. - **Medium**: Total number of vulnerabilities detected and classified as Medium severity. - **Low**: Total number of vulnerabilities detected and classified as Low severity. - **Info**: Total number of vulnerabilities detected and classified as Info severity. - **Total**: Total number of vulnerabilities detected, including all severities. ## Top critical technical services and Vulnerability density The Top Critical Technical services widget is a top critical technical services chart that represents the top technical service listed according to its criticality. Vulnerability Density is the cumulative vulnerability count per unit size of code. The Vulnerability Density, technical services chart represents the top technical services listed according to their vulnerability density. considers 1000 source lines as the unit code size. The Secure Static scan details table View is located at the bottom of the dashboard that provides the latest successfully executed Static Scan Analysis data in a tabular form and enables a detailed view of each technical service. Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical service**: The name of the micro technical service within the larger application. - **Application**: The name of the application, typically comprising multiple micro-technical services. - **Vulnerabilities**: Total Number of Open vulnerabilities. - **Critical**: Total number of vulnerabilities classified as Critical severity. - **High**: Total number of vulnerabilities classified as High severity. - **Secure Engine**: The security source tool is configured. - **Security Rating**: Security rating from A to E. - **Analysis Date**: The date the analysis was performed. - **URL Vulnerabilities**: The URL to the actual vulnerability information in the Secure engine page. :::hint{type="info"} Note: The Static Scan details table displays all data regarding the timeframe selected. All the columns in this table can be sorted except the **URL vulnerabilities** column. Above this table, you will find a search box that allows searching technical services by name and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: ## Toggel: vulnerable services vs. all services **The static scan details table** The details table helps the CISO identify which projects have the most vulnerabilities and provides a breakdown of these issues. For example, you can sort by critical vulnerabilities to prioritize those SonarQube projects. This makes it easy to understand where to focus first. For a detailed analysis history, you can select a specific repository and view the scan history. DI presents the history of vulnerabilities reported for the project, sorted by the scan analysis date. This provides a clear view of how the vulnerability rating has changed over time for a specific project. The details table also supports detailed views for each technical service. To access details for a specific technical service, Click the overflow menu located to the far right of the table and select View Details. :::hint{type="info"} Note: Technical services are a micro-service that is analogous. This is the most granular degree of granularity. Repos in Travis are mapped. Only Technical Services with static scans in the last 6 months will be displayed. ::: The following elements are displayed in this dialog: - The title **Static scan** detail plus the name of the technical service in question - The Summary, which shows the total number of **Open vulnerabilities** and the **Security rating** for the technical service - Two tabs that you can click on, with the option to toggle between ascending and descending alphanumeric order for most columns: **Details** and **Analysis** History - **Details**: Clicking the **Details** tab displays **Vulnerability details** in a tabular form and provides the following details for the technical service: - Component - Severity - Rule - Description - Effort - Line No. - Status - Latest update date - **Analysis history**: Clicking the **Analysis history** tab displays **Static scan history** in a tabular form and provides the following details for the technical service: - **Security rating**: Security rating from A to E - **Vulnerabilities**: Total number of open vulnerabilities for the technical service - **Critical**: The total number of vulnerabilities detected and classified as Critical severity - **High**: The total number of vulnerabilities detected and classified as High severity - **Medium**: The total number of vulnerabilities detected and classified as Medium severity - **Low**: The total number of vulnerabilities detected and classified as Low severity - **Info**: The total number of vulnerabilities detected and classified as Info severity - **Scan analysis date**: The date when the scan analysis was completed :::hint{type="info"} Note: At the bottom of the table, you will find: - A selectable arrow below the bottom left corner of the table filters the number of Items per page; 25, 50, and 100 are the available options. - A selectable arrow below the bottom right corner of the table enables navigation across pages of data (Page 1 of 3, Page 2 of 3, etc.) ::: By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applictions, regardless of vulernability. [title] Deploy [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Deploy supports a library of deployment tools that display data pertaining to deployment templates, technical services, and applications by status and success. Selecting the data context provides better visibility into the overall health of deployment infrastructure and processes, while also offering insight into template performance and usage frequency. The console supports the following industry-standard deployment tools. # Tools Supported in Deploy - [AWS configuration](docId\:DhPVyu9tCpJH0zlRpuLVr): Configure AWS integrations to monitor cloud deployment activities, infrastructure changes, and deployment performance across AWS environments. - [ArgoCD configuration](docId:4QAg_7nI5cw_G2XjwrFWX): Configure ArgoCD integrations to track Kubernetes application deployments, synchronization status, and GitOps workflows. - [Azure Resource Manager configuration](docId\:bubUdxDgF-iqSKgVwcI80): Configure Azure Resource Manager integrations to observe resource provisioning, template deployments, and infrastructure operations in Azure. - [Google Deployment templates](docId\:lfBjpB4qrAHnZqAarAQCL): Configure Google Deployment Manager templates to collect deployment data and monitor Google Cloud infrastructure changes. - [GoCD configuration](docId\:qJfvi-AimGgl-ajgG3x3e): Configure GoCD integrations to track continuous delivery pipelines, deployment executions, and release workflows. - [Ansible configuration](docId\:pNYgjmcWX9h-VdILGG2a_): Configure Ansible integrations to monitor automation tasks, configuration management activities, and infrastructure deployments. - [AWS CodeDeploy configuration](docId:2CjXSmw9iIUtgL5APPWPU): Configure AWS CodeDeploy integrations to retrieve deployment lifecycle data and monitor application deployment success across AWS services. - [Azure Pipelines configuration](docId\:unXS32Nf4Sg6NxynH43qj): Configure Azure Pipelines integrations to track build and deployment pipeline activities within Azure DevOps. - [Azure Release Pipelines configuration](docId\:L_TVePMo5lsOSe3ycUuDM): Configure Azure Release Pipelines integrations to monitor release management workflows and deployment stages. - [ServiceNow configuration](docId:25jhLq-AClVJQh_7HK8da): Configure ServiceNow integrations to collect incident, change request, and deployment-related operational data for unified visibility. [title] Bring your own dependency check [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ Secure dashboard represents vulnerability details for static scan, license compliance, dependency check & container vulnerability scan. # Dependency check shows vulnerabilities The process of dependency check is crucial to identify vulnerabilities in our code that attackers could potentially exploit. To achieve this, we use various tools and APIs, including Bring Your Own DependencyCheck APIs, to perform vulnerability scans and gather information. One of the ways we can scan for vulnerabilities is through Dependency Track, which helps identify vulnerabilities in third-party tools and dependencies. Using the tenant, users can share and analyze lists of vulnerabilities, allowing for the calculation of metrics related to the vulnerable components. This process enables us to proactively address potential security risks and ensure the safety of our code and systems. Secure functionality is applicable only for the premium plans in . The following image shows how the Secure page looks when data is populated from secure tools. :::hint{type="info"} Secure functionality is applicable only for premium plan in DevOps Intelligence. ::: The following image shows how the Secure page looks when data is populated from secure tools. # Bringing data into  To bring your own Build tools, complete the following steps: 1. Go to the Tools Configuration page and navigate to the Tokens tab. 2. Click on **Create Token** and give a unique Token name. 3. Select** Token Type** as Build, then click on the Create button. 4. A new entry will be added to the table in the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} Note: To Post Data to the APIs mentioned below, Add the service Token (see: [Bring your own tools](docId\:J2wCdGqoWTc5MnOocZTyA) to the **Authorization** header of the request. See cURL Example for reference. ::: # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example :** `TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX` **Step 2:  API Reference** **API : technical-services/dependency-check** **URL : https\://\{devops-intelligence-host}/dash/api/build/v3/technical-services/dependency-check** **Parameters** | **Parameter** | **Type** | **Explanation** | **Example Value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------- | | Authorization\* | Header | Authorization has a service token | 74h5cR8sETSJRvOFkdbsISY3lsgfNGu\_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX | | VulnerabiltyScanDetails \* | BODY | Scan Data in Json | | ```javascript { "component_name": "Comp1", "component_uuid": "12345", "endpoint_hostname": "MyOrg", "last_occurrence_time": "2022-12-15T07:20:50.52Z", "first_occurrence_time": "2022-12-15T07:20:50.52Z", "project_name": "myProj", "project_uuid": "98765", "provider_href": "http://www.mytest.com", "scanned_by": "BYOD", "technical_service": "BYOS", "technical_service_override": false, "technical_service_tag": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "vulnerabilities": [ { "affectedProjectCount": 0, "cvssV2BaseScore": 0, "cvssV2ExploitabilitySubScore": 0, "cvssV2ImpactSubScore": 0, "cvssV2Vector": "string", "cvssV3BaseScore": 0, "cvssV3ExploitabilitySubScore": 0, "cvssV3ImpactSubScore": 0, "cvssV3Vector": "string", "dependencies": "string", "description": "string", "published": "2022-12-12T11:48:55.888Z", "references": "string", "riskscore": 10, "severity": "High", "sha256": "string", "source": "string", "title": "string", "updated": "2022-12-12T11:48:55.888Z", "url": "string", "uuid": "982233", "vulnId": "5555", "weakness": "string" } ] } ``` ## cURL Example : **Request:** ```curl curl -X 'POST' \ 'dash/api/dev_secops/v3/technical-services/dependency-check' \ -H 'accept: application/json' \ -H 'Authorization: Token _aKFE90h5_j5xqBMJijZv5qS_XZn1GnEIoFFgSaxJvlDmdJAlePpmBVR4vAwuty5' \ -H 'Content-Type: application/json' \ -d '{ "component_name": "Comp1", "component_uuid": "12345", "endpoint_hostname": "MyOrg", "last_occurrence_time": "2022-12-15T07:20:50.52Z", "first_occurrence_time": "2022-12-15T07:20:50.52Z", "project_name": "myProj", "project_uuid": "98765", "provider_href": "http://www.mytest.com", "scanned_by": "BYOD", "technical_service": "BYOS", "technical_service_override": false, "technical_service_tag": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "vulnerabilities": [ { "affectedProjectCount": 0, "cvssV2BaseScore": 0, "cvssV2ExploitabilitySubScore": 0, "cvssV2ImpactSubScore": 0, "cvssV2Vector": "string", "cvssV3BaseScore": 0, "cvssV3ExploitabilitySubScore": 0, "cvssV3ImpactSubScore": 0, "cvssV3Vector": "string", "dependencies": "string", "description": "string", "published": "2022-12-12T11:48:55.888Z", "references": "string", "riskscore": 10, "severity": "High", "sha256": "string", "source": "string", "title": "string", "updated": "2022-12-12T11:48:55.888Z", "url": "string", "uuid": "982233", "vulnId": "5555", "weakness": "string" }, ], }' ``` **Response 200** `"Total Number of records inserted successfully is 1"` ## Secure-Dependency-Check-vulnerability request body explained | **Field** | **Data Type** | **Explanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------- | ---------------------------------------------- | | endpoint\_hostname | string | Name of the endpoints | "myOrg/myRepo" | | component\_name \* | string | Name of the component | "myRepo" | | component\_uuid \* | string | UUID of the component | "56567656" | | project\_id | string | Name of the Project | "DevOpsIntelligence" | | project\_uuid | string | UUID of the project | "980022" | | provider\_href \* | string | Provider URL on which vulnerability is scanned | "http\://mytest.com | | scannedby \* | string | Tool which is used to scan the Vunerabilities of the repositories | "BYO", | | last\_occurrence\_time\* | string | Time of first occurrence in UTC | "2022-12-05T07:20:50.52Z" | | first\_occurrence\_time \* | string | Time of last occurrence scan in UTC | "2022-12-05T07:20:50.52Z" | | technical\_service \* | string | Technical Service Name | "myservice" | | technicalserviceoverride | boolean | Override flag for the service | true | | vulnerabilities | Details of the fields | | | | Severity \* | string | Severity of Vulnerability | critical, high, low, medium | | Updated | string | Date of update | "2022-12-05T07:20:50.52Z" | | Published | string | Date of published | "2022-12-05T07:20:50.52Z" | | dependencies | string | Dependencies for the vulnerability | "libecheck-1.2.1" | | description | string | Description of the vulnerability | "For the BYO vulnerability | | Sha256 | string | SHA value | e958d6656281b0276597ac6d9453d6c5dbb6afc5 | | VulnID \* | string | Vulnerability ID | 6340a99cfc1262 | | UUID \* | string | UUID of the component | 4ca61bb22 | | weakness | string | Weakness | 862 : Missing Authorization | | Source | string | Source of vulnerability | NVD | | RiskScore | int32 | Risk score of the vulnerability | 8 | | Title | string | Title of the vulnerability | "BYO dependency check vulnerabilities" | | References | string | Reference for the vulnerability | ref\:repo | | URL | string | URL of the vulnerability | https\://myrul.in | | AffectedProjectCount | int | Count of the affected projects | 6 | | CvssV2BaseScore | float64 | | | | CvssV2ImpactSubScore | float64 | | | | CvssV2ExploitabilitySubScore | float64 | | | | cvssV3Vector | string | CVSS V3 Vector | | | CvssV2Vector | string | CVSS V2 Vector | | | CvssV3ImpactSubScore | float64 | | | | CvssV3ExploitabilitySubScore | float64 | | | [title] DevOps Intelligence [path] Services/Platform Services/Toolchain & Pipeline/ [title] Bring your own image scan [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ Learn how to integrate secure image scan tools with . The Secure dashboard presents vulnerability details for static scan, license compliance, dependency check and container vulnerability scan in accordance with the following list: - Staticscan shows vulnerabilities from SonarQube - License scan shows license compliance details: License Compliance information is sent to using Bring Your Own License Compliance APIs. - Dependency check shows vulnerabilities from Dependency Track - Container vulnerabilities scan shows image vulnerabilities: Container Vulnerability scan information is sent to using Bring Your Own Image Scan APIs Secure functionality is applicable only for premium plan in . # Bringing data into  To bring your own Deploy tools complete the following steps: 1. Go to the Tools Configuration page and navigate to the Tokens tab. 2. Click on Create Token and give a unique Token name. 3. Select Token Type as Secure, then click on the Create button. 4. A new entry will be added to the table. In the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} Note: To Post Data to the APIs mentioned below, Add the service Token (see: [Create Service Token](docId\:J2wCdGqoWTc5MnOocZTyA)) to the **Authorization** header of the request. See cURL Example for reference ::: # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example:** ```javascript TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX ``` **Step 2:  API Reference** **API /technical-services/\{technicalServiceID}/image-scan?scannedBy=anchore\&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37** **URL: https\://\{devops-intelligence-host}/dash/api/build/v3/technical-services/\{technicalServiceID}/image-scan?scannedBy=anchore\&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37** **Parameters** | **Parameter** | **Type** | **Explanation** | **Example Value** | | ------------------------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | serviceName\* | PATH | serviceName is a repository in on which Container Vulnerability scan runs(repo name) | dev\_secops | | Authorization\* | Header | Authorization has service token | 74h5cR8sETSJRvOFkdbsISY3lsgfNGu\_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX | | scannedBy\* | Query Parameter | Tool which is used to scan the Container Vulnerability of the repositories | anchore | | scannedTime\* | Query Parameter | The time at which Container Vulnerability are scanned and time(2006-01-02T15:04:05.999999999Z07:00) should be URL encoded | 2021-06-28T12%3A07%3A29.104834%2B05%3A37 | | scan \* | BODY | Build Data in Json | | ```javascript { "provider_href": "string", "vulnerable_image_scan": [ { "cvss_score": 0, "description": "string", "image_digest": "string", "package_name": "string", "package_path": "string", "package_version": "string", "severity": "string", "url_datasource": "string", "vulnerability_id": "string" } ] } ``` ## cURL example Request ```curl curl --location --request POST 'https://{devops-intelligence-host}/dash/api/build/v1/services/{serviceName}/image-scan?scannedBy=anchore&scannedTime=2021-06-28T12%3A07%3A29.104834%2B05%3A37' \ --header 'Authorization: TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX' \ --header 'Content-Type: application/json' \ --data-raw '{ "provider_href": "https://github.kyndryl.net/" "vulnerable_image_scan": [ { "cvss_score": 0, "description": "description of vulnerability", "image_digest": "unique id for image digest", "package_name": "crypto", "package_path": "https://github.kyndryl.net/multicloud/crypto", "package_version": "0.1", "severity": "high", "url_datasource": "http://host/datastoreurl", "vulnerability_id": "xxxxxsfsdxxx" } ] }' ``` **Response 200** ```curl "Total Number of records inserted successfully is 1" ``` ## Secure-Container-Vulnerability-Scan request body explained | **Field** | **Data Type** | **Explanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------------------- | -------------------------------------------------------------------- | | provider\_href | string | Provider URL on which container vulnerability is scanned | https\://github.kyndryl.net/ | | cvss\_score | int | cvss score | 1 | | description | string | description | description for vulnerability | | image\_digest | string | image digest | github.com/Luzifer/go-openssl | | package\_name | string | package name | luzifer | | package\_path | string | location of package installed in system | /Users/anilsahu/go/pkg/mod/github.com/!luzifer/go-openssl/v3\@v3.1.0 | | package\_version | string | package version | 0.1.2 | | severity | string | lseverity of vulnerability | critical, high, low, medium | | url\_datasource | string | datastore url | github.com/Luzifer/go-openssl | | vulnerability\_id | string | Vul ID | xxxxxsfsdxxx | [title] Dora metrics [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/DevOps performance metrics/ supports a broad array of performance metrics, enabling Development Managers, Developers and Testers to assess and their performance and fine tune processes to optimize that performance. DORA is one such metric framework supported by . To review DORA metrics, navigate to → **DevOps Performance Metrics**, and click the **DORA Metrics **tab. # DORA metrics Key metrics identified by Google DORA (DevOps Research and Assessment) for measuring the performance of software development teams include Deployment Frequency, Change Lead Time, Change Failure Rate and Mean Time to Recovery. They provide a comprehensive overview of team performance and are vital for evaluating and enhancing your software development process. ## DORA comprises four metrics: - **Deployment frequency metrics**: The frequency with which an organization successfully releases to production. - **Change lead time metrics**: The amount of time required to effect a release to customers. - **Change failure rate metrics**: The percentage of deployments causing a failure in production. - **Mean time to recovery metrics**: The amount of time required for an organization to recover from a failure in production. Data for these metrics is retained for 180 days. Users can choose to view data for any time within the last 180 in the following graduations: - 1 day - 7 days - 14 days - 30 days - 60 days - 90 days - 180 days (all retained data) - Custom date range Using the **Select duration** feature located on the right directly above the graphic displays, the user can select the data history range from a dropdown menu containing these selections. # Deployment frequency Deployment frequency is a key performance indicator in DevOps, measuring the rate at which an organization deploys new code or releases software to end-users in a production environment. This metric showcases the speed and agility of a development team, as more frequent deployments typically imply a faster, more responsive development cycle. :::hint{type="info"} Each successful deployment to production will be counted as one, even if the same release is deployed to multiple production environment. ::: The graph represents the total and average number of deployments for the selected history period. It is essential to map the application across all technical services to ensure the accuracy of data flow in the graphs. For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view. The details table includes technical service, application name, status, duration, deployment date, release and environment. :::hint{type="info"} The Deployment frequency table displays all data based on the graph's selected time frame and application. All columns in this table can be sorted. Above this table, you will find a search box that allows searching by Technical services and Applications by name. ::: # Change lead time Change lead time is a crucial DevOps metric that gauges the average duration between when a code change is committed and when that change is successfully deployed into the production environment. This metric reflects your development pipeline's overall efficiency and responsiveness, encompassing all process stages, from code integration and testing to the actual deployment. The graph represents the total and average number of deployments for the selected history period. For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view. The details table contains the application name, first commit, deployment date, change lead time and epic details with a redirecting link. :::hint{type="info"} Change Lead Time table displays all data based on the graph's selected time frame and application. Only the Application column can be sorted. Above this table, you will find a search field that allows searching the Application by name. ::: # Change failure rate The Change failure rate is a significant metric in DevOps that signifies the percentage of deployed changes that fail in the production environment necessitating an immediate fix. These failures could be service degradation, system outages, functionality issues or any other significant problems that negatively impact the end-user experience or system stability. CFR is mathematically defined as **Deployments Failed / Total Number of Deployments** Using this calculation, the interactive graph displays the total and average failure rate of deployments over a selected period. For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view. The detail table provides information such as application name, change failure rate, and incident details. The table includes selectable links that redirect you to relevant sections or additional information for easy navigation. :::hint{type="info"} Change failure rate table displays all data based on the graph's selected time frame and application. Only the Application column can be sorted. Above this table, you will find a search field that allows searching the Application by name. ::: # Mean Time to Recovery (MTTR) Mean time to recovery (MTTR), also known as Mean Time to Repair, quantifies how rapidly a team can restore service following a failure that impacts customers. It is the elapsed time between the **CreationTime** and **ResolvedTime** where **Creation Time** is the time at which an incident was created and Resolved Time is the time at which the incident was promoted to the Resolved state. MTTR is mathematically defined as ## Resolved Time — Creation Time The graph represents the total and average number of deployments for the selected history period. This graph allows you to filter data by priorities (P1 through P4), by default, All priorities is selected. MTTR trends help in evaluating the resilience of the system. A decreasing MTTR indicates that the team is improving its ability to recover from failures quickly, enhancing overall system reliability. As more applications are added to , users can track and compare the performance of different applications. Performance can also be measured against industry standards, categorized as High, Medium or Low according to Google’s standards. For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view. The details table includes the Technical service, Application, Number of Incidents, Mean Time To Recovery and Incident details. For easy navigation, redirecting links are incorporated within the table. :::hint{type="info"} Mean time to recovery table displays all data based on the time frame selected. All columns in this table can be sorted except the **Incident** column. Above this table, you will find a search box that allows searching by Technical services and Applications by name. In the case of ServiceNow (NOW), MTTR is calculated from the SNOW Start Time. ::: # Benchmarking DORA metrics DORA metrics enables the practice of ***benchmarking***. Benchmarking is the practice of comparing your software development team's performance to industry standards or best practices using the previously identified four key metrics against four threshold standards. These standards are cataloged according to the following table: ## DORA benchmark categories | **Performance level** | **Deployment Frequency** | **Change Lead Time** | **Change Failure Rate** | **Mean Time to Recovery** | | -------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------ | | Elite | More than once each day | Less than one day | Up to 5% | Less than one hour | | High | Once each day to once each week | Between one day and one week | 5% – 10% | One hour to one day | | Medium | Once each week to once each month | Between one week and one month | 10% – 15% | One day to one week | | Low | Nore than once each month | More than one month | More than 15% | More than one week | | | | | | | # Configuring DORA metrics Configuring DORA metrics for data collection is crucial in measuring your team's software development performance. To accurately track Deployment Frequency, Lead Time for Changes, Change Failure Rate and Time to Restore Service, you must set up a data collection pipeline. This process often involves integrating your code repositories, like GitHub or GitLab, with data aggregation and visualization tools. Open-source projects like Four Keys can facilitate this by automatically setting up a data ingestion pipeline and compiling the data into a comprehensible dashboard. This setup helps to monitor your metrics and view trends over time, providing valuable insights into your team's operational efficiency and effectiveness. ## Adding deployment information Deployment data can be obtained in one of two ways: - Adding the connection where release info is available (tools such as, ArgoCD) and add the service configuration from the tools configuration page - Posting the Record from the Bring Your Own Deployment When adding a connection, the incident Host URL fields should be populated with your ServiceNow instance host url. To post the record from the BYO deployment, refer to the configure page, here: [Bring your own deploy](docId\:SF_ESDMWw_3d2OIcoNJh0). Ensure the following: - The fields Environment and Release match the provided change request. - The itsm\_host and endpoint hostname match the ServiceNow instance url. :::hint{type="info"} If Posting the data by Bring Your Own Deployment set **isProduction **to true. ::: ## Deployment frequency This section describes how to configure data collection for Deployment frequency: ## Connect to your release info source You can connect existing tools, where release information is available, and add the service config from the tool's configuration page. For instance: If you are using ArgoCD, the service config should be created with the details available at the documentation page for configuring that service, in this case, ArgoCD. Instructions for configuring all supported services are available in the documentation (Kyndryl Docs) by clicking the **Supported tools and integration** tile :::hint{type="info"} Remember to populate the **Incident Host URL **fields with your ServiceNow instance host URL. ::: ## Use the BYO deployment API Alternatively, you can post the record from the BYODeployment using supported APIs. Ensure that the fields **environment and release** match those provided in the change request. Also, make sure that **itsm\_host** and 'endpoint hostname' match your ServiceNow instance URL. If you post the data via BYODeployment, set **isProduction** to true. ## Change lead time (CLT) This section presents configuring Change lead time from BitBucket and GitHub, GitLab, and Azure DevOps. ## Atlassian BitBucket: - BitBucket Cloud classifies issues as 'proposal' for epic tasks and 'task' for user stories. - Link tasks to their proposals using a specific format in the description: Proposal:\ followed by the full URL link to the proposal. Make sure to create a PR for each task when merging code. The PR body should contain the full link to the task: :::BlockQuote{indent="1"} The Description of the task should start with \`Proposal:\ ::: - full URL link to proposal'Once done, **All tasks** will be connected to that proposal. When working on any task, create a PR while merging code.PR body should have a full link to the task link. The issues will start getting PR data and what all PRs are there for it. The same will be flown to Proposal. If Cherry Pick PR, the PR body should have a full link to the task and also a link to the default branch PR full link. So that we can track cherry-pick PR for which PR in master. - Enable protection rules for release branches to prevent creation/deletion. - Provide a release format prefix, e.g., 'release/' (BitBucket's default format). For more information on BitBucket configuration, please see: Atlassian Bitbucket, Bitbucket Cloud and Bitbucket Server. ## GitHub and GitLab: - On GitHub and GitLab, use the 'Epic' label for epic tasks and 'User Story' for user stories. - Link user stories to their epic tasks using a specific format in the description: :::BlockQuote{indent="1"} The Description of the issue should start with \`Epic:\ full URL link to the epic \[the label created on the first step and here should be the same] ::: - Once done, **All stories **will be connected to that Epic - When working on any story, make sure you create a PR for the same while merging code. - PR body should have a full link to the user story task. - The issues will start getting PR data and what all PRs are there for it and flown to Epic. - If Cherry Pick PR, the PR body should have a full link to the user story task and also a link to the default branch PR full link. So that we can track cherry-pick PR for which PR in master. - For Cherry Pick PRs, include the full link to the user story task and the default branch PR full link in the PR body for tracking. - Enable protection rules for release branches. - Provide a release format prefix, e.g., 'release-20' (all releases should start with this). For more information on GitHub and GitLab configuration, please refer to the following links: GitHub and GitHub enterprise configuration and GitLab. ## Azure DevOps: - In Azure DevOps, create feature and user story tasks for handling epics. - Connect user stories to their epic tasks using a specific format in the description: Feature:\ followed by the full URL link to the feature. Create a PR for each story when merging code and include the full link to the user story in the PR body. The Description of the user story should start with: :::BlockQuote{indent="1"} \`Feature:\ full URL link to feature ::: - Once done, **All stories** will be connected to that Feature. - When working on any story, create a PR while merging code. PR body should have a full link to the user story task. The issues will start getting PR data and what all PRs are there for it and the same will be flown to Epic. - If Cherry Pick PR, the PR body should have a full link to the user story task and also a link to the master branch PR full link, so that we can track cherry-pick PR for which PR in master - Enable protection rules for release branches. - Provide a release format prefix, e.g., 'release-20' (all releases should start with this). For more information on Azure DevOps configuration, please see: [Configure Azure boards and repository](docId\:mJeSRzumHYtbvJd8W4sNJ) Once the release cut is done and the release branch is created, it automatically links all releases with User Stories. The Epic Change lead time calculation is determined from the first User Story's first PR merge date to the Last User Story's last merge and release deployment time. To use Jira as an issue-tracking tool and another source control tool, you must provide the SCM Host URL when configuring the Jira Connection. Note that if you specify a separate source tool in the SCM Host URL, a separate IAM connection for that specific source tool should also be established. ## Change failure rate (CFR) For consistent data collection, ensure you format the 'short description' field in the change request as follows: - '\*\*\*deployment to ENVIRONMENTNAME \*\*\* of release RELEASENAME \*\*\*' :::hint{type="info"} For "deployment to" and "of release" are required keywords. The placeholders marked with three asterisks (\*\*\*) should be replaced with appropriate values. ::: The following image depicts the example of a short description field in a change request. Data will be visualized when incidents are in a closed state. The Incident should also be mapped to the initiating ChangeRequest by giving the change request ID in the Related Records section **Change Request** and **Cause By Change field**. # Linking incidents with change requests MTTR calculations are performed for Incidents that are either in a **closed** or **resolved** state. All the incidents that are moved to a resolved or closed state within 180 days are synched. While creating Incidents, the **Configuration Item** field should be populated, which will be mapped to **TechnicalServiceName** in . If the Configuration Item field is not populated, then by default, **No CI** will be marked for such incidents and reflected in the **Technical Service** column of the MTTR details page. To correlate incidents with their respective Change Requests, provide the **Change Request ID** in the **Related Records** section under the **Change Request** and **Cause By Change** fields when creating an incident. The following image presents sample information of ServiceNow. # Mean time to recovery Mean time to recovery calculations are performed for incidents in a **closed** or **resolved **state. When creating incidents, ensure that the **Configuration Item **field is populated. This field maps to the **Technical Service Name** in DI. In cases where the Configuration Item field is not populated, **No CI** will be labeled by default for such incidents, which will then be reflected in the **Technical Service** column of the MTTR details page. [title] Build JFrog configurations [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ Before software package and vulnerability data from **JFrog** can be analyzed in , you must configure JFrog as a tool for the application and onboard the associated Technical Service. This process enables to collect software package inventory and vulnerability information from JFrog repositories and artifacts. The setup consists of two main tasks: 1. **Configure the JFrog tool for the application** by adding a Software Package tool configuration in the Build phase. 2. **Onboard a Technical Service** associated with the application to define the JFrog repository and artifacts that DevOps Intelligence should monitor. Once the configuration and onboarding are complete, automatically synchronizes software package and vulnerability data from JFrog. # Setting up Tool application configurations from JFrog To onboard software package data, users need to edit the tool configuration for the application and then onboard the associated Technical Service. Follow this path the edit the tool application configuration from Jfrog: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Toolchain & Pipeline **→ **DevOps Intelligence **→ **Settings & Utilities **→ **Application Configurations** 2. Select the application you want to configure and expand it to display the following sections: - DevOps Phase - Tools Configured - Tools Having Technical Services 3. Click the **ellipsis (...)** and select **Edit Tool Configuration**. 4. On the Edit Configurations page, locate the **Build** phase and click **Add Tool Configuration**. 5. On the Edit Tool Configuration page, configure the following: - **Build Category**: Software Package - **Tool Engine**: JFrog - Ensure that the Tool Category **Out-of-the-box** is **checked, **this because software package and vulnerability data is collected from JFrog. 6. Review the available mappings for: - **Release Format** (can be modified if required). - **Severity**: Critical, High, Medium, and Low. - **Package Status**: Allowed, Denied, Need Approval, and Uncategorized. 7. Click **Add Configuration**, then select **Next.** 8. Click **Submit** to save the configuration. Once saved, the Software Package tool is added to the application and the configured tool should appear as JFrog under the application's configured tools. # Onboard Technical Service from JFrog After configuring the tool applications, users need to onboard a technical service to enable to collect software package and vulnerability data from JFrog. Follow these steps to onboard a Technical Service for a Software package: 1. Identify the application, **click the ellipsis (...)**, and select **Onboard Technical Service**. 2. On the **Onboard Technical Service** page, configure the following settings: - **DevOps Phase:** Build - **Build Category:** Software Package - **Tool Engine:** JFrog - **Connection:** Select the JFrog connection. - **Repository:** Select the repository containing the artifacts to be onboarded. - **Artifacts:** Select the artifacts for which package and vulnerability data should be collected. 3. Click **Onboard**. After the onboarding request is submitted, begins synchronizing software package data from the selected JFrog repository and artifacts. Once synchronization is complete, package and vulnerability information becomes available in the **Software Packages** dashboard, where users can analyze package inventory, review vulnerability details and identify the applications and technical services affected by vulnerable packages. [title] Bring your own build [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ In Build, you can access insights into Build Information from multiple tools through a centralized service. Build provides a graphical representation of activity around Builds of Projects & Pipelines. Currently, Travis CI and Jenkins are supported by Build, and you can also post Builds from other tools to DevOps Intelligence Build by utilizing the provided APIs. When data is populated from build tools, the Build page displays the information in a visual format. # Bringing data into To bring your own Build tools complete the following steps: 1. Go to the Tools Configuration page and navigate to the Tokens tab. 2. Click on Create Token and give a unique Token name. 3. Select Token Type as Build, then click on the Create button. 4. A new entry will be added to the table in the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} Note: To Post Data to the APIs mentioned below, Add the service Token (see: Create Service Token) to the **Authorization** header of the request. See cURL Example for reference ::: ## Format ### Step 1: TOKEN \{the-service-token-from-step1} **Example :** ```javascript TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX ``` ### Step 2:  API Reference **API: /services/builds** **URL : https\://\{devops-intelligence-host}/dash/api/build/v3/technical-services/builds** ## Parameters: | **Parameter** | **Type** | **Explanation** | **Example Value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | build \* | BODY | Build Data in Json | | ```javascript { "build_id": "5d69de78674bf10001ed4ce1", "href": "https://spinnaker-jenkins.gravitant.net/11/", "built_at": "2020-02-26T02:42:00.184Z", "duration": 100572000000, "repo_url": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/dash_ws_mesh", "branch": "master", "commit": "d2bff1ef9bed5939d3619cb8f926ab37db6f72b2", "build_engine": "Jenkins", "build_status": "pass", "technical_service_name": "MCMP-DevOps-Intelligence/testservice", "technicalserviceoverride": true } ``` ## cURL Example: ```curl curl --location --request POST 'https://peer-core.gravitant.net/dash/api/build/v3/technical-services/builds' \ --header 'Authorization: TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX' \ --header 'Content-Type: application/json' \ --data-raw '{ "build_id": "5d69de78674bf10001ed4ce1", "href": "https://spinnaker-jenkins.gravitant.net/job/dash/job/dash_ws_mesh/job/master/11/", "built_at": "2020-02-26T02:42:00.184Z", "duration": 100572000000, "repo_url": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/dash_ws_mesh", "branch": "master", "commit": "d2bff1ef9bed5939d3619cb8f926ab37db6f72b2", "build_engine": "Jenkins", "build_status": "pass", "technical_service_name": "MCMP-DevOps-Intelligence/testservice", "technicalserviceoverride": true }' ``` ## Response 200 ```curl { "build_id": "5d69de78674bf10001ed4ce1", "href": "https://spinnaker-jenkins.gravitant.net/job/dash/job/dash_ws_mesh/job/master/11/", "built_at": "2020-02-26T02:42:00.184Z", "build_status": "pass", "duration": 100572000000, "repo_url": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/dash_ws_mesh", "branch": "master", "event_type": "", "commit": "d2bff1ef9bed5939d3619cb8f926ab37db6f72b2", "pull_request_number": "", "build_engine": "Jenkins", "technical_service_tag": null, "team_tag": null, "details": null, "technical_service_name": "MCMP-DevOps-Intelligence/testservice" } ``` ## Build Request Body Explained | **Field** | **Data Type** | **Explanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | build\_id\* | string | Object ID | 5d69de78674bf10001ed4ce1 | | href | string | Page URL | https\://peer-core.gravitant.net/dash/api/build/v3/builds/76231 | | built\_at\* | string | Build start time In **UTC** | 2020-05-26T02:42:00.184Z | | build\_status\* | string | The build status | pass, fail, passed, failed | | duration\* | uint64 | Time required to run build in **nanoseconds** | 100572000000 | | repo\_url | string | Git repository URL | https\://github.com/test\_servide | | branch | string | Branch name | master, validation, testing | | event\_type | string | The event that triggered the build | push, pull\_request, cron, API, etc | | commit | string | Git Commit ID | d2bff1ef9bed5939d3619cb8f926ab37db6f72ef | | pull\_request\_number | string | Git Pull Request number | 34 | | build\_engine\* | string | The name of the build engine | Travis CI, Jenkins, etc | | details | string | Additional details if any to be provided with the build(raw json file contents) | Raw JSON | | technical\_service\_name\* | string | technicalServiceName is an abstraction for projects, repositories, and pipelines in DevOps intelligence(project, repo, pipeline name) | MCMP-DevOps-Intelligence/testservice | | technicalserviceoverride | boolean | Override flag for the technical service | true | [title] Bring your own develop [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ As a user, you can integrate your own development tools to gain insight into your development environment. This includes issues, defects, commits, and pull requests for technical services. With our Develop page, you can easily track the progress of your development tasks and keep a finger on the pulse of your technical services. # Bringing data into To bring your own Deploy tools complete the following steps: 1. Go to the  Tools Configuration page and navigate to the Tokens tab. 2. Click on Create Token and give a unique Token name. 3. Select Token Type as Develop, then click on the Create button. 4. A new entry will be added to the table. In the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} Note: To Post Data to the APIs mentioned below, Add the service Token (see: Create Service Token) to the **Authorization** header of the request. See the cURL Example for reference ::: # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example :** `TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX` **Step 2:  API Reference** **API : /technical-services/issues** **URL : https\://\{the-service-token-from-step1}/dash/api/develop/v3/technical-services/issues** **Parameters** | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Post issues\* | BODY | Develop issues data in json | | | | | | | ```javascript { "assignees": [ "Developer" ], "category": "bug", "created_at": "2020-11-27T07:20:50.52Z", "created_by": "Tester", "endpoint_hostname": "https://github.kyndryl.net", "endpoint_technical_service_id": "tech_service_id", "issue_engine": "GitHub", "labels": [ "DI3.0_defect" ], "priority": "high", "provider_engine": "GitHub", "href": "https://dash.gravitant.net/dash/api/develop/v3/issues", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/issues/1230", "provider_id": "023456789", "provider_url_key": "1230", "severity": "sev3", "state": "open", "technical_service": "testing2", "technical_service_override": true, "technical_service_tag": { "GITHUB-NAMES": "DI/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "DI", "GITHUB-REPO-ID": "30112", "GITHUB-REPO-NAME": "hq", "GITHUB-IDS": "93210/30112" }, "title": "Posted data from swagger", "updated_at": "2022-10-27T07:20:50.52Z" } ``` ## cURL example **Request** ```curl cURL -X POST \ https://peer-core.gravitant.net/dash/api/develop/v3/technical-services/issues \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "assignees": [ "Developer" ], "category": "bug", "created_at": "2022-10-27T07:20:50.52Z", "created_by": "Tester", "endpoint_hostname": "https://github.kyndryl.net", "endpoint_technical_service_id": "tech_id1", "issue_engine": "GitHub", "labels": [ "DI3.0_defect" ], "priority": "high", "provider_engine": "GitHub", "href": "https://dash-gravitant.net/dash/api/develop/v3/issues", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/issues/1233", "provider_id": "023456789", "provider_url_key": "1233", "severity": "sev3", "state": "open", "technical_service": "testing2", "technical_service_override": true, "technical_service_tag": { "GITHUB-NAMES": "DI/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "DI", "GITHUB-REPO-ID": "30112", "GITHUB-REPO-NAME": "hq", "GITHUB-IDS": "93210/30112" }, "milestone_due_date": "2022-11-27T07:20:50.52Z", "milestone_name": "temp_milestone", "title": "Posted data from swagger", "updated_at": "2022-10-22T07:20:50.52Z" }' ``` **Response 200** ```javascript { "id": "636cd4e9f7db1c65132a4ad2", "entityID": "636cd4e9f7db1c65132a4ad2" } ``` ## Develop issue request body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------------- | | provider\_id\* | string | Object ID | 023456789 | | provider\_href\* | string | Endpoint url | https\://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/issues/1230 | | endpoint\_technical\_service\_id\* | string | Endpoint technical service ID | tech\_service\_id | | endpoint\_hostname | string | Endpoint host name | https\://github.kyndryl.net | | provider\_engine\* | string | Provider engine name | GitHub | | provider\_url\_key | string | Provider url ID | 1230 | | category\* | string | The develop category | Bug | | created\_at\* | string | Date and time of issue | 2020-11-27T07:20:50.52Z | | state | string | State of the issue | Open | | assignees | \[]string | For whom issue is assigned | Developer | | technical\_service\* | string | Technical service name is an abstraction for issue group | testing2 | | technical\_service\_override | boolean | Override flag for the service | true | ## API reference for pull requests ## API: /technical-services/pullrequests ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/pullrequests This API will post the develop pull requests data to . While posting the data. **Service token** is required to post the develop pull request record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Post pull requests\* | BODY | Develop pull requests data in json | | ```javascript { "created_at": "2022-10-18T07:20:50.52Z", "created_by": "Tester", "endpoint_hostname": "https://github.kyndryl.net", "provider_id": "30110", "endpoint_technical_service_id": "12345678", "href": "https://dash.gravitant.net/dash/api/develop/v3/pullrequests", "pr_engine": "GitHub", "provider_engine": "GitHub", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/4001", "pull_number": 4001, "state": "open", "title": "This for BYOD testing PRs", "technical_service": "DI/hq", "technical_service_tag": { "GITHUB-NAMES": "DI/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "DI", "GITHUB-REPO-ID": "30112", "GITHUB-REPO-NAME": "hq", "GITHUB-IDS": "93210/30112" }, "updated_at": "2022-10-20T07:20:50.52Z", "technical_service_override": false } ``` ## cURL example **Request** ```curl cURL -X POST \ https://peer-core.gravitant.net/dash/api/develop/v3/technical-services/pullrequests \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "created_at": "2022-10-18T07:20:50.52Z", "created_by": "Developer", "endpoint_hostname": "https://github.kyndryl.net", "endpoint_technical_service_id": "mytest", "href": "https://dash.gravitant.net/dash/api/develop/v3/pullrequests", "pr_engine": "GitLab", "provider_engine": "GitLab", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/test", "pull_number": 3001, "state": "closed", "title": "This for BYOD testing for test", "technical_service": "MCMP-DevOps-Intelligence/test", "technical_service_tag": { "GITHUB-NAMES": "MCMP-DevOps-Intelligence/test", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "MCMP-DevOps-Intelligence", "GITHUB-REPO-ID": "30000", "GITHUB-REPO-NAME": "test", "GITHUB-IDS": "93210/30000" }, "updated_at": "2022-10-19T07:20:50.52Z", "technical_service_override": true } ``` **Response 200** ```curl { "id": "636cd4e9f7db1c65132a4ad2", "entityID": "636cd4e9f7db1c65132a4ad2" } ``` ## Develop PR request body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------------ | | provider\_id\* | string | Object ID | 30110 | | technical\_service\* | string | Technical service name is an abstraction for develop pull request group | DI/hq | | provider\_href\* | string | Endpoint url | https\://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/4001 | | endpoint\_technical\_service\_id\* | string | Endpoint technical service ID | 12345678 | | endpoint\_hostname | string | Endpoint host name | https\://github.kyndryl.net | | created\_at\* | string | Date and time of pull request | 2022-10-18T07:20:50.52Z | | state | string | State of the pull request | open | | pr\_engine\* | string | Pull request engine name | GitHub | | pull\_number | string | Pull request number | 4001 | | technical\_service\_override | boolean | Override flag for the service | false | ## API reference for Commits ## API: /technical-services/commits ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/commits This API will post the develop commits data to DevOps Intelligence. While posting the data. **Service token** is required to post the develop commit record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Post commits\* | BODY | Develop commits data in json | | ```javascript { "created_at": "2022-10-28T07:20:50.52Z", "created_by": "Tester", "endpoint_hostname": "https://github.kyndryl.net", "provider_id": "30110", "endpoint_technical_service_id": "12345678", "href": "https://dash.gravitant.net/dash/api/develop/v3/commits", "scm_engine": "GitHub", "provider_engine": "GitHub", "provider_href": "https://github.kyndryl.net/DI/hq/84e1ad4", "commit_url": "https://github.kyndryl.net/DI/hq/84e1ad4", "sha": "84e1ad584e1ad5", "technical_service": "DI/hq", "technical_service_tag": { "GITHUB-NAMES": "DI/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "DI", "GITHUB-REPO-ID": "30112", "GITHUB-REPO-NAME": "hq", "GITHUB-IDS": "93210/30112" }, "technical_service_override": true } ``` ## cURL example **Request** ```curl cURL -X POST \ https://peer-core.gravitant.net/dash/api/develop/v3/technical-services/commits \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "created_at": "2022-10-18T07:20:50.52Z", "created_by": "Developer", "endpoint_hostname": "https://github.kyndryl.net", "provider_id": "301103", "endpoint_technical_service_id": "mytest", "href": "https://dash.gravitant.net/dash/api/develop/v3/pullrequests", "scm_engine": "GitHu", "provider_engine": "GitHub", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad6", "commit_url": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad6", "technical_service": "MCMP-DevOps-Intelligence/hq", "technical_service_tag": { "GITHUB-NAMES": "MCMP-DevOps-Intelligence/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "MCMP-DevOps-Intelligence", "GITHUB-REPO-ID": "30110", "GITHUB-REPO-NAME": "hq", "GITHUB-IDS": "93210/30110" }, "technical_service_override": true }' ``` **Response 200** ```curl { "id": "636cd4e9f7db1c65132a4ad2", "entityID": "636cd4e9f7db1c65132a4ad2" } ``` ## Develop commit request body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------- | | provider\_id\* | string | Object ID | 301103 | | technical\_service\* | string | Technical service name is an abstraction for develop commit group | MCMP-DevOps-Intelligence/hq | | provider\_href\* | string | Endpoint url | https\://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad6 | | endpoint\_technical\_service\_id\* | string | Endpoint technical service ID | mytest | | endpoint\_hostname | string | Endpoint host name | https\://github.kyndryl.net | | created\_at\* | string | Date and time of commit | 2022-10-18T07:20:50.52Z | | provider\_engine\* | string | Provider engine name | GitHub | | commit\_url\* | string | Commit endpoint url | https\://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad6 | | technical\_service\_override | boolean | Override flag for the service | true | ## Patch API reference for Issues ## API: /technical-services/issues ## URL: https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/issues This API will patch the develop issues data in DevOps Intelligence. While patching the data, **Service token** is required to patch the develop issue record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Patch issues\* | BODY | Patch issues data in json | | ```javascript { "assignees": "AlbertD", "category": "bug", "issue_engine": "GitHub", "labels": "bug", "priority": "High", "provider_url_key": "2233", "severity": "sev3", "state": "open", "technical_service": "my-org/my-repo", "title": "This is a bug", "updated_at": "2022-11-12T07:20:50.52Z" } ``` ## cURL example **Request** ```curl cURL -X 'PATCH' \ 'dash/api/develop/v3/technical-services/issues' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "assignees": "AlbertD", "category": "bug", "issue_engine": "GitHub", "labels": "bug", "priority": "High", "provider_url_key": "2233", "severity": "sev3", "state": "open", "technical_service": "my-org/my-repo", "title": "This is a bug", "updated_at": "2022-11-12T07:20:50.52Z" }' ``` **Response 200** ```javascript { "id": "635b8ef2eddcd1cedd51f539", "unique_technical_service_id": "635b8ef297754f22c914142e", "provider_id": "9876543210", "technical_service": "testing2", "technical_service_id": "635b9290e3bec9cf5b61ea96", "connectionId": "", "connectionName": "", "application_relationships": [], "href": "https://malathi-byod.gravitant.net/dash/api/develop/v3/issues/1230", "service_href": "", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/issues/1230", "endpoint_technical_service_id": "tech_service_id", "endpoint_hostname": "https://github.kyndryl.net", "provider_engine": "GitHub", "provider_url_key": "1230", "title": "patch api testing", "priority": "low", "severity": "high", "category": "other", "created_at": "2022-10-30T07:20:50.52Z", "updated_at": "2022-11-02T07:20:50.52Z", "state": "open", "issue_engine": "GitHub", "labels": null, "issue_type": "", "description": "", "scmengine": "", "created_by": "Malathi", "assignees": [ "Malathi" ], "milestone_name": "milestone1", "milestone_due_date": "2022-11-12T07:20:50.52Z", "ismetered": true, "technical_service_tag": { "SERVICE-UNIQUE-ID": "GitHub:https://github.kyndryl.net:tech_service_id:testing2", "additionalProp1": "", "additionalProp2": "", "additionalProp3": "" }, "pr_details": null, "child_issues": null, "is_metric_applicable": false, "technical_service_override": false } ``` ## Patch issue request body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------------------- | ---------------------------------------------- | | priority | string | Priority of the issue | high | | severity | string | Severitu of the issue | sev3 | | issue\_engine\* | string | issue engine name | GitHub | | provider\_url\_key | string | Provider url ID | 1230 | | category\* | string | The develop category | Bug | | updated\_at\* | string | Date and time of update | 2022-11-12T07:20:50.52Z | | state | string | State of the issue | open | | assignees | \[]string | For whom issue is assigned | Developer | | technical\_service\* | string | Technical service name is an abstraction for issue group | my-org/my-repo | | title | string | Title of the issue | This is new bug | ## Patch API reference for Pull Requests ## API: /technical-services/pullrequests ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/pullrequests This API will patch the develop pullrequests data in . While patching the data, **Service token** is required to patch the develop pullrequest record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Patch pullrequests\* | BODY | Patch pullrequests data in json | | ```javascript { "description": "Fixing the bug related to issue_1234", "merge_commit_sha": "3b2e89ee3fedc08442e2e358b91447cda69c996e", "merged_at": "2022-11-12T07:20:50.52Z", "pr_engine": "GitHub", "pull_number": 4000, "release_name": "release2022-11-16", "state": "open", "technical_service": "my-org/my-repo", "title": "This is fix for a bug", "updated_at": "2022-11-12T07:20:50.52Z" } ``` ## cURL example **Request** ```curl cURL -X 'PATCH' \ 'dash/api/develop/v3/technical-services/pullrequests' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "description": "Fixing the bug related to issue_1234", "merge_commit_sha": "3b2e89ee3fedc08442e2e358b91447cda69c996e", "merged_at": "2022-11-12T07:20:50.52Z", "pr_engine": "GitHub", "pull_number": 4000, "release_name": "release2022-11-16", "state": "open", "technical_service": "my-org/my-repo", "title": "This is fix for a bug", "updated_at": "2022-11-12T07:20:50.52Z" }' ``` **Response 200** ```curl { "id": "635137e1729632053dc37db5", "unique_technical_service_id": "6350f46997754f22c90a0886", "provider_id": "301102", "technical_service": "MCMP-DevOps-Intelligence/hq", "technical_service_id": "6350f4c0e3bec9cf5b61ea8c", "connectionId": "", "connectionName": "", "application_relationships": [], "href": "https://malathi-byod.gravitant.net/dash/api/develop/v3/pullrequests/4000", "service_href": "", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/4000", "endpoint_technical_service_id": "122345678", "endpoint_hostname": "https://github.kyndryl.net", "provider_engine": "GitLab", "created_at": "2022-10-18T07:20:50.52Z", "updated_at": "2022-11-02T07:20:50.52Z", "created_by": "Malathi", "pr_engine": "GitLab", "state": "open", "title": "patch api testing", "merged_at": "0001-01-01T00:00:00Z", "release_name": "release12", "description": "", "pull_number": 4002, "ismetered": true, "ischerrypick": false, "technical_service_tag": { "GITHUB-IDS": "93210/30110", "GITHUB-NAMES": "MCMP-DevOps-Intelligence/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "MCMP-DevOps-Intelligence", "GITHUB-REPO-ID": "30110", "GITHUB-REPO-NAME": "hq", "SERVICE-UNIQUE-ID": "GitLab:https://github.kyndryl.net:122345678:MCMP-DevOps-Intelligence/hq" }, "technical_service_override": false } ``` ## Patch Pull request body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------------------- | ---------------------------------------------- | | merge\_commit\_sha | string | SHA of commit | b2e89ee3fedc08442e2e358b91447cda69c996e | | pr\_engine\* | string | pr engine name | GitHub | | pull\_number | int | Pull request Number | 230 | | category\* | string | The develop category | bug | | updated\_at\* | string | Date and time of update | 2022-11-12T07:20:50.52Z | | merge\_at\* | string | Date and time of merge | 2022-11-12T07:20:50.52Z | | state | string | State of the PR | open | | assignees | \[]string | For whom issue is assigned | Developer | | technical\_service\* | string | Technical service name is an abstraction for issue group | my-org/my-repo | | title | string | Title of the issue | This is new PR | | description | string | Description of the PR | Fixing the bug | ## Patch API reference for Commits ## API: /technical-services/commits/\{commitID} ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/commits/\{commitID} This API will patch the develop commits data in . While patching the data, **Service token** is required to commit the develop commit record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------------------- | ---------------------------------------------- | | CommitID\* | PATH | Commit ID is the value received after posting the commit | 2233c878609c251f44a1bbbb | ## cURL example **Request** ```curl cURL -X 'PATCH' \ 'dash/api/develop/v3/technical-services/commits/635b8ef2eddcd1cedd51f539' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "comments": "Committing the fix for BYOD", "parent_ids": "3b2e89ee3fedc08442e2e" }' ``` **Response 200** ```curl { "id": "6357a9d8d1c04c9de360716f", "unique_technical_service_id": "6352330097754f22c90c12bf", "provider_id": "301103", "technical_service": "MCMP-DevOps-Intelligence/hq", "technical_service_id": "63523380e3bec9cf5b61ea90", "connectionId": "", "connectionName": "", "application_relationships": [], "href": "https://malathi-byod.gravitant.net/dash/api/develop/v3/Commits/84e1d4", "service_href": "", "provider_href": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad4", "endpoint_technical_service_id": "12245678", "endpoint_hostname": "https://github.kyndryl.net", "provider_engine": "GitHub", "sha": "", "comments": "Committing the fix for BYOD", "created_at": "2022-10-18T07:20:50.52Z", "scm_engine": "GitHu", "created_by": "Malathi", "commit_url": "https://github.kyndryl.net/MCMP-DevOps-Intelligence/hq/84e1ad4", "lines_added": 0, "lines_deleted": 0, "total_lines": 0, "committer": { "committer_id": "", "name": "", "email": "" }, "parent_ids": null, "ismetered": true, "technical_service_tag": { "GITHUB-IDS": "93210/30110", "GITHUB-NAMES": "MCMP-DevOps-Intelligence/hq", "GITHUB-ORG-ID": "93210", "GITHUB-ORG-NAME": "MCMP-DevOps-Intelligence", "GITHUB-REPO-ID": "30110", "GITHUB-REPO-NAME": "hq", "SERVICE-UNIQUE-ID": "GitHu:https://github.kyndryl.net:12245678:MCMP-DevOps-Intelligence/hq" }, "technical_service_override": false } ``` ## Patch Commits body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------- | ---------------------------------------------- | | comments | string | Comments about the commit | This is new commit for BYOD | | parent\_ids | string | Parent ids of the commit | 6357a9d8d1c04c9de360716f | ## Delete API reference for Issues ## API: /technical-services/issues ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/issues This API will delete the develop issues data from . While deleting the data, **Service token** is required to delete the develop issues record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Delete issues\* | BODY | Delete issues data in json | | ```javascript { "endpoint_hostname": "https://github.com", "endpoint_technical_service_id": "my-org/my-repo", "provider_url_key": "4433" } ``` ## cURL example **Request** ```curl cURL -X 'DELETE' \ 'dash/api/develop/v3/technical-services/issues' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "endpoint_hostname": "https://github.com", "endpoint_technical_service_id": "my-org/my-repo", "provider_url_key": "4433" }' ``` **Response 200** `"Deleted Successfully"` ## Delete issues body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------- | ---------------------------------------------- | | endpoint\_hostname | string | End point hostname | https\://github.com | | endpoint\_technical\_service\_id | string | ID of endpoint Technical serrvice | my-org/my-repo | | provider\_url\_key | string | Issue ID | 4433 | ## Delete API reference for Pullrequests ## API: /technical-services/pullrequests ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/pullrequests This API will delete the develop pullrequests data from . While deleting the data, **Service token** is required to delete the develop pullrequests record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Delete pullrequests\* | BODY | Delete pullrequests data in json | `{ "endpoint_hostname": "https://github.com", "endpoint_technical_service_id": "my-org/my-repo", "pull_number": 1234 }` | ## cURL example **Request** ```curl cURL -X 'DELETE' \ 'dash/api/develop/v3/technical-services/pullrequests' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' \ -H 'Content-Type: application/json' \ -d '{ "endpoint_hostname": "https://github.com", "endpoint_technical_service_id": "my-org/my-repo", "pull_number": 1234 }' ``` **Response 200** `"Deleted Successfully"` ## Delete PR body explained | **Field** | **Data type** | **Explanation** | **Example value** | | -------------------------------------- | ------------------------------------------ | -------------------------------------------- | ---------------------------------------------- | | endpoint\_hostname | string | End point hostname | https\://github.com | | endpoint\_technical\_service\_id | string | ID of endpoint Technical serrvice | my-org/my-repo | | pull\_number | int | PullRequest Number | 1234 | ## Delete API reference for commits ## API: /technical-services/commits/\{commitID} ## URL : https\://\{devops-intelligence-host}/dash/api/develop/v3/technical-services/commits/\{commitID} This API will delete the develop commits data from . While deleting the data, **Service token** is required to delete the develop commits record. ## Parameters | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------------------- | ---------------------------------------------- | | CommitID\* | PATH | Commit ID is the value received after posting the commit | 2233c878609c251f44a1bbbb | ## cURL example **Request** ```curl cURL -X 'DELETE' \ 'dash/api/develop/v3/technical-services/commits/636cd4e9f7db1c65132a4ad2' \ -H 'accept: application/json' \ -H 'Authorization: Token x0VqMwii93HnzfWwGI-uxJniZ8_clVZa2I02i3u2rXw2ZalmxntfOglTCqSE0uUZ' }' ``` **Response 200** `"Deleted Successfully"` [title] Test tools [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Test-supported tools are integrations and services used to measure the status, success rate, duration, and quality of individual builds and test executions. These tools provide test teams, engineers, and development managers with real-time visibility into software delivery performance through actionable metrics and centralized reporting. By consolidating build and testing insights into a single observability layer, teams can monitor delivery pipelines, identify bottlenecks, improve release quality, and accelerate issue resolution across hybrid IT environments. The platform supports the following industry-standard tools and integrations to collect, analyze, and visualize build and test data from your environments, including cloud-native ecosystems such as GCP Cloud Build. # Tools supported in the test phase - [Azure DevOps Test Plan configuration](docId:_ivMh6FF-qBYnIfi_y2pa): Enable teams to manage manual and automated testing within the software development lifecycle. - [Jenkins Plugin configuration](docId\:yTBqyzjCxLqaw8gRQW2ZV): Enables the platform to capture build metrics, pipeline execution results, deployment activity, and testing outcomes, providing enhanced visibility into software delivery pipelines and operational efficiency. - [SonarQube Enterprise Edition configuration](docId\:l6KMPPnIuAPFxsi9MEE_7): SonarQube is a code quality and security analysis platform that helps development teams identify bugs, vulnerabilities, and technical debt. - [GCP Cloud Build configuration](docId\:PuMeSYVf67mJYI49-3-JV): Google Cloud Build is a fully managed continuous integration and build service provided by Google Cloud Platform (GCP). - [QMetry configuration](docId\:J5HVBebAKE4560_ojHhnI): QMetry is a test management platform designed to support agile and DevOps testing practices. [title] Linking and de-linking technical services [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Technical services configuration page/ Understand how to manage technical service links that associate one technical service with another in accordance with the pipeline requirements to ensure technical compliance. # Linking technical service provides a feature to link technical services. Auto-linked technical services can be linked to another technical service in accordance with pipeline requirements. The following are key points to consider regarding the linking technical service feature: - Technical services are auto-linked for a few endpoints but mapping your technical service is always a good idea. For example, if, in the configure technical service table, you see multiple entries for a single service linked to different endpoints, you can map them together to a single service as your pipeline. - Scenarios where auto-linking of technical service is possible: - If the same tools provide data to two pages, say Jenkins provides test and build data. - If Repository Name can be retrieved from the data. Say Travis CI and Git service sharing the same repoName gets auto-linked. - Suppose a repo in git is named demo121 and in Travis (build) is demo121 but in Sonarqube (test) the name of the project linked to the build tool is releasedemo. In that case, the releasedemo of Sonarqube(test) can be mapped/ linked to the above service (demo121) resulting in creating a single service for your pipeline. :::hint{type="info"} Note: This stage is important as it has a direct impact on metering. ::: To link Technical services, perform the following steps: 1. Go to **Settings & Utilities**→ **Configure Technical service**. 2. The Technical Service tab shows a list of filters that can be used to filter and see data in the table below the filters. The following is the list of filters available to select from: - Application - Develop tool - Build tool - Test tool - Deploy tool - Run tool - Static scan - Container vulnerability scan - Dependency check 3. After selecting any required filters, a list of technical services will appear, where technical services can be clicked on. For Example, the **nginx** technical service discovered from **Google** and choose the Nginx technical service discovered by **XUNIT** (discovered using **BYOT**) and click on **Update**. 4. When the previous step has been completed, you see that Nginx technical service is discovered by different tools and is now mapped to a single technical service, and a pipeline is created with the **test** stage in Kyndryl Modern Operations Applications – , this technical service will be visible in the Test dashboard of . At this point, if a search is performed for Nginx technical service, you see that both **run** and **test **technical services have been linked together as per the pipeline requirements. ### Important: - Linking technical services of the same **type** is not possible, for example, a technical service registered by Sonarqube and BYOT is not possible as both will have the same service type i.e. **test**. - If a technical service registered by **Jira** and **Git** are linked, two separate rows will be shown in the Develop dashboard Technical service view with the same name but will show individual tools data. - After Linking technical services manually, technical services which were selected for linking on the **Link Technical service** tab will no longer be visible on the main technical service page as they will be mapped to a technical service, but this technical service can still be seen on the **Linked Technical service** tab. # De-linking technical service  provides a feature to de-link a previously linked service. Auto-linked technical services can be de-linked and linked to other technical services per the pipeline requirements. To de-link Technical service, perform the following steps: 1. Go to **Settings & Utilities** → **Configure Technical service**. 2. Select any technical service that was previously linked (for example, Nginx). 3. Select **Linked Technical service** tab. 4. Select the technical service to be **delinked**. 5. Select **Delink Technical service**, continue with the confirmation. 6. On Confirmation, the request for de-linking will be accepted and the technical service will start existing as an independent technical service. :::hint{type="info"} Note: The request will be accepted for de-linking, the individual technical service might take one sync interval (up to 5 minutes) to show up on the respective dashboards. ::: [title] DevOps performance metrics [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Performance metrics are critical to the DevOps lifecycle in ensuring Continuous Development and Delivery. With each development cycle, development managers are tasked with understanding an array measurement that indicate both the production and quality of the codebase as it is continuously deployed. Using known metrics, managers, developers and testers can evaluate the performance of the team, themselves and the code, ensuring a quality product that is constantly being enriched by enhancements as new technologies come on line. Kyndryl supports the acquisition of performance metrics that can assist in these evaluations, optimizing mission critical critical activities. DevOps performance metrics are pivotal for DevOps teams, because they offer insights into software development, delivery, and maintenance efficiency. They distinguish between high, medium, and low-performing teams, establishing a standard that aids organizations in continuously enhancing DevOps performance for superior business results. These metrics facilitate continuous improvement by offering tangible indicators for iterative adjustments and refinement. They also aid in benchmarking a team's performance against industry standards, promoting goal setting and performance enhancement. The following metrics are supported: - [Dora metrics](docId\:I2CiIGRS_sU6uk7IRDGBE) Learn about support of Google DORA performance metrics, and their critical role in fine tuning your continuous delivery processes. - [Developer productivity metrics](docId\:SGvENgqypKpcizSOcZ2H1) Learn about support of developer productivity metrics, and their critical role in fine tuning your developer processes. [title] AWS CodeCommit configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/AWS configuration/ # Data syncing AWS CodeCommit is a version control service used to privately store and manage assets such as documents, source code, and binary files in AWS provider systems. supports the integration of CodeCommit using a basic configuration process as explained in subsequent text. For the initial synchronization, our system is designed to comprehensively pull the last six months of data from the specified AWS CodeCommit APIs. After this thorough first-time data retrieval, subsequent synchronizations will employ a delta sync approach for the PullRequests and Commits APIs, fetching only the data that has been updated since the last sync time. For the remaining APIs listed below, the system will continue to retrieve the complete dataset during each sync to ensure full data integrity and consistency. Data syncing within AWS CodeCommit is broken down into three sets of synchronization specifications as follows: - **Initial sync**: The system pulls the last 6 months of data for the AWS CodeCommit APIs during the first sync. This is to fetch historical data and set a baseline for future synchronizations. - **Subsequent syncs**: A delta sync process starts for PullRequests and Commits APIs from the second sync. This means that instead of pulling all data every time, the system only fetches the data concerning the time greater than the last sync time. In other words, it only syncs the new or updated data since the previous synchronization. This approach helps reduce the amount of data transferred and optimizes the sync process. - **Other APIs**: For the other APIs mentioned in the text, the system pulls all data every time during the sync process. This might be because these APIs are expected to have a smaller data volume or due to specific integration requirements. # Endpoint API details Endpoint API Details provides information about various API endpoints interacting with AWS CodeCommit. These endpoints, Repos, Branches, Commitss, PullRequests and PullRequest Details, allow you to fetch different data types from the CodeCommit service ## Repos - Request Method: POST - URL: CodeCommit\_20150413.ListRepositories - Purpose: List all repositories in the AWS CodeCommit account. - API Response: ```javascript { "repositories":[ { "repositoryId": "f7579e13-b83e-4027-aaef-650c0EXAMPLE", "repositoryName": "MyDemoRepo" }, { "repositoryId": "cfc29ac4-b0cb-44dc-9990-f6f51EXAMPLE" "repositoryName": "MyOtherDemoRepo" } ] } ``` ## Branches - Request Method: POST - URL: CodeCommit\_20150413.ListBranches - Purpose: List all branches within a specific repository. - API Response: ```javascript { "branches":[ "main", "MyNewBranch" ] } ``` ## Commits - Request Method: POST - URL: CodeCommit\_20150413.GetCommit - Purpose: Retrieve detailed information about a specific commit. - API Response: ```javascript { "commit": { "commitId": "12345678EXAMPLE", "additionalData": "", "committer": { "date": "1484167798 -0800", "name": "Mary Major", "email": "mary_major@example.com" }, "author": { "date": "1484167798 -0800", "name": "Mary Major", "email": "mary_major@example.com" }, "treeId": "347a3408EXAMPLE", "parents": [ "7aa87a0EXAMPLE" ], "message": "Fix incorrect variable name\n" } } ``` ## PullRequests - Request Method: POST - URL: CodeCommit\_20150413.ListPullRequests - Purpose: List all pull request IDs within a specific repository. - API Response: ```javascript { "nextToken": "exampleToken", "pullRequestIds": ["2","12","16","22","30","23","35","39","47"] } ``` ## PullRequest Details - Request Method: POST - URL: CodeCommit\_20150413.GetPullRequest - Purpose: Retrieve detailed information about a specific pull request. - API Response: ```javascript { "pullRequest": { "approvalRules": [ { "approvalRuleContent": "{\"Version\": \"2018-11-08\",\"Statements\": [{\"Type\": \"Approvers\",\"NumberOfApprovalsNeeded\": 2,\"ApprovalPoolMembers\": [\"arn:aws:sts::123456789012:assumed-role/CodeCommitReview/*\"]}]}", "approvalRuleId": "dd8b17fe-EXAMPLE", "approvalRuleName": "2-approver-rule-for-main", "creationDate": 1571356106.936, "lastModifiedDate": 571356106.936, "lastModifiedUser": "arn:aws:iam::123456789012:user/Mary_Major", "ruleContentSha256": "4711b576EXAMPLE" } ], "lastActivityDate": 1562619583.565, "pullRequestTargets": [ { "sourceCommit": "ca45e279EXAMPLE", "sourceReference": "refs/heads/bugfix-1234", "mergeBase": "a99f5ddbEXAMPLE", "destinationReference": "refs/heads/main", "mergeMetadata": { "isMerged": false }, "destinationCommit": "2abfc6beEXAMPLE", "repositoryName": "MyDemoRepo" } ], "revisionId": "e47def21EXAMPLE", "title": "Quick fix for bug 1234", "authorArn": "arn:aws:iam::123456789012:user/Nikhil_Jayashankar", "clientRequestToken": "d8d7612e-EXAMPLE", "creationDate": 1562619583.565, "pullRequestId": "27", "pullRequestStatus": "OPEN" } } ``` ## PullRequest Details - Request Method: POST - URL: CodeCommit\_20150413.GetPullRequest - Purpose: Retrieve detailed information about a specific pull request. - API Response: ```javascript { "pullRequest": { "approvalRules": [ { "approvalRuleContent": "{\"Version\": \"2018-11-08\",\"Statements\": [{\"Type\": \"Approvers\",\"NumberOfApprovalsNeeded\": 2,\"ApprovalPoolMembers\": [\"arn:aws:sts::123456789012:assumed-role/CodeCommitReview/*\"]}]}", "approvalRuleId": "dd8b17fe-EXAMPLE", "approvalRuleName": "2-approver-rule-for-main", "creationDate": 1571356106.936, "lastModifiedDate": 571356106.936, "lastModifiedUser": "arn:aws:iam::123456789012:user/Mary_Major", "ruleContentSha256": "4711b576EXAMPLE" } ], "lastActivityDate": 1562619583.565, "pullRequestTargets": [ { "sourceCommit": "ca45e279EXAMPLE", "sourceReference": "refs/heads/bugfix-1234", "mergeBase": "a99f5ddbEXAMPLE", "destinationReference": "refs/heads/main", "mergeMetadata": { "isMerged": false }, "destinationCommit": "2abfc6beEXAMPLE", "repositoryName": "MyDemoRepo" } ], "revisionId": "e47def21EXAMPLE", "title": "Quick fix for bug 1234", "authorArn": "arn:aws:iam::123456789012:user/Nikhil_Jayashankar", "clientRequestToken": "d8d7612e-EXAMPLE", "creationDate": 1562619583.565, "pullRequestId": "27", "pullRequestStatus": "OPEN" } } ``` [title] Software Packages [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ The **Software Packages** dashboard provides a centralized view of software packages and their associated vulnerabilities across applications and technical services that have been onboarded into DevOps Intelligence. The dashboard enables users to identify vulnerable packages, understand their severity and determine which applications and technical services are impacted, helping teams respond more quickly to security risks and remediation requirements. With this dashboard, users can: - View the total number of software packages across onboarded applications and technical services. - Identify packages that contain known vulnerabilities. - Analyze vulnerabilities by severity level, including Critical, High, Medium and Low. - Search for a specific package and determine which applications and technical services use it. - Review detailed vulnerability information for individual packages. - Export package and vulnerability data for further analysis and remediation planning. To use the Software Packages dashboard, the application and its associated technical services must first be onboarded into DevOps Intelligence. During onboarding, a connection is established to JFrog, which serves as the source of package and vulnerability data. # Software Packages page Once onboarding is complete, DevOps Intelligence collects package information from the selected repositories and artifacts, correlates that data with the associated applications and technical services and presents the results on the **Software Packages** page. This page provides a centralized view of software package inventory and vulnerability data across onboarded applications and technical services. The **Software Packages** page includes dashboard widgets and a detailed packages table that help users: - View the total number of software packages across onboarded applications and technical services. - Identify packages with known vulnerabilities and analyze them by severity level, including Critical, High, Medium and Low. - Determine which applications and technical services are affected by a specific package vulnerability. - Search for software packages and review detailed vulnerability information. - Export package and vulnerability data for further analysis and remediation planning. - Prioritize remediation efforts by identifying the applications, technical services and teams impacted by vulnerable packages. To access the Software Packages page, follow these steps: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** →**Platform Services** → **Toolchain & Pipeline** → **DevOps Intelligence **→ **Build **→ **Software Packages** # Software Packages dashboards The **Software Package dashboards** provide a high-level view of software package inventory and vulnerability data across onboarded applications and technical services. The dashboard widgets help users quickly identify vulnerable packages, analyze vulnerability severity and focus on packages that require remediation. Selecting a dashboard widget filters the package table to display the corresponding package results. The following dashboards are displayed on the Software Packages page: **Total Packages: **Displays the total number of software packages identified across all onboarded applications and technical services. This metric provides an overall view of the software package inventory being monitored in DevOps Intelligence. **Total Vulnerable Packages: **Displays the total number of packages that contain one or more known vulnerabilities. The widget also provides a breakdown by severity level, helping users assess the overall security risk across onboarded applications. **Critical Vulnerable Packages: **Displays the number of packages that contain critical vulnerabilities. Selecting this tile filters the dashboard to show only packages that require immediate attention and remediation. **High Vulnerable Packages: **Displays the number of packages that contain high-severity vulnerabilities. Selecting this tile filters the dashboard to show packages that present significant security risks and should be prioritized for remediation. **Non-Vulnerable Packages: **Displays the number of packages that do not currently contain any known vulnerabilities. This metric helps users understand the portion of their software inventory that is considered secure based on the latest scan results. # Software Packages table The **Software Packages** table provides a detailed view of software package inventory and vulnerability data collected from onboarded applications and technical services. The table works together with dashboard widgets, allowing users to focus on specific package categories and quickly identify affected applications and services. Users can use the **Search** field to locate specific packages within the current filtered results. The following data is displayed in the package table: - **Package Name:** The name of the software package identified within onboarded applications and technical services. - **Package Type:** The package manager or package type associated with the software package. - **Versions:** The version of the software package currently detected in the application or repository. - **License:** The software license associated with the package, helping users evaluate licensing and compliance requirements. - **Technical Service:** Identifies the technical service where the package is being used. A package can be associated with one or more technical services. Select the technical service link to view additional details about the service. If **+ View** is displayed, the package is associated with multiple technical services. Select **+ View** to display the complete list of associated technical services. - **Application:** The application that contains or uses the package, allowing users to determine where a package is deployed. - **Security Champion:** The security champion associated with the application or technical service. - **Total Vulnerabilities:** The total number of vulnerabilities identified for the package across all severity levels. - **Critical Vulnerabilities:** The number of critical-severity vulnerabilities identified for the package. - **High Vulnerabilities:** The number of high-severity vulnerabilities identified for the package. # Export Software Packages Use the **Export** option to download selected package records for further analysis, reporting, or remediation planning. To export package information, follow these steps: 1. Select one or more package records from the **Packages** table. **Export** option becomes available after one or more package records are selected from the table. 2. Click **Export** to download the exported file containing the selected package information for further analysis or remediation planning. [title] Azure DevOps Test Plan configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Test tools/ To enable data retrieval from Azure Test Plans by , it's crucial to set up an [Azure DevOps](docId:_ivMh6FF-qBYnIfi_y2pa) connection. This connection acts as a bridge, allowing seamless data flow and ensuring efficient integration of Azure Test Plans. The configuration process is straightforward, enabling Azure Test Plans' data within the robust framework of . **Access rights**: The connection must have the following access rights: - **Test management**: Read access right - **User profile**: Read access right To access templates, you must have specific roles; please see: [User and role management](docId\:vy_2iguh1sL9qJU_qE6t_) # Configuration You must choose the Project, Organization, and Test type, then add a Technical Service to establish the configuration; once you have made those selections complete the following steps to configure Azure DevOps Test plans: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → → **Settings & Utilities **→ **Tools Configuration**. 2. Select **Add configuration +** and a **Add tool configuration** form will be displayed; here, you will select: 3. Azure Test Plans from the **Tool Engine** dropdown menu. 4. The **Connection**, **Test type**, **Technical service**, **Organization** and **Project** each one from its dropdown menu 5. Select the **Add configuration** button at the bottom of the form. After completing the configuration, you can view the configuration details in the table on the configuration page. [title] Azure Pipelines configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ Learn how to configure for the integration of Azure Pipelines to broaden the observability of your hybrid IT estate. To enable effective data synchronization from Azure Pipelines Build into , it's crucial to establish an adequately configured Azure DevOps connection. This connection is a secure bridge between the two platforms, allowing seamless data transfer and management. Establishing this connection enables to leverage Azure Pipeline's robust capabilities, enhancing its monitoring and reporting features. This configuration enhances the accuracy and efficiency of data handling and amplifies the overall functionality of the tool. **Access rights**: The connection must have the following access right: - **Build**: Read access right. - **User profile**: Read access right. # Roles required As a user, your permissions determine the actions you can perform on the bring-your-own (BYO) template data. You must view, create, update, and delete roles to perform the respective actions. By default, these permissions are granted to the **Editor**. The **Viewer**, on the other hand, is only endowed with the view role. # Configuring for Azure Pipelines recent customers :::hint{type="info"} Note: The procedures in this section are valid only for customers onboarded 6 June 2024 or after. Procedures for legacy customers are provided in the subsequent section *Configuring * * for Azure Pipelines, legacy customers*. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Note: Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with Azure Pipeline as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure Azure Pipelines or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Build row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select **Build** for **Build Categories**. The service displays the **Tool Engine** field. 6. Select Azure Pipelines for **Tool Engine**. The service displays the **Status** field. 7. Enter the current statuses of the builds of the Azure Pipelines (Passed, Failed and In Progress, multiselect). 8. Click **Submit**. # Onboarding Azure Pipelines After configuring Azure Pipeline, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Build** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **Azure Pipelines** for **Tool Engine**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the Repository Name field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that Azure Pipelines has been fully configured. # Deleting Azure Pipelines as a technical service The administrator may, at will, delete the Azure Pipeline technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Build**. 4. Click **Delete Technical Service**. 5. Click Azure Pipelines for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. # Configuring for Azure Pipelines, legacy customers :::hint{type="info"} Note: The procedures in this section are valid only for customers onboarded before 6 June 2024. ::: You must choose the Project and Organization and add a Technical Service and additional configurations for customizations to establish the configuration. Extra settings are available to handle the states of **Passed**, **Failed** and **In Progress**, which are terms employed in the dashboards. You have the flexibility to introduce custom terms for these states. For instance, any value input under the **Passed** category will be interpreted as passed when displayed on the dashboard. Once you have made these selections complete the following steps to configure AWS CodePipeline: 1. Within Kyndryl application, click the overflow **Menu** button from the top left corner, navigate to and expand the menu. 2. Expand **Settings & Utilities,** then select **Tools Configuration.** 3. Select **Add configuration +** and a **Add tool configuration** form will be displayed; here, you will select: 4. **Azure Pipeline - Build** from the **Tool Engine** dropdown menu. 5. The **Connection**, **Test type**, **Technical service**, **Organization **and **Project** each one from its dropdown menu. 6. And you can fill in the** Additional configuration for customization** section at the bottom of the form if you would like to personalize it with custom terms for **Passed**, **Failed** or **In progress** statuses. 7. Select the **Add configuration** button at the bottom of the form. After completing the configuration, you can view the configuration details in the table on the configuration page. A sample image showcasing this is provided below for your reference. [title] AWS CodeBuild configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ To retrieve and analyze data from AWS CodeBuild, you must first set up and configure an AWS connection. This connection enables access to AWS CodeBuild information that can be used for reporting, monitoring, and operational improvements. Access rights Ensure the connection includes the following permissions: - Create - Delete - Update - View To access templates, you must also have the required roles. For more information, see: [AWS CodeBuild configuration](docId\:ETrkyCUWzAo2X5FcmI-Gd) # Configuring AWS CodeBuild for recent customers :::hint{type="info"} The steps in this section apply only to customers onboarded on or after 6 June 2024. If you are a legacy customer, refer to the section "Configuring AWS CodeBuild for legacy customers. ::: Use the following steps to configure AWS CodeBuild for your application: :::hint{type="info"} Tool configurations are linked to a specific application and DevOps phase. During setup, you will select both the application and the DevOps phase that AWS CodeBuild will support. ::: 1. Click **Settings & Utilities** → **Application Configuration** to view your existing applications. 2. Select the application you want to configure, or create a new application. 3. In the Build row for the selected application, click the overflow menu (vertical ellipsis). 4. Select **Add New Tool Configuration**. The **Add Tool Configuration** form opens. 5. For **Build Categories**, select **Build**. 6. For **Tool Engine**, select **AWS CodeBuild**. 7. In the **Status** field, select the build statuses you want to track, such as Passed, Failed, and In Progress. 8. Click **Submit** to save the configuration. # Onboarding AWS CodeBuild After configuring AWS CodeBuild, onboard the technical service to complete the setup. 1. Open the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The onboarding form opens. 3. For **DevOps Phase**, select **Build**. 4. For **Tool Engine**, select **AWS CodeBuild**. 5. In **Select Connection**, choose the connection you want to use. 6. In **Select Organization**, choose the appropriate organization. 7. In **Select Projects**, choose the project you want to onboard. 8. Select the appropriate repository. 9. Click **Onboard**. You are redirected to the Application Configuration page. 10. To verify the configuration, open the overflow menu for the Develop phase and select **Edit/Delete Tools Configuration**. # Deleting AWS CodeBuild as a technical service You can remove AWS CodeBuild from an application at any time. 1. Navigate to **Settings & Utilities** → **Application Configuration**. 2. Expand the application to display all associated phases. 3. In the **Build** row, click the overflow menu. 4. Select **Delete Technical Service**. 5. For **Select Tools Configured**, choose **AWS CodeBuild**. 6. Select the appropriate organization. 7. Select the appropriate project. 8. Click **Delete**. # Configuring AWS CodeBuild for legacy customers To configure AWS CodeBuild in the Kyndryl application, provide an Application Name, Deployment Group Name, and any additional configuration settings that support your preferred workflow. The dashboard uses the status terms Passed, Failed, and In Progress by default, but you can customize these labels to match the terminology used by your team. Any custom term entered for a status will appear under the corresponding dashboard category. In the application, from the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Section** → **Item** → **Sub-item **→ **Sub-item**. Expand Settings & Utilities, then select Tools Configuration. Select Add configuration + to open the Add tool configuration form, then complete the following steps: 1. From the Tool Engine dropdown menu, select AWS CodeBuild. 2. Choose the appropriate Connection, Technical service, and Project name from their respective dropdown menus. 3. In the Additional configuration for customization section, enter custom terms for the Passed, Failed, or In Progress statuses if you want the dashboard terminology to align with your organization’s preferences. 4. Select Add configuration at the bottom of the form to save your configuration. After the configuration is complete, the configuration details are displayed in the table on the configuration page. [title] Tools configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Supported tools/ Learn how can be configured to integrate with individual tools extending the value of your investment in your resources. The **Tools Configuration** page displays the configuration of all tools that have been configured for integration with . Use it to configure supported tools in your IT estate. # Accessing Tools Configurations page The tools configuration landing page presents a universal header at the top of the page. The header contains the following elements: - Breadcrumbs (selectable for ease of navigation). - The title **Tools configuration**. - Two tabs that govern the type of tool you want to configure: - Out of the box tools - Bring your own tools Follow these steps to access the Tools Configurations page: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Toolchain & Pipeline **→ **DevOps Intelligence **→ **Settings & Utilities **→ **Tools Configuration**. This opens the **Tools Configuration** page, where you can manage and configure DevOps tool integrations. # Out of the box tools tab The service presents a tools configuration table, which serves as a platform for knowing what tools are currently supported, managing connections with them and setting configurations necessary to make those connections. Subsequent sections describe the table, setting connections and setting configurations. # Configured tools table The Configured Tools table provides a centralized view of all configured tool integrations, including their status, connection details and overall configuration health. - A date and time stamp (this date shows the last updated date). - A search box to filter the configured tools. - An **Add New +** configuration button. The **Configured tools table** provides data in a tabular form, separated by columns and sorted as follows: - **Tool engine: **The tool configured i.e: Ansible, Bitbucket, Jira, etc. - **Status:** The current status of the configured tool: - **Success:** Green check icon for fully configured tools. - **Partial Success:** Yellow ellipsis icon for partially configured tools. - **Failure:** Red x icon for failed tool configurations. - **Connections configured: **The number of connections configured to each tool. :::hint{type="info"} The table view provides a clickable arrow below the bottom right corner of the table that enables navigation across pages of data (Page 1 of 3, Page 2 of 3, etc.) and a Drop-down menu to the left to select how many items per page are displayed. ::: When accessing this screen all tools that are configured will be displayed, conversely a **"No data found"** message will be displayed with customized instructions based on access level role as follows: - **Privilege User:** No tools configured yet, add your first tool. - **No tools available:** No configurable tools available at this moment, contact the platform admin. - **Restricted User:** Contact your admin/editor to enable the tools configuration for you. # Adding connections As a privileged user with and **Admin** or **Editor** role, tools can be added as needed from this configuration screen, to configure tools complete the following steps: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to → **Connections Management** 2. Select the **Add Connection** button. For more information about connections, see [Cloud connections](docId\:sg8Svl5kKw9ZT8yTr0beW). For a list of tools and configurations, see [Tools connections configurations.](docId:0JYjuMk43ordXDMJN-Lvh) :::hint{type="info"} Once the connections are configured, select the **Test Connection** button and a **Success** or **Failure** message displays. ::: For a list of tools and configurations please visit [Supported tools](docId\:cRuTgj1F0ko53NYZhEIXu) and [Bring your own tools](docId\:J2wCdGqoWTc5MnOocZTyA) # Adding configuration Select **Add configuration**. A screen will display configuration settings about  tool engine. To configure the tool engine, complete these steps: 1. Select the tool engine from the Tool engine drop-down box. 2. Complete the appropriate configuration for the tool engine. :::hint{type="info"} Each tool engine requires different parameters for configuration. ::: # Additional actions and notifications By navigating to the vertical ellipsis of each tool located to the right of the table and selecting **View details**, will open the configuration screen for that specific tool. Here the information will be grouped into two tabs **Configuration** and **Sync**. # Configuration Presents the parameters of the tool engine in the form of a table that includes the following columns: - **Host**: Host URL. - **Connection**: Name of the tool engine connection. - **Projects**: Name of the project for the connection. - **Archive**: Shows the connection is live or has been archived. Each connection about the specific tool will display configuration settings, by selecting the vertical ellipsis menu more actions will be available for each tool configured as follows: **For live configured tools** - Archive - Delete **For archived configured tools** - Unarchive - Delete **Notifications** By performing any given action mentioned, an alert will be triggered as follows: :::hint{type="info"} All actions performed need to be confirmed once an alert is triggered. ::: - **Archive:** By archiving this configuration, sync will be paused; you can restart the process again by unarchiving it - **Unarchive:** By unarchiving this configuration, sync will be restarted. - **Delete:** All data and references associated with it will be deleted, after the data retention period. This action cannot be reversed after the data retention period has expired. A data retention period for tool configuration and technical service association data has been established. Once the tool connection is requested to be deleted/not available, the configuration data will remain available in for 24 hours. After this retention period expires, the configuration data will be permanently removed. # Sync The Sync feature scans current data for visibility after configuring credentials and provides a time estimation of the sync, delete and pulled intervals. The sync is performed based on the current environment priority. # Sync status The Sync status section will display the status of the data retrieved after the tool engine is configured. It presents the parameters of the tool engine sync in the form of a table that includes the following columns: - **Connection:** Displays the local connected tool name for the sync. - **Active sync:** Shows the active status of a sync. - **Records processed:** Displays the number of records processed - **Duration:** Shows the amount of time taken to perform a sync. - **Last run:** Displays the last Sync run. - **Status:** Current sync status information. # Sync details The Sync details section displays the record details of each account selected. It presents the parameters of the tool engine sync in the form of a table that includes the following columns: - **Record name:** Displays the name of the record selected. - **Active sync:** Shows the active status of a sync. - **Records processed:** Displays the number of records processed - **Duration:** Shows the amount of time taken to perform a sync. - **Last run:** Displays the last Sync run. - **Status:** Current sync status information. Each tool has Configuration and Sync tabs, which is how a Sync tab would look. For a user with the **Editor** role, the status column value for the unconfigured connection in the Sync status and Sync details table will be Configuration waiting. When you click, a tooltip appears with the message `No configuration was found for this connection. Add all the necessary data to complete the configuration.` along with Add configuration button. After pressing the Add configuration button, the user will be sent to the **Configuration** tab, where the `Add tool configuration` side panel for the selected tool will be shown. For a user with **Viewer** role, the tooltip message will be `No configuration found for this connection. Contact the admin to complete the configuration.` along with the Learn more button. After clicking on Learn more button user will be navigated to the documentation page. # Bring your own tools tab :::hint{type="info"} You must be assigned the** Administrator **role to set the configuration for private tools. ::: The bring your own tools tab Enables the creation of tokens and adding tool mappers. These two features are enabled by two radio buttons: - Create token - Create tool mapper # Create token A service token is necessary for connecting private tools to DI and for creating tool mapper. If a service token already exists for a private tool, you can use that token to create an additional mapper for that tool. If a token does not exist, you must create one, before creating a new mapper. You must create a token before a tool can make a connection to . Use the following procedure: 1. Click **Create token**. The service displays the Tokens panel. 2. In the **Name** field enter a name for the token. 3. Click the dropdown menu in the **Token Type** field. 4. Click **Create** to create the token or **Cancel** to abort the operation. The service returns to the Bring your own tools tab. If you created a token, the service displays a success message and a field indicating the existence of a token. You can show or hide the token string by clicking the eye shaped icon. Next to the show/hide icon is a copy icon to enable copying the token to the OS clipboard. You can also regenerate the token by clicking the **Re-generate Token** button. Click the **View Token List** button to view a list of existing tokens. A list of existing tokens is also available on the Tokens panel, enabling you to review existing tokens before creating a new one. # Create tool mapper The Create mapper feature enables administrators to add data mapping files to their pipeline through the user interface, giving users sample generated commands such as CURL, GitHub Actions and Jenkins. This capability enables an efficient method of posting mapped data. To create a tool mapper, you must have a mapping file containing mapping instructions such as the following example: ```javascript { "tool": "trivy", "mapper": { "imagescanmapping": { "analysisdate": "", "cves": "", "cvssscore": "CVSS.nvd.V3Score", "datasource": "PrimaryURL", "description": "Description", "fixedversions": "", "imagedigest": "Layer.Digest", "packagename": "PkgName", "packagepath": "PkgID", "packagetype": "PkgPath", "packageversion": "InstalledVersion", "published": "", "severity": "Severity", "severitysource": "", "vulnerabilityid": "" }, "root": "Results.#.Vulnerabilities" }, "parentmapper": { "imagescanmapping": { "analysisdate": "", "imagedigest": "Layer.Digest" }, "root": "Results.#.Vulnerabilities" } } ``` :::hint{type="info"} A tool mapper for Trivy is being added, which is mapped with container vulnerability scan. ::: Before creating the mapper, review the requirements for each DevOps phase presented in [Mapper configuration](docId\:Hj67yMCVBWMI9oe5AKujG) then use the following procedure, borrowing from the example mapper file as necessary: 1. Click Create tool mapper. The service displays the Create mapper wizard. 2. Select a tool category from the Tool Category dropdown. 3. Select Use Existing Token if a current token for the tool exists or Create New Token to create one if one does not exist. 4. Select an existing token from the token dropdown or create a new token using the procedure in the previous section Create token. 5. Click **Next**. The wizard progresses to Tool Manager. 6. Select **Existing Mapper** to specify an existing (previously added) mapping file or **Create Mapper** to add a new mapping file. 7. In the case of **Existing Mapper**, select a tool from the **Select tool** dropdown or, in the case of **Create Mapper**, click **Add file** and select your mapping file. If you add a mapping file, the service displays the file content on an edit canvas. Edit the file if necessary. Click **Next**. The wizard progresses to **Command Generation** and displays all parameters. 8. Select values for the parameters. 9. Click **Generate Command**. The wizard progresses to **View Generated Command**. The command is presented as a CURL, GitHubAction and Jenkins. 10. Copy the generated command in the form of your choice and add it to your pipeline. [title] DevOps Intelligence role-based functions [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ the DevOps functions that drive Role Based Access Control (RBAC) built into , enabling governance of your hybrid IT estate. supports four role-based functions that DevOps teams use to observe the performance of each phase of the DevOps life cycle and make necessary adjustments in your governed resources: - **The Development Manager**: - Requires a unified view of pipeline, tools, containers and application development and deployment status. - Checks cluster health of the application spread across multiple data centers and multiple clouds. - **The Development Engineer:** - Performs enterprise-level view to measure the SDLC maturity level. - Requires summary view of a service's core metrics spread across multiple clouds. - Maintains a macro view of pipelines, tools, containers and application development and deployment status. - Leads the development of pilots to test business hypotheses. - Advises on cost optimization opportunities by analyzing usage and utilization costs as well as asset performance. - Communicates frequently with stakeholders on project status. - Enables application developers to move at speed while optimizing cost, security and performance positions. - Acts as a systems integrator when the application he is managing is a large application or is developed in waterfall method. - **The Site Reliability Engineer**: - Support DevOps teams in template development and use. - Integrate IaaS and PaaS into DevOps pipelines. - Perform a large amount of Automation. - Assist with the design and testing of end-to-end resilience. - Design of PaaS/IaaS service templates. - **The Security and Compliance Officer**: - Manage risk and compliance, and secure and protect the business's assets (employees, data, information and office locations). - Direct staff to assess, monitor and develop strategies to proactively guard against information and information technology (IT) risks. - Respond to incidents; establish appropriate standards and controls; manage security technologies; and direct the establishment and implementation of policies and procedures. - Work to understand and measure the potential implications of a security breach. - Align audit and information-related compliance. - Identify, assess and prioritize enterprise-wide risks that have the potential to inflict harm on the organization (uncertainty in financial markets, project failures, legal liabilities, credit, risks, accidents and natural disasters). [title] Bring your own metrics [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ Learn how to integrate metrics tools to . Metrics are the life blood of Developer Operations. The ability to measure productivity, the health of resources, up time and recovery is critical to both efficiency and effectiveness. How well teams work together and their ability to achieve service levels at each DevOps phase and the transition management from phase to phase are dependent on metric feedback. directly supports specific metrics tools *out of the box*, but also supports your ability to integrate your own tools that are not supported directly. Subsequent sections provide information to perform this integration. ## Integrating Plan metrics tools ::::WorkflowBlock :::WorkflowBlockItem Add your Planning tool: 1. Create or Edit an application in Application manager. 2. Go to add Tool Configuration page. 3. Select Plan. 4. Click on **Add Tool Configuration** button. 5. Select the **Tool Category** as **Bring your own tool** option. 6. Provide a BYO tool name and save the configuration. 7. Click **Submit**. ::: :::WorkflowBlockItem Generate a Token. You must generate the token before posting data to . Use any REST client tool. - End Point: http\://your\_tenant\_host/dash/api/insightscontroller/v1/config/tokens - Method: POST - Body: ::: :::WorkflowBlockItem Use the token generated in **step 2** to post the data: - End Point: http\://\/dash/api/insightscontroller/v1/issueSnapshot/dash/api/insightscontroller/v1/issueSnapshot - Method: POST - Header: authorization: \ - Body: ::: :::WorkflowBlockItem Verify that data is displayed in **DevOps Performance Metrics** dashboard. ::: :::: ## Integrating develop metrics tools Use the *Integrating Plan metrics tools* procedure but post the data in accordance with the type of endpoint: - Commits - Issues - Pull requests **End Points for Commits** - End Point: https\://your\_tenant\_host/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/commits/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/commits - Method: POST - Header: authorization: \ - Body: **End Points for Issues** - https\://your\_tenant\_host>/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/issues/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/issues - Method: POST - Header: authorization: \ - Body: **End Points for Pull Requests** - End Point: https\://your\_tenant\_host/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/pullrequests/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/pullrequests - Method: POST - Header: authorization: \ - Body: Verify that data is displayed in **DevOps Performance Metrics** dashboard. ## Integrating Build metrics tools Use the following procedure to integrate your Build metrics tools: ::::WorkflowBlock :::WorkflowBlockItem Create or Edit an application in Application manager. ::: :::WorkflowBlockItem Go to add Tool Configuration page. ::: :::WorkflowBlockItem Select the build phase. ::: :::WorkflowBlockItem Click on **Add Tool Configuration** button. ::: :::WorkflowBlockItem Select the **Tool Category** as **Bring your own tool** option. ::: :::WorkflowBlockItem Turn on **Existing Tool From Mapper**. ::: :::WorkflowBlockItem Select the tool from existing mapper. ::: :::WorkflowBlockItem Configure the required **Release and Severity** details accordingly the phase and tool engine selected. By default, **Existing Tool From Mapper** will be turned off so that you can provide a BYO tool name. ::: :::WorkflowBlockItem Enter a tool name. ::: :::WorkflowBlockItem Select an existing tool from the Mapper. ::: :::WorkflowBlockItem Complete the form, providing details for the Mapper. ::: :::WorkflowBlockItem Click **Save**. ::: :::WorkflowBlockItem Click **Submit**. ::: :::WorkflowBlockItem Generate a token: Generate a Token. You must generate the token before posting data to . Use any REST client tool. - End Point: http\://your\_tenant\_host/dash/api/insightscontroller/v1/config/tokens - Method: POST - Body: ::: :::WorkflowBlockItem Post the data, by providing End Points for Generic Builds: - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-builds/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-builds - Method: POST - Header: authorization: \ ::: :::WorkflowBlockItem Verify that data is displayed in **DevOps Performance Metrics** dashboard. ::: :::: ## Integrating Secure metrics tools Use the *Integrating Build metrics tools* procedure to integrate Secure metrics tools but post the data in accordance with the type of endpoint: - Static Scan - License Scan - Vulnerability Scan - Dependency Check **Static Scan** - End Point: https\://\/dash/api/v4/static-scan/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/vulnerabilities - Method: POST - Header: authorization: \ - Body: - End Point: https\://\/dash/api/v4/static-scan/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-vulnerabilities - Method: POST - Header: authorization: \ **License Scan** - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/vulnerabilities - Method: POST - Header: authorization: \ - Body: - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-vulnerabilities - Method: POST - Header: authorization: \ **Container Vulnerability Scan** - End Point: https\://\/dash/api/v4/image-scan/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/vulnerabilities - Method: POST - Header: authorization: \ - Body: - End Point: https\://\/dash/api/v4/image-scan/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-vulnerabilities - Method: POST - Header: authorization:\ **Dependency Check** - End Point: https\://\/dash/api/v4/dependency-check/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/vulnerabilities - Method: POST - Header: authorization: \ - Body: - End Point: https\://\/dash/api/v4/dependency-check/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-vulnerabilities - Method: POST - Header: authorization: \ Verify that data is displayed in **DevOps Performance Metrics** dashboard. ## Integrating Test metrics tools Use the *Integrating Build metrics tools* procedure to integrate Secure metrics tools but post the data in accordance with Test tools requirements: - https\://\< >/dash/api/test/v3/application/Dominoq-1/technical-services/petstore-api/tool/my\_byo\_tool1/tests/543c9bab-48ed-44ad-82e1-9538ee2461f2?testType=unit\&fileType=xunit\&technicalServiceOverride=true\&releasename=release-2025.03.26\&environmentname=production\&providerhref=https%3A%2F%2Ftest.result.com - Method: POST - Header: authorization: \ - File upload: Upload the automation xml file output as of automation. As test type is unit in above api call. Verify that data is displayed in the **Test** dashboard. ## Bring your own deploy Use the procedure for integrating Build metrics tools to integrate Secure metrics tools but post the data in accordance with Deploy tools requirements: **Endpoints for deployment** - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/deployments - Method: POST - Header: authorization: \ - Body: **Endpoints for generic deployment** - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/generic-deployments - Method: POST - Header: authorization: \ Verify that data is getting displayed in **DevOps Performance Metrics** dashboard. ## Bring your own monitor Use the procedure for integrating Build metrics tools to integrate Secure metrics tools but post the data in accordance with Monitor tools requirements: **Endpoints for Incidents** - End Point: https\://\/dash/api/application/\{applicationName}/technical-services/\{technicalServiceName}/tool/\{toolName}/incidents - Method: POST - Header: authorization: \ - Body: **Endpoints for generic Incidents:** - End Point: https\://\ Verify that data is displayed in **DevOps Performance Metrics** dashboard. ## Bring your own CLT Use the *Integrating Plan metrics tools* procedure but post the data in accordance with your CLT: - End Point: https\://\/dash/api/insightscontroller/v1/issueSnapshot - Method: POST - Header: authorization: \ - Body: Verify that data is displayed in **DevOps Performance Metrics** dashboard. ## Deleting: Bring your own metrics tools Use the following procedure to delete individual bring your own metrics tools: 1. For deleting the metrics, select the phase in the application. 2. Press the **Delete Technical Service** option in the overflow menu. 3. Select the BYO tool. 4. Select the tools for deletion. 5. Click **Delete**. [title] Bring your own deploy [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ As a user, you can leverage Deploy Service, our centralized service that displays all deployment results from various deployment tools within your DevOps Pipeline. Our platform shows data from tools like Argo CD and various cloud endpoints, as displayed in the following figure when data is populated. With Deploy Service, you can easily bring in deployments from multiple tools and also post deployments from different tools to Deploy by utilizing the APIs that we provide. This way, you can efficiently monitor and manage your deployments across your entire DevOps ecosystem. # Bringing data into To bring your own Deploy tools complete the following steps: 1. Go to the  Tools Configuration page and navigate to the Tokens tab. 2. Click on **Create Token** and give a unique Token name. 3. Select **Token Type** as **Deployments**, then click on the **Create button**. 4. A new entry will be added to the table in the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} Note: To Post Data to the APIs mentioned below, add the service Token ( Create Service Token) to the **Authorization** header of the request. See the cURL Example for reference ::: # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example :** `TOKEN B8FkfCC3PRVrezteLHp0rPROs2p6yZk_swVLpP_36D7pd5HHLhx7UXqlH_BvpQGo` **Step 2:  API Reference** **API: /services/deployments** **URL : https\://\{devops-intelligence-host}/dash/api/deployments/v4/technical-services/deployments** **Parameters:** | **Parameter** | **Type** | **Explanation** | **Example value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------- | | Deployment \* | BODY | Deployment Data in Json | | ```javascript { { "id": "6325a4ce1bb54ed5487e5911", "connections": [], "deploymentid": "256t767t7", "template_name": "sampleTechnicalService", "provider": "gocd", "providerCode": "gocd", "tool": "BYOD", "environment": "string", "release": "release-2022.09.30", "status": "Deployed", "name": "di-dashboard", "creation_date": "2022-09-12T07:20:50.52Z", "duration": 10057200, "endpoint_technical_service_id": "di-dashboard", "endpoint_hostname": "https://travis.com", "href": "https://appsvt2-di-release.multicloud-ibm.com/dash/api/deployments/v4/deployments/6325a4ce1bb54ed5487e5911", "servicehref": { "deployments": "https://appsvt2-di-release.multicloud-ibm.com/dash/api/deployments/v4/deployments/6325a4ce1bb54ed5487e5911/templates" }, "providerhref": "https://travis.com/1234", "technical_service": "sampleTechnicalService", "technical_service_id": "6325a67a2cf73f8af6382211", "unique_technical_service_id": "6325a4ce7f9d5f0c984d2d5c", "application_relationships": [ { "application_name": "Domino1", "application_id": "6325b3c277a1e154206b6985", "relationship_types": [ "uses" ] } ], "kcmp_app_href": "", "kcmp_app_name": "CCM", "technical_service_tag": { "SERVICE-UNIQUE-ID": "gocd:https://travis.com:di-dashboard:sampleTechnicalService", "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "ismetered": true, "isproduction": true }, } ``` ## cURL Example **Request** ```curl curl -X POST \ https://peer-core.gravitant.net/dash/api/deployments/v4/technical-services/dash_aws/deployments \ -H 'Authorization: Token zkkh_KmDI2Ib3-6i9eFzdm72zG32UtG4oQqkn63iDUeA5QoMC9RcAxU1Vy5sVFEG' \ -H 'Content-Type: application/json' \ -H 'cache-control: no-cache' \ -d '{ "creation_date": "2020-07-26T05:06:10.949Z", "deploymentid": "endpointID_1", "duration": 2345171, "name": "AWS", "provider": "AWS", "Details": { "CreationTime": "2020-07-27T13:30:39.181Z" }, "technical_service_name": "MCMP-DevOps-Intelligence/serviceName", "technicalserviceoverride": true }' ``` **Response 200** `{ "ID": "5f22c301ac17b7ba55644fba","EntityID":"endpointID_1" }` ## Build request body explained | **Field** | **Data Type** | **Explanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | DeploymentID\* | string | Object ID | 5d69de78674bf10001ed4ce1 | | Name | string | Name of deployment | 225-mcmp-aws-lamp-job | | Provider\* | string | Provider name | AWS | | Status\* | string | The deployment status | Deployed, deployed, DEPLOYED, Failed, failed, FAILED | | Duration\* | int64 | Time required to run deployment in **microseconds** | 1005720 | | CreationDate\* | string | Date and time of deployment | 2019-10-12T07:20:50.52Z | | ProviderHref | string | Endpoint Url | https\://ec2-164-8-1.us-west-2.compute.amazonaws.com/api/v4/job\_templates/16/jobs/?id=225 | | Details | map\[string]interface\{} | Additional details of a template(raw json file contents) | Raw JSON | | technical\_service\_name\* | string | Technical serviceName is an abstraction for deployments group | MCMP-DevOps-Intelligence/devProject1 | | serviceoverride | boolean | Override flag for the service | true | | isProduction | boolean | If deployment is Production | true | [title] Troubleshooting and FAQ [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ This section describes common migration issues and the recommended resolution steps. ## Global catalog item not found :::hint{type="info"} Some global catalog items available in Automation Services (AS) are intentionally not migrated to Service (BAS). ::: If a global catalog item is not available after migration: 1. Review the **Global Approved Catalog items for migration** section. 2. Verify whether the catalog item is included in the approved migration list. 3. Confirm that the migration completed successfully. 4. If the catalog item is included in the approved list but is still unavailable, contact the migration support team. :::hint{type="info"} Only catalog items approved for migration are made available in BAS. Catalog items that are not included in the approved migration list are not migrated. ::: ## Tenant catalogs, workflows, schedules, or events not found If private catalogs, workflows, schedules, or events are not available after running the **AIOPS Automation Services Migration** catalog item, review the migration workflow execution to identify failed migration activities. ### Review migration failures 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Locate the **AIOPS Automation Services Migration** workflow execution. 3. Select the **More actions** menu (**...**) and then select **View Details**. 4. Open the **Activities **tab. 5. Review the activity list and identify activities with a **Failed **status. 6. Open the failed activity and review the error message. 7. Determine the cause of the failure. 8. Resolve the reported issue, such as: - Missing prerequisites - Configuration issues - Permission-related issues - Credential-related issues 9. Run the migration catalog item again. 10. Verify that the previously missing catalogs, workflows, schedules, or events are available in BAS. ### Review migration summary A high-level summary of migration results is available in the **Summarize Migration** activity within the workflow execution. The summary provides information about: - Successfully migrated items - Skipped items - Failed items - Migration statistics For additional details, review the **Output Parameters** tab of the migration workflow execution. ## Retry a failed workflow execution If a workflow execution fails, the workflow can be restarted after the underlying issue is resolved. :::hint{type="info"} Restarting a workflow executes the automation from the beginning. Before restarting the workflow, confirm with the Delivery Platform Engineer (DPE) that the automation is safe to rerun and supports retry operations. ::: ### Restart a workflow Perform the following steps to restart the workflow: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Workflow Executions**. 2. Locate the workflow execution with a **Failed** status. 3. Select the workflow execution to view its details. 4. Select the **More actions** menu (**...**). 5. Select **Restart Workflow**. 6. Review the workflow inputs. 7. Confirm the restart request. 8. Monitor the execution from the **Workflow Executions** page until it is completed. [title] QMetry configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Test tools/ The setup for with QMetry, requires several procedures, most of which are in , but the initial procedure requires access to the QMetry console. Further, the following prerequisites are required: - **QMetry Account:** The administrator should have an active QMetry account on the specific QMetry instance user want to connect to. If user don't have one, user need to sign up for a QMetry account. - **Access to a QMetry Instance:** Ensure that User have access to the specific QMetry instance where the projects, test suites and test cases are hosted. Users need the URL or web address of the QMetry instance user want to connect to. - **Project Membership:** Users must be part of the QMetry projects user intend to access. Ensure that users have the necessary project membership to retrieve information about projects, test suites and test cases. - **Access Policy as Platform Administrator and **&#xNAN;** Administrator:** Ensure that the user has the necessary access policies.The user should have the Platform Administrator role to create and manage connections effectively. The user needs the Administrator role, which allows them to create and manage configurations. Review and execute the content in the following sections in the order they are presented. # Create a QMetry API token In order to establish a connection, the first configuration procedure, you must first acquire a QMetry API token, which is available only from the QMetry console. Use the following procedure: 1. Navigate to the sub menu "Open API" from the "Integrations" menu on the left hand side of the page. QMetry will automatically generate an API token. 2. Click the Copy API Key icon to copy the existing key. # Create a connection to QMetry Establishing a connection to QMetry is prerequisite to configuring the service. Use the following procedure: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Service Operations** → **Connections Management ** 2. From the left navigation menu, select **Tool Connections**. The **Tool Connections** page is displayed. 3. Click **Add Connection** to create a new tool connection. 4. Choose Connection type as **QMetry.** 5. Select in **Supported apps** drop down. 6. Provide **Connection name**. 7. Provide other non-mandatory field information. 8. Click **Nex**t and **enter the Host.** 9. Click** Next** and enter the **Username** and **APIkey** which have access to projects which need to be pull on . # DevOps configuration for QMetry, recent customers :::hint{type="info"} This procedure is valid only for customers onboarded 6 June, 2024 or after. ::: Having established a connection, you must complete the configuration procedure. Take note of the following caveats: - QMetry tool can only be configured at the project level. - Multiple Test Suites can be selected against projects. - Test Suites are just a way to restrict what all data user needs for a given project. - QMetry will only sync data available with connection configured against it. - At the project level, technical services are always configured as mutually exclusive. - If two users having same privileges tries to onboard the technical service for the same project only the first user can create the technical service. It will not be listed for the second user to onboard. Use the following procedure to complete the configuration: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **** → **Settings & Utilities **→ **Application Configuration**. 2. Locate the Application Name and click the **ellipsis (⋮)** next to the application. 3. Select **Edit Tool Configuration**. 4. Select the phase as **Test **and navigate to **Add Tools **step. 5. Click **Add Tool Configuration**. 6. From **Tool engine**, select **QMetry**. 7. Map your execution status to four levels. Passed, Failed, Skipped and Blocked. 8. Select the respective statuses into the respective categories. 9. Click **Add Configuration.** ## Editing configuration Use the following procedure to edit the configuration: 1. Click on overflow menu and select "Edit" option to edit the tool. 2. Modify the execution status. 3. Click **Save Configuration**. ## Deleting configuration Use the following procedure to delete the current configuration. 1. Click on overflow menu and select "Delete" option to delete the tool. 2. Click Delete on the confirmation modal to proceed to delete. # Onboarding the QMetry technical service After configuring DevOps for QMetry, you must onboard it as a technical service. Note the following caveats: - QMetry tool can only be configured at project level. - Multiple Test Suites can be selected against projects. - Test Suites are just way to restrict what all data user needs for a given project. - It will only sync data available with connection configured against it. - At project level, technical services are always configured as mutually exclusive. - If two users having same privileges tries to onboard technical service for the same project only the first user is allowed to create the technical service, as the project is already on-boarded, it will not be listed for the second user to onboard. Use the following procedure: 1. Navigate to -> Settings & Utilities -> Application Configurations. 2. Click on Overflow menu for the chosen application and click **Onboard Technical Service**. :::hint{type="info"} Note: displays all the phases for which the tool has been configured for the application - Select the phase as Test - Select the tool engine as QMetry - Connection - select connection name from the dropdown menu. ::: ## Deleting the QMetry technical service The administrator may, at will, delete the QMetry technical service. Use the following procedure: 1. Navigate to → Settings & Utilities → Application Configurations. 2. Expand the application to see all the associated phases. 3. Click the Overflow menu associated with the Test phase. 4. Click **Delete Technical Service**. # Reviewing test suite data in DI After has been fully configured, displays all test suites being tracked by QMetry in the table view at the bottom of the Test page. The view provides general information about each test suite such as status (how many tests were Skipped, Passed, Failed and Blocked), Total number of tests in the suite and the execution date. Detailed information about each suite are available by clicking the overflow menu for that test suite and selecting **View Details**. responds by navigating to the Details page for that suite, where additional information regarding activity and history is available. The Activity tab presents a graphic presentation of the tabular data on the table. The Historical details tab presents additional details such as Code Smells and Bugs. On both tabs you have the option of selecting a time frame for testing from the Duration control located in the upper right. [title] Secure SDLC Governance Dashboard [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ DevOps security concerns are addressed in large part by supplemental tools used by your team to expose potential vulnerabilities and to understand the range and nature of remedial actions to prevent security breaches. The Secure dashboard provides reports and scoring to assist security assessments using data accumulated from these tools. The Secure SDLC Governance Dashboard presents a table with six columns: - **Applications Name:** The name given to the application associated with a set of security tools at the time the application was created. - **Security Champion:** The e-mail address of the designated Security Champion for the application. - **Maturity Assessment report:** A link to a SharePoint site containing a report with data regarding the application, aggregated from the security tools composing the application. - **Last Maturity Assessment:** The last date an assessment was made using the tools associated with the application. - **Maturity Assessment Score:** A relative security health score assigned by the application based on data collected by the tools associated with the application; lower scores are associated with greater security vulnerability. A minimum score of 8 is deemed acceptable. Scores lower than 8 appear in red, and scores of 8 or higher appear in black. - **Security Tools:** A list of security tools associated with the application. # Secure SDLC Governance Dashboard setup The Secure SDLC Governance Dashboard presents data acquired by security tools associated with a defined application. The application is defined using the Application Configuration feature. The feature prompts you for specific information such the application name, the tools you are using for each phase in the SDLC (in this case Security) and the Security Champion. Use the following procedure: 1. List all your security applications. 2. Classify them by logical use. For example, if you have some security tools that you use for user management and other tools for resource management, classify them accordingly. These classifications form the applications you will create in the Application Configuration feature. 3. Refer to [Application configuration](docId\:OAbXJrTPPYSz1MJo1R2iV) 4. Create an Insights Controller token: Navigate to **Settings and Utilities** →**Tools Configuration**. 5. Click the **Bring your Own Tools** tab. The service defaults to the **Create New Token** tab. 6. Enter a name for your token in the **Name** field. 7. Select Insights Controller for **Token Type**. 8. Click **Create**. 9. Call the Insight Controller API to enable your maturity reports. By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applications, regardless of vulnerability. [title] Secure module widgets [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ The Secure dashboard view contains five widgets that, combined, provide a deep understanding of the vulnerabilities in these key security components: - Secure Alerts - Application Summary - License by Severity - Static Scan - Dependency Check - Container Vulnerability Scan # Secure alerts Secure alerts show GitHub-generated alerts when the codebase has dependencies with known vulnerabilities. This graph consists of an information box containing the following elements: - The name of the technical service that triggered the alert. - The number of days since the alert was last opened. - The name of the application where the technical service alert was triggered. - The number of triggered alerts is based on your timeframe selection. - The severity of the alert by category: - **Critical:** Dark red warning circle. - **High:** Red warning triangle. - **Medium:** Orange condition wait point. - **Low:** Sky blue inverted warning triangle. The Secure alerts widget has a clickable arrow in the top right corner to view the Secure alerts dashboard. # Application summary The Application Summary widget allows you to view vulnerabilities based on the following criteria: - The displayed data is governed by the date range selected from the timeframe in the header. - Applications. - A timeframe for which to show data. The Application Summary widget displays a graph representing the total number of vulnerabilities for Security categories: Static scan, Open-source license compliance, Dependency Check, and Container vulnerability scan added according to applications. The Application Summary widget presents two axis that indicates the **No. of Vulnerabilities** detected within a specified period: - X-Axis** (No. of Vulnerabilities):** The X-axis corresponds to the number of vulnerabilities detected in the selected period. Depending on the time you select, the bar graph changes in color based on the severity of the vulnerabilities detected. - By hovering over the graph, the following data is presented for each vulnerability category: - **Y-value:** Corresponds to a specific Application (i.e.SecureDash). - **No. Of Vulnerabilities:** The total number of vulnerabilities detected. - **Group:** One of the five severities categories is represented by the color pointed to. - Y-Axis: The Y-axis corresponds to the total number of applications. The bars in the graph are colored based on the severity category: - Critical: Dark red square. - High: Red square. - Medium: Orange square. - Low: Sky blue square. - oInfo: Green square. # License by severity The License by Severity widget graph represents the total aggregated licenses detected according to day-month timeline selection. Severities are classified into two categories: **Critical** and **Info**. Graph data supports the selection of predetermined Drop-down menu Applications and Dashboards. By default, it is for all technical services and applications. By default, it represents the data for the last 7 days. The License by severity widget presents two axis that indicates the **Total License Detected** within a specified period: - X-Axis (**Months/Dates**): The X-axis corresponds to the month for which data in the bar graph is shown. Depending on the time you select, the bar graph changes in color based on the severity of the licenses detected. By hovering over the graph, the following data is presented for each license severity: - **Group**: The severity that the licenses in a given group have. - **Months/Range**: The cut-out date for detected licenses. - **Total/Value**: Total number of licenses in a particular group. - Y-Axis (**Total License Detected**): The Y axis corresponds to the total number of licenses found for each severity within a given period. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Dates**: The cut-out date for detected licenses. - **Critical**: Total number of licenses detected and classified as Critical severity. - **Info**: Total number of licenses detected and classified as Info severity. - **Total**: The total number of licenses from all severities. The License by severity widget has a clickable arrow in the top right corner to view the Open-source license compliance dashboard. # Static scan The Static scan widget represents the total number of vulnerabilities aggregated according to day-month timeline selection **for Static scan** only. Graph data supports selecting predetermined Applications and Dashboards from the Drop-down menu. By default, it is set to all Applications and technical services. This graph also supports a predetermined day-month timeline selection, which represents the data for the last 7 days by default. The Static scan widget presents two axis that indicates the **No. of Vulnerabilities** detected within a specified period: **X-Axis (Duration):** The X-axis corresponds to the months and dates from the period selected to show data. The bars in the graph are colored based on the severity category: - Critical: Dark red square. - High: Red square. - Medium: Orange square. - Low: Sky blue square. - Info: Green square. **Y-Axis (Total Vulnerabilities):** The Y-axis corresponds to the number of vulnerabilities detected in the selected period. By hovering over the bars in the graph, you can view data about the total number of vulnerabilities detected and the severity they belong to, as follows: - **Group**: The severity of the vulnerabilities. - **Date/Range**: The cut-out date the vulnerability was detected. - **Value**: The total number of vulnerabilities detected. Static scan analyzes your source code to identify any security vulnerabilities susceptible to attack. The Static scan feature supports the use of tools such as SonarQube. The Static scan widget has a clickable arrow in the top right corner to view the Static scan dashboard. # Dependency check The Dependency Check widget displays the total number of vulnerabilities detected within a project dependency. This graph also supports a predetermined day-month timeline selection, which represents the data for the last 7 days by default. The Dependency Check widget presents two axis that indicates the total number of dependency vulnerabilities detected: - X-Axis (**Duration**): The X-axis corresponds to the months and dates from the period selected to show data. - Y-Axis (**Total Vulnerabilities**): The Y-axis corresponds to the number of vulnerabilities detected within a project dependency. By hovering over the bars in the graph, you can view data about the total number of vulnerabilities detected, as follows: - **Group**: The severity of the vulnerabilities. - **Date/Range**: The cut-out date the vulnerability was detected. - **Value**: The total number of vulnerabilities detected. Dependency Check widget elicits project dependencies and scans for any known vulnerabilities. The Dependency Check feature supports the use of tools such as Dependency-Track. The Dependency Check widget has a clickable arrow in the top right corner to view the **Dependency Check** dashboard. # Container vulnerability scan The Container vulnerability scan widget displays the total number of vulnerabilities detected within a container image. This graph also supports a predetermined day-month timeline selection, which by default represents the data for the last 7 days. The Container vulnerability scan widget presents two axis that indicates the total number of container vulnerabilities detected: - X-Axis (**Duration**): The X-axis corresponds to the months and dates from the period selected to show data. - Y-Axis (**Total Vulnerabilities**): The Y-axis corresponds to the number of vulnerabilities detected within a container image. The vulnerabilities and security issues discovered from various Security tools would be mapped into the following five severities: Critical is the highest and Info is the lowest from an overall risk scoring perspective. If the security uses different severities/names other than the following, the mapping will be done based on the order of the severity: - Critical: Dark red square. - High: Red color. - Medium: Orange square. - Low: Sky blue square. - Info: Green square. By hovering over the bars in the graph, you can view data about the total number of vulnerabilities detected, as follows: - **Group**: The severity of the vulnerabilities. - **Date/Range**: The cut-out date the vulnerability was detected. - **Value**: The total number of vulnerabilities detected. The Container vulnerability scan feature supports using tools such as IBM Vulnerability Advisor. The widget has a clickable arrow in the top right corner to view the Container vulnerability scan dashboard. [title] Global Automation Catalog [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/ ## Overview The Global Automation Catalog provides a centralized repository for Kyndryl-certified automation content that enables consistent reuse of approved automation solutions across multiple tenants and regions. Global automation content is created, managed, and governed centrally through the Bridge Operations account, while tenant-specific content continues to support customer-specific automation requirements within individual tenants. ## Global and tenant-specific catalog content Automation catalog content is categorized into two types: - Tenant-specific catalog content supports customer-specific operational requirements and is available only within the respective tenant. - Global catalog content contains standardized automation solutions that are certified, tested, and approved for reuse across multiple tenants and regions. Examples of global catalog content include common automation tasks such as patch installation, antivirus deployment, and other standardized operational activities that can be reused across different customer environments. # Governance model Global catalog content is managed centrally through the Bridge Operations account. All global automation content is: - Created and maintained by authorized Kyndryl teams. - Certified in accordance with Kyndryl processes before publication. - Published through the Global Automation Catalog. - Governed centrally to maintain content quality and consistency. When creating a global catalog item, a certification confirmation checkbox must be selected. This acknowledgment confirms that the content complies with Kyndryl certification requirements and is required before the item can be created. # Access model Access to the Global Automation Catalog is restricted to authorized users with the required permissions. Users access the Global Automation Catalog through the Bridge Operations account. Only authorized users can create, manage, publish, or retire global catalog content. Tenant users can view and activate published global catalog items in their local catalogs, but they cannot manage or modify global content from tenant accounts. # Accessing the Global Automation Catalog To access the Global Automation Catalog: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Bridge Operations** account → **Global Automation Catalog.** The Global Automation Catalog uses the same content creation and publishing workflow as the existing Orchestration Administration experience. Users can create catalog items, specify metadata such as name, description, type, and category, and manage content through the standard publication lifecycle. New catalog items are initially created in a Draft state and must be published before becoming available to tenant accounts. # Publishing global content Global content is created and published from the Bridge Operations account. After a catalog item is published, the content becomes available in tenant catalogs. Global content is identified as Global indicator, which distinguishes it from tenant-specific catalog items. Published global catalog items can be: - Viewed in tenant catalogs. - Activated within tenant accounts. Executed using the same workflow as tenant-specific catalog items. [title] Ansible configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ # Configuring Ansible for Designed for multi-tier deployments, Ansible models your IT infrastructure by describing all of your system's inter-relations, rather than just managing one system at a time. It uses no agents and no additional custom security infrastructure, so it's easy to deploy and, most importantly, it uses a simple language (YAML, in the form of Ansible Playbooks). supports Ansible. For to pull data from Ansible Tower, you must configure an Ansible account. The following list contains the elements you must address to configure ansible properly: - Access Rights: The account should have, at a minimum, read privilege for the job templates and jobs you intend to synchronize. - The Application requires the following information: - **Name:** Local account name. It could be any string and is used only for reference. - **User:** Username for Ansible Tower. The userID with which user logged in to Ansible Tower. - **Token:** Personal access token. It can be generated from the following menu selection within Ansible Tower: Users`->`Select a User`->`Token`->`\[+]. The personal access token requires application configuration in accordance with the following procedure: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Settings & Utilities **→ **Application Configuration** 2. Click **+ ** 3. Add the information details. 4. Select **Save**. # Create a token for the user 1. Select User 2. Select Token 3. Select the plus (+) icon Select **Save**. A new window displays the Token created for you. The credentials screen requires the following information: 1. **Name:** any name (For example: Ansible) 2. **Host:** hostname (For example: http\://dash-ansible.com) 3. **User:** username or ansible server (For example: Admin) 4. **Token:** your personal access token (For example: abxffgjskghaj) With regard to the **VerifySSLCertificate** option, you must determine whether the Ansible service should verify the certificate of the remote Ansible Tower. The default value is (value e.g. yes, verify, ignore). Toggle this option to (value) when the remote Ansible Tower uses a self-signed or untrusted certificate. [title] Dependency Check [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ Dependency check is a critical element of your Security assurance. enables dependency checks tools to help you understand whether the dependency of each tool has been met to prevent security vulnerabilities. dependency check indicates potential gaps in the operation of your tools that might be missing the latest security updates on the tool itself or other tools on which it depends. # Dependency dashboard composition Selecting Dependency check will open the dependency check dashboard displaying graphs representing the dependency severity chart under the following criteria: - Dependency check by severity - Top critical technical services - Top critical components - Dependency check details # Dependency check by severity The graph data represents the total number of vulnerabilities aggregated according to day-month timeline selection. Severities are classified into five categories: Critical, High, Medium and Low. Graph data supports the selection of the above Drop-down menu application & teams. By default, it represents 180 Days old data. - X-Axis (**Duration**): The X-axis corresponds to the months and dates from the time period selected to show data. - Y-Axis (**Total Vulnerabilities**): The Y-axis corresponds to the number of vulnerabilities detected in the selected time period. By hovering over the bars in the graph, you can view data about the total number of vulnerabilities detected and the Severity they belong to, as follows: - **Group:** The Severity to which the vulnerabilities belong. - **Months/Date:** The cut out date for the vulnerabilities detected. - **Total/Value:** The total number of vulnerabilities detected. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Critical:** Total number of critical Vulnerabilities. Represented by a dark red color. - **High:** Total number of high Vulnerabilities. Represented by a red color. - **Medium:** Total number of medium Vulnerabilities. Represented by an yellow color. - **Low:** Total number of low Vulnerabilities. Represented by a green color. # Top critical technical services and Top critical components The top critical technical services chart represents top 5 technical services listed according to its criticality and, the Top critical components chart represents top 5 components listed according to its criticality. # Dependency check details The Dependency check details table is a table that provides the latest dependency check executed enabling a detailed view of each technical service. Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical service:** The name of the micro technical service within the larger application. - **Application:** The name of the application, typically comprising multiple micro-technical services. - **Vulnerabilities:** Total number of vulnerabilities detected for a technical service. - **Critical:** Total number of critical vulnerabilities detected for a technical service. - **High:** Total number of high vulnerabilities. - **Unassigned:** Total number of unassigned checks. - **Vulnerability components:** Total number of vulnerabilities components. - **Secure engine:** The security source tool configured. - **First occurrence:** Date of the first vulnerability occurrence. - **Last occurrence:** Date of the last vulnerability occurrence. The Dependency check table also supports detailed views for each technical service. To access details for a specific technical service, Click the overflow menu located to the far right of the table and select **View Details**. # Dependency check table details When you select **View Details** from a technical service from the table details, a new dialog appears with technical service details. The following elements are displayed in this dialog: - The title **DevOps-Operations**. - Two tabs that you can click on, with the option to toggle between ascending and descending alphanumeric order for most columns: **Components** and **Vulnerabilities**. - **Components:** Clicking the **Components** tab displays **Component Details** in a tabular form and provides the following details for the technical service: - Component - Version - License - Risk Score - Vulnerabilities - **Vulnerabilities:** Clicking the **Vulnerabilities** tab displays **Vulnerabilities Details** in a tabular form and provides the following details for the technical service: - Vulnerability ID - Source - Weakness - Description - Severity - CVSS Score - Component Name - Sha-256 - Risk Score - Dependencies :::hint{type="info"} The **Dependency check** and **Vulnerability details** table displays data regardless of the timeframe selected. All columns in this table can be sorted, and above this table, you will find a **Settings** icon that allows changing the table settings to show or hide pre-selected columns and a search box that allows you to search. ::: # Configuration A dependency Track connection in IAM is required prior pulling data in . Make sure to have the proper access rights to the projects intended to sync and specify the project which user needs to track through the . For additional information on how to set a connection, refer to [Dependency Track configuration](docId\:H73fhs8PJ-oKDOPoVvZwd). By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applications, regardless of vulnerability. [title] Developer productivity metrics [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/DevOps performance metrics/ Developer productivity is highly dependent on the processes that govern activity. Most developers perform at very high levels within the boundaries of their organization and the processes that govern those activities, but their productivity can be limited by those boundaries. In that context, it's important to acknowledge that creativity is an integral but understated element of strategic software architecture and tactical coding, and that creativity is challenging to measure. The final outcome of software development is often thought of similar to the same way people think of assembling a jigsaw puzzle. That there is a model participants work toward, with a certainty of what the final outcome will be, the photo on the box. It's a well-defined picture that developers work toward in which the final form is predetermined. The reality is that it's more like a Lego set that can be used to build something that has a specified utility and for which the final form is not entirely certain. Kyndryl has determined that, at a minimum, the following metrics are critical to assessing the progress of the development effort: - **Commit Frequency**: Tracks the number of Commits integrated into the main branch by each developer per day. - **Pull Request Size**: Quantifies the volume of code changes submitted in a single pull request. - **Pull Request Time to Merge**: The time span from the creation of a Pull Request (PR) until it is merged into the main branch. - **Code Review Velocity**: Measures the time it takes for code changes or pull requests to be reviewed and either approved or rejected. - **Code Review Efficiency**: Measures the ratio of new defects found during a pull request review to the total number of known defects not yet resolved. To review Developer Productivity metrics, navigate to → **DevOps Performance Metrics**, and click the **Productivity Metrics** tab. # Commit Frequency Commit frequency measures how often a developer or team Commits code to a project's main branch. It is calculated by dividing the number of Commits by the length of the time period. It is a proxy for how many features are shipped, and it indicates a team's ability to integrate new code. A high Commit frequency can mean a team is productive and merging code frequently. By contrast, a low Commit frequency indicates challenges with deploying code changes. Frequent committing helps in early detection of issues and reduced chances of conflict between developments. Tracking is enabled at both the application level and developer level. The Commit Frequency dashboard widget is bounded by Commit dates on the X axis and the number of Commits on the Y axis. The widget defaults to a multi-line graph that tracks either application Commits, or developer Commits depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Commits for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in Commit frequency. Hover over each data point to display the following details: - Developer or application - Number of Commits for the developer or application on that date - The number of technical services Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details: - Commit ID: A hot link to all four metrics for that Commit in the form of graphic displays. - Application: The application associated with that Commit. - Technical Service: The service that was updated. - Commit date: The date on which the Commit occured. - Message: Messages submitted with the Commit. - Linked PR\:The Pull request associated with the Commit. - Created By: The ID of the developer who executed the Commit. A filter to select individual applications or developers is also available with two caveats: - The release manager role is required to view developers. - A maximum of 10 developers can be selected. # Pull Request Size Pull Request Size indicates the extent or magnitude of the modifications made by a developer and has two components: - Line of code modified (added or deleted) - Number of files modified. Benefits of smaller Pull Requests enables easier reviews and faster feedback. Generally, larger Pull Requests require more time to review and are more difficult to assess. This can negatively affect downstream metrics such as Time to Merge and Code Review Velocity, and diminish development team efficiency. Industry standard guidelines suggest a pull Request Size of 200 to 400 lines of code. The actual threshold should be set by your organization and used as a baseline in assessing development teams.The Pull Request Size dashboard widget is bounded by the Pull Request dates on the X axis and the number of files modified on the Y axis. The widget defaults to a multi-line graph that tracks either by application or developer depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Pull Requests for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in Pull Request Size. Hover over each data point to display the following details: - Developer or application - Lines modified - Date of pullrequest - Tool engine - Technical services - release manager is required to view developers. - A maximum of 10 developers can be selected. Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details: - **Pull Request number:** A hot link to all four metrics for that Pull Requst in the form of graphic displays. - **Application:** The Application associated with the Pull Request. - **Technical Service:** The service that was updated. - **Status:**The status of the Pull Request. - **Message:** Any message posted with the Pull Request. - **Created On:** The date the Pull Request was created. - **Merged On:** The date and time of the merge. - **No. of Files modified:** The number of files that were changed within the Pull Request. - **No. of Comments:** Code line comments accompanying the Pull Request. :::hint{type="info"} Pull Request data is captured only for Pull Requests that have been succesfully merged. ::: # Pull Request Time to Merge Pull Request Time to Merge is calculated from the time of Pull Request creation to merge, including any time it was in draft status. A low Time to Merge is associated with a higher success rate for Pull Requests and a shorter cycle time. A high Time to Merge can indicate that a team is managing too much work in progress, which can lead to bottlenecks and increased context switching, whereas a low Time to Merge indicates Team Efficiency; Collaboration Insight; Enhanced Code Quality. The Pull Request Time to Merge dashboard widget is bounded by the Pull Request dates on the X axis and the merge time span on the Y axis. The widget defaults to a multi-line graph that tracks either by application or developer depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Pull Requests for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in merge time. Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details: - **Pull Request number:** A hot link to all four metrics for that Pull Request in the form of graphic displays. - **Message:** Any message posted with the Pull Request. - **Created On:** The date the Pull Request was created. - **Merged with Main Branch On:** The date and time of the merge. - **Created By:** The Developer who initiated the Pull Request. - **Time To Merge:** The merge duration time. - **No. of Comments:** Code line comments accompanying the Pull Request. - **No. of Lines Changed:** The total number of lines that changed in the submitted code. - **No. of Files modified:** The number of files that were changed within the Pull Request. A filter to select individual applications or developers is also available with two caveats: - The release manager role is required to view developers. - A maximum of 10 developers can be selected. :::hint{type="info"} Pull Request data is captured only for Pull Requests that have been succesfully merged. ::: # Code Review Velocity Code Review Velocity measures how quickly code changes are evaluated and integrated into the main codebase, often indicated by the average time taken for a pull request to be reviewed and approved. This metric assesses the efficiency of the code review process by tracking the duration between submitting a request and receiving feedback. The following upstream metrics are used to calculate Code Review Velocity: 1. **Track Submission Time:** Record the time when a pull request or code change is submitted for review. 2. **Track Feedback Time:** Record the time when the initial feedback is provided. 3. **Calculate Duration:** Subtract the submission time from the feedback time to get the review duration. 4. **Average Duration:** Calculate the average review duration over a specific period, for example, weekly or monthly, to get a meaningful metric. The Code Review Velocity dashboard widget is bounded by the Pull Request dates on the X axis and the number of code reviews on the Y axis, and it displays the average duration of all code reviews as a header. The widget defaults to a multi-line graph that tracks either by application or developer depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average speed for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who's reviews are above and below average in duration. Hover over each data point to display the following details: - Developer or application - Number of Pull Requests - Number of code reviews - Date of code review - Tool Engine Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details: - **Pull Request number:** A hot link to all four metrics for that Pull Requst in the form of graphic displays. - **Summary:** The description that explains the changes made in a pull request. - **Raised On:**The date and time the Review was requested. - **Merged On:** The date and time of the merge. - **Developer Requested:** The developer who requested the review. A filter to select individual applications or developers is also available with two caveats: - The release manager role is required to view developers. - A maximum of 10 developers can be selected. :::hint{type="info"} * The review time does not depend on whether PR was accepted or rejected. * Pull Request data is captured only for Pull Requests that have been succesfully merged. ::: :::hint{type="info"} GitHub and other tools integrated by way of the*Bring Your Own Tools* DevOps feature are supported for capturing these metrics, to accommodate your team's approach. ::: # Code Review Efficiency Code review efficiency measures how effectively the code review process identifies defects before the code is merged into the main codebase. It helps ensure that the code quality is high and reduces the number of defects that are introduced to production. It is calculated as follows: 1. Find the the number of inline comments in the code submitted code for the pull request review (brownfiled deployment). 2. Find the number of defects identified by defect number during the review (greenfield deployment). 3. Find the sum of the brownfiled and greenfield defects that remain unresolved. 4. Find the ratio of unresolved conflicts in the pull request review to the resolved conflicts in the codebase. 5. Divide the sum by the number of total defects. This metric provides insights into the development activity at both the application and individual developer levels, enabling teams to optimize their workflow and improve efficiency. Using this insight, development managers acquire the following benefits: - **Improved Code Quality:** Efficient code reviews help identify and fix defects early, leading to higher quality code. - **Reduced Rework:** By identifying issues early, the amount of rework required is minimized, saving time and resources. - **Increased Productivity:** Efficient reviews streamline the development process, allowing teams to deliver features faster. - **Enhanced Collaboration:** Regular reviews foster better communication and collaboration among team members. A filter to select individual applications or developers is also available with two caveats: - The release manager role is required to view developers. - A maximum of 10 developers can be selected. [title] Supported tools [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ supports the integration of tools including the integration of third party, data collection and management (DevOps) tools such as GitHub, CodeQL and SonarQube. This capability centralizes your view of the lifecycle, minimizing the need to monitor multiple stations and simplifying administrative operations. Each DevOps tool in your library can be public or private to the client. As part of the standard offering, only the integration to the five standard public service providers (AWS, Azure, Google, IBM Cloud and Alibaba) are included. All other service provider integrations, even if standardized and covered by best practices, require custom service engagement with a professional services team. Integration relies on REST API calls over HTTPS. In the case of public services, the communication is direct from to the service provider API server. In the case of private services, the communication may require an agent deployed on the client network. Interactions with DevOps tools include: - Retrieving issue (defects, tasks) data - Retrieving build data - Retrieving test data - Retrieving deployment data - Retrieving Kubernetes cluster and container data The **Tools Configuration** page allows you to onboard and manage the tools integrated with your application. Use this page to configure tool settings and onboard tools, validating connections and ensuring each tool is properly set up before use. To onboard tools in your application, ensure to complete the prerequisetes: 1. Log in to the **Kyndryl Bridge Console**. 2. Open the **hamburger menu** in the upper-left corner. 3. Navigate to **Services** > **Platform Services, Toolchain & Pipeline**. 4. Select **DevOps Intelligence**. 5. In the left navigation pane, click **Settings & Utilities** > **Tools Configuration**. This opens the **Tools Configuration** page, where you can manage and configure DevOps tool integrations. For more information see, [Tools configuration](docId:0JYjuMk43ordXDMJN-Lvh). # Pre-requisites 1. **Roles and permissions**: Ensure you have the necessary roles and permissions within the platform to add tools, specifically the Platform Admin role. To verify your roles and permissions, refer to the Permissions section. 2. **Invalid credentials: **An "Invalid Credentials" error may occur due to incorrect or outdated login credentials or an incorrect host configuration. To resolve this issue: 1. Select Administration. 2. Navigate to . 3. Under Connections, select the connection with incorrect credentials. 4. View the connection details. 5. Edit the connection and enter the correct credentials. 3. **Configuration pending**: If a connection displays a "Configuration Pending" status, the setup for that connection has not been completed. Refer to the configuration section in the tools documentation below for additional guidance. 4. **Internal server error**: If you encounter an "Internal Server Error," the service may be temporarily unavailable or the pod may be restarting. Wait a few minutes and try again. 5. **On Premise Proxy Adapter**: If you are using a non-default DI tool with the On Premise Proxy Adapter, ensure the corresponding service is enabled in the Tenant Manager before adding the connection or service configuration. Refer to the appropriate configuration documentation for setup guidance. # Third party tools integration supports the integration of third party, data collection and management (DevOps) tools such as GitHub, CodeQL and SonarQube. This capability centralizes your view of the lifecycle, minimizing the need to monitor multiple stations and simplifying administrative operations. Each DevOps tool in your library can be public or private to the client. As part of the standard offering, only the integration to the five standard public service providers (AWS, Azure, Google, IBM Cloud and Alibaba) are included. All other service provider integrations, even if standardized and covered by best practices, require custom service engagement with a professional services team. Integration relies on REST API calls over HTTPS. In the case of public services, the communication is direct from to the service provider API server. In the case of private services, the communication may require an agent deployed on the client network. Interactions with DevOps tools include: - Retrieving issue (defects, tasks) data - Retrieving build data - Retrieving test data - Retrieving deployment data - Retrieving Kubernetes cluster and container data # Supported tools The platform supports the following tools: | **Category** | **Tool** | **Version / Details** | | ----------------------------------------- | ------------------------------------- | --------------------------------------------------------------------- | | Secure | Dependency Track | Default version. The platform pulls data from Dependency Track. | | Secure | CodeQL | — | | Secure | JFrog Security Essentials (Xray) | — | | Secure | Qualys Container Security Tool | — | | Secure | SonarQube | Default version. | | Develop | Atlassian Bitbucket | Cloud - API Version 2.0 / Server - API Version 1.0 | | Develop | Atlassian JIRA | API Version V2 | | Develop | AWS CodeCommit | Default version. | | Develop | AWS CodePipeline | Default version. | | Develop | AWS DevOps | Default version. | | Develop | Azure Boards and Azure Repo | API Version 7.0. Supports Azure DevOps Cloud and Azure DevOps Server. | | Develop | GitLab (Public and Enterprise) | API Version V4 | | Develop | GitHub (Public and Enterprise) | Default Version (V3) | | Build | AWS CodeBuild | — | | Build | Azure Pipelines Build | — | | Build | Jenkins | — | | Build | JFrog Artifactory | — | | Test | Azure DevOps - Test Plans Support | Default Version | | Test | Jenkins Plugin | — | | Test | SonarQube | Default Version | | Deploy | ArgoCD | — | | Deploy | AWS CloudFormation | SDK Version - 1.35.9 | | Deploy | AWS CodeDeploy | — | | Deploy | Azure Pipeline Deploy | — | | Deploy | Azure Pipelines release | — | | Deploy | Azure Resource Manager | — | | Deploy | GoCD | — | | Deploy | Google Deployment Templates | SDK Version - 0.69.1 / API Version - V2 | [title] Open source license compliance [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ # Open Source License compliance More and more companies are choosing open source tools as part of a standard library composing the tool stack. The downside is that many of these tools while inexpensive or complementary, still require a license. Whether open source or proprietary, licenses must be maintained. a license violation is a violation regardless of whether the tool is open source. Managing that license library is therefore a critical element of your developer operations. provides observability of the state of your open-source license compliance Selecting Open source license compliance opens the Open-Source License Compliance dashboard displaying a set of graphs that monitor open-source licenses statuses, and an export feature that allows a customized report file download, as follows: - License Detected - License by Severity - Export License Compliance Details - License Compliance Details ll open-source code must be regulated. The primary function of this dashboard is to track of all licenses being used by each application and to understand which are authorized and which are not. # Display Filters The dashboard is equipped with two filters to tailor data presentation to specific requirements: - **Global Filter:** Filter by application and duration (time span in days from selected origin to present) for example, the past 30 days. Default **All**. - **Release Filter:** Filter by a specific release such as 8/27/2025. Default **All**. The two filters work in concert to limit presented data to the selected application AND duration AND Release. If both are set to the default **All** data is presented. However, if for example, you filter on *my\_application* (global filter) and release *July 23, 2025* (release filter), the dashboard will present only data for *my\_application* at release *July 23, 2025*. # License Detected The License Detected graph represents the total number of licenses detected according to the day-month timeline selection. Severities in this widget are classified according to their criticality: - **Allowed**: Green color. - **Denied**: Red color. - **Uncategorized**: Dark red color. - **Need approval**: Yellow color. Graph data supports selecting predetermined Applications and Dashboards from the Drop-down menu. By default, it is for all applications and all technical services and, it represents the data for the last 7 days. The License Detected widget presents two axis that indicates the** Total License Detected** within a specified period: - X-Axis (**Duration**): The X-axis corresponds to the month in which the bar graph data is shown. Depending on the time you select, the bar graph changes in color based on the severity of the licenses detected. By hovering over the graph, the following data is presented for each license severity: - **Group**: The severity that the licenses in a given group have. - **Range**: The cut-out date for detected licenses. - **Value**: Total number of licenses in a particular severity group. - Y-Axis (**Total License Detected**: The Y axis corresponds to the total number of licenses found for each severity within a given period. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Range**: The cut-out date for detected licenses. - **Allowed**: Total number of licenses detected in the Allowed category. - **Denied**: Total number of licenses detected in the Denied category. - **Uncategorized**: Total number of licenses detected in the Uncategorized category. - **Need approval**: Total number of licenses detected in the Need Approval category. - **Total Licenses**: The total number of licenses from all categories. # License by Severity The License by Severity widget graph represents the total number of aggregated licenses detected according to day-month timeline selection. Severities are classified into two categories: **Critical** and **Info**. Graph data supports selecting predetermined Applications and Dashboards from the Drop-down menu. By default, it is for all applications, all teams, and for default organizations. By default, it represents the data for the last 7 days. The License by severity widget presents two axis that indicates the **Total License Detected** within a specified period: - X-Axis (**Duration**): The X-axis corresponds to the month in which the bar graph data is shown. Depending on the time you select, the bar graph changes in color based on the severity of the licenses detected. By hovering over the graph, the following data is presented for each license severity: - **Group**: The severity that the licenses in a given group have. - **Range**: The cut-out date for detected licenses. - **Value**: Total number of licenses in a particular severity group. - Y-Axis (**Total License Detected**): The Y-axis corresponds to the total number of licenses found for each severity within a given period. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Range**: The cut-out date for detected licenses. - **Critical**: Total number of licenses detected and classified as Critical severity. - **Info**: Total number of licenses detected and classified as Info severity. - **Total**: The total number of licenses from all severities. # Export license compliance details Export license compliance details allow you to download a report file based on **Technical services** and **License status**, multiple selections are enabled on both options, to download a license report complete the following procedure: 1. Select **Search Technical services** and choose one or more technical services. 2. Select **Search Licence Type** and choose one or more license statuses. 3. Select **Export to CSV** and a dialog will prompt you to save or open the CSV file. # License Compliance Details table The License Compliance Details Table View is a table that provides technical service Security data in a tabular form and enables a detailed view of each technical service. Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical service**: The name of the micro-technical service within the larger application. - **Application**: The name of the application, typically comprising multiple micro-technical services. - **Image Name:** The assigned image name. - **Release Name:** The name of the release in which the license was activated. - **License detected**: Total number of licenses detected for a technical service. - **Denied:** The number of licenses that were denied. - **Need Approval:** The number of licenses for which approval has not been granted. - **Allowed:** The number of licenses that have been granted. - **Uncategorized:** The number of licenses for which the license text is not recognized by an open-source body. The Table view supports a sort feature that enables you to toggle between ascending and descending alphanumeric order for all columns except **License detected** and **Critical**. :::hint{type="info"} The** Table View** displays all data without regard to filter selection. ::: To access details for a specific technical service, click the row for that technical service. It also supports detailed views for each technical service, to access details for a specific technical service, click the row for that technical service). When you click on a technical service from the Table View, a new dialog appears with technical service details. The following elements are displayed in this dialog: - **License**: The name of the license for a given technical service. - **Package name**: The name of the license directory (package location) - **Package version**: The version of the license detected. - **License Status**: One of the categories that licenses can fall into. :::hint{type="info"} The Table View provides a clickable arrow below the bottom right corner of the table that enables navigation across pages of data (Page 1 of 3, Page 2 of 3, etc ::: By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applications, regardless of vulnerability. [title] GitLab: Plan phase [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ GitLab is a single application that spans the entire software development lifecycle. This makes GitLab unique and creates a streamlined software workflow, unlocking your organization from the constraints of a pieced-together toolchain. supports your use of GitLab and GitLab Enterprise. For   to pull data from GitLab, you must configure a GitLab account. **GitLab** Application requires the following information for GitLab: - **Name:** Local account name. It could be any string and is used only for reference. - **User:** Username for GIT. Generally, the email ID with which the user logged in to GIT. - **Token:** Personal access token. Tokens can be generated from the following menu selection: settings → access tokens. The personal access token requires permissions within the following recommended scopes: Application also requires the following GitLab credentials: - **GitEndPoint:** gitlab - **Name:** neha-gitlab - **User:** a\_user\@domain.com - **Token:** Personal access token. **GitLab Enterprise** Application requires the following information for GitLab Enterprise: - **Name:** Local account name. It could be any string and is used only for reference. - **Host:** Git API URL of the Git Host. eg, API url will be like https\://gitlab.gravitant.net - **User:** Username for GIT. Generally the email ID with which user logged in to GIT. - **Token:** Personal access token. The personal access token requires the permissions within the following recommended scopes: Application also requires the following GitLab Enterprise credentials: - **GitEndPoint:** gitlab enterprise - **Host: **https\://gitlab.gravitant.net - **Name:** rajat - **User:** a\_user\@domain.com - **Token:** Personal access token. # Configuring for GitLab: Plan phase and recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June 2024 or after. Procedures for legacy customers are provided in the subsequent section *Configuring * &#xNAN;* for GitLab, legacy customers*. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with GitLab as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure GitLab or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Plan row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select GitLab for **Tool Engine**. 6. Click **Submit**. # Onboarding GitLab: Plan phase After configuring GitLab, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Plan** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **GitLab** for **Tool Engine**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the Repository Name field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that GitLab has been fully configured. # Deleting GitLab as a technical service The administrator may, at will, delete the GitLab technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Plan**. 4. Click **Delete Technical Service**. 5. Click GitLab for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. # Configuring for GitLab, legacy customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded before 6 June 2024. ::: If the user wants to track all the repository comprising this organization (Organization Level), then he would need to select orgs. And, if the user wants to track a particular repository (Repository Level), he would need to select repos. **Organization level tracking:** For this type of tracking, some selections have to be made in the system, as described in the following list: - **Account:** Refers to the account through which the tracking is to be done. - **Select Tracking Type:** Users must select **Organization** for Org level tracking - **Search Organization:** By selecting here, a list of all organizations for the selected account but not tracked by Application. Select any organization you want to track and select **Configure**. **Repository level tracking:** For this type of tracking, some selections have to be made in the system, as described in the following list: - **Account:** Refers to the account through which the tracking is to be done. - **Select Tracking Type:** User must select **Repository** for Repo level tracking - **Search Organization:** By selecting here, a list of all organizations for the selected account but not tracked by Application. Select any organization to be tracked and select**Configure**. Select any organization you want to track and select **Configure**. - **Search Repository:** By selecting here, a list will be displayed with all the repositories that are part of the selected organization but not tracked. Select any repository you want to track and select**Configure**. 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 mins: Refresh current data - The account Delete Interval is set to 7 mins: All deleted accounts updated - The history pulled Interval is set to 180 days: Data history # Configuring GitLab To complete the integration of GitLab, you must complete a configuration process. Kyndryl supports two different configuration processes only one of which your organization has subscribed. If your organization was onboarded before 6 June, 2024, you are subject to the legacy process (legacy customers). If your organization was onboarded on 6 June 2024 or after, you are subject to the new process (recent customers). Refer to the appropriate document in the following list: - [Application configuration: legacy customers](docId\:M1Tce9Nzb0Dguu9W8zoGw) - [Creating an application](docId\:r_oXvj9o68Noa0fc6J5ks) :::hint{type="info"} 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 efficent 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. ::: [title] Secure module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Inspect your hybrid IT estate for vulnerability details in Static Scan, Dependency Check using Container Vulnerability Scan and Secure alerts. :::hint{type="info"} The Secure functionality is applicable only for **Premium Plan**. ::: Preeminent to the DevOps lifecycle is the requirement of security. All phases of the lifecycle rely on minimal vulnerabilities and optimum security protocols. All activity in the Develop, Build, Test and Deploy stations are predicated on a secure environment that preculdes compromise of the work results. provides native security tools role-based access that enable a secure development environment, but it goes a step further, allowing the integration of industry vaunted security tools as well. The Security module displays data that indicates potential vulnerabilities that can help you to preempt external security breaches minimizing attacks and inadvertent internal security missteps that can compromise the integrity of applications and services you offer valuable customers, protecting them as well. # Secure Module composition In the Secure dashboard, data can be filtered by two criteria: - **Dashboards:** Select a dashboard to view development data specific to that dashboard. - [Secure SDLC Governance Dashboard](docId\:E01YyWfnDeYrfP1YgqxPc) - [Secure alerts](docId\:MrPFfez9p-F1WGUnDPSin) - [Open source license compliance](docId\:oZEOlEYLXjhZiQMJxEkq-) - [Static scan](docId:067iAwEsTno9_iOpmeCh1) - [Dependency Check](docId\:vBVWZnjJoxjGhvp352_eu) - [Container vulnerability](docId\:nLprib08gjT1xP2smrMfl) - **Applications:** Comprehend the issues and health of cloud services such as CAM and Enterprise Marketplace. **Notes:** Depending on your selections from these filters, the data displayed in the widgets varies, and some widgets may show the message *“No Data Available”*, which means there is no recent data available for your selection. # Widgets The Secure dashboard displays data in the form of five widgets presented as follows: - Secure alerts - Application summary - License by Severity - Static scan - Dependency check - Container vulnerability For details on widgets, click [here](docId\:iybMFaTHX5YdGTMqjGQuo). [title] Jenkins Plugin configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Build/ Jenkins is the leading open-source automation server, providing hundreds of plugins to support building, deploying, and automating any project. For to pull data from Jenkins, you must configure a Jenkins account. # Jenkins Plugin The plugin must be downloaded and then installed. You may do so by visiting Artifactory Jenkins Plugin. Or from tenant, follow these next steps to download the plugin from the File Server: 1. Select** Developer Console** from the user icon menu at the top right of the screen and from the **API Documentation** tab select `DevOps Intelligence` from the Application drop-down menu, and `file-server` from the Service drop-down menu. 2. Execute the /files API to get the list of files. 3. Copy the name of the file to download. The file related to the Jenkins plugin has the following format: **kyndryl-platform-devops-x.x.x-SNAPSHOT.hpi** use the latest version of the plugin. 4. Execute the (/*files*/\{*fileName*}) API by clicking the **Execute** button. 5. Select the **Download file** link in the response body. # Configuration steps Jenkins plugin is an example of Bringing Your Own Build and Bring Your Own Test tools. By using this plugin, the Jenkins host is able to send build data to the intelligence dashboard. The steps to configure the Jenkins plugin are as follows: 1. Login to Jenkins Server. 2. Upload Plugin. Go to **Manage Jenkins**→**Manage Plugins**→**Advanced Tab**. Then, under **Upload Plugin**, select the plugin to upload, which is the kyndryl-platform-devops-x.x.x-SNAPSHOT.hpi (for example Jenkins plugin) :::hint{type="info"} Note: The .hpi file can be downloaded from file-server or artifactory option. ::: 3. Restart the Jenkins server. Check on the **Installed** tab if the plugin is enlisted (search for ). 4. Add the credentials to Jenkins.To accomplish this, create a token in in the build tool (a service token). Please select the following menu selections for this step: Go to **Dashboard**→** Settings & Utilities**→** Tools configuration →** **Token**→ Select the token type as **Build** or **Test** Copy the token value.Once the token is obtained, perform the following menu selection to add the credentials to Jenkins: **Jenkins Dashboard**→**Credentials**→**System**→**Global Credentials**`Add Credentials` for build or test.The credentials page will open, Select Kind as Username and Password, Scope as Global and give the build or test token generated in DevOps Intelligence as password. :::hint{type="info"} Note: Enter the credential username as the token name created in and the password as the actual service token. ::: 5. Configuring plugin in the Existing Jobs (for projects).To accomplish this, select any job to configure the installed plugin, and then select **Configure**→**Post-Build Actions**.After that, select the **Publish build information to ** option from the **Add-Post-Build Action** drop-down.Then, select **Apply** and **Save**. 6. Build the Project to publish the build data to . The selections to be made here are: **Project**  →**Build Now**. [title] Bring your own tools [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Understand how to integrate unsupported tools with , extending the single pane of glass DevOps affords in your hybrid IT estate. allows you to use your private tools and customize your processes and environment to meet your needs. This means you can take advantage of the tools you are already familiar with, specific to your workflows and avoid the costs of training and onboarding new tools. With this support for private tools, you can easily integrate your existing tools into your cloud environment using APIs and plug-ins. This integration ensures that your tools are seamlessly connected to your cloud environment, giving you the visibility and control you need to manage your software development and deployment processes effectively. also supports tool mappers, enabling your private tools to post data to . The following types of private tools are supported: - Bring your own test: Test API Integration. - Test file upload support: - Unit - Jacoco - Mocha - Karmamocha - Jmeter - Cobertura Instanbul - Bring Your Own Build: Build API integration. - Bring Your Own Deploy: Deploy API integration. - Bring Your Own Develop: Develop API integration. - Bring Your Own Secure API integrations. - Bring Your Own Image: Image API integration. - Bring Your Own Static Scan: Static Scan API integration. - Bring Your Own Dependency-Check: Dependency Check API integration. Industry-standard tools are also supported: Supported tools. # Creating a service token For the Application to access your tool, you must create a service token. To create a service token for a build tool, go to **Settings & Utilities** →**Tools configuration **→ **Token tab**. Select the **Create token** button and provide the following information in the *Add token* section of the token dialog: - **Name:** Name of token. It could be any string. - **Type:** The type of token needed (Build, Deployments, Develop, Secure or Test). # Navigating tools and APIs The Application provides access to your tools through the **Settings & Utilities** menu is found under the **Open** icon in the upper left corner of the Application. When you select **Settings & Utilities**, the Application displays a series of options, among them **Tools**, by selecting it, a new screen will display information regarding all configured tools within the  Application. To view the APIs for your tools, select the **Developer Console** tab found under the **User** icon located in the upper right corner of the Application. When selecting **Developer Console** a new screen displaying a series of tabs among them **API Documentation**. On the **Application** drop-down menu, select  from the list, and the **Service** In the drop-down menu, select the technical service (tool) you would like to configure. - [Bring your own tools](docId\:J2wCdGqoWTc5MnOocZTyA) Learn how to integrate build tools to . - [Bring your own dependency check](docId\:JdEly4iqb1-do8ogomEF4) Learn how to integrate Dependency Check tools to Kyndryl Modern Operations –  . - [Bring your own deploy](docId\:SF_ESDMWw_3d2OIcoNJh0) Learn how to integrate deploy tools to . - [Bring your own develop](docId\:o3JSOD6iAjC5QWq6p1kPL) Learn how to integrate develop tools to . - [Bring your own image scan](docId\:gRxRaIBYcxx2vhhRsOxxU) Learn how to integrate secure image scan tools with . - [Bring your own license](docId\:teN-pQ9Wi-aOL-W0VZFuF) Learn how to integrate secure license tools to Kyndryl Modern Operations – . - [Bring your own metrics](docId\:QBj2Xkdcmm4NCjmJ0MtYM) Learn how to integrate metrics tools to . - [Bring your own static scan](docId\:pM025VJFSR9OuyojZssgA) Learn how to integrate static scan tools to Kyndryl Modern Operations –  . - [Bring your own test](docId:192pUHGNIiawD3QBh1wct) Learn how to integrate test tools to Kyndryl Modern Operations – . [title] Introduction [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ ## Migration overview The Service (BAS) provides a modern orchestration platform for automation workflows, catalogs, schedules, and events previously managed in Automation Service (AS). This guide covers the activities required after migration, including: - Reviewing migration reports - Configuring CACF credentials - Testing and validating migrated assets - Configuring IAM access - Enabling automation The guide also introduces BAS workflow authoring capabilities, which can be used to create new workflows and expand automation use cases. ## Migration process The migration process consists of the following high-level phases: ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/1brXC9HjH2shVh5F-m6mF_image.png) ## Customer account segmentation and migration tracking The AS to BAS migration report provides an account-level view of migration readiness and progress. Customer accounts are grouped into migration lanes based on: - Current AS usage - GSMA configuration - Planned EPSA adoption This segmentation helps identify the appropriate migration path and track migration activities for each account. The report provides visibility into whether an account contains: - Public catalogs - Private catalogs - Events - Schedules The report also tracks account progress through the following migration phases: - Pre-Migration - Migration - Post-Migration Each phase displays the current migration stage and any remaining activities required to complete the migration. For more information, see [View AS-to-BAS Migration Report](https://kyndryl.sharepoint.com/\:x:/r/sites/CTO/_layouts/15/Doc.aspx?sourcedoc=%7BC6C2FF7B-E674-49E6-97FF-90B9D1AC2051%7D\&file=AS_to_BAS_Customer_Status_Tracker.xlsx\&action=default\&mobileredirect=true). [title] Bring your own static scan [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Bring your own tools/ Learn how to integrate static scan tools to Kyndryl Modern Operations –. Devops Intelligence Secure dashboard represents vulnerability details for static scan, license compliance, dependency check & container vulnerability scan. With **Bring your own static scan** APIs, vulnerability scan information is transmitted to . Every time a piece of code violates a coding guideline, tools like Sonarquebe highlight a problem. Each issue has one of five severity levels: **Blocker**, **Critical**, **High**, **Major**, **Minor** and **Info**. allows users to provide a list of vulnerabilities, generate metrics based on these vulnerabilities and display severity ratings based on the parameters listed below. **A** = 0 Vulnerabilities** B** = at least 1 Minor Vulnerability **C** = at least 1 Major Vulnerability **D** = at least 1 Critical Vulnerability **E** = at least 1 Blocker Vulnerability :::hint{type="info"} Note: Secure functionality is applicable only for premium plan in . ::: # Bringing data into  To bring your own Build tools complete the following steps: 1. Go to the  Tools Configuration page and navigate to the Tokens tab. 2. Click on Create Token and give a unique Token name. 3. Select Token Type as Build, then click on the Create button. 4. A new entry will be added to the table in the table entry. 5. Click on the vertical ellipsis icon on the respective row and select the view/regenerate token option. 6. Copy that token by clicking copy icon in the token field. :::hint{type="info"} To Post Data to the APIs mentioned below, Add the service Token (see: [Creating a service token](docId\:J2wCdGqoWTc5MnOocZTyA)) to the **Authorization** header of the request. See cURL Example for reference. ::: # Format **Step 1: TOKEN \{the-service-token-from-step1}** **Example:** **TOKEN 74h5cR8sETSJRvOFkdbsISY3lsgfNGu\_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX** **Step 2:  API Reference** **API: technical-services/static-scan** **URL https\://\{devops-intelligence-host}/dash/api/build/v3/technical-services/staticscan** **Parameters** | **Parameter** | **Type** | **Explanation** | **Example Value** | | ------------------------------------------ | ------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authorization\* | Header | Authorization has a service token | 74h5cR8sETSJRvOFkdbsISY3lsgfNGu\_V5aNur4Pxu1Jh8kP0NQBJhuWQsRmGzTX | | vulscan \* | BODY | Scan Data in Json | `{ "endpoint_hostname": "string", "provider_href": "string", "scannedby": "string", "scanned_time": "string", "technical_service": "string", "technical_service_tag": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "technicalserviceoverride": true, "vulnerabilities": [ { "actions": [ "string" ], "attr": { "jira-issue-key": "string" }, "author": "string", "closeDate": "string", "comments": [ { "createdAt": "string", "htmlText": "string", "key": "string", "login": "string", "markdown": "string", "updatable": true } ], "component": "string", "creationDate": "string", "debt": "string", "effort": "string", "hash": "string", "key": "string", "line": 0, "message": "string", "project": "string", "resolution": "string", "rule": "string", "severity": "string", "status": "string", "tags": [ "string" ], "textRange": { "endLine": 0, "endOffset": 0, "startLine": 0, "startOffset": 0 }, "transitions": [ "string" ], "type": "string", "updateDate": "string" } ], "vulnerability_density": 0 }` | ## URL example **Request** ```javascript curl -X 'POST' \ 'dash/api/dev_secops/v3/technical-services/static-scan' \ -H 'accept: application/json' \ -H 'Authorization: Token aJzv1zn_G-XmerycnRhX1uzUGyPZZWvbK-bcRdAZoRs6XzIUnThfLnolc0sTrzoL' \ -H 'Content-Type: application/json' \ -d '{ "endpoint_hostname": "123", "provider_href": "http://mytest.com", "scannedby": "BYO", "scanned_time": "2022-12-05T07:20:50.52Z", "technical_service": "myservice", "technical_service_tag": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "technicalserviceoverride": true, "vulnerabilities": [ { "actions": [ "string" ], "attr": { "jira-issue-key": "string" }, "author": "string", "closeDate": "string", "comments": [ { "createdAt": "string", "htmlText": "string", "key": "string", "login": "string", "markdown": "string", "updatable": true } ], "component": "string", "creationDate": "string", "debt": "string", "effort": "string", "hash": "string", "key": "newkey", "line": 0, "message": "string", "project": "string", "resolution": "string", "rule": "string", "severity": "Critical", "status": "OPEN", "tags": [ "string" ], "textRange": { "endLine": 0, "endOffset": 0, "startLine": 0, "startOffset": 0 }, "transitions": [ "string" ], "type": "string", "updateDate": "string" } ], "vulnerability_density": 0 }' ``` **Response 200** "Total Number of records inserted successfully is 1" ## Secure-Static-Scan-vulnerability request body explained | **Field** | **Data Type** | **Explanation** | **Example Value** | | -------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------- | ----------------------------------------------- | | endpoint\_hostname | string | Name of the endpoints | "myOrg/myRepo" | | provider\_href \* | string | Provider URL on which vulnerability is scanned | "http\://mytest.com | | scannedby \* | string | Tool which is used to scan the Vunerabilities of the repositories | "BYO", | | scanned\_time \* | string | Time of the scan in UTC | "2022-12-05T07:20:50.52Z" technical\_service \* | | technicalserviceoverride | boolean | Override flag for the service | true | | Vulnerabilities | Details of the fields | | | | Key \* | string | Value of the Key | "new\_key" | | Severity\* | string | Severity of Vulnerability | critical, high, low, medium | | Component | string | Name of the Component | "/var/lib/comp" | | Project | string | Name of the Project | "DI-SecOps" | | Rule | string | Rule Name | unused variable | | Line | int32 | Line number | 124 | | Hash | string | Hash value | d94d76ad5f5cecd413e | | Resolution | string | Reason of remediation | resolved | | Status \* | string | Status of the Vulnerability | OPEN, CONFIRMED, REOPEND | | Message | string | Details of the Vulnerability | "This is created for BYO" | | Effort | string | Time taken to resolve | 30 min | | Debt | string | | | | Author | string | Name of the Author | Alice | | Tags | \[]string | Tages for the vulnerability | unused | | CreationDate | string | Date of creation | "2022-12-05T07:20:50.52Z" | | UpdateDate | string | Date of update | "2022-12-05T07:20:50.52Z" | | CloseDate | string | Date of close | "2022-12-05T07:20:50.52Z" | | Type | string | Type of Vulnerability | internal | | TextRange | string | Range of texts | | | Comments | string | Comments on the vulnerability | "Created for the internal services" | | Attr | \[]string | Attributes | | | Transitions | string | transitions | | | Actions | string | Actions taken | | [title] ServiceNow configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ ServiceNow is a sophisticated Incident and Change ticketing system. As incidents are reported and change requests are made, ServiceNow provides a platform to enable tracking these ITSM requests and accrue performance data as your DevOps team acts on these tickets. By integrating ServiceNow with , you can compile critical statistics such as Change Faiure Rate (CFR) and Mean Time to Restore (MTTR) automatically, statistics that are traditionally challenging to dynamically calculate. To Integrate ServiceNow with you must complete the following procedures: 1. Inventory and acquire prerequisite requirements. 2. Create a connection between ServiceNow and . 3. Enable an onboarding configuration application. 4. Onboard it as a technical service. # Prerequisite requirements The following items are required before beginning: - **Obtain ServiceNow Credentials:** Users must have valid credentials (username and password) to access the ServiceNow platform. - **User Role Requirements:** Users must have appropriate roles assigned in ServiceNow to pull, create, and manage incidents and change requests. If you are unsure about the required roles, please refer to the ServiceNow documentation on role management for guidance on role assignments and permissions. - **Access Policy as Platform Administrator and ** &#xNAN;** Administrator:** Ensure that the user creating the connection has the necessary access policies. The user should have the Platform Administrator role to create and manage connections effectively. Users must be assigned the Administrator role, which allows them to create and manage configurations. # Creating a connection Use the following procedure to create a connection between and ServiceNow: 1. Click **App Manager** → **IAM** → **Connections** → **Add New** → **Add connection**. 2. Select the **Add Connection** option. 3. Select Content provider as snow. requires the following information: - **Connection Name:** Local connection name. It could be any string and is used only for reference. - **Service Now Instance URL:** ServiceNow Host URL. Example: https\://dev123456.service-now\.com/ - **Username for ServiceNow:** The user ID with which user logged in to ServiceNow. - **Password:** Password of the User with which user logged in to ServiceNow. - **ProxyID (Optional):** This is the UUID for the Proxy Adapter. A proxy adapter serves as a bridge between your on-premise applications and the cloud, enabling secure and efficient communication, and is necessary if your customer's data is behind their firewall. Proper configuration is essential for optimal performance and security if this option is required. 4. Complete the form. The following fields may be populated with nonsense values while creating the connection: - Client ID - Token # Configuring ServiceNow To complete the integration of ServiceNow, you must complete a configuration process. Kyndryl supports two different configuration processes, only one of which your organization has subscribed. If your organization was onboarded before 6 June, 2024, you are subject to the legacy process (legacy customers). If your organization was onboarded on 6 June 2024 or after, you are subject to the new process (recent customers). Refer to the appropriate document in the following list: - [Application configuration: legacy customers](docId\:M1Tce9Nzb0Dguu9W8zoGw) - [Creating an application](docId\:r_oXvj9o68Noa0fc6J5ks) :::hint{type="info"} Note: 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. ::: [title] AWS configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ Amazon Web Services (AWS) provides a robust and secure cloud services platform, delivering essential resources such as computing power, database storage and content delivery to help scale and grow your business. enhances your AWS experience by offering insightful data analysis, and this section outlines the necessary configuration steps. To enable to efficiently extract data from multiple AWS services, setting up and configuring an AWS account is imperative. This setup is critical in harnessing the full potential of AWS and capabilities. The following are supported AWS services: - Cloud formation - EC2 - EKS  only reads data from these services; hence, ReadOnly access is required for all of them. # Access rights for Cloudformation  performs the following actions on AWS Cloudformation: - ListStacks - DescribeStacks - DescribeStackEvents - DescribeStackResources - GetTemplate - GetTemplateSummary  requires the ReadOnly access for all actions. See the following example for reference: ```javascript { "Version":"2030-10-07", "Statement":[{ "Effect":"Allow", "Action":[ "cloudformation:DescribeStacks", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStackResources", "cloudformation:ListStacks", "cloudformation:GetTemplate", "cloudformation:GetTemplateSummary" ], "Resource":"*" }] } ``` **Access Rights for Elastic Container Service(EC2):**  performs the following actions on AWS EC2: - DescribeInstances Please note that managed policies for Amazon EC2 can be used to provide ReadOnly Access to EC2 service: - AmazonEC2ReadOnlyAccess **Notes:** Using the credentials provided, Kyndryl Platform Discovery will pull (Sync) **Deployments and Virtual Machines** on behalf of . 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 mins: Refresh current data. - The account Delete Interval is set to 7 mins: All deleted accounts are updated. - The history pulled Interval is set to 180 days: Data history. **Access rights for Elastic Kubernetes Service(EKS):**  performs the following actions on Amazon EKS: - ListClusters - DescribeCluster This example shows how you can create a policy that allows a user read-only access to list or describe all clusters: ```javascript { "Version": "2030-10-07", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` For more details, see your Delivery representative. - [AWS CodeCommit configuration](docId\:J_us-avg8JYZ6pvgHL5r6) Learn how to configure for the integration of AWS CodeCommit to broaden the observability of your hybrid IT estate. - [AWS DevOps connection](docId\:NeXnShmXZqPAmqwhPimEr) Learn how to configure for the integration of AWS Connection to broaden the observability of your hybrid IT estate. [title] Glossary of terms [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/DevOps Intelligence user interface/ The following is a list of the definitions related to : - **Pipeline**: a pipeline is a combination of tools that they use in order to move their software through the development cycle and into production. Normally this means bringing together information from many disparate sources such as: - **SCM** (Source Code Management) tools such as GIT and Mercurial - **CI/CD/CD** (continuous integration) tools such as Jenkins, Travis-CI, Circle-CI and Team City - **CI/CD/CD** Continuous Delivery tools such as Travis-CI, Spinnaker and Circle-CI. - **CI/CD/CD** Continuous Deployment tools which are often the same set as continuous delivery tools - **Technical services:** Technical services are the basis of all elements we provide visibility to. A technical service can itself be comprised of other services. Technical services are the primary resource we focus on. Technical services are supported by a single git REPO (or more than one repository, some repositories may support more than one service); plus, they have a build and unit test (somewhere). As well, technical services can be used in one or more applications, where they are developed and managed by one team. - In addition, the Development team and Management team should normally be the same for most services, but it is not guaranteed. Normally, technical services are deployed via a kubernetes services definition (in k8s) or may have just a POD definition or a replica set; or through a template in AWS/Azure/Google (if VM or non-Kubernetes based). - **Cardinality**: - Repositories are associated with a single service. - Technical services can be associated with zero, one or more applications. - **Applications**: an application is a higher level service. Application and Technical Service are somewhat similar and based on the approach undertaken by a given development organization they will choose what constitutes an application as they see fit. Common service used by many applications are likely to be grouped together as applications like a CORE application or an IAM service. The granularity will likely vary, and the best statement is it would be whatever the customer feels qualifies as the granularity that fits their needs. - **Tenant Roles**: Tenant level roles have little to no relationship to organization roles. A tenant level role is intentionally limited to the Administration capabilities of the system. All users who have been invited/authorized to use the system are implicitly considered tenant members. A tenant admin has the ability to invite new members, remove users as well as granting others the role of being a tenant admin as well as removing the tenant admin role from someone. [title] Dependency Track configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ Dependency Track is continually scanning components for known flaws. When a component is added or changed in Dependency-Track, it is analyzed; this occurs during file ingestion and component modifications through REST APIs or the user interface. Every component in the Dependency Track is automatically evaluated daily, regardless of changes. supports your use of Dependency Track. For to pull data from Dependency Track, you must configure a Dependency Track account. **Access rights:** The account should have read access to the projects we intend to sync. requires the following information: - **Name:** Local account name. It could be any string and is used only for reference. - **Host:** Dependency Track Host URL. For example: `https://dtrack.kyndryl.net` - **ApiKey:** The ApiKey can be generated from - Access Management → Create Team → Select Generate APIKey Credentials should look similar to the image below. # Configuration The user needs to select the project that must be tracked through the tool. When the configuration is successful, we can see the configuration in the table on the configuration page. [title] Support [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ This section describes the support and escalation process for issues encountered during or after the Automation Services (AS) to Services (BAS) migration. ## Support process If a migration issue cannot be resolved by reviewing migration reports, workflow execution details, or execution logs, create an incident through the Bridge support process. ### Create request Perform the following steps to create an request: 1. Open the Bridge support interface. 2. Create a new incident. 3. For the field, **Where are you experiencing the issue**, select **Bridge Platform**. 4. Provide a detailed description of the issue. Before submitting the incident, review the migration workflow execution and migration reports to identify any reported errors or failed activities. Include the following information in the incident: - Migration workflow execution ID - Account or tenant details - Migration report details - Affected catalogs, schedules, workflows, or event rules - Error messages and execution logs - Steps performed before the issue occurred :::hint{type="info"} * Providing complete diagnostic information helps the support team investigate and resolve the issue more efficiently. * Capture screenshots of failed activities, workflow execution details, and output parameters when reporting migration issues. ::: For instructions on creating incidents, go to **Bridge Converged Platform Support** and the **General Instructions to Open an Incident Ticket** guide. ## Escalation process If an issue cannot be resolved through the standard incident process or requires additional attention, follow the **Bridge Converged Platform Support** escalation process. [title] GitLab: Develop phase [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Learn how to configure for the integration of GitLab during the Develop phase to broaden the observability of your hybrid IT estate. GitLab is a single application that spans the entire software development lifecycle. This makes GitLab unique and creates a streamlined software workflow, unlocking your organization from the constraints of a pieced-together toolchain. supports your use of GitLab and GitLab Enterprise. For   to pull data from GitLab, you must configure a GitLab account. **GitLab** Application requires the following information for GitLab: - **Name:** Local account name. It could be any string and is used only for reference. - **User:** Username for GIT. Generally, the email ID with which the user logged in to GIT. - **Token:** Personal access token. Tokens can be generated from the following menu selection: settings → access tokens. The personal access token requires permissions within the following recommended scopes: Application also requires the following GitLab credentials: - **GitEndPoint:** gitlab - **Name:** neha-gitlab - **User:** a\_user\@domain.com - **Token:** Personal access token. **GitLab Enterprise** Application requires the following information for GitLab Enterprise: - **Name:** Local account name. It could be any string and is used only for reference. - **Host:** Git API URL of the Git Host. eg, API url will be like https\://gitlab.gravitant.net - **User:** Username for GIT. Generally the email ID with which user logged in to GIT. - **Token:** Personal access token. The personal access token requires the permissions within the following recommended scopes: Application also requires the following GitLab Enterprise credentials: - **GitEndPoint:** gitlab enterprise - **Host: **https\://gitlab.gravitant.net - **Name:** rajat - **User:** a\_user\@domain.com - **Token:** Personal access token. # Configuring for GitLab: Develop phase, recent customers :::hint{type="info"} Note: The procedures in this section are valid only for customers onboarded 6 June 2024 or after. Procedures for legacy customers are provided in the subsequent section *Configuring * &#xNAN;* for GitLab, legacy customers*. ::: Use the following procedure to configure the for Azure Pipelines: :::hint{type="info"} Note: Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure, you are choosing the application and DevOps phase to associate with GitLab as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure GitLab or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Develop row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the **Add Tool Configuration** form. 5. Select GitLab for **Tool Engine**. 6. Click **Submit**. # Onboarding GitLab: Develop phase After configuring GitLab, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Develop** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **GitLab** for **Tool Engine**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service displays the Repository Name field. 8. Select the appropriate repository. 9. Click **Onboard**. The service navigates to the Application Configuration page. 10. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that GitLab has been fully configured. # Deleting GitLab as a technical service The administrator may, at will, delete the GitLab technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Develop**. 4. Click **Delete Technical Service**. 5. Click GitLab for **Select Tools Configured**. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. 8. Click **Delete**. # Configuring for GitLab, legacy customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded before 6 June 2024. ::: If the user wants to track all the repository comprising this organization (Organization Level), then he would need to select orgs. And, if the user wants to track a particular repository (Repository Level), he would need to select repos. **Organization level tracking:** For this type of tracking, some selections have to be made in the system, as described in the following list: - **Account:** Refers to the account through which the tracking is to be done. - **Select Tracking Type:** Users must select **Organization** for Org level tracking. - **Search Organization:** By selecting here, a list of all organizations for the selected account but not tracked by Application. Select any organization you want to track and select **Configure**. **Repository level tracking:** For this type of tracking, some selections have to be made in the system, as described in the following list: - **Account:** Refers to the account through which the tracking is to be done. - **Select Tracking Type:** User must select **Repository** for Repo level tracking. - **Search Organization:** By selecting here, a list of all organizations for the selected account but not tracked by Application. Select any organization to be tracked and select**Configure**. Select any organization you want to track and select **Configure**. - **Search Repository:** By selecting here, a list will be displayed with all the repositories that are part of the selected organization but not tracked. Select any repository you want to track and select **Configure**. 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 mins: Refresh current data. - The account Delete Interval is set to 7 mins: All deleted accounts updated. - The history pulled Interval is set to 180 days: Data history. # Configuring GitLab To complete the integration of GitLab, you must complete a configuration process. Kyndryl supports two different configuration processes only one of which your organization has subscribed. If your organization was onboarded before 6 June, 2024, you are subject to the legacy process (legacy customers). If your organization was onboarded on 6 June 2024 or after, you are subject to the new process (recent customers). Refer to the appropriate document in the following list: - [Application configuration: legacy customers](docId\:M1Tce9Nzb0Dguu9W8zoGw) - [Creating an application](docId\:r_oXvj9o68Noa0fc6J5ks) :::hint{type="info"} 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 efficent 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. ::: [title] Mend.io configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ Mend.io specializes in Software Composition Analysis (SCA), Static Application Security Testing (SAST), and container security, helping developers to securely manage open-source risks, license compliance, and AI-generated code. supports Mend.io as an integral part of your security SDLC regimen. # Prerequisites The following items are prerequisite to Mend.io integration with : - Mend.io account - Access Policy as Platform Administrator role: Users must be assigned the Platform Administrator role to create and manage connections. - Administrator role: Users must be assigned the Administrator role to create and manage configurations. # Integration procedure The following procedure describes how to configure and integrate a supported tool with Developer Experience: 1. Create a UserKey. 2. Creat a Connection. 3. Tool Configuration – Secure Phase 4. Onboard the technical service Details are available in subsequent sections: # Create a UserKey Use the following procedure to create a UserKey: 1. Click on Manage & Administer → Connections Management. 2. Click **Tool Connections** from the left-side menu. You will be redirected to the **Tool Connections** page. 3. Click **Add Connection**. 4. Choose Connection type as **Mend.io**. 5. Name Local account name for reference. 6. Enter the Mend.io Host URL. Example: `https://test.mend.io` 7. Enter the created e-mail and Userkey. # Create a connection Use the following procedure to create a connection: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application and click on **Edit Tools Configuration**. You will be redirected to the **Add Tools** step. 3. Select Secure for **Phase**. 4. Click **Add Tool Configuration**. The service navigates to the **Edit Tool Configuration** step. 5. Select category as **License Scan**. Select Tool Engine as **Mend.io**. 6. Complete the configurations, categorized into two tabs (**Release** and **License status**). 7. Click **Add Configuration**. # Tool configuration Use the following procedure to add Mend.io to . 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application 3. Click on **Edit Tools Configuration**. The service navigates to the **Add Tools** step. 4. Select the phase as Secure. 5. Click on **Add Tool Configuration**. The service navigates to the **Edit Tool Configuration** step. 6. Select category as **License Scan**. 7. Select Tool engine as **Mend.io**. 8. Complete the form, categorized into two tabs (**Release** and **License status**). 9. Click **Add Configuration**. Release Identification takes the following format: - Prefix signifies the starting sequence of characters for releases, with the default value being empty. - Variable signifies the starting sequence of characters for releases, with the default value being empty. - The release format is applicable to identify the release names in issues and the release branches. :::hint{type="info"} The tool configuration inherits the release prefix and variable from the application. To override these values only for this configuration, click on the **Edit **button and make the necessary changes. Changing the values here will not impact the release prefix and variable set in the application. ::: # Example prefix and variable designators | **Prefix** | **Variable** | **Matched Example** | | --------------------------------------- | ----------------------------------------- | --------------------------------------------------------------------- | | release- | YYYY.MM.DD | release-2023.03.10,release-2023.04.12,release-2023.02.17 | | release- | \*\*\*\* .\*\*\* .\*\* | release-2023 .03 .10,release-2023 .04 .12,release-2023 .02 .17 | | rel- | \*\*\*\* | rel-2023,rel-2022 | | release- | \*\*\*\* .\*\*\* .\*\* | release-2023 .Mar .10,release-2023 .Apr .12,release-2023 .Feb .17 | | release- | \*\*\*\* .\*+ .\*\* | release-2023 .Mar .10,release-2023 .04 .12,release-2023 .February .17 | | release- | \*+ .\*+ .\*\* | release-23 .Mar .10,release-2023 .04 .12,release-2023 .February .17 | | release- | \*\*\*\* .\*\* .\*\* .\*\* | release-2023 .03 .10 .03,release-2023 .04 .12 .10 | | | \*\*\*\* | 2023,2022,2021 | | version | | version1,version2023,version2.3 | Supported License Status includes the following: - Allowed - Denied - Need Approval :::hint{type="info"} The Mend.io tool classifies license risks into Low, Medium, and High categories. These risk levels should be mapped to the Allowed, Need Approval and Denied in DI. ::: # Onboard the Technical Service Use the following procedure to onboard the technical service: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application 3. Select **Onboard Technical Service**. 4. Select the phase as **Secure**. 5. Select the category as **License Scan**. 6. Select the tool engine as **Mend.io**. 7. For **Connection**, select connection name from the drop down. 8. For **Repository**, select repository name from the drop down. 9. Click **Onboard** to onboard the technical service. # Delete the Technical Service You have the option of deleting the technical service at any time. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Expand the application to see all the associated phases. 3. Click the overflow menu for the phase (**Secure**). 4. Click **Delete Technical Service**. 5. Select the category as **License Scan**. 6. Select tool engine as** Mend.io.** 7. Select the **Organization** and **Repository.** 8. Click **Delete**. [title] Google Cloud Platform integration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ Google Cloud Platform is a suite of public cloud computing services offered by Google. The platform includes various hosted services for computing, storage, and application development that run on Google hardware. Software developers, administrators, and other enterprise IT professionals can access Google Cloud Platform services over the public internet or through a dedicated network connection. Configure a Google Cloud account or project for to pull data from Google Cloud. #  Google Cloud Platform The Application requires the following steps to configure Google Cloud Platform project to pull data from the respective project: - **Name:** Local account name. It could be any string and is used only for reference. - **Choose and Upload:** The JSON file was downloaded from Google Cloud Platform. The following example image shows where in the Application you must click to accomplish the previous task: :::hint{type="info"} Using the given credential, Kyndryl Discovery pulls (Sync) **Deployments and Virtual Machines** on behalf of . ::: 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 mins: Refresh current data. - The account Delete Interval is set to 7 mins: All deleted accounts are updated. - The history pulled Interval is set to 180 days: Data history. For more details, see your Delivery representative. [title] Multiphase onboarding for technical services [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Technical services configuration page/ Onboarding technical services in DevOps Intelligence (DI) typically requires separate configuration for each phase: Develop, Build, Secure and Scan. This process can increase administrative effort, extend onboarding times, and introduce inconsistencies across phases. To address these challenges, we propose a unified onboarding experience. This approach offers several advantages, including: - Select multiple phases during the initial setup. - Track which phases have been onboarded. - View available phases for future onboarding. - Add phases later without reentering service details. By adopting this streamlined approach, organizations can significantly reduce administrative tasks, minimize configuration issues and accelerate the overall onboarding process. The goal is to configure once, select multiple phases from the start and easily extend capabilities later. # Multiphase onboarding for a technical service The following steps guide you through onboarding a technical service using the multiphase onboarding: 1. Go to the **Kyndryl Bridge DevOps Console** page. 2. From the left navigation, select **Kyndryl Services.** 3. Locate **Tool Chain & Pipeline Observability** and navigate to DevOps Intelligence 4. Scroll through the available sections and locate **Settings & Utilities**. 5. Select **Application Configuration **and go to the **Multiphase Onboarding** tab 6. Click the** + Create multiphase onboarding **button 7. Complete the following steps: :::::WorkflowBlock :::WorkflowBlockItem Step 1: Connection 1. Select your **connection type** from the dropdown list 2. Select your **connection** from the dropdown list 3. Click **Validate connection** 4. Click **Next** ::: :::WorkflowBlockItem Step 2: Tools 1. Select the tools to onboard and the available phases to include for each tool 2. Click **Next** ::: ::::WorkflowBlockItem Step 3: Repositories 1. Select up to 100 repositories to onboard 2. Assign application bindings using the application column for each repository, or use the dropdown menu at the top to apply a binding to all selected repositories 3. Click **Next** :::hint{type="info"} You can navigate between pages without loosing your previous selections. ::: :::: :::WorkflowBlockItem Step 4: Review 1. Review all repositories and verify the information is correct or already onboarded 2. Click **Submit** ::: :::WorkflowBlockItem Step 5: Processing Monitor the onboarding progress for each tool ::: :::WorkflowBlockItem Step 6: Results Review the results report to identify successfully processed repositories, failed repositories and repositories missing a tool ::: ::::: [title] Mapping technical services [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Technical services configuration page/ Technical services are auto-discovered for a few endpoints but mapping your technical services is always a good idea, for example, if you see multiple entries for a single service for the different endpoints in the configure technical services table, you can map them together to a single service as your pipeline. As an example, keep in mind that if a repo in git is named demo121 and in Travis (build) it is demo121, but in SonarQube (test) the name of the project linked to the build tool is releasedemo, the releasedemo of SonarQube (test) can be mapped/ linked to the above technical service (demo121) resulting in creating a single service for your pipeline. :::hint{type="info"} Note: This stage is important as it has a direct impact on metering. ::: The following is an example list of the different technical services identified by after configuring tools & credentials. Also, this table shows all the technical services identified by by default. And in this example, the **Git**, **Test** and **Build** tools were configured earlier so respective technical services are mentioned later. # Technical services - TestProject (Test) - backend (Test) - MCMP-Java-Pipeline (Test) - demo\_for\_aparna (Test) - MCMP-Java-Pipeline (Team MCMP-Java), (Develop-Git) - MCMP-DevOps Project (Build) - MCMP-TestGoProject (Build) - MCMP-Task-Gophercise (Develop-Git), (Build), (Test), (application-Project!) - recover (Team-mgmtuser), (Develop-Git), (Build), (Test) - MCMP-SimpleMavenProject (Build) - MCMP-TestMavenProject (Build) In order to link technical services, you must complete the following steps: 1. Go to **Settings & Utilities** and then click on **Configure Technical services**. 2. In the **Associate technical service** tab, click on the Overflow menu, and choose** Link Technical services** tile in the technical services table. 3. Select any service that has to be mapped across the pipeline. 4. **MCMP-Java-Pipeline** is a service identified by **Git** and **Test** we can map them together and make it a single service as our pipeline. 5. Then, click on the Git **MCMP-Java-Pipeline** as we want to link our test service to our git service. 6. Select the test service and click **Update Technical service**. 7. Now, if we search for MCMP-Java-Pipeline we see that both test and git service have been linked together as per the pipeline requirements. :::hint{type="info"} Linking technical services of the same type is not possible, for example, a service registered by Sonargube and BYOT is not possible as both have the same service type. If a service is registered by Jira and Git are linked, two separate rows will be shown in the Develop dashboard Technical services view, with the same name but will show individual tools data. ::: [title] Metering technical services [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Technical services configuration page/ Metering technical services is a tool that displays a comprehensive list of services for which a customer is charged. The information provided is updated on a monthly basis and covers a period of approximately six months. The display includes details such as the name of the technical service, the tool utilized, the type of service and the date of discovery. A customer's charge for a particular service will be reflected in the metering table. The data is displayed by default in a table containing six tabs for the last six months. The table has a **Date Range**: filter feature that allows the timeframe selection for six months from today's date. Next to the filter icon, you will find a search box that allows searching for technical services by name and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. To download a report on metering services, select the month for the report you would like to receive, then select the **Download** button next to the filter. A .csv file will be downloaded automatically.  The metering service table displays data in a tabular form and provides information on each technical service charged. Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical Service:** the name of the micro technical service within the larger application; this column can be sorted. - **Tool:** the name of the tool where the technical service is linked. - **Type:** the type of the technical service. - **Discovered at:** the time when the technical service was discovered at; this column can be sorted. When the desired custom date range and organization(s) are selected, the information will be displayed in the form of a new tab, which will have the name of the custom date range you have selected. [title] Pre-migration [path] Services/Platform Services/Bridge Automation/Bridge Automation Service/Automation Service to Bridge Automation Service migration guide/ Before migrating to Service (BAS), complete the required setup and access configuration tasks described in this section. ## Prerequisites Before using BAS, ensure that: - The account is onboarded to the appropriate , and BAS is enabled. For more information, go to [Onboarding and enabling Bridge Automation](docId:1ipTNb5rxza-2rCOlW-U5). - A user with the **Bridge Platform Administrator** role completes the prerequisite configuration tasks. - Verify that the required automation access groups are available in Bridge IAM. The access groups typically begin with **automation**. Common access groups include: - **automation\_admin** or **automation\_administrator** - **automation\_editor** - **automation\_operator** - **automation\_viewer** ## Create dedicated CACF credentials To allow BAS to access the CACF, create dedicated credentials for each organization or account. 1. Follow the IAM process to obtain a Functional ID for BAS access to CACF. This task is typically performed by the Delivery Program Executive (DPE). For more information, go to [Identity Management at Kyndryl](https://kyndryl.sharepoint.com/sites/IdentityandAccessManagement/SitePages/Identity%20Management.aspx#how-to-create-a-functional-or-application-id-1). 2. Sign in to Ansible Automation Platform (AAP) using the Functional ID. This step creates the AAP user profile associated with this ID. 3. The Tower Account/Organization Administrator grants the required permissions to the AAP user profile. 4. A Tenant Automation Administrator (TAA) can generate a token in AAP. BAS uses this token as the FID token to connect to AAP for a specific organization. :::hint{type="info"} For assistance with creating a Functional ID or completing CACF-related tasks, contact the CACF team. For more information, go to, [Automation Services Onboarding and Enablement](https://kyndryl.sharepoint.com/sites/CTO-Automation/SitePages/Automation-Services-Enablement.aspx?TeamsCID=745d84aa-a321-42a6-8d5d-9ee941928136#aap-communication-with-aiops-automation-services). ::: ## Onboard a dedicated CACF connection as a Bridge credential :::hint{type="info"} A user must have the **Bridge Platform Administrator** role to create connections in Bridge. ::: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Connections Management.** 2. Select **Tool Connections**, and then select **Add Connection**. 3. Configure the connection: 1. Set Connection type to CACF. 2. Under Supported apps, select Provisioning Orchestration and Automation. 3. Enter a connection name using the following format: :::Paragraph{indent="3"} \@CACF\_INSTANCE ::: :::Paragraph{indent="3"} **Example:** ace\@devtest4 ::: 4. Enter a description to identify the target environment (Optional). 5. Click **Next**. 6. Enter the endpoint URL and GSMA organization information. :::hint{type="info" indent="1"} Enter the endpoint URL and GSMA organization information. ::: 7. Click **Next**. 8. Enter the authorization token. For more information, go to **Create dedicated credentials for CACF**. 9. Click **Next**. 10. Review the configuration details and click **Submit**. ## Enable automation admin access group with admin role 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Access Management** → **Access Groups.** 2. Login as a user with the **Bridge Platform Administrator** role. 3. Edit the **automation\_admin** or **automation\_administrator** access group. 4. Assign the **Orchestration Administrator** role. 5. Save the changes. [title] JFrog configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure/ JFrog configuration enables integration with the JFrog platform to collect artifact andvulnerability data from supported repositories. A connection to the JFrog portal is requiredbefore configuring the integration. To pull data from any JFrog tool, , a connection to the JFrog portal is necessary. # Pre-requisites requires the following information: :::Paragraph{listStyleType="disc" indent="2"} **Connection Name:** Local connection name. It could be any string and is used only for reference. ::: :::Paragraph{listStyleType="disc" indent="2"} **HostURL:** JFrog Artifactory Host URL. For example: `https://testKyndryl.jfrog.io` ::: :::Paragraph{listStyleType="disc" indent="2"} **Token:** Token ID can be produced via the JFrog portal by following these steps: Select the user's **Email ID**, select **Edit Profile** and then choose **Generate an Identity Token**. ::: :::hint{type="info"} The identity token requires **read access **in JFrog. ::: To set up a new connection, go to **Admin**, followed by , and then choose **Connections**. Select the ' button and select the **Add Connection** option. # Configuration As a user, you will need to select the **Connection**, **Repository**, and **Release format** (for example: release-YYYY.MM.DD) that you want to track through . :::hint{type="info"} Vulnerabilities & Artifacts data will not be pulled for Repositories that have not been configured for X-Ray scan at the JFrog server. ::: After successfully configuring, you can view your settings in the table on the configuration page. # Sync details Understanding the dynamics of data pulling, how X-Ray Scan Repositories work, identifying ReleaseName, and the method of Technical Service Identification are crucial to make your system perform seamlessly. Here, you'll find the explanation divided into four sections, each outlining a different aspect: - **JFrog Artifactory**: Only pulls **Docker** type data. This information can be viewed on both the **Secure** dashboard → **Container Vulnerability Scan** and **Build** dashboard → **Image Manager**. - **X-Ray Scan Repositories**: Repositories enabled for X-Ray scanning will synchronize. If a service config is created for Repo1, but Repo1 is not set up for X-Ray Scan, then the entity data for that repo would not sync. This missing data would not appear on the Image Manager & Container Vulnerability Scan page. - **ReleaseName Identification**: This is determined by the format chosen on the service config page. If the format does not correspond to the release name, an *unknown* release name will be labeled. Artifacts with the "latest" version will be tagged as the *main* release. Artifacts with "latest-" & "master-" versions will be tagged as the latest release. - **Technical Service Identification**: This is determined using the repo sub-path. For instance, for the repo name 'ibmcb-docker-local,' the technical service would be 'ibmcb-docker-local/dash/bitbucket.' Please refer to the image below for better understanding. During the Sync process, the tool performs several tasks related to JFrog reports. Notably, the tool creates reports on the JFrog side and, after processing, deletes them. As a user, you must know not to delete these reports from the endpoint. When integrating JFrog data with , utilizing it on a single tenant is recommended. This approach arises from JFrog's limitations on the number of report generation requests. Sync may sometimes fail due to these restrictions at the JFrog endpoint, especially if the number of report generation requests exceeds the limit. If you encounter a sync failure caused by report limitation errors, the suggested resolution is to delete Old/User-created reports. Remember these tips to ensure seamless and effective use of the tool. [title] GoCD configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ GoCD is an open-source continuous delivery server created by ThoughtWorks. GoCD offers businesses a first-class build and deployment engine for complete control and visibility. It was designed for continuous delivery and the concepts essential to this practice are built at the core. Enterprise add-ons and professional support are available from ThoughtWorks. For  to pull data from GoCD, you must configure a GoCD account. **Access rights:** The account should have at least read rights on the pipelines we intend to sync. [title] Azure Pipeline Deploy configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy/ Establishing this connection enables to leverage Azure Pipeline's robust capabilities, enhancing its monitoring and reporting features. This configuration enhances the accuracy and efficiency of data handling and amplifies the overall functionality of the tool. **Azure Pipeline Deploy** is an Azure DevOps service that automates application deployment workflows across development, testing and production environments. It helps teams deliver software reliably by orchestrating deployment processes, tracking releases and enforcing deployment controls. To enable effective data synchronization from Azure Pipeline Deploy into , it's crucial to establish a properly configured Azure DevOps connection. This connection acts as a secure bridge between the two platforms, enabling seamless data transfer and management. By establishing this connection, can leverage Azure Pipeline Deploy data to enhance monitoring, reporting, and deployment visibility. This integration improves the accuracy and efficiency of data handling while providing deeper insights into software delivery performance and overall operational health. # Access rights The connection must have the following access right: - **Pipeline Resources**: Use access right. - **Build**: Read access right. - **User profile**: Read access right. # Roles required As a user, your permissions determine the actions you can perform on the bring-your-own (BYO) template data. You must view, create, update, and delete roles to perform the respective actions. By default, these permissions are granted to the **Editor**. The **Viewer**, on the other hand, is only endowed with the view role. # Configuration You must choose the Project and Organization, Pipeline name, and add a Technical Service and additional configurations for customizations to establish the configuration. Extra settings are available to handle the states of **Passed**, **Failed** and **In Progress**, which are terms employed in the dashboards. You have the flexibility to introduce custom terms for these states. For instance, any value input under the **Passed** category will be interpreted as passed when displayed on the dashboard. Once you have made these selections complete the following steps to configure AWS CodePipeline: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → → **Settings & Utilities **→ **Tools Configuration**. 2. Select **Add configuration +** and a **Add tool configuration** form will be displayed; here, you will select: - **Azure Pipeline - Deploy** from the **Tool Engine** dropdown menu. - Select the** Connection** and **Provider** from the dropdown menu. - Enter the **Release name**, **Environment** and **Incident host URL.** 3. Select Yes or No on each following field if the configuration is for a production environment. 4. From each dropdown menu, select the **Technical Service,** **Organization**, **Project** and **Pipeline name.** 5. And you can fill in the** Additional configuration for customization** section at the bottom of the form if you would like to personalize it with custom terms for **Passed**, **Failed** or **In progress** statuses. 6. Select the **Add configuration** button at the bottom of the form. After completing the configuration, you can view the configuration details in the table on the configuration page. A sample image showcasing this is provided below for your reference. [title] GitHub Webhook configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/GitHub and GitHub Enterprise configuration/ A GitHub Webhook enables to receive notifications dynamically (as relevant events occur). When specified events occur, GitHub sends an HTTP POST payload to the webhook's configured URL. supports this capability as a necessary complement to GitHub. Use the procedures in the following sections to create the GitHub Webhook necessary to receive these notifications. # Setup instructions for your organization/repository ## Prerequisite requirements - Administrator access to the GitHub repository. - A server or service endpoint that can receive webhook payloads. - HTTPS endpoint for secure webhook delivery. - You must create a secret token. Use the following procedure to create a secret token: 1. Navigate to **Tools Configuration.** 2. Switch to **Bring your own tools.** 3. In the **Create New Token** tab, select token type as **Webhooks.** 4. Press the **Create** button to generate the token. After confirming the prerequiste requirements, decide whether you want to set up events for all repositories in your organization or choose individual repositories. Create a webhook at the organization level to cover all repositories, or at the repository level for specific repos. ## Organization Level setup Use the following procedure to set up a GitHub Webhook for your organization (compare at **Repository Level** setup immediately following this procedure): 1. Navigate to your repository on GitHub (or organization in the event you prefer to set up an Organization level hook). 2. Click on **Settings** --> **Webhooks** 3. Click **Add webhook** 4. Configure the following settings: - **Payload URL**: The URL of your endpoint (must be HTTPS for production). The Url would the tenant host along with ***"/dash/api/broker/v1/webhook/collector"*** - **Content type**: `application/json` - **Secret**: Set a secure secret to validate webhook payloads - **Events**: Choose which events should trigger the webhook. Choose from the following: - Code scanning alerts - Dependabot alerts - Deployment statuses - Issue comments - Issues - Meta - Member - Organizations (only for Org hooks) - Pull request review comments - Pull request reviews - Pull requests - Pushes - Workflow jobs - Workflow runs - **Active**: Check this box to enable the webhook. 5. Click **Add webhook** to save. ## Repository Level setup A repository level Webhook is required whether you have an organizational level Webhook. If you have set up an organization Webhook, you must still perform the setup procedure for specific repositories that will be in use. The procedure is the same for organization level setup with two exceptions in the **Events** options: - There is no Organization option. - Repository setup contains an additional option, **Collaborator add remove changed**. To begin repository level setup navigate to the repository for which you set a Webhook, and follow the procedure described for organizational setup. ## Setup Github workflow for retrying failed events All events processed by your endpoint are displayed on the GitHub webhook page. If your tenant is temporarily unavailable, those events will not be processed. GitHub tracks each event and its status. GitHub integration includes support for retrying failed events. You can implement this feature at the organizational level or the repository level. Implementing it at the organizational level enables retries at the repository level for repositories associated with that organization. To implement event retrying at the organizational level, create a workflow file using the latest workflow repository file as a guide. The workflow file path takes the following form: https\://github.kyndryl.net/MCMP-DevOps-Intelligence/devops-reusable-workflow The following variables are necessary: - **ORGANIZATION\_NAME**: The name of your GitHub organization. - **REPO\_NAME**: The name of your GitHub Repository (If you are creating workflow for any repository) - **HOOK\_ID**: The unique identifier for the webhook you want to retry. You would get this ID in the url when you edit the created hook. - **HOSTNAME**: The base URL for your GitHub Enterprise or API endpoint. - **WEBHOOK\_TOKEN**: A secret token stored in your repository or organization secrets, used for authentication. :::hint{type="info"} Token of type ***Webhooks*** can be used only once in a tenant. If you have already generated use the existing token. ::: ## Troubleshooting If you encounter data synchronizing problems, use the following checklist to troubleshoot the fail point: - Check webhook delivery logs in GitHub - Ensure your endpoint is accessible from the internet - Check your server logs for errors processing the payload - Do not disable or skip any of the required events in the GitHub webhook configuration. Disabling any required events can lead to data mismatch. If a mismatch occurs due to incomplete events, the entire technical service must be deleted and re-onboarded. [title] Configuring DevOps Intelligence for GitHub, recent users [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/GitHub and GitHub Enterprise configuration/Configure DevOps Intelligence for GitHub, legacy users/ This procedure is valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent section Configure for GitHub, legacy customers. You must then onboard the technical service. Use the following procedures. # Plan 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Select an existing application or create a new application. 3. Then **Add New Tools**→ **Plan** → **Add Tool Configuration**→ For tool engine select **GitHub** 4. Complete the configurations, categorized in the four tabs: **Release**, **Work Item Format**, **Bug Formats**, **Bug Severity**. 5. Click **Add Configuration**. # Develop 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Select an existing application or create a new application. 3. Then **Add New Tools**→ **Plan** → **Add Tool Configuration**→ For tool engine select **GitHub** 4. Select the pull request states. 5. Click **Add Configuration**. # Secure 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Select an existing application or create a new application. 3. Then **Add Tools **→ **Secure** → **Add Tool Configuration**→ For secure categories select **Secure Alerts **→ for tool engine select **GitHub.** 4. Fill the configurations, categorized into two tabs (**Severity** and **State**). 5. Click **Add Configuration**. :::hint{type="info"} GitHub's Dependabot alert is used in the Secure phase, Secure Alerts category. ::: # Onboard the technical service You must now onboard the technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application and click the **Onboard Technical Service** option. 3. Select the phase for which you want to configure GitHub. The page displays only the phases for which this tool has been configured for the application. 4. Select the tool engine as GitHub. 5. For **Connection**: Select the appropriate connection name from the drop down. supports the following types of GitHub tracking: - Organization - Repository - Non-Organization(Independent) Repositories Use the following procedures: # Organization Tracking To track Organizational data, use the following procedure: 1. Select Tracking Type **Organization**. 2. Select the appropriate organization. 3. Click **Onboard** to onboard the technical service. # Repository Tracking To track repository level data, use the following procedure: 1. Select Tracking Type: **Repository**. 2. Select the appropriate organization for the repository. The organization accounts will be listed. 3. Select the appropriate repository. A search box allows filtering repositories by name. The selection of repos persists when the user navigates to the next page in the table. 4. Click **Onboard** to onboard the technical service. :::hint{type="info"} In case of GitHub Enterprise accounts, if the administrator has set a limit on API calls, will optimize its data fetching process and will execute approximately 1000 calls each hour. This is to make sure no other task using the credentials is hampered. Once the limit is exceeded, displays a message on GitHub`sync` page. ::: # Non-Organization (Independent) Repositories To track non-organization repositories, use the following procedure: 1. Select Tracking Type - **Repository**. (Optional) 2. Select the appropriate repository. 3. Click **Onboard** to onboard the technical service. # Deleting the Technical Service Use the following procedure to delete the technical service: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Expand the application to see all the associated phases. 3. Click on Overflow menu against the phase and click on **Delete Technical Service**. ## [title] Bridge Notification Service [path] Administration/ Bridge offers numerous benefits that enhance user experience, improve communication and boost overall productivity by helping users stay informed about important events. enables platform services to send unified notifications to end users. enhances communication and overall platform usability by providing the following benefits: - Enhanced user engagement - Real-time communication - Improved user experience - Increased productivity - Reduced email overload - Cost-effective communication # Notification roles and permissions The following are the roles and permissions for accessing and managing notifications, including the ability to view, create, edit, enable or disable notifications: - **Platform Admin, Platform Operator and Platform Editor:** Have full access to notification capabilities. Can create, edit, delete, enable, disable and manage notifications, configure recipients and control notification settings across the platform. - **Platform Viewer:** Has view-only access (end-user experience). Can access and read relevant notifications, including acknowledging Priority notifications and view both notification settings and actual notifications, but cannot make any changes. # Notification types Notifications are intended for all users within an account and are typically used to communicate important updates, such as scheduled maintenance or planned downtime. They require users to acknowledge receipts, ensuring visibility and awareness of critical information. The following notification types are supported: - **Priority notifications:** Priority Notifications: notifications are must-read messages that require users to acknowledge them. - **Service-based notifications: **Service-based notifications are automatically generated notifications triggered by system events within Bridge services, providing real-time updates on workflows, operations and system activities. These notifications can be viewed through the notification bell icon or the notification details page, where users can access the full list of notifications. # Supported notification channels Service notifications are delivered through the following supported channels, allowing users to stay informed based on their preferences and context: - **In-app notifications**: In-app notifications are displayed directly within the platform to ensure timely visibility. Users can access them through the notification bell icon or from the notification’s details page. - **Email**: Provide an alternative channel for receiving updates outside of the platform. These notifications ensure that users are informed even when they are not actively using the applications. Email notifications are delivered in outlook with configurable headers, content and recipient lists. - **Both in-app and email notifications (default selection)**: Enables both in-app and email notifications, allowing users to receive updates directly within the platform as well as via email. This option is selected by default to ensure users stay informed in real time, regardless of where they are. # Notification recipients Notifications can be targeted at different audiences depending on the intended scope and purpose, typically falling into the following categories: - **User notifications: **User notifications are sent to specific individuals or Access Groups within an account. Administrators can assign recipients directly, ensuring that only the intended users receive the notification. When created, user-level notifications remain in Draft status until individual users or Access Groups are added through the UI. - **Account-level notifications:** Account-level notifications are broadcast to all users within a selected account. When configured, no individual user selection is required, as notifications are automatically delivered to all users within the defined scope. The account name is applied based on the selected context. Once created and saved, account-level notifications are active by default. [title] Develop dashboard table view [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ A new dialog appears when you click on a technical service View details from the table view. The technical service details view has tabs for Overview, Issue, Defects and Summary of Issues and Defects. The following elements are displayed in this dialog: - At the top, the **Development Activity** is the name of the technical service in question. - Below is the tool engine that displays the current engine tool. - The next item in the technical service details view is a time frame with the following selections: - **1D**: 1 Day, last 24 hours - **7D**: Last 7 Days - **14D**: Last 14 Days - **2M**: Last 2 Months - **3M**: Last 3 Months - **6M**: Last 6 Months - **Custom duration**: A custom date range within 6 months - Two boxes containing the summary of the aggregate of **Defects** (new, updated, closed) and **Issues** (new, updated, closed). - Five tabs, which allow you to navigate further to ascertain a deeper level of detail for each of the following activity arenas: - **Overview (default):** Provides Summary Graphs listed in a subsequent bullet. - **Defects:** Presents Updated Defect Details table. - **Issues:** Presents Updated Details table - **Pull Requests:** Presents Pull Request Details table - **Contributors:** Presents Contributors Details table - **Summary graphs** This section contains four graphs: - **Defects** - **Issues** - **Pull Requests** - **Commits** :::hint{type="info"} The pull requests and commits graphs are not presented for JIRA technical services. ::: As mentioned in the content list, you can navigate to pages that provide further details in activities in each of the supported arenas. The following list describes these details: - **Defects tab:** This table references the source engine for all Updated faults for that technical service. When you expand each row (if the problem includes tags), a chevron symbol appears next, indicating the tags applied to that fault. The Defects dialog presents a table with the following elements: - **Contributor's ID or Contributor Name:** The name or ID of the contributor depending on the tool you are using. - **Defect no:** The number of the Defects linked to the Defect in Jira. - **Summary:** A brief description of the Defect. - **State:** Current defect state: open or close. - **Created date:** The date the Defect was created. - **Updated date:** The date the Defect was updated. - **Assignee:** The user the Defect was assigned to. - **Created by:** The user that created the request. :::hint{type="info" indent="2"} Only the **Defect no** and **Summary** columns can be sorted, and above this table, you will find a search box that allows searching by **Defect no** and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: - **Issues tab**:  This tab offers a table concerning the source engine that displays all the Updated problems for that technical service. When you expand the Issue, you'll see a chevron icon next to each row (if the Issue includes tags), revealing the tags applied to it. The Issues dialog presents a table with the following elements: - **Contributor's ID or Contributor Name:** The name or ID of the contributor depending on the tool you are using. - **Issue no:** The number of the Issue with a link to the source issue. - **Summary:** A brief description of the Issue. - **State:** Current issue state: open or close. - **Created date:** The date the Issue was created. - **Updated date:** The date the Issue was updated. - **Assignee:** The user the Issue was assigned to. - **Created by:** The user that created the Issue. :::hint{type="info" indent="2"} Only the **Issue no** and **Summary** columns can be sorted, and above this table, you will find a search box that allows searching by **Issue no** and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: - **Pull request table** This table only applies to Git, Bitbucket, and Azure DevOps and does not include Jira. This table displays all open pull requests for that technical service, with the PR number as a link to the source engine. The Pull request tab presents a table with the following elements: - **PR number:** The number of the Defects linked to the Defect in JIRA. - **PR Summary:** A brief description of the Defect. - **Created date:** The date the Defect was created. - **Updated date:** The date the Defect was updated. - **Created by:** The user that created the request. :::hint{type="info" indent="2"} All columns can be sorted, and above this table, you will find a search box that allows searching and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: - **Contributor tab** This table applies only to Git and Bitbucket. The Defects dialog presents a table with the following elements. This table contains the names of Contributors during the time period chosen, including the following: - **Contributor's ID or Contributor Name:** The name or ID of the contributor depending on the tool you are using. - **Commits: **The total number of commits per contributor. - **Line of Code Added:** The line number of the code that was added. - **Line of Code Deleted:** The line number of the code that was deleted. - This table contains the names of Contributors during the time period chosen, including the following: :::hint{type="info"} Some tools do not provide statistical support for lines added and deleted. In such cases, the table displays the number of files modified. ::: - This table contains the names of Contributors during the time period chosen, including the following: - 7/14/30 days - 3/6 months - Any custom timeframe not exceeding 180 days. All columns can be sorted. A search icon (magnifying glass) and a settings icon (gear) are located above the table on the right. The settings icon enables displaying and hiding selected columns. [title] Tool connections [path] Administration/Connections Management/ # Adding a tool connection 1. From the side panel menu, select the **Tool Connections** option. 2. Select **Add Tool Connection**. The **Add Connection** page opens. 3. Fill in the required fields: - Connection name - Supported apps - Connection type - Access Tags 4. Click the **Create tag** button and fill in data. 5. Click the **Create button** and verify that the created tag is displayed in the **Access Tag** dropdown. 6. Click **Next** 7. In the **Connection configuration** section, provide all the necessary inputs, and click **Next**. 8. Add details in the **credential** section and click the **Next** button. 9. Verify that all the entered data is displayed in the respective fields of the **Review** page, and click **Submit**. A message "connection added successfully" displays. Verify that the created connection is displayed in the table. # Manage a tool connection - **View:** To verify that all the filled-in details are displayed in the view details page, click the connection row action item and select **View details** - **Edit: **From the **Action** menu in the table, click the **Edit action** option. An **Edit **screen displays. Verify that the updated data is reflected as expected in the respective connection. - **Delete: **To successfully delete the selected connection, click the **Delete Action** menu item and confirm your action. [title] Bridge Access Management [path] Administration/ [title] Roles [path] Administration/Bridge Access Management/ A role is a collection of permissions used as a building block for access policies. Administrators can create custom roles; Bridge platform roles are system-managed. # Accessing the roles page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="28" height="28"}, go to **Administration** → → **Roles** - Total roles, Bridge roles (Platform), Custom roles and planned Service roles. - Custom roles list at the top; Platform roles at the bottom. - Select the permissions count to view or search a role’s permissions. # Viewing a list of roles By accessing the **Roles** page, you are presented with four different cards providing relevant information for the Account Administrator: - The **Total Roles** card displays the total number of roles in your account. - The **Bridge Roles** card displays the total number of Platform roles in your account. - The **Service Roles **card displays the total number of service roles in your account. - The **Custom Roles **card displays the total number of custom roles created by the administrator. # Creating a custom role To create a custom role, complete the following steps: 1. From the **Roles** page, select **Add role.** 2. Enter role name and custom ID (both mandatory). 3. Enter an optional description. 4. Select a **Service** (non-editable after save). - Whenever a service is registered to Kyndryl Platform Central, it appears in this drop-down. 5. **Select a Role** for the chosen service. Platform roles are listed first, then custom roles. - This selection populates the permissions list for that service and role combination. 6. Review the populated permissions and **select the specific permissions** to include for this custom role. 7. Click **Save**. # Editing a role :::hint{type="info"} You can edit only the custom roles that you have created. If the role name is not clickable, you might not have the required permissions to edit that role. ::: To edit a custom role, follow these steps: 1. From the **Roles** page, locate the role that you want to edit. 2. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/JndGM9EedPv0uB0o6JMpp-20260601-221027.svg" alt caption width="28" height="28"}and select **View Details**. 3. Click **Edit** at the bottom of the page. 4. On the **Edit Role** page, you can modify the following details: - **Role Name**: Enter a unique name to identify the custom role. - **Description: **Provide a brief description of the role and its intended purpose. - **Permissions:** Select the permissions that determine the actions users assigned to this role can perform. To modify role permissions,** select **or **clear** **the checkbox **next to the appropriate permission. 5. Select **Update **and confirm the changes. # Deleting a role To delete a custom role, follow these steps: 1. Click the overflow menu next to the role of your choice and select **Delete**. 2. Confirm the deletion by typing the name of the role in the search field. ## Prerequisites for editing roles To modify or remove roles, be aware of the following requirements: - Editing preserves existing permissions. Custom ID and Service fields are not editable. - Bridge Platform roles cannot be modified. - Only custom roles can be deleted. The authorized roles to perform these changes are: - **Administrator**: Create, edit, delete custom roles. - **Operator, contributor, viewer:** View roles. # Learn more [Roles and permissions](docId\:ICs69b2oEsEwnrtSMBI3W) [title] Users [path] Administration/Bridge Access Management/ The **Users** page provides a centralized view of all users in your Kyndryl Bridge account. From this page, administrators can monitor user activity, manage user access, and review the access groups assigned to individual users. Summary cards provide a quick overview of the user population and invitation status, helping administrators track account adoption and user lifecycle management. The **Users** page includes the following summary cards: - **Total Users:** Displays the total number of users in the account. - **Active Users:** Displays the number of users with active account access. - **Pending Invites:** Displays the number of users who have been invited but have not yet completed the onboarding process. - **Invite Users:** Opens the invitation workflow to add new users to the account. The Users page provides a table that display information about each user, including: - **Name:** Displays the user's name. - **Access Group**: Displays the name of the access group assigned to the user. - **Email:** Displays the user's email address. - **Status:** Indicates the user's current status, such as **Active** or **Pending**. - **Actions:** Click the **ellipsis menu (⋮) **to view the actions available for the selected user. Each user can be expanded to display the access groups assigned to that user. The expanded section includes the following information: - **Access Group:** The name of the access group assigned to the user. - **Service: **The service associated with the access group. - **Description:** A brief description of the access group. - **Members Count:** The total number of members assigned to the access group. Administrators can use the **Search** field and **Filter** option to quickly locate specific users and refine the displayed results. # Prerequisites to invite users To invite users in :  - You must have the **Administrator** role in the account.  - Valid email addresses (up to 10) must be available for each user.  - Access groups and any required roles should be predefined.  - Ensure understanding of which access groups apply to Kyndryl vs. Non-Kyndryl users.  # Accessing the Users page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **** → **Users**. # Viewing a list of users By accessing the **Users** page, you are presented with three different cards providing relevant information for the Account Administrator: - The **Total Users** card displays the total number of users in your account. - The **Active Users** card displays the total number of active users in your account. Users who have not activated their account yet (Pending Status) are omitted from this total. - The **Pending Invites** card displays the total number of users who have not activated their accounts yet. # Inviting new users Administrators can invite both Kyndryl and non-Kyndryl users to a account, assign them to access groups, and optionally apply access policies during the invitation process. Up to 10 users can be invited at a time, with the appropriate roles and permissions assigned upon onboarding. This capability streamlines user onboarding, supports role-based access management and helps ensure secure access through user validation and policy controls. :::hint{type="info"} Access management only grants access to the Kyndryl Bridge account. If you need access to a specific service, follow the steps described in [Understanding Bridge Access Management](docId\:ZrxU_G76DRxWkHiBkquF-). ::: To invite new users to a account, click the **Invite Users** card and follow these steps: 1. **Add User: **Select the user type (Internal Kyndryl users or external Non-Kyndryl users). Enter the email address of the invitee(s) in the box. You can add up to 10 different email accounts and validate them by pressing the "Bar" key or "Enter" key on your keyboard. 2. Select **Next**. 3. **Assign to Bridge Access Group: **Select the access group(s) where the invitee needs to be associated by selecting the box next to the corresponding access group. To learn more, see [Access Groups](docId\:HZc4qy5Gh7gwkLHfYsAyC). :::Paragraph{indent="1"} In the **Assign to Service Access Group **section, review the **Service **column to identify the service associated with each Service Access Group. This information helps ensure that users are assigned to the correct access group and receive access only to the intended service and related resources. ::: Optionally, select **Assign to Service Access Groups** for specific tools or services.  - Example: CollabDrive\_Administrator, CollabDrive\_Viewer  - Kyndryl-specific access groups (e.g., Kyndryl Account Manager) are only available when inviting Kyndryl users. :::hint{type="info"} Access groups are created by default and cannot be customized. ::: 4. Use the following table as a reference when assigning Bridge access groups. | **User type** | **Who needs to** | **Select the Access Group(s)** | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | | &#xNAN;** Access Groups** | | | **Customer**
**Administrator** | - Can view, create and modify consultations - Can view, create, modify and delete quotations - Can convert quotations to subscriptions - Can view, create, modify and delete subscriptions - Can view notifications - Can invite users to account - Can invite users to the Customer Engament Hub - Can view, create and modify own support tickets - Can view support tickets created by all users within an account. - Can view, create, modify and delete API keys - Can view and create assessments | Administrator | | **Customer**
**Buyer** | * Can view, create and modify consultations * Can view, create, modify and delete quotations * Can convert quotations to subscriptions * Can view, create, modify and delete subscriptions * Can view notifications. * Can view, create and modify own support tickets * Can view, create, modify and delete API keys * Can view and create assessments | Contributor | | **Customer**
**Technical User** | - Can view, create and modify consultations - Can view quotations - Can view subscriptions - Can view notifications - Can view, create and modify own support tickets - Can view, create, modify and delete API keys | Operator | | **Basic**
**Customer**
**(minimum permissions)** | * Can view consultations * Can view quotations * Can view subscriptions * Can view assessments * Can view notifications * Can view, create and modify own support tickets | Viewer | | **Account Administrator** | - Can view, create and modify consultations - Can view, create and modify quotations - Can convert quotations to subscriptions - Can view, create, modify and delete subscriptions - Can approve subscriptions - Can view notifications - Can invite users to account - Can view, create and modify own support tickets - Can view, create, modify and delete API keys - Can view and create assessments | Kyndryl Account Manager \*\* | | **Delivery Partner** | * Can view consultations * Can view quotations * Can view and modify subscriptions * Can view notifications * Can invite users to account * Can view, create and modify own support tickets * Can view, create, modify and delete API keys | Kyndryl Delivery Team - DPE - CPE \*\* | | | **Kyndryl AIOps Access Groups** | | | **Kyndryl AIOps Administrator** | | AIOps\_Integrated\_Administrator | | **Kyndryl AIOps Technical User** | | AIOps\_Integrated\_Operator | | **Basic Kyndryl AIOps User (minimum permissions)** | | AIOps\_Integrated\_Viewer | | | **Service Access Groups** | | | **Document Administrator** | - Can view, download, upload, modify and delete documents | CollabDrive\_Administrator | | **Document Viewer** | * Can view and download documents | CollabDrive\_Viewer | | **Customer Partner and Consult Partner** | - Can view Go To Market Hub - Can create assessments based on the recommendations listed - Can update the status of the assessments - Can promote recommendations | GTM Experience Administrator \*\* | | **Go To Market Team (Delivery Partner, Enterprise Architect, Technology Advisor)** | * Can view Go To Market Hub | GTM Experience Viewer \*\* | 5. Select **Next.** 6. **Assign Access Policies (optional): **Select the scope of the service you want to assign to the invitee, including roles. To learn more, see [Access Policies](docId\:nb3bZm-bsA3w7AEFpbDzs). 7. Select **Next**. 8. **Review** the summary including:  - User email addresses  - User type (Kyndryl or Non-Kyndryl)  - Assigned access groups  - Assigned access policies (if applicable) 9. Click **Send Invite** to complete the onboarding process.  After sending an invitation, you can monitor the user's onboarding progress and invitation status from the Users page. The following outcomes may occur: - Invited Kyndryl users will appear in the **Users** list with Active status, if the user is already part of any other Bridge Account  - Invited Non-Kyndryl users will appear in the **Users** list with a **Pending** status.  - Once Non-Kyndryl users or a new Kyndryl user to accepts the invitation, their status will change to **Active**.  - If the invite fails, detailed error messages will help identify the issue.  ## User invitation e-mail An email invitation is automatically sent to the invited user with instructions to access the account and complete the onboarding process. Such user must select the `Activate  account` link in that email and should follow the [User onboarding](docId\:gYq4GiMMed2mQvaA3EFOv) process to become a new member in your account. :::hint{type="info"} - Only Kyndryl.com email IDs can be added to these access groups. Note that some services are only visible by those in the Kyndryl-named access groups because they are currently for internal use only. - Service-specific access groups, such as Kyndryl , become available after the service subscription is activated. Account administrators must assign both a Kyndryl Bridge platform access role (viewer at a minimum) and a service-specific access role. ::: The following message is sent to the user (Click **Next** and follow the on-screen prompts): *Welcome \[UserName],* * You’ve been invited to join \[AccountName] on Kyndryl Bridge. Use the procedure to sign in:* * Ensure your username is associated with Kyndryl ID before you proceed to the next step as it’s required to activate your account. Follow the instructions later in this email if you need to set up your Kyndryl ID* * Click the activation link below.* * Enter your username. Example: kbsvtadmin2\@kyndryl-modernops-kb-ist.awsapps.com* :::hint{type="info"} The activation link can be used only once and it expires in 30 days. ::: # Managing user invitations After users are added to a account, administrators can manage their account invitation lifecycle from the **Users **page. Available actions include resending or revoking invitations, viewing invitation details, updating user membership and access groups and removing users from the account as needed. ## Viewing invitation details The **Invite Details** shows invitation sent and expiration dates, status, and access groups assigned to that user. However, this option is only available to users with a pending invitation. Follow these steps to view the user invitation details: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="57" height="57"} next to the user that you want to learn more about. 2. Select **Invite Details**. ## Resending invitation You can resend an invitation to users who have not yet accepted their invitation or completed the onboarding process. Follow these steps to resend a user invitation: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="57" height="57"} next to the user that you want to resend the invitation to. 2. Select **Resend Invite **and confirm your action. ## Revoking invitation You can revoke a pending invitation to prevent a user from accessing or activating the account through the invitation link. Follow these steps to revoke a user invitation: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="57" height="57"} next to the user from whom you want to revoke the invitation. 2. Select **Revoke Invite **and confirm your action. ## Editing membership You can update a user's membership by modifying the access groups assigned to users with an **Active **status. Follow these steps to edit user membership: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="57" height="57"} next to the user that you want to edit. 2. Select **Edit Membership**. 3. Select or unselect the access groups that you want to assign or remove from the user. 4. Select **Assign**. As an administrator, when you access the details of your own user account, the **Details **page is displayed as **read-only**. No modifications to your own user permissions are allowed. ## Deleting user You can remove users from the account when they no longer require access. Follow these steps to delete a user: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="57" height="57"} next to the user that you want to delete. 2. Select **Delete User **and confirm your action. :::hint{type="info"} You can delete users in bulk from the **Users** tab. Simply check the box next to the users that you want to delete from this account and select **Delete**. ::: [title] Cloud connections [path] Administration/Connections Management/ **Cloud Connections** provides a centralized location for viewing and managing cloud provider connections within Connections Management. Administrators can monitor credential expiration dates and status, identify connections that require attention, review connection details and metadata and perform connection management tasks from a single interface. By providing visibility into credential health and lifecycle information, the page helps support proactive credential management, governance and the ongoing operation of cloud integrations. # Cloud Connections table - **Connection Type**: Displays the cloud provider associated with the connection. - **Name**: Displays the connection name. - **Access Tags**: Shows the tags assigned to the connection. - **Description**: Provides additional information about the connection. - **Expiry Status**: Indicates whether credentials are active, expiring soon, or expired. - **Credential Expiry Date**: Displays the configured credential expiration date. - **Date Added**: Shows when the connection was created. - **Last Updated**: Displays the most recent update date. The system evaluates configured credential expiry dates daily and generates notifications **30 days and 7 days before expiration **for all supported connection types, including **Cloud Connections, Content Connections and Tool Connections**. Expired and soon-to-expire connections are highlighted in the Connections table to help administrators prioritize credential updates. Any changes made to the Credential Expiry Date are recorded in the audit history. # Capabilities - **Actions: **Next to the connection, select the **Actions** (ellipsis) menu to perform the following operations: - **View Details**: View the connection configuration, credential information, metadata, and expiration details associated with the selected cloud connection. - **Edit**: Modify the connection configuration, update credentials, change the credential expiry date, or update connection information as needed. - **Delete**: Remove the connection from Connections Management. Deleting a connection unregisters it and removes the associated connection configuration. - **Search: **Use this field to quickly locate specific cloud connections. - **Add Cloud Connection:** Click **Add Cloud Connection **to create a new cloud connection when additional cloud providers or accounts need to be onboarded. # Cloud Providers You can establish a connection for common services for the following cloud providers: - IBM Cloud - Microsoft Azure (CSP, EA, Application Insights, MPA and Subscription) - Google Cloud - AWS - Alibaba Cloud - VMware - vSphere - Demo Cloud - BYOD - Private Container Cluster # Registering a connection After creating your cloud account with certain policy permissions, you need to register a connection in . The credentials of your account are the ones that will be added to the page.  The configuration and credential details required will vary based on the selected cloud provider. Please ensure that you complete all fields on the page with the correct information. The following example outlines the onboarding process for an AWS connection. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration**→ **Service Operations** → **Connections Management**. 2. From the side panel menu, select the **Cloud Connections** option. 3. Select **Add Connection**. The **Add Connection** page opens. 4. Complete the following information to onboard your supported cloud connection: - **Connection Name**: Enter the connection name of your choice. - **Description**: Enter the description for the connection. - **Technology Category**: Select Cloud Provider from the drop-down menu. - **Connection Type**: Select the cloud connection from the drop-down menu. - **Tags**: Select a tag from the drop-down menu. :::hint{type="info"} If no access tags have been created, you can add them directly on the Tool page. To learn more about Access Tags, see [Access Tags Management](docId\:ecMgTeAnTw7m2dkR4_jtH). ::: 5. Add the configuration details. Not all the details are required; it depends on the cloud provider selected. 6. **Billing data toggle**: Toggle on if you are using this connection for billing data. If the billing data is enabled, complete the following information: - **Cost and Usage Report Path**: Enter the cost and usage report path. - **Account Number**: Enter the account number for which the bill is to be generated. 7. **Account Number**: Enter the account number. 8. **S3 Bucket**: Enter the S3 Bucket credential. 9. **Additional Info**: Enter any additional info required. 10. **Region**: Enter the ID of the region where the service will be accessed. In the context of setting up a credential for AWS, the region refers to the AWS region that will be specified in all AWS APIs calls made through this connection. This setting ensures that the content returned by API calls is limited to the specified AWS region. 11. **Advance**: Click the down arrow and complete the following information: - **Delegated Access**: Enter the ARN. - **External ID**: Enter the external ID. 12. Add the credential details. Not all the details are required; it depends on the cloud provider selected: - **Access Key ID**: Enter the Access Key ID. - **Secret Access Key**: Enter the secret access key. - **Client ID**: Enter the client ID. - **Secret**: Enter the secret ID or API key. - **User**: Enter the username. - **API Key**: Enter the API key. - **Data Set**: Enter data set. - **Service Key**: Enter the billing JSON key (in base 64). 13. Click **Test Connection** to test whether the credentials are valid.  This is a crucial step prior to adding the connection. Typically, the connection fails because the credentials are incorrect or the data cannot be displayed due to a permission limitation.  14. Click **Add**. A “Success: \[Connection Name] has been successfully added” alert is displayed. Additionally, the new connection can be viewed on the page.  If the connection is not successful, a “Failed: \[Connection Name] could not be added” alert with the reasons for failure is displayed. If all the information added is correct, and you are still encountering issues, [create a support ticket.](docId\:nFbfvQtiJz6ZeSJmhg8B9) # Deleting a connection Often, you may want to unregister a connection to maintain control of your IT data. 1. From the **Cloud ** page. 2. Click the **Actions** icon next to the connection you want to delete and select **Delete**. 3. Type the name of the connection and click **Confirm**. 4. Click the Global menu icon. 5. Click **Services** and select **Common Inventory**. The Common Inventory page opens. 6. On the top left corner, click on the **Page Filter** icon located below the Inventory header. 7. Expand the Provider Information and select the **Account Name** radio button, if not selected already. 8. Type the name of the connection and click **Confirm**. 9. Search by the connection name that was deleted. If a user has added multiple connections with the same Account Number, deleting one connection will only remove that specific connection and its resource information. The Account Number will still be visible in the page, as it is also associated with other connections. [title] Tool Chain Management [path] Catalogs/ [title] Develop module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ enables observable performance of the DevOps lifecycle to enable continual finetuning of each DevOps phase. The Developer module reports critical developer activity as it relates to the performance of your team. # Developer module composition In this dashboard, data can be filtered by two criteria: - **Dashboards:** Select a dashboard to view development data specific to that dashboard. - **Applications:** Comprehend cloud services' issues and health, such as Cost $Asset Management or Enterprise Marketplace. :::hint{type="info"} Depending on your selections from these filters, the data displayed in the widgets varies. Some widgets may show a *"No Data Available"* the message, which means no recent data is available for your selection. ::: The Develop dashboard displays data in multiple graphs and a table view table that allows a view of critical components of the development phase: - **Development activity:** A graph shows all activities per calendar month, issues (brown), and defects (aqua green). - **Applications:** A horizontal bar graph displays the top five applications with the highest updated defects/issues. - **Technical services:** A table views data for each supported technical service and includes a drill-down feature that enables a detailed view of each instance. # Download reports The Develop dashboard supports a reporting feature to download an open issues report. This enables users to download data in Excel format so that users can download and sent reports to those who do not have access to DI or want to perform additional analysis on the consolidated dataset. To download a report click the download button, located in the upper right corner of the dashboard in accordance with the following procedure: 1. Click Download to display the download dialog. 2. Enter a name in the **YOUR FILE NAME** field. All other fields are pre-populated. 3. Click **Download** to download the report or **Cancel** to cancel the download. # Widgets The Develop dashboard displays two widgets that visually represent development activities and applications. ## Development activity The Development Activity widget allows you to view **Defects** or **Issues** based on the following criteria: - The displayed data is governed by the date range selected from the timeframe in the header, **Select Duration**, default **7 Days**. - Dashboard filter - Applications filter - **Defect** or **Issues** Category, dropdown menu located on the right above the displayed widget. For each category there are three status option to display data in the widget: - New - Updated - Closed The Development activity widget presents two axes that indicate the **Activities** within a specified timeframe in which the Defects and Issues occurred: - **The X-Axis (Number of activities):** The X-axis corresponds to the dates within the activity's timeframe. - **The Y-Axis (Timeline):** The Y-axis corresponds to the number of new, updated or closed defects or issues for the selected timeframe. # Applications The top five applications in terms of defects or issues are represented in this graph. The top 5 applications with the most updated defects are displayed by default, but the category and type switches can be altered. Only the top 5 non-zero applications are shown in this graph. When a user selects one of the applications on the graph, the data for that application is automatically filtered and displayed in the Technical service table. # Defects and issues status The Development Activity widget presents six permutations depending on whether you select the **Defects** or **Issues** category, and which of the three status condition you select **New**, **updated** or **Closed**. The Consult the following list for details: - **New Defects:** Provides a view of bugs discovery rate. This trend helps the development manager to understand the growth of new bugs, which is critical for new features. A spike might indicate a problematic release or a specific area of the application that needs attention. If the trend shows a consistent number of new bugs, it might indicate that the team is not addressing the root causes of these bugs. - **Updated Defects:** Displays a visibility of bugs that are being processed. These are the bugs that are in different categories like active or test etc. Comparing different applications will help development managers to identify which team is focusing on working on bugs. - **Closed Defects:** Displays bugs that have been closed during the selected duration. The development manager can relate the trend of closed bugs with each release. If the number of closed defects increases after a release, it might indicate an initial instability that is being addressed. Conversely, a steady decline in closed defects over time can suggest that the application is becoming more stable. By comparing the trend of closed defects with the trend of new defects, you can manage your defect backlog more effectively. A higher rate of closure compared to new defects indicates a reducing backlog. - **New Issues:** The trend in the bottom right captures the information of the newly created epics and user stories. An ideal way to visualize this is monthly. Depending on the sprint planning activities, usually this should be higher at the Sprint planning phase. This can be correlated with the sprint schedule. - **Updated Issues:** Displays those issues that have changed its status. These issues can be user epics and user stories that the engineering team is currently processing. This should again follow the sprint cycle as it should reduce the time sprint ends. The right graph (Applications) gives an application level breakup, which should also account to the similar split in the team structure. The development manager can improve the team allocation based on the updated issues of the applications. - **Closed Issues:** Displays the rate of closing epics and user stories. Consistent closure of features indicates a well-functioning team, while fluctuations might highlight areas that need attention or improvement # Technical Services table The Technical service table view is located at the bottom of the Develop dashboard, which provides technical service development data in a tabular form and enables a detailed view of each technical service. The table shows different projects which are configured in . In this case the data is configured at fpl.com project and all the information with respect to defects and issues are captured. Information about the source code management tool is captured in the table. Currently, it is configured at the different project repos being configured as a technical service and mapped to different applications. The Active Pull Request (PR) is an important matrix, which gives the development manager a view on the code approval policy. A high number of Active PRs should be alarming for the development manager and then he/she shall go into the details to identify why there are these many PR which are pending to be merged. :::hint{type="info"} Technical services are a micro-service that is analogous. This is the most granular degree of granularity. Repos in Git and Bitbucket and projects in Jira are mapped. Only Technical Services with developments in the recent 6 months will be displayed. ::: Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical service:** The name of the micro technical service within the larger application. - **Application:** The application's name typically comprises multiple micro-technical services. - **New defects:** The number of new defects opened against the technical service during the selected time. - **Updated defects:** The number of open defects against the technical service that have been updated during the selected time. - **New issues:** The number of new issues opened against the technical service during the selected time. - **Updated issues:** The number of open issues against the technical service was updated during the selected time. - **Active PR:** Active Pull Requests. - **Tool engine:** The name of the technical service that produced the issue or defect ticket, such as Git. :::hint{type="info"} The Development details table displays all data regarding the timeframe selected. All the columns in this table can be sorted. Above this table, you will find a search box that allows searching technical services by name and a **Settings** an icon allows changing the table settings to show or hide pre-selected columns. ::: At the far right of each table, is an overflow menu icon that enables a detailed view of the issue described in that row. click View Details to review the following: - **Defect and Issue Summary:** This comparison displays the trend of new vs updated vs closed bugs during a specific period of time. By comparing the trend of closed defects with the trend of new defects, you can manage your defect backlog more effectively. A higher rate of closure compared to new defects indicates a reducing backlog. Similarly, it also compares the trend of issues together for new vs updated vs closed. - **Detailed view of Issues and Defects:** Above the Defects and Issues graph, is a Defects Summary and an Issues Summary containing the number of anomalies (New, Updated and Closed Defects and Issues). Each number is a clickable hyperlink that displays a drill-down view of that item. Tag searches also available. - **Pull Request and Commit:** These two charts capture the information on the trend of how commits and pull requests are progressing. This data is captured from GitHub for the repo you have selected in the Technical Services page. The metrics illustrate the development activity within the specified repository. The closed trend indicates how many pull requests have been approved and merged into the main branch. Ideally, there should be a balanced flow between the number of new pull requests and the number of closed pull requests. The commit trend reflects the level of development activity in the repository. Regular commits contribute to effective branch management, keeping the codebase up to date and reducing integration conflicts. - **Details of Pull Request and Contributors:** The details page of a pull request provides an overview of the number of open PRs for the selected repository. The updated date indicates the age of each PR, allowing managers to see which parts of the codebase are pending review and for how long. This capability offers insight into the review efficiency of the application. The PR link directs to the GitHub page, where development managers can monitor and review progress and identify any delays. If the number of open PRs is high for a specific repository, appropriate intervention might be necessary to prevent delays. Contributor details are specific to the selected repository and time frame. This information shows how much a developer has contributed in terms of lines of code changed and the number of commits. It also indicates the size of PRs, which should be managed to ensure an effective review process. The table view also supports detailed views for each technical service. To access details for a specific technical service, Click the overflow menu to the far right of the table and select View Details. For more information, see [Develop dashboard table view](docId\:Ya-G3jglSHK6QUTiMKxbZ) - [Develop dashboard table view](docId\:Ya-G3jglSHK6QUTiMKxbZ) View a tabular presentation of Develop details. [title] Build module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ The Build module presents the general health of your builds as measured by status and success. The product displays the data for the entire system per dashboard and application based on build-run statistic tools such as Travis and Bring Your Own Build (BYOB) Jenkins plug-in. In the Build dashboard, data can be filtered by two criteria: - **Dashboards:** Select a dashboard to view development data specific to that dashboard. - **Applications:** Comprehend Build Kyndryl's applications health, such as CAM or Enterprise Marketplace. :::hint{type="info"} Depending on your selections from these filters, the data displayed in the widgets varies. Some widgets may show a "No Data Available" message, which means no recent data is available for your selection. ::: The Build dashboard displays data in multiple graphs and a table view table that allows having a view of critical components of the Build phase: - **Build Status:** A graph that shows all builds, grouped by month and represented by two colors: green (passed) and red (failed). - **Build Success:** A graph that displays the total percentage of both Passed and Failed builds. - **Longest Builds/Technical services:** A horizontal bar graph shows all builds per service. # Widgets The Build dashboard displays three widgets that provide a graphic representation of **Build status**, **Build success**, and **Longest builds**, as well as a table view titled **Technical service builds**. # Build status The Build status widget presents a bar graph representing **Passed** (green color) and **Failed** (red color) builds. The Build status widget presents two axes that indicate the **Total Builds** within a specified timeframe: - X-Axis (**Duration**): The X-axis corresponds to the timeframe in which builds took place. By hovering over the graph, the following data is presented: - **Group** : Either Passed or Failed builds. - **Range** : The total number of builds for the timeframe. - **Value** : Either Passed or Failed builds. - Y-Axis (**Total Builds**): The Y-axis corresponds to the total number of Builds in the selected timeframe. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Duration:** The cut-out date for quantified builds. - **Passed:** Total number of Passed builds. - **Failed:** Total number of Failed builds. - **Total:** Total number of Builds in both Passed and Failed categories. # Build success The Build Success widget is a graph showing the total percentage of all **Passed** and **Failed** builds. The Passed builds are represented in green color while the Failed builds are represented in red. # Longest builds The Longest Builds/Technical services widget displays all builds per service. All the technical services are listed and represented by purple bar graphs, organized in descending order starting with The technical service with the longest build at the top. # Technical service builds The Technical service builds table is located at the bottom of the Build module and provides technical service Build data in a tabular form and enables a detailed view of each service. :::hint{type="info"} Technical services are a micro-service that is analogous. This is the most granular degree of granularity. Repos in Travis are mapped. Only Technical Services with builds in the past 6 months will be displayed. ::: Each row in the table displays information for a specific service, separated by columns of information type: - **Service**: the name of the micro-service within the larger application. - **Application**: the name of the application corresponding to the build. - **Build results**: the completion percentage of each build. - **Duration**: the amount of time the build took place. - **Build engine**: the name of the tool engine. :::hint{type="info"} The Technical service build table displays all data regardless of the timeframe selected. All columns in this table can be sorted. Above this table, you will find a search box that allows searching technical services by name and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: The Table View also supports detailed views for each service. To access details for a specific service, click the row. The dashboard responds by displaying a view dialog containing service details. Select the following link for more information: [Build Table view](docId\:SR5aBwtl4leECaukHF6sI) [title] Configuring Tool Chain Management applications [path] Catalogs/Tool Chain Management/ Learn how to add applications and their CICD pipeline tools in to enable the observability of CICD pipeline tools that support services in your hybrid IT estate. teams commonly use peripheral tools to monitor and manage services for themselves and customers. As services are deployed and updated, and as those updates are developed and deployed, a library of tools is often used to understand both the efficiency and effectiveness of related activities. This provides insights into the tools and teams that are responsible for those tools. For example, frequent build fails for services that typically pass QA testing can indicate that either testing is not adequate or that existing build processes should be examined to understand why the service passes Test but cannot reliably pass Build. These insights are much easier using tools such as Qmetry and JFrog artifactory and what they tell us about the performance of services on which DevOps and customers rely. ## Configuration procedure Use the following procedure to configure an application for a new service: 1. Click + **Configure new Application**. the service Navigates to **Step 1 Create Application & Add Tools**. 2. Enter the application name in the **Application Name** field. 3. Select a phase, for example **Plan**. 4. Click **+ Add Tool(s)**. The service displays the Add Tool(s) panel, and confirms your selected phase, for example **Add Tool(s) to Plan phase**. 5. You have the option of selecting an onboarded tool or adding a new tool, which has not been onboarded. ### Selecting an existing (onboarded) tool :::Paragraph{listStyleType="decimal" listRestartPolite="1" indent="2"} Click the down arrow on the **Tool Name** field to display a dropdown list of all onboarded tools. ::: :::Paragraph{listStyleType="decimal" listStart="2" indent="2"} Click the tool of choice from the list. ::: :::Paragraph{listStyleType="decimal" listStart="3" indent="2"} Enter the URL for the tool instance used for the service in question. For example the URL for the Azure Board project used by your team for the service. ::: :::Paragraph{listStyleType="decimal" listStart="4" indent="2"} Click the green plus to add an addtional tool or **Save **to add the tool(s). ::: ### Creating a new tool 1. Click **Create a new tool +**. The service displays the **Tool Name** and **Tool URL** fields. 2. Enter the tool name in the **Tool Name** field. 3. Enter the URL for the tool instance used for the service in question. 4. Click **Create & Add** tool. The service adds the tool and displays a green plus sign (**+**) and a red **X**. ### Adding additional tools 1. To add an additional tool, click the green plus sign (+) 2. To remove a tool, click the red **X** 3. When all tools have been added, click **Save**. 4. Continue adding tools to each phase until the application is complete. 5. Click **Next**. The service presents the Tools Configuration list displaying all tools added for each phase. 6. Click **Submit**. ## Editing applications You can edit the application configuration by editing each phase of an application as needed to add and remove tools. Use the following procedure: 1. Click the down arrow next to the application name to expand the application, displaying the eight phases and all tools that have been added. 2. Click the vertical ellipsis located at the far right end of the phase you want to edit to display the overflow menu, containing the **Edit** menu item. 3. Click **Edit** to display the tools for the selected phase. 4. Click **+ Add Tools** to add tools to the phase using the Add tools procedure in the previous section (*Configuration procedure*) or the vertical ellipsis to display the overflow menu with the items **Edit **and **Delete**. **Edit **allows you to edit the URL. **Delete **deletes the tool from that phase. [title] DSRR Approval Management [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/DSRR Candidacy/ **DSRR Approval Management** provides a centralized way to maintain application approver information used in DSRR release and governance workflows. Replacing the spreadsheet-based process, it allows authorized users to manage approver records through bulk imports and individual updates. The capability supports notification of workflows and governance oversight by maintaining a controlled, auditable list of approvers for each application. Role-based access controls ensure that only authorized users can make changes. Approver information is automatically synchronized with DSRR workflows to help ensure accurate routing of approvals and consistent governance processes. # DSRR Approver Management access The **DSRR Approver Management** feature is controlled by a feature flag and must be enabled before it becomes available. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Toolchain & Pipeline **→ **DevOps Intelligence **. 2. From the left navigation menu, select **Settings & Utilities**. 3. Select **DSRR Approver Management**. The **DSRR Approver Management page** is displayed, providing visibility into application approver governance, governance metrics and approver records used throughout DSRR workflows. # DSRR Approver Management page The **DSRR Approver Management** page provides a centralized view of application approver governance and approval coverage across the organization. The **DSRR Approver Management **page is synchronized with the **Application Configuration **page, establishing a single source of truth for application information. Applications created, updated or deleted in Application Configuration are automatically reflected in DSRR Approver Management, reducing duplicate administration and ensuring consistency across both areas. The **DSRR Approver Management **page displays three summary cards that provide a high-level overview of DSRR approver governance coverage across applications: - **Total Applications**: Displays the total number of applications being managed. - **Governance Complete**: Shows the number of applications with complete owner and approver information. - **Applications Missing Owners**: Identifies applications that require owner assignments or governance updates. ## DSRR Governance table The DSRR Governance table provides detailed information about application approver governance records: - **Application name**: Name of the application. - **Governance Status**: Governance status (for example, Complete). - **Created by**: User who created the record. - **Created at**: Date and time the record was created. - **Updated by**: User who updated the record. - **Updated at** (if available): Date and time of the latest update. Select an application name and expand it to view the approval requirements and assigned approvers for each approval category associated with the selected application. The following information is displayed: - **Approver Type**: The approval category associated with the application, such as Architecture, Data Science, DevOps or Documentation. - **Mandatory Approval Needed**: Indicates whether the approval category is required for the application. The Mandatory Approval Needed field can only be updated by Release Manager. - **Primary Approver**: The primary contact responsible for providing approval. - **Secondary Approver**: The backup approver who can provide approval when the primary approver is unavailable. - **Tertiary Approver**: An additional escalation or backup approver for the approval category. # Data management actions When viewing an application record, users can perform the following actions based on their assigned role and permissions: - **Edit**: Update approval requirements and approver assignments for the selected application. - **Export Data**: Release manager and Development manager can now export approver information for review, maintenance or reporting purposes. Data can be exported in the following formats: - **CSV (.csv)** - **JSON (.json)** - **XLS (.xls)** - **Import Data**: Import approver information in bulk. This action is available only to users with appropriate permissions (for example, Release Managers). ### Import prerequisites and validation requirements - Applications must be onboarded to DevOps Intelligence before they can be imported. Until applications are onboarded and displayed on the DSRR Approver Management page, the **Import** and **Export** options may not be available. In such cases, the bulk import template is provided directly to designated Release Managers for initial data loading. - During import, DevOps Intelligence (DI) validates the **Application Name** specified in the import file against the applications that have already been onboarded to DI. - An application record is imported successfully only if the application is already onboarded to DI. If the application is not onboarded, the import for that specific record fails. - As a prerequisite, applications must be onboarded to DI before their records can be imported. - In the import file, **Application Name** is a mandatory field. All other fields are optional. - If an import fails due to data issues in the import file, an error message is displayed at the top of the page. Users can download the error log to review the specific issues causing the failure and take the necessary corrective actions before retrying the import. # Roles and permissions Permissions determine which users can view, update, import, export and manage approver information used in DSRR governance workflows: | **Role** | **Actions allowed** | **Restrictions** | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | **Release Manager** | • View all application governance records. 
• Create, update and manage approver information. 
• Import approver data in bulk. 
• Export approver data for maintenance and reporting. 
• Manage approval records across applications. | There are no functional restrictions.
| | **Development Manager** | • View application governance records. 
• Update approver information through individual record edits. 
• Maintain approver assignments using the user interface. 
• Export approver data. | • Cannot import approver data in bulk. 
• Does not have access to the Import Data function. | | **All Users** | View approval management information and governance status. | Cannot import approver data.
Cannot perform administrative approval management actions. | | | |  
 
| [title] Tool Chain Management role management [path] Catalogs/Tool Chain Management/ Learn how to grant appropriate access to your users based on their role as they manage the tool chain for specific applications. employs a Role-Based Access Controls (RBAC) to enable appropriate access for individuals assigned those roles. Each role grants privileges to individuals, such as viewing and editing, for specific service allowing administrators to tailor access to team members according to organizational needs and policies. Subsequent sections describe the supported DevOps Intelligence roles and list the privileges granted for each role. ## roles User actions in are role-driven. Actions are granted as privileges associated with roles assigned to individual users. The following roles currently exist in the system: - **Administrator role:** Create, delete, update or view DevOps defined in the application. - **Editor role:** Update and view the DevOps and delete the list of tools defined in each phase. - **Viewer role:** View the listed in the service and refresh the tool status for all tools in . Each role endows privileges to the user assigned that role. The following permissions are required to view, edit, delete and refresh configurations from : - Create ToolChain - View ToolChain - Edit ToolChain - Delete ToolChain These privileges are provided to users by assigning users the aforementioned roles in accordance with the described privileges associated with each. For example, the Administrator role provides all four privileges (Create, View, Edit and Delete), whereas the Viewer role provides only Viewer privilege. [title] Atlassian Jira configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ Jira Software is part of a family of products designed to help teams of all types manage work. Originally, Jira was designed as a bug and issue tracker. But today, Jira has evolved into a powerful work management tool for all kinds of use cases, from requirements and test case management to agile software development. The following items are prerequisite to integration: - **Jira Account:** User should have an active Jira account on the specific Jira instance user want to connect to. If user don't have one, user need to sign up for a Jira account. - **Access to Jira Instance:** Ensure that User have access to the specific Jira instance where the projects, components, and issues are hosted. Users need the URL or web address of the Jira instance user want to connect to. - **Project Membership:** Users must be part of the Jira projects user intend to access. Ensure that users have the necessary project membership to retrieve information about projects, components, and issues. - **Access Policy as Platform Administrator and ** &#xNAN;** Administrator:** Ensure that the user creating the connection has the necessary access policies. The user should have the Platform Administrator role to create and manage connections effectively. The user needs the Administrator role, which allows them to create and manage configurations. # Jira REST API version compatibility relies on Jira's REST API, and it is designed to work with a specific version. As of now, the integration is aligned with Jira REST API version 2 (/rest/api/2/). It's crucial to ensure that Jira is using a compatible version for the integration to function optimally. # Integrating Jira with pulls data from GitHub Actions such as Build and Deploy details, including its unique identifier, status, time stamp, duration and cause. The process for onboarding GitHub actions comprises the following steps, each of which is a multistep procedure: 1. Create a Personal Access Token. 2. Create a connection. 3. Configure the application. 4. Onboard the Jira technical service. # Creating a personal access token Jira API Tokens are used as a form of authentication in Jira Services to access and interact with its resources programmatically or through APIs. Use the following procedure to create a Jira token: 1. Navigate to the top right corner of the Jira homepage. 2. Click on your profile picture and select **Manage Account**. 3. Go to the **Security** tab. 4. Click on **Create and manage API tokens**. 5. Select **Create API token**. # Creating a connection To pull data from GitHub Actions, you must establish a connection between and GitHub Actions. Use the following procedure: 1. Click on **Settings** → → **Connections** → **Add New** → **Add connection**. 2. Select **Add Connection**. 3. Select the appropriate authentication type. 4. If you are using a Proxy Adapter to access through an intermediary layer, enter the UUID for the adapter in the Proxy ID field. :::hint{type="info"} - When the sync-all is enabled, all the organization and repositories for which the user has access will be synced. - When the Archive is enabled, the connection is archived for future use. - For OAuth-based authentication, follow the steps given here to get the below-required fields: - **ConsumerKey:** Given on Jira Application Link Page. - **PrivateKey:** Private key (.pem format) of the public key generated while configuring Jira Application Link Page. - **Secret:** Generated after User confirmation from a Dialog box. - **AccessToken:** Generated value using Secret. ::: # Configuring for GitHub Actions, recent customers :::hint{type="info"} Note: The procedures in this section are valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent section Configure for GitHub, legacy customers. ::: Having created a connection, you must now configure the application. Use the following procedure: 1. Click **Settings & Utilities** → **Application Configuration**. 2. Select an existing application or create a new application. 3. Navigate to **Add Tools** step. 4. Select the phase as **Plan**. 5. Click **Add Tool Configuration**. 6. Complete the configurations, presented in the following tabs: - Release - Work Item Format - Bug Formats - Bug Severity - Bug Status # Onboarding the Jira technical service You must now onboard the technical service. Use the following procedure: 1. Click **Settings & Utilities** → **Application Configurations**. 2. Click the overflow menu for the chosen application and click on **Onboard Technical Service**. 3. Select the phase as **Plan**. 4. For **Tool engine**, select Jira. 5. For **Connection**, select the appropriate connection name from the drop down. 6. Enter the Technical Service name. You can select Project tracking or Component tracking. Onboarding technical services are always configured as mutually exclusive. If two users having same privileges attempt to create technical service for the same project/component, only the first user is allowed to create the technical service because the project/component is already configured. The service will not be listed for the second user to configure. This behavior applies to sync. For project tracking, select the Project Name from the dropdown. Configured projects are omitted from the list. The **Component** field should remain empty. For Component tracking, select the Project name and the component name. ## Deleting the technical service The administrator may, at will, delete the GitHub technical service. Use the following procedure: 1. Click **Settings & Utilities** → **Application Configuration**. 2. Expand the application to see all the associated phases. 3. Click the Overflow menu against the Plan phase. 4. Click **Delete Technical Service**. 5. For tool engine select **Jira**. 6. Select the appropriate Projects and Components. 7. Click **Delete**. ## Configuring for GitHub Actions, legacy customers The user needs to select the Project that needs to be tracked through the and its respective Components. Then, tracking can be done at two levels: - **Project Level**: This will track all the entities of a given project if no components selected - **Components Level**: This will track issues only for those selected Components # Project Level tracking For this type of tracking, certain selections have to be made in the system, as follows: - **Tool engine**: Jira - **Technical service name**: It could be any string and is used only for reference. - **Project**: Here, the user must select **Project** Name from the dropdown. The already configured project will be omitted from the list. - **Component**: At project-level tracking, this field should be empty. The following is an image of the Project Level Tracking configuration screen: # Component level tracking For this type of tracking, certain selections have to be made in the system, as follows: - **Tool engine**: Jira - **Technical service name**: It could be any string and is used only for reference. - **Project**: Here, the user must select **Project** Name from the dropdown. The already configured project will be omitted from the list. - **Component**: At project-level tracking, this field should be empty. **API key:** Personal access token, generated from the following menu selection: your profile and settings → personal settings → app passwords. If the configuration is successful, then a window will appear that shows a table with the configuration details. The Sync Feature scans current data for visibility after configuring credentials at periodic intervals. The intervals are set as follows: - The account Sync Interval is set to 5 mins: Refresh current data. - The account Delete Interval is set to 7 mins: All deleted accounts updated. - The history pulled Interval is set to 180 days: Data history. For more details, see your Delivery representative. [title] Accessing Notifications [path] Administration/Bridge Notification Service/ Notifications in are organized into categories to help users quickly identify and prioritize important information. Each category serves a specific purpose, making it easier to monitor service-related updates and respond to critical events that require immediate attention. - Service Notifications - Priority Notifications :::hint{type="info"} Notifications from both categories can be viewed through the notification bell, priority alert indicators, or the Notifications page and are retained for up to **365 days**. ::: # Notification bell icon :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/McBWPCbcNlAoAkcF7riYR-20260601-213350.svg" alt caption width="57" height="57"} The notification bell icon, located in the top-right corner of the application, serves as the primary entry point for viewing notifications, with a red indicator signaling when unread notifications are available. When you select the bell icon, a flyout panel opens and displays a list of recent notifications, allowing you to quickly review and access updates. Each notification includes a title, description, and severity indicator. A maximum of five notifications is displayed in the flyout panel. Follow these steps to view notifications from the bell icon: 1. Go to **Kyndryl Bridge Console ** 2. On the top-right corner, click the** notification bell icon **:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/McBWPCbcNlAoAkcF7riYR-20260601-213350.svg" alt caption width="57" height="57"}**.** 3. A notification flyout panel is displayed, where you can view recent notifications from any application. Each notification shows a title, a brief description, the source application, the severity level, and the time the notification was sent. 4. Select **Settings** to configure how notifications are displayed by choosing how notifications are sorted (for example, by most recent), select a read mode and the number of notifications to be displayed. 5. After you configure all settings, select **Apply to save** your changes. 6. **Mark all as Read** allows you to mark all notifications as read if needed. 7. Click the filter (funnel) icon to filter notifications by type (for example, Critical, Warning, or Info) 8. Select **See all Service Notifications** in the bell icon to navigate to the **Notifications details** page, where you can review all available notifications. # Notifications details page The Notifications details page provides a centralized view of all notifications generated across services. On the Notifications details page, users can: - Review and filter service and priority notifications in a structured table view. - Use the search field to quickly locate specific notifications. - Refine results using filters such as severity, notification type and other available criteria. - Mark all notifications as read with a single action. - Access Notification Management to configure notification settings. :::hint{type="info"} Manage notifications button is available only to users with administrator role permission. ::: The Notifications details page can also be accessed by following these steps: 1. From the** Bridge Console** Home page, use the left navigation menu and select **Notifications** (the bell menu option). 2. The Notifications main page will be displayed. There are two main notification tabs on the main Notifications details page: - Service-based Notifications - Priority Notifications # Viewing Service-based notifications The main Notifications page includes a Service-based notifications tab. This tab displays notifications generated by different services across the platform, allowing users to review all service-based updates in one place. Follow these steps to access Service-based notifications: 1. From the main Notifications page, select the **Service-based Notifications** tab. 2. Find the notification you want to review and select **View Source** to view additional details. From here, you can: - Select **View Details** to open additional information about the notification. - Select **Mark as Read** to mark the notification as reviewed. - Select **Source** to review the source of the notification. The following columns are displayed in the Service notifications table: - **Severity**: Indicates the type of notification, such as Info, Warning, Critical or Success. - **Title**: Displays the name or summary of the notification. - **Description**: Provides additional details about the notification. - **App/Service**: Identifies the application or service that generates the notification. - **Type**: Specifies the category of the **notification**. - **Date**: Shows when the notification was generated. - **Actions**: Provides options to interact with the notification, such as viewing more details or accessing the source. The table supports pagination, allowing users to efficiently navigate through large volumes of notifications. # Viewing Priority Notifications When you log in to any Kyndryl application for the first time, a Priority notification pop-up appears in the top-right corner of the screen. Priority notifications display only high-priority items that require immediate attention and typically highlight critical updates or time-sensitive information that may impact users or services. For example, **Scheduled maintenance:** The PROD environment will be unavailable from 02:00–04:00 UTC on July 15 due to scheduled maintenance. Follow these steps to view Priority Notifications: 1. When you log in to a Kyndryl application for the first time, a** Priority Notification pop-up** appears in the top-right corner of the screen. 2. Select **Read now** to open the notification details in a side panel or dismiss the alert if no immediate action is required. The panel displays complete notification details, where you can review the information and select **Yes, I read** to mark it as read, if needed. 3. Priority notifications pop up in the following scenarios: - When users log in to Bridge. - When users switch between applications within the same account (for example, from Service A to Service B). In both cases, all unacknowledged priority notifications are automatically displayed to ensure users are aware of important updates requiring attention. 4. Select View All Priority Notifications to go to the Notifications details page. The main Notifications page includes a Priority notifications tab, which displays high-priority notifications that require attention and highlights important or time-sensitive updates. The following columns are displayed in the Priority Notifications table: - **Severity**: Indicates the importance level of the notification, such as Notice, Warning, or Critical. - **Service**: Identifies the application or service that generates the notification. - **Notification**: Displays the title or name of the notification, summarizing the event or update. - **Description**: Provides additional details about the notification, including context or actions required. - **Start date**: Shows when the notification or event begins. - **End date**: Indicates when the notification or event is expected to end, if applicable. The table supports pagination, allowing users to efficiently navigate through large volumes of notifications. From here, you can: - Select **View Details** to open additional information about the notification. - Select **Mark as Read** to mark the notification as reviewed. - Select **Source** to review the source of the notification. [title] API Keys [path] Administration/Bridge Access Management/ API keys are secure identifiers used to authenticate applications and services when they connect to APIs. They function as password-like tokens with a defined set of access rights, helping ensure that only authorized applications can access APIs. API keys also support monitoring and tracking of API usage, enabling administrators to identify misuse, control access and improve the security of integrations. As a foundational component of cloud API security, API keys help protect services while allowing controlled communication between systems. # Prerequisites  The following prerequisites must be met to manage API keys: - **Administrators** can manage all API keys. - **Non-administrator users** can manage their own API keys. - **Non-administrator users** can manage other users' API keys when their assigned access policies grant the required permissions. :::hint{type="info"} You can also associate API keys with **Service IDs, Access Groups** and **Users.**            For details, see – [Service IDs](docId\:I2WXFQP2tstQi7GfvOF18)            For details, see -  [Access Groups](docId\:HZc4qy5Gh7gwkLHfYsAyC)            For details, see – [Users](docId:7caOs2IBiKFBH9x-bz51X)        ::: # API Keys page The **API Keys **page provides a centralized location for creating, viewing, and managing API keys within your account. From this page, authorized users can monitor existing API keys, manage access credentials, and control application access to services. The page also displays a summary card with the total number of API keys available, along with a list of the API keys associated with your account. # Accessing the Users page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="28" height="28"}, go to **Administration** → → **API Keys ** # Managing API Keys The **API Keys **page enables authorized users to create and manage API keys used for secure authentication between applications and services. From this page, based on your role, you can create new API keys, view and update key details, regenerate credentials, lock or unlock keys and remove keys that are no longer needed. These capabilities help maintain secure access to APIs while providing control over how applications integrate with services. ## Viewing a list of API keys By accessing the **API Keys** page, you are presented with a card that displays the total number of API keys available and a list of such keys that you have added to your account. ## Creating a new API key Create a new API key to enable secure authentication for applications and services that access APIs. Follow these steps to create a new API key: 1. On the **API keys** page, click **Create API Key**.  2. Enter the **name** (mandatory) and **description** (optional).  - Use unique names that start with a letter and can include letters, numbers, underscores, and hyphens (up to 60 characters).  - Write descriptions up to 100 characters long and may include special characters.  3. Click **Create API key**.  4. Copy the generated key using the **copy icon **:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/TlS7H4A_o_JkOnMrBZlrD-20260602-174641.svg" alt caption width="28" height="28"} or select **Download Key**. The new API key appears in your list.  ## Editing an API key  Update the name or description of an existing API key to keep key information accurate and easy to identify. Follow these steps to edit an API Key: 1. Click the **overflow** menu:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/JndGM9EedPv0uB0o6JMpp-20260601-221027.svg" alt caption width="28" height="28"}next to the API key you want to modify.  2. Select **Edit Key** and update the name and description.  3. Click **Update**.  ## Regenerating API key Regenerate an API key when you need to replace an existing key value while preserving the associated configuration and permissions. Follow these steps to regenerate an API Key: 1. Click the **overflow** menu:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/JndGM9EedPv0uB0o6JMpp-20260601-221027.svg" alt caption width="28" height="28"}next to the API key you want to regenerate. 2. Select **Regenerate**. 3. Copy the new API key using the **copy icon **:inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/TlS7H4A_o_JkOnMrBZlrD-20260602-174641.svg" alt caption width="28" height="28"} or select **Download Key**.  ## Deleting an API key  Delete an API key when it is no longer required or should no longer be used to access Bridge services. Follow these steps to delete an API Key: 1. Click the **overflow menu** next to the API key.  2. Select **Delete **and confirm the deletion.  ## Locking and unlocking API keys You can prevent an API key from being deleted or modified by locking it. A locked API key is represented by the **Locked** icon :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/ISzYWnQSznncH1WQKGEeq-20260602-175146.svg" alt caption width="28" height="28"}. You can unlock an API key at any time to update or delete it from your platform. To lock or unlock an API key, follow these steps: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="28" height="28"} next to the API key that you want to edit. 2. Select the **Lock** or **Unlock** option, depending on whether the API key has been locked before. 3. Confirm the action. :::hint{type="info"} Whenever an API key is locked, the regenerate, edit, and delete actions will not be available. ::: # Best practices  The following best practices can help you manage API keys securely and efficiently: - Assign descriptive names so keys are easy to identify.  - Lock keys that are in using to prevent accidental changes.  - Periodically rotate API keys to maintain security.  - Delete keys that are unused or outdated to reduce risk.  - Use different keys for different integrations to track usage and limit the impact if one key is compromised.  - Least privilege: keep role and policy scopes minimal and specific. - Use access groups: assign policies to groups to scale consistently. - Name clearly: use descriptive names for roles, policies, service IDs and API keys. - Rotate credentials: regenerate API keys on a regular cadence and after personnel changes. - Review regularly: audit roles, policies, service IDs and keys each release and retire what you no longer need. - Lock when stable: lock service IDs and keys to avoid accidental changes. # Troubleshooting If you encounter issues while creating, managing, or using API keys, review the following troubleshooting guidance and recommended resolutions to help identify and resolve common problems. **Symptom**: User cannot see expected resources. **Likely cause**: Policy is attribute scoped and tags do not match. **Fix**: Align user or service ID attributes with resource tags; recheck policy scope. **Symptom**: “Assign policy” lists only “platform” in Service. **Likely** **cause**: No service registered to Platform Central. **Fix**: Register the service, then select it in the Service drop-down. **Symptom**: API key actions are disabled. **Likely** **cause**: Key is locked. **Fix**: Unlock the key to edit, regenerate or delete. **Symptom**: Service ID cannot be modified. **Likely** **cause**: Service ID is locked. **Fix**: Unlock the service ID; note it overrides individual API key lock states. **Symptom**: Custom role seems incomplete. **Likely** **cause**: Permissions not selected during creation. **Fix**: Edit the role; add specific permissions from the populated list and save. [title] Container vulnerability [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ supports a view of security vulnerabilities that you can monitor. Selecting Container Vulnerability Scan dashboard displays graphs representing the severity of vulnerabilities in a chart, under the following criteria: - Vulnerability by Severity - Top Critical Technical Services - Container Vulnerability Scan Details This graph represents the total number of vulnerabilities detected aggregated according to day-month timeline selection. Graph data supports selections of a Drop-down menu application & teams. By default, it is for all applications, all teams & default organizations and it represents 180 days old data. Severities are classified into 4 categories: - **Critical**: Dark red square. - **High**: Red square. - **Medium**: Orange square. - **Low**: Sky blue square. - **Info**: Green square # Display Filters The dashboard is equipped with two filters to tailor data presentation to specific requirements: - **Global Filter:** Filter by application and duration (time span in days from selected origin to present) for example, the past 30 days. Default **All**. - **Release Filter:** Filter by a specific release such as 8/27/2025. Default **All**. The two filters work in concert to limit presented data to the selected application AND duration AND Release. If both are set to the default **All** data is presented. However, if for example, you filter on *my\_application* (global filter) and release *July 23, 2025* (release filter), the dashboard presents only data for *my\_application* at release *July 23, 2025*. # Vulnerability by Severity The Vulnerabilities by Severity widget provides details about any detected vulnerabilities within a container image, by means of a bar graph that presents two axis, described as follows: - X-Axis (**Duration**): The X axis corresponds to the months and dates from the time period selected to show data. - Y Axis (**Total Vulnerabilities**): The Y axis corresponds to the number of vulnerabilities detected in the selected time period. By hovering over the bars in the graph, you can view data about total number of vulnerabilities detected and the severity they belong to, as follows: - **Group:** The severity to which the vulnerabilities belong. - **Duration:** The cut out date for the vulnerabilities detected. - **Total/Value:** The total number of vulnerabilities detected. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Range:** The cut-out date for detected Vulnerabilities. - **Critical:** Total number of vulnerabilities detected and classified as Critical severity. - **High:** Total number of vulnerabilities detected and classified as High severity. - **Low:** Total number of vulnerabilities detected and classified as Low severity. - **Total:** Total number of vulnerabilities detected including all severities. # Top Critical Technical services This chart represents the top 5 technical services listed according to their criticality. This table represents the list of technical services with the latest data scan per technical service. Each row in the table displays information for a specific technical service, separated by columns of information type: - **Technical service:** The name of the micro technical service within the larger application. - **Application:** The name of the application typically comprises multiple micro technical services. - **Vulnerabilities:** Total number of vulnerabilities detected for technical service. - **Critical:** Total number of critical vulnerabilities detected for technical service. - **Scanned on:** The technical service was scanned. - **Secure engine:** The security source tool is configured. # Export functionality The Export functionality feature has two dropdown menus for technical services and severity levels. Technical services refer to specific features or functionalities of a software system, and severity levels indicate the severity of issues that require attention i.e: Critical, High, Medium, Low and Info. To generate a report, you must select at least one service from the technical services menu and a severity status. Once you have selected the technical services and severity level, you can generate a custom report that focuses on the specific features or functionalities of interest and provides relevant information about the selected issues. The report is saved as a zip file, which you can easily download and share the reports with colleagues, stakeholders or other interested parties. # Container Vulnerability Scan details The Table view supports a sort of feature for the following column that enables you to toggle between ascending and descending alphanumeric order for all columns except for URL Vulnerabilities. It also supports detailed views for each technical service, to access details for a specific technical service, click the row for that technical service. When you click on a technical service from the Table View, a new dialog appears with package details for the technical service. The following elements are displayed in this dialog: - The title **Name of the Service** in question. - The Sub-title **Container Vulnerability Scan Details**. - A search feature that facilitates the search of a specific package name. - A table that displays information for a specific package, separated by columns of information type: - Package Name - Package Version - Package Path - Image Digest - Vulnerability ID - severity - Description - CVSS Score The Secure dashboard also supports functionality for Bring Your Own Image. For integration with other Secure Tools, see [Bring your own tools](docId\:ytczdnbRB9xNljeCC__rt). By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applications, regardless of vulnerability. [title] Configure Azure boards for legacy customer [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/Configure Azure boards and repository/ :::hint{type="info"} 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. :::hint{type="info"} 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. 1. 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. :::Paragraph{indent="1"} Examples of the patterns identified with the given prefix and variable: The system can match various release patterns using the specified prefix and variable. ::: :::Paragraph{listStyleType="disc" indent="2"} For `User Story` fixed release is in which the User Story is done. ::: :::Paragraph{listStyleType="disc" indent="2"} For `Bug` fixed release is in which the Bug is Fixed and can be multiple since fixes can be . ::: :::Paragraph{listStyleType="disc" indent="2"} By default, For Azure Boards, a fixed release is identified from the `Iteration Path` which follows just the release format. ::: 2. **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. 3. **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`. [title] Content connections [path] Administration/Connections Management/ # Adding a content connection 1. From the side panel menu, select the **Content Connections** option. 2. Select **Add Content Connection**. The **Add Connection** page opens. 3. Fill in the required fields and click the **Create Tag** button. 4. Click the **Create tag** button and fill in data. 5. Click the **Create button** and verify that the created tag is displayed in the **Access Tag** dropdown. 6. Click **Next** 7. In the **Connection configuration** section, provide all the necessary inputs, and click **Next**. 8. Add details in the credential section and click the **Next** button. 9. Verify that all the entered data is displayed in the respective fields of the **Review** page and click **Submit**. A message "connection added successfully" displays. Verify that the created connection is displayed in the table. # Manage a content connection - **View:** To verify that all the filled-in details are displayed in the view details page, click the connection row action item and select **View details** - **Edit: **From the **Action** menu in the table, click the **Edit action** option. An **Edit **screen displays. Verify that the updated data is reflected as expected in the respective connection. - **Delete: **To successfully delete the selected connection, click the **Delete Action** menu item and confirm your action. [title] Image management [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Untitled/ The Image Management feature within suite is pivotal for users gaining insights into the software images used within your organization's software development lifecycle. This feature grants you access to pertinent data about these images, facilitating your decision-making processes. The Image Management allows you to keep track of the various components of modern software, which often includes a blend of in-house developed source code and third-party libraries, mainly open-source ones. With the rising dependence on open-source libraries, security vulnerabilities and license compliance issues can arise; the Image Management feature helps you avoid such issues, keeping your software assets safe and secure. At a macro level, the Image Management feature gathers crucial data about the images used in the software development lifecycle. This includes the total count of unique images, the number of images with vulnerabilities, and images not scanned in the last 150 days. To view the Image management dashboard, you must: 1. From the top left menu button, select . 2. Select **Build** option and expand the menu. 3. Select **Image management**. On this dashboard, you will be presented with an Image management widget, a Top 5 applications with vulnerable images and an Image details table. # Key image vulnerability management metrics The Image Management Metrics are split into four categories: - **Overall unique images**: This metric includes the total count of unique images from the latest master images; even if a single technical service contains multiple images, it counts as one. The percentage of these images that are open-source is also displayed. - **Images with vulnerabilities**: This represents the number and percentage of images with vulnerabilities. This metric also compares the vulnerability image percentage increase or decrease in the last 30 days concerning the previous 30 days. - **Images multiple critical/high vulnerabilities**: This metric represents the total number of images with multiple critical or high vulnerabilities out of the total vulnerable images. - **Images Not Scanned in the Last 150 Days**: Displays the number of images not scanned in the last 150 days. # Images not scanned in last 150 days Once selected, images not scanned in the last 150 days section provides detailed information about the Top 5 applications with vulnerable images and will also be displayed in the Image details table, presenting images that have not undergone a scan in the past 150 days. # Top 5 applications with vulnerable images The vulnerabilities by severity for the Top 5 applications graph comprehensively shows the total number of vulnerabilities distributed across two severity categories: Critical and High. This visualization supports: - **Application Filtering**: The graph adjusts based on the selection in the application dropdown menu. By default, it displays data for all applications. - **Timeline Adjustment**: It supports a selectable timeline that defaults to the past 7 days and can be adjusted as needed. - **Release Selection**: The graph also updates based on the selected release from the Release dropdown. # Image details table The Image details table provides a detailed view of each image's vulnerabilities. The table adjusts based on the selections made in two dropdowns: Technical service and Severities. It shows all applications and data from the past 7 days by default. Here's what each column represents: - **Image**: The name of the image. - **Version**: The version of the image. - **Technical service**: The technical service associated with the image. - **Application**: The application to which the image is linked. - **Release**: The release under which the image falls. - **Total vulnerabilities**: The total number of identified vulnerabilities. - **Critical** and **High**: The number of vulnerabilities categorized based on their severity. - **Last scanned**: The last date the image was scanned for vulnerabilities. - **Tools Engine**: Displays the name of the tool engine in use. The Image details table displays all data based on the timeframe selected. All columns in this table can be sorted except the Tool engine column. Above this table, you will find a search box that allows searching technical services by name and a **Settings** icon that allows you to change the settings to show or hide pre-selected columns. Additionally, an export function allows you to download a zip report of the table for offline analysis and record-keeping. # Image details view The Image details view can be accessed by selecting the vertical ellipsis menu located to the far right of the image in the table and selecting **View details**; this page provides a comprehensive view of the vulnerabilities associated with a specific image; you will see the Image name, the Version, and a Vulnerability summary categorized as Critical and High. The table on this page gives detailed information about each vulnerability as follows: - **Package Name**: The package associated with the image. - **Path**: The path to the package. - **Issue ID**: The unique identifier for the vulnerability. - **Severity**: The severity level of the vulnerability. - **Description**: A summary of the vulnerability. - **CVSS Score**: A numerical representation, ranging from 0-10, of the severity of a security vulnerability. - **Fixed Version**: The version where the vulnerability has been addressed and resolved. [title] Navigate to Access Request Management page [path] Administration/Bridge Access Management/Access Request Management/ Navigate to the Access Request Management page to manage your access to accounts and access groups. This page provides a centralized location to view your account memberships, submit new access requests, track request status and review access-related information. Follow the below path to navigate to the **Access Request Management** page: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration**→ **Access Management **→ **Access Request Management**. This action displays the **Access Request Management **page. ## My Accounts tab The **My Accounts **tab displays the accounts you have access to and provides information about your assigned roles and permissions. To access the My Accounts tab: 1. Navigate to the **Access Request Management** page. 2. Select the **My Accounts** tab. This tab provides a centralized view of all accounts and access groups associated with your user ID, including: :::Paragraph{listStyleType="disc" indent="2"} **Account Name:** Displays the account name. ::: :::Paragraph{listStyleType="disc" indent="2"} **Account ID:** Displays the unique account identifier. ::: :::Paragraph{listStyleType="disc" indent="2"} **Country:** Displays the account's country. ::: :::Paragraph{listStyleType="disc" indent="2"} **Segment ID:** Displays the associated business segment identifier. ::: :::Paragraph{listStyleType="disc" indent="2"} **Account Description:** Provides a brief description of the account. ::: 2. **Identify the account name and expand an account** to view the access groups associated with it, including: - **Access Group Name:** Displays the access group name. - **Members:** Shows the number of members in the access group. - **Description:** Provides a brief description of the access group. - **Status:** Displays the current status of the access group. 3. Select **View Details **to view the account details, including customer accounts, service provider accounts and all access groups associated with a specific account. 4. The **View Membership Only **toggle on the account details page controls which access groups are displayed for the selected account. Use this toggle to switch between viewing only your current memberships and all access groups available within the account. - **View Membership Only = On**: Displays only the access groups that you currently belong to within the selected account. This view helps you quickly review your existing access and permissions. - **View Membership Only = Off: **Displays all access groups available within the selected account, including both the access groups you already belong to and those you do not currently belong to. This view helps you identify additional access groups that may be available and request access to them through the Edit Access workflow. ## My Request tab **My Requests **tab displays all access requests submitted by the user, including request details, approval status, submission date and available actions. From this tab, users can also track the progress of access requests, review request information and monitor approval outcomes for requested accounts and access groups. To access the My Requests tab: 1. Navigate to the **Access Request Management** page. 2. Select the **My Requests** tab. The request table displays the following information: :::Paragraph{listStyleType="disc" indent="2"} **Request Date: **The date the access request was submitted. ::: :::Paragraph{listStyleType="disc" indent="2"} **Account Name: **The name of the account for which access was requested. ::: :::Paragraph{listStyleType="disc" indent="2"} **Access Groups:** The access groups included in the request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Account ID: **The unique identifier of the requested account. ::: :::Paragraph{listStyleType="disc" indent="2"} **Country: **The country associated with the requested account. ::: :::Paragraph{listStyleType="disc" indent="2"} **Reviewer: **The approver assigned to review the request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Status: **The current state of the request, such as Pending, Approved, Rejected, Cancelled or Expired. ::: Locate the request you want to review and **expand it **to view the access group details associated with the request: :::Paragraph{listStyleType="disc" indent="2"} **Access Groups**: The access groups included in the request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Service**: The service associated with the access group. ::: :::Paragraph{listStyleType="disc" indent="2"} **Description**: A description of the access group. ::: :::Paragraph{listStyleType="disc" indent="2"} **Members Count**: The number of members assigned to the access group. ::: From this page you can perform the following **actions**: - **View Details** Click the **ellipsis** (...) **menu** and select **View Details**. The **Request Details** page opens, where you can review request information, including: :::Paragraph{listStyleType="disc" indent="2"} **Account details:** Displays the selected account information. ::: :::Paragraph{listStyleType="disc" indent="2"} **Access groups:** Shows the requested access groups. ::: :::Paragraph{listStyleType="disc" indent="2"} **Request justification:** Displays the reason for the access request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Access group descriptions:** Provides details about the requested access groups. ::: :::Paragraph{listStyleType="disc" indent="2"} **Approval or rejection comments:** Shows comments provided by the approver. ::: :::Paragraph{listStyleType="disc" indent="2"} **Approval or rejection dates:** Displays when the request was approved or rejected. ::: :::Paragraph{listStyleType="disc" indent="2"} **Approver information and request status:** Shows the approver details and current request status. ::: - **Cancel Request** Click the **ellipsis** (...)** menu** and select **Cancel**. Available only when the request is in Pending status. Use this action to withdraw a request before it is reviewed by the account administrator. Access requests cancelled by the requestor are retained for **30 days** from the date they reach the **Expired** state. After the retention period ends, these requests are automatically removed from the system. # Request access for accounts Additionally, users can request access if they are not currently a member of an account through one of the following two key flows: - **(Scope 1) Request access to a new Bridge account** (for users who are not members of the account). - **(Scope 2) Request access to different access groups** (for users who need access to additional access groups in an account they already belong to). Users **are **allowed to search for any account in the "Request Access" flow irrespective of whether user already has access to the tenant or not. ## Requesting access to a new Bridge account or request access to a different Access Group within an account    This request allows users who are not currently members of a account to request access to that account.  Follow these steps to initiate an access request to a or AIOps account that you are not currently a member of:  1. From the Access Request Management page, click **Request Access.** 2. Locate the account that you want to access. You can **search** for an account by name or use the **Country **and **Segment ID** filters to narrow the list of available accounts and click **Next.** 3. Select the access groups that you want to join for the selected account. You can request access to one or more access groups as part of the same access request. Access groups are organized into two categories: :::Paragraph{listStyleType="disc" indent="2"} **Bridge Access Groups **for platform-level access. ::: :::Paragraph{listStyleType="disc" indent="2"} **Service Access Groups** for service-specific access. For the Service Groups, use the **Filter by service name **option to narrow the list of access groups displayed in the table. ::: To access the functionality, users must belong to at least one Bridge Access Group. To ensure this requirement is met, the **Bridge Viewer** access group is selected by default when submitting an access request; this can be unselected as needed. The Bridge Viewer access group provides the minimum level of access required to use the functionality. 4. Enter a **business justification** (500 character minimum) for the access request and click **Next**.  5. Review the request summary and click **Submit**.    The Edit Access workflow creates a new access request for the selected account and does not modify previously submitted requests. If a submitted request is not reviewed by an account administrator within **30 days** of submission, its status is automatically updated to **Expired**.  Whenever an access request is submitted, the request is routed to the appropriate approver for review, and an email notification is sent to notify the approver of the new access request. # Requestor email notifications Requestors receive **email** notifications throughout the access request lifecycle to help them track the status of their requests and stay informed of any required actions. Requestors receive email notifications when: - The access request is **approved**. - The access request is **rejected**, along with **reason for rejection**. - The access request is **expired**. The email contains the following information: - Account name - Account ID - Approved access groups - Country - A direct link to the approved or rejected access request that routes users to the **My Accounts **page. - Contact information for Kyndryl Bridge Support. [title] AWS DevOps connection [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ To configure an AWS DevOps connection within the platform, following the correct sequence of steps is essential to ensure a successful setup. This guide will provide a step-by-step walkthrough to help you configure this connection effectively, promoting seamless data flow and efficient operations. By following these steps, you can effectively configure an AWS connection within the platform: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Service Operations**→ **Connections Management.** 2. Select the** Add New** and fill in all the necessary information required, such as **Connection name**, **Technology Category** and **Connection Type**. 3. Specify and enter the appropriate information if you will use the connection for **Billing Data**. 4. Enter the credential details, such as **Access Key** and **Secret Key**. 5. Select the **Test connection** button to validate the configuration. 6. Select the **Add** button at the bottom of the form. # Configuration As a user, you must input a valid endpoint. This endpoint should list the repositories you aim to monitor via the platform. Inputting the correct endpoint ensures you can effectively track and manage the necessary repositories. # Repository level tracking This guide will lead you through the process, ensuring you can effectively monitor and manage your repositories. 1. **Tool engine**: AWS . 2. **Connection**: Select the connection name from the dropdown menu. 3. **Endpoint**: Enter the valid endpoint, which will give the list of repositories. 4. **Repository**: Select the repository and click configure. After completing the configuration, you can view the configuration details in the table on the configuration page. [title] Deploy module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Navigate the view of your Deploy landscape, to ascertain deployment performance for applications, technical services and cloud services for supported providers. The Deploy dashboard presents an at-a-glance view of your deployments as measured by status and success. The product displays the data for the following services: - [AWS configuration](docId\:DhPVyu9tCpJH0zlRpuLVr) - [Azure Resource Manager configuration](docId\:bubUdxDgF-iqSKgVwcI80) - [Google Cloud Platform](docId\:tnYUtki-BT7ynfYbv1WXW) - [ArgoCD configuration](docId:4QAg_7nI5cw_G2XjwrFWX) # Deployment data filters The Deploy module presents two filters to narrow presented data to specific needs: - **Releases:** Select releases from a dropdown menu. Select only the releases for the deploy data you want to observe. - **Environments:** Select environments from a dropdown menu. Select only the environments for data you want to see. As services are deployed, in different environments, such as multiple develop, staging and production environments. Using this filter, you can track specific deployments in different environments. If specific application deployments are failing multiple times in one or more environments, the DevOps team can assess whether the cause is an application or environment issue and take the appropriate action. # Widgets The Deploy dashboard displays three widgets that provide a graphic representation of different aspects of deployments: - Deployment frequency - Deployment frequency trend - Top 5 applications by failure rate - Deployments by environment - Deployment status - Deployment duration trend :::hint{type="info"} Some widgets may show a "No Data Available" message, which means no recent data is available for your selection. ::: # Deployment frequency Deployment Frequency refers to the frequency of successful software releases to production in the last seven days. A donut chart represents this widget. The date range filter is not applied to this chart; it is fixed to the previous 7 days. # Deployment frequency trend This graph represents the deployment frequency for each application over a selected period of \[1/7/14/30 days, 2/3/6 months] interval. Also, for a specific date range, use the calendar icon. The weekly deployment frequency average is displayed at the top of the chart. The Deployment Frequency widget presents two axes that indicate the **Deployment frequency** and **Date** within a specified timeframe: - X-Axis **(Date(Year))**: The X-axis corresponds to the timeframe in which an application was deployed. By hovering over each bullet point in the chart line, the following data is presented: - **Application**: Name of the application deployed. - **Date**: Date in which the application was deployed. - **Total**: Total amount of deployments for the application. - Y-Axis (**Deployment frequency**): The Y-axis corresponds to the time it took for deployments. # Top 5 applications by failure rate This graph represents the top 5 applications with the highest failure rate for the last seven days. There are three failure rate options to filter the applications (more than 60%, more than 75%, and more than 90%). Also, this graph will not change for any date range. # Deployments by environment This graph represents the total number of deployments for each environment over a selected period of \[1/7/14/30 days, 2/3/6 months] interval. A donut chart represents this widget. For a specific date range, use the calendar icon. The total deployment count is displayed at the top of the chart. # Deployment status This graph represents the number of deployments passed/failed over a selected period of \[1/7/14/30 days, 2/3/6 months] interval. For a specific date range, use the calendar icon. Passed deployments are represented in green, and failed deployments are in red. This widget is represented by default as a bar chart; by selecting the drop-down menu, the graph can be converted into a donut chart. The Deployment status widget presents two axes that indicate the **Number of Deployments** and **Date** within a specified timeframe: - X-Axis **(Date(Year))**: The X-axis corresponds to the date on which an application was deployed. By hovering over each bullet point in the chart line, the following data is presented: - **Status**: The status of the deployment is **Success** or **Failure**. - **Date**: Date on which the application was deployed. - **Application**: Name of the application deployed. - Y-Axis (**Number of Deployment**): The Y-axis corresponds to the amount of deployments that have taken place. # Deployment duration trend This graph represents the duration of deployments for each application over a selected period of \[1/7/14/30 days, 2/3/6 months] interval. Also, for a specific date range, use the calendar icon. Selecting any deployment opens the Deploy detail view, which represents: - **Templates**: Shows an overview and the operations of the templates. - **Resources**: Present the name and kind of the deployment technical service. - **Input parameters**: Shows information regarding the technical service input. - **Output parameters**: Shows information regarding the technical service input. This widget is represented by default as a bar chart. The Deployment duration trend widget presents two axes that indicate the **Duration** and **Date** within a specified timeframe: - X-Axis (**Date(Year)**): The X-axis corresponds to the date on which an application was deployed. By hovering over each bullet point in the chart line, the following data is presented: - **Application**: Name of the application deployed. - **Date**: Date on which the application was deployed. - Y-Axis (**Duration **of Deployment): The Y-axis corresponds to the amount of deployments that have taken place. # Deployment table The Deployment table is located at the bottom of the deploy dashboard; it provides technical service deployment data in a tabular form and enables a detailed view of each deployment and its technical service. :::hint{type="info"} Technical services are a micro-service that is analogous. This is the most granular degree of granularity. Only Technical Services with deployments in the recent 6 months will be displayed. ::: Each row in the table displays information for a specific technical service, separated by columns of information type: - **Deployments name**: The name of each deployment. - **Technical service**: Represents the template name that got deployed. - **Deployment date**: The date the service was deployed. - **Provider**: Represents provider name through which tool it got deployed. - **Environment**: Instance where the deployment was released. - **Application**: Name of the Application deployed. - **Release**: Release associated with the deployment. - **Status**: Current deployment status. - **Duration**: Represents the time duration. - **Tools engine**: Tools source where the deployment was executed. :::hint{type="info"} The Technical Service deployment table displays data based on the timeframe selected. All columns can be sorted. Above this table, you will find a search box that allows searching technical services by name and a Settings icon that allows changing the table settings to show or hide pre-selected columns. ::: The table view also supports detailed views for each technical service. To access details for a specific technical service, Click the overflow menu to the far right of the table and select View Details. For more information, see [Deploy dashboard table view details](docId\:CuaRWSj_nIJgnGwgEaR2l). You can access the cluster for a specific deployment by selecting its row within the Deployments table; also, by selecting the overflow menu on a deployment that has a cluster data point associated. The option **Go to CCM** will allow you to navigate directly to the Pod Namespace of that specific deployment and its details within the Container Cluster Management application, if you select **Back to **&#xNAN;**,** you will be redirected to application. [title] Test dashboard table view details [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Untitled/ A new dialog appears with technical service details when you click on a technical service from the table view. The following elements are displayed in the dialog the table calls: | **Element name** | **Description** | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Test detail | Details including the name of the technical service in question. | | Tool Engine | Name and URL that will navigate when selected to the tool engine to check additional details and the **Test Type**. | | Activity | The Activity tab introduces two widgets with bar graphs that present different data about Tests. The widgets are described as follows:
* **Test status** represents the total of all tests executed for the selected period. The Test Status bar graph provides data for **Passed** Tests within a specific timeframe. The Test Status graph presents two axes that represent data described as follows: - **The X-Axis (Duration):** The X-axis corresponds to the timeframe in which tests took place. By hovering over the graph, as well as by placing the cursor right above a bar, in alignment with the center of it, the following data is presented: - **Group:** Corresponds to the Unit Tests group. - **Range:** Date of the execution of the tests. - **Value:** A total number of tests executed in a determined timeframe. - **Y-Axis (Total Tests):** The Y-axis corresponds to the total number of Tests that passed for the selected timeframe. * **Test duration** represents the average duration for all tests executed for the selected timeframe. The Test Duration graph presents two axes that represent data described as follows: - **The X-Axis (Duration):** The X-axis corresponds to the timeframe in which tests took place. By hovering over the graph, the following data is displayed: - **Group:** Corresponds to the Unit Tests group. - **Range:** Date of the execution of the tests. - **Value:** A total number of tests executed in a determined timeframe. - **Y-Axis (Execution Duration Average in Seconds):** The Y-axis corresponds to the total execution time for Tests measured in seconds. | | Historical details |
The **Historical details** the tab provides details about **Test executions**. The data is presented in a tabular form, and each row in the table displays information for a specific technical service, separated by columns of information type:
* **Execution date:** The date and time when the Test was executed. * **Failed:** The total number and percentage of Tests in the Failed category or group. * **Skipped:** The total number and percentage of Tests in the Skipped category or group. * **Passed:** The total number and percentage of Tests in the Passed category or group. * **Total:** The total number of Tests. * **Code smells:** The amount of code that possibly indicates a deeper problem. * **Bugs:** The number of Bugs found in the code. * **Release:** Release that is associated with the executed tests. * **Environment:** An instance of the application where tests were executed. * **Duration:** The total time a Test took to be executed. | | Timeframe | To later select activity or historical details, select one of the following timeframes:
* **1D** (1 Day, last 24 hours) * **7D** (Last 7 Days) * **14D** (Last 14 Days) * **2M** (Last 2 Months) * **3M** (Last 3 Months) * **6M** (Last 6 Months) * **Custom duration** (A custom date range within 6 months) | :::hint{type="info"} The **Test executions** the table displays data regardless of the timeframe selected. All columns in this table can be sorted and above this table, you will find a **Settings**  icon that allows changing the table settings to show or hide pre-selected columns ::: [title] Consultations [path] Catalogs/Bridge Service Catalog/ Consultations allow you to understand the benefits of a particular service with the help of Kyndryl representatives. If you need additional information from a sales representative, you can schedule a consultation at your preferred time. This is a 30-minute session where you can discuss and determine if the service you selected is the most suitable solution for your environment. # Book a consultation 1. From the page, select the service of your interest. 2. Select **Schedule a Consultation**. 3. Enter the following details: - **Title**: Enter a meaningful title to describe your request. - **Service Category**: Select a category, if not already selected. - **Service Name**: Select a service, if not already selected. - **(Optional) Service Package:** Select a service from the dropdown list. This option might not be visible for all services, as not all of them include a service package. - **Consultation Subject**: Select the type of inquiry you have regarding the service. You can select multiple options: - Pricing - Subscription - Configuration - About Services - Billing and Quotation - Others 4. **Description: **Enter additional details you want to know during the consultation. This is a mandatory field. 5. **Call Type:** Select the communication type. This is a mandatory field. - Video call - Voice call 6. **Meeting Date:** Select an available date from the calendar. 7. **Time Range:** Select the time frame where you would prefer to be contacted. This is a 3-hour time slot. 8. Select **Continue**. 9. Review the information entered. If required, select **Edit Consultation Details** to change or add additional details. Otherwise, select **Submit Request**. You will be redirected to the **Console Consultations** page. An email will also be sent confirming this request. For more information, see [Managing consultations](docId\:paFmnpB2enJxyEjYDFtBU). [title] Roles and permissions [path] Administration/Bridge Access Management/Roles/ services permissions enable Administrators to select specific permissions used to create custom roles, allowing users to have designated actions and permissions for specific services based on the authorization model. # System settings System permissions control access to service broker repositories, service broker settings and issue management capabilities. These permissions allow administrators to view, create, update and delete service broker configurations and support issues as needed. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------- | | feedback.brokers-repos.view | Allow to view service broker repos | Administrator | | feedback.brokers-settings.create | Allow to create service broker settings | Administrator | | feedback.brokers-settings.delete | Allow to delete existing service broker settings | Administrator | | feedback.brokers-settings.update | Allow to update existing service broker settings | Administrator | | feedback.brokers-settings.view | Allow to view service broker settings | Administrator | | feedback.issues.create | Allow to create issue | Administrator | | feedback.issues.delete | Allow to delete existing issue | Administrator | | feedback.issues.update | Allow to update existing issue | Administrator | | feedback.issues.view | Allow to view issues | Administrator | # ## User invitations Organization Management permissions control access to organization and invitation management capabilities. These permissions allow users to create and view organizations, invite and manage users, resend or update invitations, reinvite account owners and perform administrative actions based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | accounts.user.reinvite | Allow to reinvite the account initial user | - Administrator - Editor | | iam.invitations.create | Allow to create invitations | Administrator | | iam.invitations.delete | Allow to delete invitations | * Administrator * Editor | | iam.invitations.resend | Allow to resend pending invitations | - Administrator - Editor | | iam.invitations.update | Allow to update invitations | * Administrator * Editor | | iam.invitations.view | Allow to view invitations | - Administrator - Editor | | iam.organization.bulkdelete | Allow to delete multiple organizations | * Administrator * Editor | | iam.organization.create | Allow to create new organization | - Administrator - Operator - Viewer | | iam.organization.invite | Allow to invite new user to an organization | * Administrator * Editor | | iam.organization.view | Allow to view an organization | - Administrator - Editor | ## Resources and users Resources and users permissions control access to resource, resource group, user group and user management capabilities. These permissions allow users to view resource-related information and manage users, user mappings and user lifecycle operations based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------------- | ------------------------------------------------- | | iam.resourceattributes.view | Allow to view resources | - Administrator - Editor - Operator - Viewer | | iam.resourceattributesvalues.view | Allow to view resources attribute values | * Administrator * Editor * Operator * Viewer | | iam.resourcegroups.view | Allow to view resource groups | - Administrator - Editor - Operator - Viewer | | iam.usergroups.view | Allow to view user groups | * Administrator * Editor * Operator * Viewer | | iam.usermapping.update | Allow to update user mapping assertions | - Administrator - Editor | | iam.users-lastoperation.view | Allow to view last operation performed for an user | * Administrator * Editor | | iam.users.bulkdelete | Allow to delete multiple users | - Administrator - Editor | | iam.users.create | Allow to create the users | Administrator | | iam.users.delete | Allow to delete the users | * Administrator * Editor | | iam.users.update | Allow to update the users | - Administrator - Editor | | iam.users.view | Allow to view the users | * Administrator * Editor | ## Account, roles and permissions These permissions govern access to account administration, role management, broker configuration and related resources. These permissions enable users to create, modify, view, and manage accounts, custom roles, brokers, catalogs and business services based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ------------------------------------------------------------------ | ------------------------------------------------- | | fileserver.files.view | Allow to view files | - Administrator - Editor - Operator - Viewer | | iam.accounts.create | Allow to create a new account | Administration | | iam.accounts.delete | Allow to delete accounts | * Administrator * Editor | | iam.accounts.update | Allow to update an account | - Administrator - Editor | | iam.accounts.revoke | Allow to revoke one or more user access from the logged in account | * Administrator | | iam.accounts.view | Allow to view accounts | - Administrator - Editor - Operator - Viewer | | iam.brokers.delete | Allow to delete broker | * Administrator * Editor | | iam.brokers.register | Allow to register new broker | - Administrator - Editor | | iam.brokers.test | Allow to test brokers | * Administrator * Editor * Operator * Viewer | | iam.brokers.view | Allow to view brokers | - Administrator - Editor - Operator - Viewer | | iam.businessservices.view | Allow to view business services | * Administrator * Editor * Operator * Viewer | | iam.catalogs.view | Allow to view catalogs | - Administrator - Editor - Operator - Viewer | | iam.customrole.create | Allow to create a custom role | Administrator | | iam.customrole.delete | Allow to delete a custom role | * Administrator * Editor | | iam.customrole.update | Allow to update a custom role | - Administrator - Editor | | iam.customrole.view | Allow to view custom roles | * Administrator * Editor * Operator * Viewer | ## Service IDs Service ID permissions control access to Service ID management capabilities. These permissions allow users to create, update, delete and view Service IDs used for authentication and service-to-service interactions, based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.serviceids.create | Allow to create serviceids | Administrator | | iam.serviceids.delete | Allow to delete serviceids | - Administrator - Editor | | iam.serviceids.update | Allow to update serviceids | * Administrator * Editor | | iam.serviceids.view | Allow to view serviceids | - Administrator - Editor - Operator - Viewer | ## SMTP SMTP permissions control access to email configuration and SAML service provider metadata. These permissions allow users to manage SMTP settings for email communications and view SAML SP metadata required for identity federation and authentication, based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.smtp.create | Allow to create smtp config | Administrator | | iam.smtp.delete | Allow to delete smtp config | - Administrator - Editor | | iam.smtp.view | Allow to view smtp config | * Administrator * Editor * Operator * Viewer | | iam.spmetadata.view | Allow to view SAML SP metadata | - Administrator - Editor - Operator - Viewer | ## IdP IdP (Identity Provider) permissions control access to identity provider configuration and federation settings. These permissions allow users to view metadata, create, update, delete and manage identity providers used for authentication and single sign-on (SSO), based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ----------------------------------------------- | ------------------------------------------------- | | iam.idp-metadata.view | Allow to view identity provider metadata | - Administrator - Editor - Operator - Viewer | | iam.idp.create | Allow to create identity provider | Administrator | | iam.idp.delete | Allow to delete identity provider | * Administrator * Editor | | iam.idp.replace | Allow to replace fields of an identity provider | - Administrator - Editor | | iam.idp.update | Allow to update an identity provider | * Administrator * Editor | | iam.idp.view | Allow to view an identity provider | - Administrator - Editor - Operator - Viewer | ## API keys, key values and tokens These permissions control access to authentication credentials and configuration data used across the platform. These permissions allow users to create, manage, update, delete and view API keys, tokens, and key-value pairs based on their assigned role, supporting secure access and service integration. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.apikeys.create | Allow to create api keys | - Administrator - Editor - Operator - Viewer | | iam.apikeys.delete | Allow to delete existing api keys | * Administrator * Editor * Operator | | iam.apikeys.manage | Allow to manage api keys | - Administrator - Editor | | iam.apikeys.replace | Allow to replace existing api keys | * Administrator * Editor * Operator * Viewer | | iam.apikeys.update | Allow to patch existing api keys | - Administrator - Editor - Operator - Viewer | | iam.apikeys.view | Allow to view api keys | * Administrator * Editor * Operator * Viewer | | iam.tokens.create | Allow to create a token | Administrator | | iam.tokens.delete | Allow to delete a token | - Administrator - Editor | | iam.tokens.replace | Allow to replace a token | * Administrator * Editor | | iam.tokens.update | Allow to update a token | - Administrator - Editor | | iam.tokens.view | Allow to view tokens | * Administrator * Editor * Operator * Viewer | | iam.keyvalues.create | Allow to add key-value | Administrator | | iam.keyvalues.delete | Allow to delete key-value | - Administrator - Editor | | iam.keyvalues.update | Allow to update key-value | * Administrator * Editor | | iam.keyvalues.view | Allow to view key-value | - Administrator - Editor - Operator - Viewer | ## Access tags Access Tags permissions control access to the management of access tags used to organize and govern access across the platform. These permissions allow users to create, update, delete and view access tags based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.accesstags.create | Allow to add accesstags | Administrator | | iam.accesstags.delete | Allow to delete accesstags | - Administrator - Editor | | iam.accesstags.update | Allow to update accesstags | * Administrator * Editor * Operator | | iam.accesstags.view | Allow to view accesstags | - Administrator - Editor - Operator - Viewer | | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.accesstags.create | Allow to add accesstags | Administrator | | iam.accesstags.delete | Allow to delete accesstags | - Administrator - Editor | | iam.accesstags.update | Allow to update accesstags | * Administrator * Editor * Operator | | iam.accesstags.view | Allow to view accesstags | - Administrator - Editor - Operator - Viewer | ## Access groups and access policies Access Groups and Access Policies permissions control the management of access groups, group membership, access rules and authorization policies. These permissions allow users to create, modify, delete and view access groups and policies, manage group members and rules and control access governance based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | iam.accessgroups-members.add | Allow to add members to access group | - Administrator - Editor | | iam.accessgroups-members.delete | Allow to delete accessgroup member | * Administrator * Editor | | iam.accessgroups-members.view | Allow to view access group members | - Administrator - Editor | | iam.accessgroups-rules.add | Allow to add rules to access group | * Administrator * Editor | | iam.accessgroups-rules.delete | Allow to delete access group rules | - Administrator - Editor | | iam.accessgroups-rules.view | Allow to view access group rules | * Administrator * Editor * Operator * Viewer | | iam.accessgroups.create | Allow to create accessgroup | Administrator | | iam.accessgroups.delete | Allow to delete accessgroup | - Administrator - Editor | | iam.accessgroups.update | Allow to update access group | * Administrator * Editor * Operator | | iam.accessgroups.view | Allow to view access groups | - Administrator - Editor - Operator - Viewer | | iam.authzpolicy.create | Allow to create new authorization policies | Administrator | | iam.authzpolicy.delete | Allow to delete authorization policies | * Administrator * Editor | | iam.authzpolicy.update | Allow to update authorization policies | - Administrator - Editor | | iam.authzpolicy.view | Allow to view authorization policies | * Administrator * Editor * Operator * Viewer | | iam.policies.view | Allow to view policies | - Administrator - Editor - Operator - Viewer | # Connections, Notifications and Metering These permissions control access to connection management, notification configuration, and usage monitoring capabilities. These permissions allow users to create, test, update and view connections; manage notification settings, templates and in-app notifications; and access metering data, usage reports and tenant consumption details based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ------------------------------------------------------- | ------------------------------------------------- | | iam.connections.create | Allow to create connections | Administrator | | iam.connections.delete | Allow to delete connections | - Administrator - Editor | | iam.connections.test | Allow to test connections | * Administrator * Editor * Operator * Viewer | | iam.connections.update | Allow to update connections | - Administrator - Editor | | iam.connections.view | Allow to view connections | * Administrator * Editor * Operator * Viewer | | metering.brokersusage.view | Allow to view service broker usage | - Administrator - Editor - Operator - Viewer | | metering.meter.view | Allow to view metering details | * Administrator * Editor * Operator * Viewer | | metering.resetcosa.create | Allow to reset cosa state | - Administrator - Editor - Operator - Viewer | | metering.tenantmeter.view | Allow to view tenant specific metering details | * Administrator * Editor * Operator * Viewer | | metering.tenantsusage.view | Allow to view tenant specific metering usage | - Administrator - Editor - Operator - Viewer | | metering.usage.download | Allow to download metering data | * Administrator * Editor * Operator * Viewer | | metering.usage.view | Allow to view metering usage | - Administrator - Editor - Operator - Viewer | | notification.emailsettings.create | Allow to create notification emailsettings | * Administrator * Editor * Operator * Viewer | | notification.emailsettings.delete | Allow to delete notification emailsettings | - Administrator - Editor - Operator - Viewer | | notification.emailsettings.update | Allow to update notification emailsettings | * Administrator * Editor * Operator * Viewer | | notification.emailsettings.view | Allow to view notification emailsettings | - Administrator - Editor - Operator - Viewer | | notification.inapp.create | Allow to create inapp notification | * Administrator * Editor * Operator * Viewer | | notification.inapp.delete | Allow to delete inapp notification | - Administrator - Editor - Operator - Viewer | | notification.inapp.update | Allow to update inapp notification | * Administrator * Editor * Operator * Viewer | | notification.inapp.view | Allow to view inapp notification | - Administrator - Editor - Operator - Viewer | | notification.template.create | Allow to create notification template | * Administrator * Editor * Operator * Viewer | | notification.template.delete | Allow to delete notification template | - Administrator - Editor - Operator - Viewer | | notification.template.put | Allow to put notification template | * Administrator * Editor * Operator * Viewer | | notification.template.update | Allow to update notification template | - Administrator - Editor - Operator - Viewer | | notification.template.view | Allow to view notification template | * Administrator * Editor * Operator * Viewer | | security.connections.create | Allow to create connections | - Administrator - Operator | | security.connections.delete | Allow to delete connections | * Administrator * Editor * Operator | | security.connections.link | Allow to link shared connections | - Administrator - Editor - Operator | | security.connections.replace | Allow to replace connections | * Administrator * Editor * Operator | | security.connections.test | Allow to test connections | - Administrator - Editor - Operator | | security.connections.update | Allow to update connections | * Administrator * Editor * Operator | | security.connections.view | Allow to view connections | - Administrator - Editor - Operator - Viewer | | security.connectionstatus.view | Allow to get test connection status | * Administrator * Editor * Operator * Viewer | | security.connectiontypes.create | Allow to add/update connectiontypes for a client tenant | Administrator | | security.connectiontypes.delete | Allow to delete connection types for a client tenant | - Administrator - Editor | | security.connectiontypes.view | Allow to view connectiontypes for a client tenant | * Administrator * Editor | # Tenant settings Tenant Settings permissions control access to tenant administration, configuration, identity management, invitations, entitlements and operational settings. These permissions allow users to manage tenant properties, roles, identity providers, OIDC applications, invitations, feature flags and other tenant-level resources, while also providing visibility into tenant activity, settings and configuration details based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------------------------- | | iam.tenant-activitylogs.view | Allow to view activity logs for a tenant | - Administrator - Editor - Operator - Viewer | | iam.tenant-entitlements.update | Allow to update tenant entitlements | * Administrator * Editor | | iam.tenant-entitlements.view | Allow to view tenant entitlements | - Administrator - Editor | | iam.tenant-membership.add | Allow to add the tenant level roles of the users | * Administrator * Editor | | iam.tenant-membership.remove | Allow to remove the tenant level roles of the users | - Administrator - Editor | | iam.tenant-opssettings.view | Get Ops Settings | * Administrator * Editor | | iam.tenant-owner.update | Allow to update tenant owner | - Administrator - Editor | | iam.tenant-settings.update | Allow to update tenant settings | * Administrator * Editor | | iam.tenant-settings.view | Allow to view tenant settings | - Administrator - Editor - Operator - Viewer | | iam.tenant.bindinginfo.view | Allow to view binding info | * Administrator * Editor | | iam.tenant.create | Allow to create new tenant | Administrator | | iam.tenant.delete | Allow to delete a tenant | - Administrator - Editor | | iam.tenant.modify | Allow to modify a tenant | * Administrator * Editor | | iam.tenant.update | Allow to update a tenant | - Administrator - Editor | | iam.tenant.view | Allow to view tenants | * Administrator * Editor * Operator * Viewer | | iam.tenantidp.create | Allow to create tenant manager level identity provider | Administrator | | iam.tenantidp.delete | Allow to delete tenant manager level identity provider | - Administrator - Editor | | iam.tenantidp.replace | Allow to replace fields of tenant manager level identity provider | * Administrator * Editor | | iam.tenantidp.update | Allow to update fields of tenant manager level identity provider | - Administrator - Editor | | iam.tenantidp.view | Allow to view tenant manager level identity provider | * Administrator * Editor * Operator * Viewer | | iam.tenants-globalfeatureflags.update | Allow to update tenant featureflags | - Administrator - Editor | | iam.tenants-opssettings.update | Allow to update tenant opssettings | * Administrator * Editor | | iam.tenants-opssettings.view | Allow to view tenant opssettings | - Administrator - Editor - Operator - Viewer | | iam.tm-invitations.create | Allow to create tenant manager level invitations | Administrator | | iam.tm-invitations.delete | Allow to delete tenant manager level invitations | * Administrator * Editor | | iam.tm-invitations.update | Allow to update tenant manager invitations | - Administrator - Editor | | iam.tm-invitations.view | Allow to view tenant manager level invitations | * Administrator * Editor | | iam.dcphost.view | Allow to retrive the dcp base host based on region | - Administrator - Editor - Operator - Viewer | | iam.delegatedtoken.create | Allow to create delegated token | Administrator | | iam.dns.view | Allow to view dns | * Administrator * Editor * Operator * Viewer | | iam.domains.view | Allow to view domains | - Administrator - Editor - Operator - Viewer | | iam.globalidp.view | Allow to view global identity providers | * Administrator * Editor * Operator * Viewer | | iam.identity.unlink | Allow to unlink the user identity | - Administrator - Editor | | iam.oidcapp.create | Allow to create OIDC application | Administrator | | iam.oidcapp.delete | Allow to delete OIDC application | * Administrator * Editor | | iam.oidcapp.replace | Allow to replace OIDC application | - Administrator - Editor | | iam.oidcapp.update | Allow to update OIDC application | * Administrator * Editor | | iam.oidcapp.view | Allow to view OIDC application | - Administrator - Editor - Operator - Viewer | # Audit Audit permissions control access to audit records and audit management capabilities. These permissions allow users to view, download and manage audit information, providing visibility into system activities and supporting compliance, governance and operational monitoring based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | audit.records.download | Allow to download audit records | - Administrator - Editor | | audit.records.view | Allow to view audit records | * Administrator * Editor | | iam.audit.delete | Allow to delete audit | - Administrator - Editor | | iam.audit.replace | Allow to replace audit | * Administrator * Editor | | iam.audit.view | Allow to view audit | - Administrator - Editor - Operator - Viewer | # Security Security permissions control access to connection management, Vault configuration, and connection metadata. These permissions allow users to create, update, test, view and delete secure connections, manage Vault configurations through APIs and access connection metadata required for secure integration and credential management based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | security.connections.create | Allow to create connections | Administrator | | security.connections.delete | Allow to delete connections | Administrator | | security.connections.update | Allow to update connections | Administrator | | security.connections.view | | Administrator
Viewer | | security.connections.test | Allow to test connections | Administrator
Viewer | | security.vaultconfig.create | Allow to create Vault Config \[Only API] | Administrator | | security.vaultconfig.delete | Allow to delete Vault Config \[Only API] | Administrator | | security.vaultconfig.view | Allow to view Vault Config \[Only API] | Administrator | | security.connectionstypes.view | Allow to view connections metadata | Viewer | # Discovery Management Discovery Management permissions control access to inventory resources, discovery records, actions, locations, categories and tags. These permissions allow users to view discovery data, execute and manage actions, access inventory information and manage resource tags, based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------- | | common-discovery.account.view | Allow to view inventory accounts | - Administrator - Editor - Operator - Viewer | | common-discovery.actions.admin | Allow to onboard actions | Administrator | | common-discovery.actions.execute | Allow to execute actions | * Administrator * Operator | | common-discovery.actions.view | Allow to view inventory actions | - Administrator - Editor - Operator - Viewer | | common-discovery.category.view | Allow to view inventory records' category | * Administrator * Editor * Operator * Viewer | | common-discovery.location.view | Allow to view inventory records' location | - Administrator - Editor - Operator - Viewer | | common-discovery.service.view | Allow to view inventory records | * Administrator * Editor * Operator * Viewer | | common-discovery.tags.edit | Allow to edit/add/delete inventory resources tags | - Administrator - Editor | | common-discovery.tags.view | Allow to view import tags jobs for inventory resources | * Administrator * Editor | # Actions **T**hese permission**s **control access to the Action Registry and action management capabilities. These permissions allow users to view, create, update and manage action categories, definitions, providers, policies, requests, statistics, support resources and action types, as well as onboard and administer actions based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | actions.action\_category.view | Allow to perform view operation on action category | - Administrator - Editor - Operator - Viewer - Action viewer - Action Registry Admin | | actions.action\_definition.view | Allow to perform view operation on action definition | * Administrator * Editor * Operator * Viewer * Action viewer * Action Registry Admin | | actions.action\_policy.view | Allow to perform view operation on action policy | - Administrator - Editor - Operator - Viewer - Action viewer - Action Registry Admin | | actions.action\_provider.view | Allow to perform view operation on action provider | * Administrator * Editor * Operator * Viewer * Action viewer * Action Registry Admin | | actions.action\_request.view | Allow to perform view operation on action request | - Administrator - Editor - Operator - Viewer - Action viewer - Action Registry Admin | | actions.action\_stats.view | Allow to perform view operation on action stats | * Administrator * Editor * Operator * Viewer * Action viewer * Action Registry Admin | | actions.action\_support.view | Allow to perform view operation on action support | - Administrator - Editor - Operator - Viewer - Action viewer - Action Registry Admin | | actions.action\_types.view | Allow to perform view operation on action type | * Administrator * Editor * Operator * Viewer * Action viewer * Action Registry Admin | | actions.action\_category.crud | Allow to perform crud operation on action category | - Administrator - Editor - Action Registry Admin | | actions.action\_definition.crud | Allow to perform crud operation on action definition | * Administrator * Editor * Action Registry Admin | | actions.action\_engine\_api\_manager.crud | Allow to perform crud operation on action enginer api manager | - Administrator - Editor - Action Registry Admin | | actions.action\_engine\_practitioner.crud | Allow to perform crud operation on action engine practitioner | * Administrator * Editor * Action Registry Admin | | actions.action\_onboarding.crud | Allow to perform crud operation on action onboarding | - Administrator - Editor - Action Registry Admin | | actions.action\_policy.crud | Allow to perform crud operation on action policy | * Administrator * Editor * Action Registry Admin | | actions.action\_provider.crud | Allow to perform crud operation on action provider | - Administrator - Editor - Action Registry Admin | | actions.action\_request.crud | Allow to perform crud operation on action request | * Administrator * Editor * Action Registry Admin | | actions.action\_stats.crud | Allow to perform crud operation on action stats | - Administrator - Editor - Action Registry Admin | | actions.action\_support.crud | Allow to perform crud operation on action support | * Administrator * Editor * Action Registry Admin | | actions.action\_types.crud | Allow to perform crud operation on action types | - Administrator - Editor - Action Registry Admin | # Topology Topology permissions control access to topology, impact analysis, metadata and tag information. These permissions allow users to view resource relationships, dependency mappings, impact analysis data, topology metadata and associated tags, helping them understand and analyze the structure and connections of managed resources based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | topology.impactanalysis-data.view | Allow to view impactanalysis | - Administrator - Editor - Operator - Viewer | | topology.topology-data.view | Allow to view topology data | * Administrator * Editor * Operator * Viewer | | topology.topology-metadata.view | Allow to view topology metadata | - Administrator - Editor - Operator - Viewer | | topology.topology-tags.view | Allow to view topology tags | * Administrator * Editor * Operator * Viewer | # control access to cluster monitoring, discovery, insights, custom views, geolocation data, metrics, alerts, logs and Kubernetes resource management. These permissions allow users to view cluster health and performance information, manage Kubernetes resources, access operational insights and administer containerized workloads across managed clusters based on their assigned role. | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------------------------- | ------------------------------------------------- | | ccm.cluster-alerts.view | Allow to view alerts of a cluster | - Administrator - Editor - Operator - Viewer | | ccm.cluster-data.view | Allow to view cluster data | * Administrator * Editor * Operator * Viewer | | ccm.cluster.view | Allow to view cluster | - Administrator - Editor - Operator - Viewer | | ccm.clusters-alerts.view | Allow to view alerts of all clusters | * Administrator * Editor * Operator * Viewer | | ccm.clusters.view | Allow to view clusters | - Administrator - Editor - Operator - Viewer | | ccm.custom-views.create | Allow to create custom views | * Administrator * Editor * Operator * Viewer | | ccm.custom-views.delete | Allow to delete custom views | - Administrator - Editor - Operator - Viewer | | ccm.custom-views.update | Allow to update custom views | * Administrator * Editor * Operator * Viewer | | ccm.custom-views.view | Allow to view custom views | - Administrator - Editor - Operator - Viewer | | ccm.discovery-clusters.view | Allow to view discovery clusters | * Administrator * Editor * Operator * Viewer | | ccm.geo-locations.delete | Allow to delete geographical locations for clusters | - Administrator - Editor - Operator - Viewer | | ccm.geo-locations.edit | Allow to edit geographical locations for clusters | * Administrator * Editor * Operator * Viewer | | ccm.geo-locations.view | Allow to view geographical locations for clusters | - Administrator - Editor - Operator - Viewer | | ccm.geolocation-aggregates.view | Allow to view cluster geolocation aggregates | * Administrator * Editor * Operator * Viewer | | ccm.insights-recommendations.view | Allow to view Insights recommendations | - Administrator - Editor - Operator - Viewer | | ccm.kubernetes-clusterrole.create | Allow to create Kubernetes resource - ClusterRole | * Administrator * Editor * Operator | | ccm.kubernetes-clusterrole.delete | Allow to delete Kubernetes resource - ClusterRole | Administrator | | ccm.kubernetes-clusterrolebinding.create | Allow to create Kubernetes resource - ClusterRoleBinding | - Administrator - Editor - Operator | | ccm.kubernetes-clusterrolebinding.delete | Allow to delete Kubernetes resource - ClusterRoleBinding | Administrator | | ccm.kubernetes-configmap.create | Allow to create Kubernetes resource - ConfigMap | * Administrator * Editor * Operator | | ccm.kubernetes-configmap.delete | Allow to delete Kubernetes resource - ConfigMap | Administrator | | ccm.kubernetes-cronjob.create | Allow to create Kubernetes resource - CronJob | - Administrator - Editor - Operator | | ccm.kubernetes-cronjob.delete | Allow to delete Kubernetes resource - CronJob | Administrator | | ccm.kubernetes-customresourcedefinition.create | Allow to create Kubernetes resource - CustomResourceDefinition | * Administrator * Editor * Operator | | ccm.kubernetes-customresourcedefinition.delete | Allow to delete Kubernetes resource - CustomResourceDefinition | Administrator | | ccm.kubernetes-daemonset.create | Allow to create Kubernetes resource - DaemonSet | - Administrator - Editor - Operator | | ccm.kubernetes-daemonset.delete | Allow to delete Kubernetes resource - DaemonSet | Administrator | | ccm.kubernetes-deployment.create | Allow to create Kubernetes resource - Deployment | * Administrator * Editor * Operator | | ccm.kubernetes-deployment.delete | Allow to delete Kubernetes resource - Deployment | Administrator | | ccm.kubernetes-endpoints.create | Allow to create Kubernetes resource - Endpoints | - Administrator - Editor - Operator | | ccm.kubernetes-endpoints.delete | Allow to delete Kubernetes resource - Endpoints | Administrator | | ccm.kubernetes-endpointslice.create | Allow to create Kubernetes resource - EndpointSlice | * Administrator * Editor * Operator | | ccm.kubernetes-endpointslice.delete | Allow to delete Kubernetes resource - EndpointSlice | Administrator | | ccm.kubernetes-horizontalpodautoscaler.create | Allow to create Kubernetes resource - HorizontalPodAutoscaler | - Administrator - Editor - Operator | | ccm.kubernetes-horizontalpodautoscaler.delete | Allow to delete Kubernetes resource - HorizontalPodAutoscaler | Administrator | | ccm.kubernetes-ingress.create | Allow to create Kubernetes resource - Ingress | * Administrator * Editor * Operator | | ccm.kubernetes-ingress.delete | Allow to delete Kubernetes resource - Ingress | Administrator | | ccm.kubernetes-job.create | Allow to create Kubernetes resource - Job | - Administrator - Editor - Operator | | ccm.kubernetes-job.delete | Allow to delete Kubernetes resource - Job | Administrator | | ccm.kubernetes-limitrange.create | Allow to create Kubernetes resource - LimitRange | * Administrator * Editor * Operator | | ccm.kubernetes-limitrange.delete | Allow to delete Kubernetes resource - LimitRange | Administrator | | ccm.kubernetes-namespace.create | Allow to create Kubernetes resource - Namespace | - Administrator - Editor - Operator | | ccm.kubernetes-namespace.delete | Allow to delete Kubernetes resource - Namespace | Administrator | | ccm.kubernetes-networkpolicy.create | Allow to create Kubernetes resource - NetworkPolicy | * Administrator * Editor * Operator | | ccm.kubernetes-networkpolicy.delete | Allow to delete Kubernetes resource - NetworkPolicy | Administrator | | ccm.kubernetes-persistentvolume.create | Allow to create Kubernetes resource - PersistentVolume | - Administrator - Editor - Operator | | ccm.kubernetes-persistentvolume.delete | Allow to delete Kubernetes resource - PersistentVolume | Administrator | | ccm.kubernetes-persistentvolumeclaim.create | Allow to create Kubernetes resource - PersistentVolumeClaim | * Administrator * Editor * Operator | | ccm.kubernetes-persistentvolumeclaim.delete | Allow to delete Kubernetes resource - PersistentVolumeClaim | Administrator | | ccm.kubernetes-pod.create | Allow to create Kubernetes resource - Pod | - Administrator - Editor - Operator | | ccm.kubernetes-pod.delete | Allow to delete Kubernetes resource - Pod | Administrator | | ccm.kubernetes-poddisruptionbudget.create | Allow to create Kubernetes resource - PodDisruptionBudget | * Administrator * Editor * Operator | | ccm.kubernetes-poddisruptionbudget.delete | Allow to delete Kubernetes resource - PodDisruptionBudget | Administrator | | ccm.kubernetes-priorityclass.create | Allow to create Kubernetes resource - PriorityClass | - Administrator - Editor - Operator | | ccm.kubernetes-priorityclass.delete | Allow to delete Kubernetes resource - PriorityClass | Administrator | | ccm.kubernetes-replicaset.create | Allow to create Kubernetes resource - ReplicaSet | * Administrator * Editor * Operator | | ccm.kubernetes-replicaset.delete | Allow to delete Kubernetes resource - ReplicaSet | Administrator | | ccm.kubernetes-resource-types.view | Allow to view Kubernetes resource types list | - Administrator - Editor - Operator - Viewer | | ccm.kubernetes-resourcequota.create | Allow to create Kubernetes resource - ResourceQuota | * Administrator * Editor * Operator | | ccm.kubernetes-resourcequota.delete | Allow to delete Kubernetes resource - ResourceQuota | Administrator | | ccm.kubernetes-role.create | Allow to create Kubernetes resource - Role | - Administrator - Editor - Operator | | ccm.kubernetes-role.delete | Allow to delete Kubernetes resource - Role | Administrator | | ccm.kubernetes-rolebinding.create | Allow to create Kubernetes resource - RoleBinding | * Administrator * Editor * Operator | | ccm.kubernetes-rolebinding.delete | Allow to delete Kubernetes resource - RoleBinding | Administrator | | ccm.kubernetes-secret.create | Allow to create Kubernetes resource - Secret | - Administrator - Editor - Operator | | ccm.kubernetes-secret.delete | Allow to delete Kubernetes resource - Secret | Administrator | | ccm.kubernetes-service.create | Allow to create Kubernetes resource - Service | * Administrator * Editor * Operator | | ccm.kubernetes-service.delete | Allow to delete Kubernetes resource - Service | Administrator | | ccm.kubernetes-serviceaccount.create | Allow to create Kubernetes resource - ServiceAccount | - Administrator - Editor - Operator | | ccm.kubernetes-serviceaccount.delete | Allow to delete Kubernetes resource - ServiceAccount | Administrator | | ccm.kubernetes-statefulset.create | Allow to create Kubernetes resource - StatefulSet | * Administrator * Editor * Operator | | ccm.kubernetes-statefulset.delete | Allow to delete Kubernetes resource - StatefulSet | Administrator | | ccm.kubernetes-storageclass.create | Allow to create Kubernetes resource - StorageClass | - Administrator - Editor - Operator | | ccm.kubernetes-storageclass.delete | Allow to delete Kubernetes resource - StorageClass | Administrator | | ccm.pod-logs.download | Allow to download pod logs | * Administrator * Editor * Operator * Viewer | | ccm.prometheus-alerts.view | Allow to view cluster alerts | - Administrator - Editor - Operator - Viewer | | ccm.prometheus-node-metrics.view | Allow to view cluster node-metrics | * Administrator * Editor * Operator * Viewer | | ccm.prometheus-pod-metrics.view | Allow to view cluster pod-metrics | - Administrator - Editor - Operator - Viewer | | ccm.prometheus-stats.view | Allow to view cluster stats | * Administrator * Editor * Operator * Viewer | | ccm.provider-aggregates.view | Allow to view cluster provider aggregates | - Administrator - Editor - Operator - Viewer | # Feature flags Feature Flags permissions control access to the creation and management of feature flags used to enable, disable and control platform functionality. These permissions allow users to create, view, enable, disable and delete feature flags based on their assigned platform role. | ******Permission name****** | ******Description****** | ******Roles Related****** **to****** | | -------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | platform.featureflags.create | Allow to create feature flags | Platform Administrator | | platform.featureflags.delete | Allow to delete feature flags | Platform Administrator | | platform.featureflags.disable | Allow to disable feature flags | Platform Administrator | | platform.featureflags.enable | Allow to enable feature flags | Platform Administrator | | platform.featureflags.view | Allow to enable feature flags | Platform AdministratorPlatform Viewer | [title] Tool Chain Management user interface [path] Catalogs/Tool Chain Management/ Navigate and understand the user interface to optimize your use of the service. The landing page contains a list of all the applications that have been configured for the service. The page includes the following elements: - **Bread Crumbs: **Observe the convenient navigation guide. - **Header:** Understand your location within the Service . - **Search bar:** Type the first few characters of a configured application name to return a list of matching application names. - **Filter:** Click to display a list configured applications and select those you want to view without the distraction of the full list of applications. - **+ Configure New Application:** Click to configure a new application, associating specific tools with DevOps phases of one or more services. - **Configured Applications table: **Review the list of applications (rows) and the following data regarding them (columns): - **Application Name:** The unique identifier provided by the user configuring the application. - **Created by:** The username of the user who created the application. - **Last Updated:** The date and time the data was last updated. - **Last Status Refresh:** The date and time the health (status) of the service (application) was reported. ## applications An application in refers to a service, in your IT estate, that is supported by a specific collection of tools for each phase of the DevOps lifecycle. Each application in the table can be expanded to expose the eight phases of the DevOps lifecycle displaying the tools your team uses to support the service in each of those phases. Example: You have access to *Universal Workflow*, a microservice provisioned by your DevOps team. The team uses the following tools to support the service at each phase: - **Plan:** Azure Boards - **Develop:** GitHub - **Build:** GitHub Actions and Jfrog Aritifactory - **Secure:** SonarQube and CodeQL - **Test:** Qmetry - **Deploy:** ArgoCD - **Monitor:** Grafana - **Operate:** Datadog and Terraform Using , you have a centralized view of the entire suite of tools required to support the microservice. This capability of a single pane of glass provides coherent observability, eliminating the requirement of multiple consoles. ## application features and functions To the left of each application name in the application table, is an expand/collapse chevron that you can use to display the application composition. Expanding the application, displays the eight phases in one column (&#xNAN;** Phase**) and the tools associated with each phase in a second column (**Tools**). If the application has been configured without a tool for any phase, the **Tools** column is blank for that phase. The tools listed in the **Tools** column are represented as icons and contain a hot link to the tool. If Single Sign-on is enabled for the tool, clicking the link navigates you to your account in the tool and you can view data for that tool. If Single Sign-on is not enabled the service navigates you to the external tool home page. You also have the option of editing each phase to add and delete tools. To that end, you can display an overflow menu by clicking the vertical ellipsis at the far right of the Tools column within an application. The menu contains an **Edit** option. Click **Edit** to edit the tools listed in the tools column for that phase, for example **Plan**). [title] Tag Repository [path] Administration/Bridge tag management/ **Tag Repository **serves as the central repository for managing tag definitions and their associated tag values within Kyndryl Bridge. It helps organizations maintain standardized metadata, improve resource classification, support governance requirements and ensure consistent tagging across services and environments. # Access Tag Repository Access **Tag Repository **to view and manage existing Tag Repositories, create new tags, and maintain consistent tagging across : 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Tag Management **→** Bridge Tag Management.** 2. From the left navigation menu, select **Tag Repositories**. The **Tag Repositories** page is displayed, where you can view, create and manage tags across the platform. # Tag Repository page The **Tag Repository** page provides a centralized location for managing tag definitions and their associated values. The **Tag Repository** page includes the following components: - **Last updated**: Displays the date and time when the tag repository was last updated. - **Search keys and values**: Search for tags by tag key or tag value. - **Filter**: Refine the list of tags based on specified criteria. - **Add Tags**: Add one or more tags to the repository. - **Delete**: Remove selected tags from the repository. ## Tag repository table Provides a centralized workspace for managing tag keys and values within the repository. The table includes the following information for each tag: - **Tag Key**: The name of the tag definition associated with the tag. - **Type**: Indicates the tag scope or classification type. - **Tag Categories**: The category assigned to the tag definition. - **Used By**: Identifies resources or services currently using the tag. - **Definition Compliance**: Indicates whether the tag complies with its associated tag definition. - **Actions**: Provides available actions for managing the selected tag. Select the expand icon next to a tag to view its associated tag values and additional details. Tags created directly from the tag repository are labeled non-compliant because they lack definitions. However, the administrator can still use these tags and update their definitions later on from the [Tag Definitions](docId\:Bk-pJYH9CGZyhqfXthEV3) page. # Method 1: Add tag values from active tags created on the Tag Definition page The system is designed to prevent errors. If you, as the tag administrator, add tag values that are outside the constraints established on the tag definitions page, the system will display an error message and stop the addition of such values, ensuring the integrity of the tag repository. ## To add a tag value 1. Go to the **Tag Repository**. Go to the page and look for the tag key that requires an update. 2. Click the **View Details** option and select **Add tag values**. 3. Add all the required values, separated by commas. The set constraints are displayed to ensure that the values added are compliant. An error message will be displayed for non-compliant values. 4. Once all values are added, click the **Add Tag(s)** button. The window closes, and a new message displays on the page: “Tag value(s) successfully added. You have successfully added values \[name], \[name] to key \[name]”. ## To delete a tag value 1. Select the tag that requires the update. 2. Click the expandable icon to review the definition of compliance for each value. 3. Select the value that needs to be deleted and click the options icon. 4. Select the **Delete **option. A new window pops up requesting to confirm this action. 5. Click the **Delete Value** button to confirm the deletion. Otherwise, click **Cancel**. Once deleted, the window closes, and a message displays: “Tag value \[name] deleted successfully. You have successfully deleted tag value \[name] from the tag \[name]”. # Method 2: Create a new key or value pair directly within the repository :::hint{type="info"} An administrative control capability at an account level allows the enabling or disabling of the creation of tags directly to the tag repository. For additional details, see [administrative control](docId\:JCDR38ddarTLTZUa_kfgv). ::: If you create a new tag using a tag key already in the repository but without a tag value, the system will suggest similar tag keys already available, ensuring consistency and avoiding duplication. ## Add a tag 1. Go to the **Tag Repository** page and click the **Add Tags** button. A new window opens. 2. Select whether you will add new tag(s) or bulk add tags. 3. Enter a unique tag key. The tag management allows tag keys with a minimum of 1 character and a maximum of 256 characters, including numbers from 0 to 9 and special characters (!@$%\*();: \_ - / \ ). 4. Enter all the tag values associated with the key, separated by commas. 5. Once you have completed all the information, click the **Add Tags** button at the bottom of the window. ## Edit tag value Once tags are added, they can be managed and edited directly in the repository, with changes validated according to the associated tag definition and automatically reflected where applicable.  Changes are validated according to the associated tag definition and, for enumerated tags, are also reflected in the corresponding tag definition.  Validation behavior varies based on the configuration:   - **Free input (string):** The value must meet the defined rules, and the following message informs the user that the update will be applied in the Tag Repository: **The modified tag value will be updated in the tag repository**.  - **Enumerated list**: Users can only select predefined values in an enumerated list, which defines a fixed set of allowed values in the tag definition and does not allow free text.  The following message informs the user of the impact of the update: **Modifying a tag value updates it in the repository and changes the associated enum in the "Environment" tag definition*. *** Modifying a tag value can affect related tag definitions in the following ways: - If an administrator modifies a tag value in the tag repository and the corresponding tag definition uses a **Regex **or **String **constraint, or if no tag definition exists, the system displays the following message: "The modified tag value will be updated in the tag repository." - If an administrator modifies a tag value in the tag repository and the corresponding tag definition uses an **Enum list** constraint, the system displays the following message: "The modified tag value will be updated in the tag repository and the corresponding enum value within the associated tag definition." In this case, the updated tag value in the tag repository is also reflected in the corresponding enum value in the tag definition. ## Delete a tag Account administrators can delete tags with no associated resources/applications. You will have the option to delete all unused tags or delete an unused tag. To delete an unused tag: 1. Go to the **Tag Repository**. On the page, look for the tag key that needs to be eliminated. 2. Click the **view details** option and select **Delete**. To delete all unused tags: 1. From the **Tag Repository** table, select all the tags that need to be removed and click the **Delete Tags** button at the top. # Method 3: Import tags to the Tag Repository page This functionality enables the efficient simultaneous importation of many tags into the repository to create multiple tags. Account administrators can define account-specific tags in bulk and upload a JSON/CSV template to create multiple tags. Perform the following procedure to import tags in bulk: 1. From the **Tag Repository** page, select the **Add Tags** button. A window opens. 2. Select the **Bulk add tags **option. 3. Drag, drop, or choose the JSON or CSV file containing the tags you want to import. The file should not exceed 1 MB in size. The template should have two mandatory fields: tag key and tag value. Otherwise, an alert message displays: '*This file is missing the required columns. *or *This file exceeds the 1 MB file size limit.*' . A sample file is available for reference; download and review this sample before uploading your import file. 4. If you no longer want to import the file you selected, click the **remove** link to discard it. If you no longer want to continue with this operation, click **Cancel** to exit this window. 5. When the system validates the file, click the **Upload** button to proceed with the import. A notification indicates whether the process has been completed successfully or partially. The system imports tags that are unavailable in the tag repository. To ensure data integrity, the system imports only the value once for duplicate entries. You can maintain the same file and continue adding tags as needed. When uploading the same file with the latest updates, only the new entries are imported. When you import a tag key with the same name as an existing tag, it will automatically follow the current tag rules. For example, if you import a tag key called 'Team' and 'Team' already exists in the tag rules, the new 'Team' tag will be compliant. Any values that do not meet the rules will be marked, indicating they require attention. The import report in the notification details the success or failure of each entry in the import file, providing a clear understanding of the import process. It also explains the reason for failure (for example, a tag already exists, an empty field, or a duplicate value). ## In-App notifications for Tag Repository The bulk import feature in the Tag Repository provides In-App notifications to inform users of the outcome of their tag import. So that users know if the tags were successfully imported or if they encountered any failure. Import notifications provide a holistic view to the tag import process. As the process is asynchronous, users receive updates indicating whether the import is: - **Successful**: Indicates that all tags were imported successfully, including the total count of imported tags. - **Unsuccessful**: Indicates that the import failed completely, and no tags were imported. - **Partially successful**: Indicates that some tags were imported successfully while others failed, including counts for both. ## Importing Tag Repository reports Notifications include an option to download a detailed import report. The import report provides a detailed, **downloadable summary** of the tag import results, enabling users to quickly validate which tags were successfully imported and identify any failures. The import report is available from the In-App notification for all import outcomes (successful, unsuccessful, and partially successful). It contains the following columns: - **Tag key**: The identifier of the tag being imported. - **Tag value**: The value associated with the tag. - **Status**: Indicates whether each entry was **Success** or **Failed.** - **Reason for failure**: Provides an explanation for failed entries. Common failure reasons may include tag already exists, duplicate value, no tag value available, etc. The import report complements In-App notifications by offering a row-level view of the import outcome based on the import file for better troubleshooting and auditability.   # Method 4: Store tags in the Tag Repository page Tags from cloud providers and external sources, such as ServiceNow, can be sent to the tag repository through various Bridge applications and services. This integration enables applications to store tag information in the tag repository instead of within their own systems. Once applications send tag information to the repository, the repository will manage the lifecycle of those tags. The **used by** A column in the tag repository table allows you to view all the applications that currently use a particular tag. Discovered tags are pushed by the applications to the repository, and any updates, such as new or deleted tag values, will be reflected in the tag repository whenever a push occurs. When discovered tags are sent to the repository, any duplicate tag key/value pairs will be reconciled. If tags are pushed without an associated tag definition, the tag repository will indicate that the definition is missing for those tags. Tags that are stored with the same key as an existing tag definition will automatically be considered compliant. For example, if a tag is pushed to the tag repository, but a tag key with the same name already has an existing tag definition, then the newly pushed tag will automatically be compliant because a definition for that tag key already exists. In such cases, tag keys will not be duplicated. However, tags discovered from external sources may not comply with the tag definitions and could be deemed non-compliant. If an application or service adds a new value to an existing tag key in their respective application, that value will be added to the repository as well. For example, if an application or service uses the 'Environment' tag from the common tag repository and does not find a suitable value to tag with, it may create a new value called **Production**. In this case, the new tag value should also be appended to the list of values for the 'Environment' tag in the repository. The Tag Administrator is responsible for ensuring that all values comply with the established rules. [title] Release management module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ Release management is a pivotal discipline within the DevOps framework. This process ensures that software builds traverse smoothly from the development environment through various stages, culminating in a production-ready state. In modern agile and rapidly evolving development cycles, where software updates can be frequent, release management becomes invaluable. It's not just about transitioning code; it's about confirming that this code is stable, aligns with quality standards, and meets business needs. brings a nuanced dimension to release management, transforming it from a mere process to a strategic orchestration. Embedding structure and defined checkpoints ensures that releases are scrutinized and validated at every step. From development managers to release managers, stakeholders can quickly assess a release's risk profile, ensuring informed decisions without silos. This provides an overview of the risk profile for a single application, which can be selected from the global application menu. We have captured nine different parameters across the Plan and Test categories. With a consistent release nomenclature, you can understand how the release is performing in these nine parameters compare to their respective thresholds. These thresholds can be set at the application level and configured by an administrator. # Dashboard composition When you navigate to the Release Management Dashboard, it is not populated. You must select a release from the **Dashboard View**, which is displayed as an interactive collection of specification displays. Use the following procedure: 1. Click the Application dropdown, which initially displays **All data.** 2. Select the application from the dropdown list. 3. Select the release from the Releases dropdown. 4. Select the environment from the Environments Dropdown. The service displays all parameter values, a gauge chart and the Release Decision Parameters table. :::hint{type="info"} The releases that are available for assessment are limited to those that have occurred in the previous 180 days. ::: When you land on the release management page, you'll encounter drop-downs to select the desired **Application**, **Releases** and **Environments**. Plus, you'll observe a gauge chart that measures from **Low** to **High **and a unique table labeled **Parameters for the Decisions**. Ensure you have picked the right application, release and environment. # Gauge chart The gauge chart on the release management dashboard quickly indicates the risk level of your release as High, Medium or Low. High risk suggests significant issues that might impede the release, Medium indicates moderate concerns, Low implies minimal risk and No Risk indicates all risks have been eliminated, aiding in swift decision-making for release progression in DevOps. Key risk assessments on the gauge chart include: - **High risk**: - 80% (or more) of parameters are below the acceptable threshold. - The presence of severity 1 or 2 bugs compounds the risk. - **Medium risk**: - The release exhibits concerns, with over 50% of its parameters falling below the threshold, warranting closer scrutiny. - **Low risk**: - Indicates a relatively robust release state, with only 20% (or more) parameters below the threshold. - **No risk** - Indicates all risk has been eliminated. # Secure alerts The Release dashboard supports Secure Alerts, enabling visibility into security issues detected for a release. The dashboard supports viewing and tracking secure alerts so teams can identify and address risks before approving a release. Secure alerts are present in the following dashboard elements: - Gauge Chart: The risk calculation presented displayed in the gauge chart is affected by data from secure alerts. - Secure Alert tile array: A row of individual tiles that present identified security vulnerabilities. - Release Decision Parameters table: Table line items that present identified security vulnerability details. For more details refer to [Secure alerts](docId\:MrPFfez9p-F1WGUnDPSin) # Release approval With **Editor** role, you can approve a release for a specific application, environment, and release. All it takes is to select the **Approve release** button. Once you approve the release, you'll see the "Decision history" button. :::hint{type="info"} When you approve a release, it's final. You can't revert or duplicate the approval for the identical application, release and environment trio. ::: # Decision history As an **Editor**, once you approve the release, the system intuitively updates its interface. Your **Decision History** is a detailed archive, showcasing: - The specific determinations you've made for each release. - The exact timestamps of when you sanctioned each approval. - The reasons and considerations that influenced your decisions. The page presents two tabs that present information to assist with release management: - Release Decision Parameters: Tabular data governing release management decisions with details. - Deliverables: The composition of releases. # Release decision parameters The Release Decision Parameters Release Management supports the following elements to assist with release decisions: - **Parameters**: These are the distinct elements that factor into your release decisions. For convenience in evaluation, you can sort this column. - **Current Values**: Represents each parameter's real-time metrics that contribute to the release assessment. This column has been made sortable by severity to aid in your evaluation process, enabling a more nuanced understanding. - **Default**: Refers to the benchmark settings Kyndryl has standardized for each parameter. This column remains static, designed to provide a consistent reference point and is not subject to sorting. For a deeper analysis or to share with your team, you can **Download** a comprehensive list detailing each parameter, its current value, and its threshold value. This information is conveniently provided in a CSV format, ensuring ease of use and integration into any data analysis tool or platform you prefer. # Performance metrics tiles These metrics highlight parameters such as Static Scan, Secure Alerts and Container Vulnerability Scan that have descended below their designated threshold values. By glancing at these tiles, you can quickly ascertain areas that might require your attention, ensuring that no critical detail goes unnoticed during the release decision-making process. Each tile contains a hot link that navigates to a details page, providing detailed information about the metrics. # Release decisions parameters table The Release Decision Parameters table contains reports values for specified parameters within the context of release status and thresholds as shown in the following ***representative*** table, which can vary depending on the application: | **Parameters** | **Current Release Status** | ***di_application*** **Threshold** | **Prev Release :** ***latest*** | **% Change with Prev Release** | | ------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- | | Open critical bugs | 1 | 10 | 2 | 50% | | Unclassified bugs | 0% | 5% | 25% | 100% | | Code coverage | 95% | 90% | 90% | 5.6% | | Average code smell | 50 | 5 | 90 | 44% | | Code smell density | 5% | 10% | 6.9% | 27.7% | | Skipped tests | 31.6% | 0% | 41% | 24.2% | | Failed functional tests | 21.4% | 0% | 16.7% | 28.6% | | Failed unit tests | 20% | 5% | 0% | 100% | | User stories completed | 95% | 90% | 93.3% | 33.7% | | Critical Vulnerabilities | 16 | 0 | 25 | | | Denied Licenses | 0 | 0 | NA | NA | | Secure Alerts | NA | 0 | NA | NA | ## Table header elements - **Parameters:** Supported parameters, the values of which collectively determine release decisions. - **Current Release Status:** The values of the parameters listed in column one. - **GitHub-Kyndryl threshold:** The minimum acceptable value to allow a release. - **Prev Release - *release date*:** The values of the parameters listed in column one for the previous release - **% Change with Previous release:** The difference in the value of the parameters listed in column one between the current release and the previous release, expressed as a percentage of the value in the previous release. For example, if the code coverage for the current release is 70% and the code coverage for the previous release is 100%, the release delta has degraded 30%. ## Release parameters - **Unclassified Bugs:** Denotes those bugs that currently exist without a designated severity level, prompting a review to categorize them appropriately. - **Skipped Tests:** Reflects the tests intentionally overlooked during the testing phase. It indicates the percentage of bypassed unit tests, pointing to potential risk areas. - **Failed Unit Test Cases:** Pinpoints areas in your code that might be error-prone. It represents the proportion of unsuccessful unit tests compared to the total executed. - **Failed Functional Tests:** Offers insight into the robustness of your application's functionalities by showcasing the percentage of functional tests that did not pass. - **Open Critical Bugs:** A direct count of pressing unresolved issues. These bugs have been flagged with severity levels 1 and 2, signaling immediate attention. - **Unclassified Bugs:** Denotes those bugs that currently exist without a designated severity level, prompting a review to categorize them appropriately. - **Average Code Smell:** Computes the mean ratio of code anomalies to the cumulative count of technical services. This helps your gauge code quality and areas needing refactoring. - **Code Smell Density:** Focuses on code quality by indicating the percentage of code discrepancies encountered per 100 lines within the specific technical service(s). - **User Stories Completed:** Represents the percentage of user stories that have been completed out of the total number of user stories that have been created linked with the specific release. - **Critical Vulnerabilities:** Lists only critical-level vulnerabilities found in container images, filtered based on the selected application and its corresponding release. - **Denied Licenses:** The list of licenses that are restricted or denied by policy, depending on the specific application and release version selected. - **Secure Alerts:** Notifications that address the dynamic nature of threats as they occur, providing an immediate understanding of your hybrid IT estate. # Parameter table column settings The table view can be customized to show or hide columns displayed in the table. Click the gear icon above the table on the right to display an array of column labels. Each column label has an associated checkbox. Check the associated box to display a hidden column or uncheck the associated box to hide a displayed column. :::hint{type="info"} By default, only the **Parameters**, **Current Release Status** and **GitHub-Kyndryl Thresholds** columns are displayed. ::: ## Parameter details Details are available for each release parameter to enable a more thorough analysis than is possible using the raw statistic and comparison to the previous release presented in the table. The service might report that the Skipped tests parameter, for example, is 5.2% and that this represents a 29.6% improvement over the last release. While this information is useful, it doesn’t provide a sense of whether tests are skipped more often in the case of some services compared to others. If some services sustain a higher incident of skipped tests than others, the release manager will likely be prompted to investigate the reason. In the case of Skipped tests, this additional information is available. The right column contains a vertical ellipsis. To see details use the following procedure: 1. Click the ellipsis to display an overflow menu with a View Details option. 2. Click **View Details**. The service displays a Release Management / Parameter Details panel. The panel presents the following details: - Parameter name - Value for the current release - Filter: Select from Technical services (all services) or individual services - Details table: Details vary by parameter # Details table The following table explains the details available for each release parameter: ## Release parameter details | **Release parameter** | **Available details** | **Why details are useful** | | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Code coverage | Execution Date, Coverage, Duration, Tool Engine | This parameter helps the release manager to understand which Technical service is accounting for the least code coverage for a release. Development managers can then assess details and direct the team to focus on improving the coverage for that specific service. | | Skipped tests | Test Run ID, Technical Service, Total, Skipped, Tested at, Tool Engine. | Understanding whether some services sustain higher rates of skipped tests can guide release managers to understand which services are the bottleneck for the entire release. Approving high skipped test rates can result in high possibility of incidents when application is in production. | | Failed unit tests | Test Run ID, Technical Service, Total, Failed, Tested At, Tool Engine | The details page helps to identify which services have higher failed unit tests. High failed unit tests indicate potential defects, risking stability and reliability of the software in a production environment. | | Failed functional tests | Test Run ID, Technical Service, Total Failed, Tested At, Tool Engine | The details page helps to identify which services have the highest failed functional test rates. High failed functional test rates suggest critical features might not work as intended, risking user dissatisfaction and product credibility, post-release. | | Open critical bugs | Bug, Summary, State, Technical Service, Severity, Created By | Understanding the severity of a collection of open bugs by service enables insight regarding the general quality of service code and implies whether further investigation into the service is warranted. | | Unclassified bugs | Bug, Summary, State, Technical Service, Created By, Assigned to | Understanding the list of bugs which are unclassified in one single page with respect to an upcoming release helps development managers be prepared for any unknown issues. He can go through the list and assign appropriate severity within the parent tool. | | Average code smell | Technical Service, Execution Date, Code Smell, Duration, Tool Engine | Understanding chronically high code smell for a specific service indicates that investigation of code quality for that service is warranted. | | Code smell density | Technical Service, Execution Date, Code Smell Density, Duration, Tool Engine | Understanding chronically high code smell density for a specific service indicates that investigation of code quality for that service is warranted. | | User stories completed | User Story, Summary, Feature Name, Technical Service, Created On, Assigned to | The details page provides the list of user stories and associated features which the team have completed as \[art of the release. | | Critical Vulnerabilities | Technical Service, Application, Image Name, Release Name, Total Vulnerabilities, Critical, High, Scanned on, Secure Engine | Critical-level vulnerabilities found in container images are one of the most important variables in the *go-no go* decision process. Severe consequences are possible if the threshold is breached. | | Denied Licenses | Technical Service, Application, Image Name, Release Name, License Detected, Critical, Scanned on, Secure Engine | This parameter represents the list of licenses that are restricted or denied by policy, depending on the specific application and release version selected. This is a necessary factor in release management. | # Configuring the release management parameters Release Management enables *Go/No-go* decision making on the part of the release manager. Release managers must understand based on identified parameter values whether a given release should proceed.  identifies critical release parameters and enables the setting of threshold values for at-a-glance *Go/No-go* decisions. :::hint{type="info"} The application provides default release decision parameters tenant-wide, which can be modified for each application by administrators assigned the **Release Manager** role. ::: You must be assigned one of two roles to configure these parameters: - **DI Admin:** You can configure these parameters from the Configure Technical Services page (DevOps Overview → Settings & Utilities → Configure Technical Services) for the entire tenant across all applications. - **DI Release Manager Role:**You can configure these parameters from the Release Management page for each application. # Deliverables The Deliverables tab presents a deliverables table listing all components in the selected release with the following information: - **Features/Defects:** The Feature or defect ID, which is a hotlink to details for that feature or defect. - **Description:** A summary description of the item. - **Type:** The type of item that is being release, for example Feature, Defect or User Story. - **Current State:** The current state of the item such as Ready for Staging or Resolved. A filter is available to narrow the elements by type: - Select all (default) - Issues: - Feature - User Story - Defects # Editing the release parameter configuration On the Release Management page, the parameters initially listed in the Release Decision Parameters table are set for the entire tenant by a user who has been assigned the DI Admin role from the Configure Technical Services page. If you have been assigned the DI Release Manager role, you can edit these parameters for a specific application, which is the one you selected when you first arrived at the Release Management landing page. Click the **Edit Configurations** button located above the table on the right. The application displays an edit canvas: Make the necessary changes and click **Save configuration**. [title] Service IDs [path] Administration/Bridge Access Management/ Service IDs are non-human identities for apps, services, subscriptions, servers or automated processes. They avoid using personal credentials and enable scoped, durable access for teams. # Accessing the Service IDs page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="28" height="28"}, go to **Administration** → → **Service IDs** # Role-based permissions for service IDs - **Administrator or account owner**: can create, view, edit, lock or unlock, delete, assign to access groups, manage API keys and assign policies. - **Contributor and operator**: can view service IDs and manage API keys. Cannot create, edit or delete service IDs. - **Viewer**: can view only. # Creating a service ID To create a service ID, see the following steps: 1. Select **Add Service ID**. 2. Enter a unique name and optional description. 3. Click **Add Service ID.** # Assigning an access policy to a service ID To assign an access policy to a service ID, complete the following steps: 1. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/nSYuNUHJdb4gGBAWMXOSC-20260602-172708.svg" alt caption width="28" height="28"} next to the service ID key that you want to edit. 2. Click **Assign Access.** 3. Select a **Service.** 4. Select the **Scope**. 5. Click **Assign** # Learn more [API Keys](docId\:xFTW8fInm1eYUfKPg7fly) [Access Policies](docId\:nb3bZm-bsA3w7AEFpbDzs) [Roles and permissions](docId\:ICs69b2oEsEwnrtSMBI3W) [title] Test module [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ In the Test dashboard, data can be filtered by two criteria: - **Dashboards:** Choose a dashboard to select data specific to applications. If a user has more than one dashboard, there will be more than one option to select. - **Applications:** Comprehend the build health of cloud applications such as Cost & Asset Management or Enterprise Marketplace. :::hint{type="info"} Depending on your selections from these filters, the data displayed in the widgets varies. Some widgets may show the message *“No Data Available”*, which means no recent data is available for your selection. ::: The Test dashboard displays data in five widgets and a table view that allows a view of critical components of the Test phase: | **Test phase components** | **Description** | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Test summary by application | This graph summarizes tests performed on all configured applications based on the selection chosen. This choice might be based on the number of failed, passed or skipped tests. | | Top 5 technical services with less coverage | This graph depicts the top five technical services with the least coverage during the previous seven days. | | Overall test status | The Overall test status graph represents the number of tests passed, failed, and skipped over the selected timeframe and the data status is described as follows:
* **Failed** (Red): Tests failed within the selected period. * **Passed** (Green): Tests passed within the selected period. * **Skipped** (Yellow): Tests executed but not finalized; thus, their final result cannot be determined.
By hovering over the graph, the following data is presented for each test status:
* **Group**: the test status from the three categories. * **Date**: date of the execution of the tests. * **Value**: total number of tests executed in a determined time frame.
The Overall test status widget presents two axes that indicate the **Test** within a specified time frame in which Passed, Failed and Skipped tests occurred:
* X-Axis (**Days(Year)**): The X-Axis corresponds to the dates within the activity's time frame. * Y-Axis (**Total tests**): The Y-Axis corresponds to the number of Passed, Failed or Skipped Tests for the selected time frame. | | Test type status |
The Test Type Status widget is a graph showing **Unit tests**. The widgets display the total numbers for each of the following:
* **Unit tests**: Displays the results of automated tests to ensure that a section of an application meets its design and behaves as intended. * **Functional tests**: Displays the results of successfully executed Functional Tests. * **Other tests**: Displays the results of other tests executed. | | Top 5 technical services with code smells/bugs | Based on a 7-day sample, this graph depicts the top 5 technical services with the most code smells/bugs. **Code Smells** are the default selection; using the drop-down menu, you can view the **Bugs**. | :::hint{type="info"} When Unit tests, Functional tests, or Other tests are checked or unchecked, the **Overall test status** widget will automatically be updated based on the new parameters. ::: # Compare releases page The Compare Release page enables teams to evaluate how their test results have evolved over time. This comparison focuses on a single application and examines two different releases. From the data served by this page development managers can understand how the team has progressed in building stable code from one release to the next. These trends help managers make data-driven decisions about resource allocation, identify areas needing improvement and optimize the development workflow. Understanding these trends is crucial for assessing and mitigating risks, ensuring that the software remains reliable and meets quality standards. The information on these parameters are being captured from SonarQube in this case. The page offers insights into different releases the following parameters: - Bugs - Coverage - Affected technical services - Code smells - Failed tests - Skipped tests :::hint{type="info"} The duration for comparison is always 180 days; this option is set by default and cannot be changed. ::: You can Navigate to the Compare Release page from the Test dashboard by clicking the **Compare releases** button. To see the comparison charts and their tabular representation, you must pick at least one application, two releases, and one environment in the Compare Release Dashboard. By default, you would be shown all six parameters of a test run as charts. However, you have the ability to eliminate any chart that does not meet their standards. Please remember that if the selected charts are to become the default, they must be stored as custom views; otherwise, any changes in chart selection will be lost in the next login session. :::hint{type="info"} The "Compare Release" page now includes an "Export to .CSV" functionality, allowing users to easily export comprehensive reports of product, software or service comparisons over time. This feature enhances the analysis of changes, updates, and improvements between different releases for more efficient decision-making and tracking. ::: The deleted charts from the **Add components** window can be re-added by dragging and dropping the item. Charts can also be rearranged based on their importance. The table chart concisely summarizes all charts. # Technical service test table The Technical service tests table is located at the bottom of the Test dashboard, which provides technical service Test data in a tabular form and enables a detailed view of each service. Each row in the table displays information for a specific service, separated by columns of information type: - **Technical service:** The name of the micro-service within the larger application. - **Applications:** Comprehend the test environment health of IBM cloud applications such as CAM and Enterprise Marketplace. - **Test type:** The type of Test. - **Failed:** The total number and percentage of Tests in the Failed category or group. - **Skipped:** The total number and percentage of Tests in the Skipped category or group. - **Passed:** The total number and percentage of Tests in the Passed category or group. - **Total:** The total number of Tests. - **Bugs:** The total amount of Bugs. (Hidden by default) - **Code smells:** The total amount of code smells. (Hidden by default) - **Coverage:** The type of coverage. (Hidden by default) - **Release:** Release that is associated with the executed tests. - **Environment:** The instance of the application where tests were executed. - **Duration:** The total time a Test took to be executed. - **Execution date:** The date the Test was executed. - **Tool engine:** The Test tool source. :::hint{type="info"} The Technical service test table displays all data regardless of the time frame selected. All columns in this table can be sorted. Above this table, you will find a search box that allows searching technical services by name and a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: The Table view also supports detailed views for each service. Click on the details view for a specific project, displays the project’s performance along with a historical view of scan results and scan duration. Tracking scan durations over time enables a development manager to assess the efficiency of the scanning process. provides historical trends for individual projects, and analyzing the trends of scan test results in both unit testing and functional testing offers a comprehensive view of the software’s health and the development process. High and consistent pass rates in unit tests indicate stable and reliable code at a granular level. Consistent passing of functional tests ensures that the application complies with industry standards and regulations. To access details for a specific technical service, Click the overflow menu to the far right of the table and select **View details**. Select the following link for more information:[Test dashboard table view details](docId\:m76ZEF8h8HwKko1Zrg4Pc) [title] Configure DevOps Intelligence for GitHub, legacy users [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/GitHub and GitHub Enterprise configuration/ This procedure is valid only for customers onboarded before 6 June 2024. Procedures for recent customers are provided in the subsequent section Configure for Git and legacy customers. # Organization level tracking 1. Navigate to → **Settings & Utilities** → **Tools Configuration** → **Add Configuration**. 2. For **Tool engine**, select **GitHub.** 3. For**Connection**select the appropriate connection name. For **Tracking Type**, select **Organization**. 4. For Organization, select any organization to be tracked. 5. Click configure. Additional configurations are supported: - Configure release format: Release can be identified by the pattern generated from two fields, **prefix** and **variable**. - Severity of defects: Sev 1, Sev 2, Sev 3 and Sev 4 are terminologies used in dashboards. Using these severity levels, the user is allowed to provide mapping for endpoint Severity Values. For example, any value provided under the "Severity: Sev 1" category, will be considered as "Sev 1" while displaying the values on the dashboard. # Tracking Non-Organization(Independent) Repositories Use the following procedure to configure GitHub for repositories: 1. Navigate to → **Settings & Utilities** → **Tools Configuration** → **Add Configuration**. 2. For **Tool engine**, select GitHub. 3. For **Connection**, select the appropriate connection name. 4. For **Type**, select Repository and Organisation. This selection is **not** required. 5. For Repository select any repo you want to track. 6. Click configure. Additional configurations are supported: - Configure release format - Release is being identified by the pattern generated from two fields, **prefix** and **variable**. - Severity of defects: Sev 1, Sev 2, Sev 3 and Sev 4 are terminologies used in dashboards. Using these severity levels, the user is allowed to provide mapping for endpoint Severity Values. For example, any value provided under the "Severity: Sev 1" category, will be considered as "Sev 1" while displaying the values on the dashboard. - [GitHub Webhook configuration](docId\:Zq0J-dl3DYuBbeSzVhD_t) Understand how to configure a Webhook for GitHub to ensure proper data synchronization. [title] Approval Requests [path] Administration/Bridge Access Management/Access Request Management/ The **Approval Requests** is available only to users with the **Approver **role, such as DPEs (Delegated Platform Engineers) and **Account Administrators**. This tab enables approvers to review, approve, reject, revoke and monitor access requests for Bridge accounts and access groups. By centralizing the approval process, it helps ensure that access is granted only to authorized users, supports compliance with access governance policies and provides visibility into the status and history of access requests across managed accounts. The Approval Request page displays a list with some key metadata, such as: :::Paragraph{listStyleType="disc" indent="2"} **Account ID:** Displays the unique account identifier. ::: :::Paragraph{listStyleType="disc" indent="2"} **Account Name:** Displays the account name. ::: :::Paragraph{listStyleType="disc" indent="2"} **Access Group:** Displays the requested access group. ::: :::Paragraph{listStyleType="disc" indent="2"} **Requestor Email:** Shows the requestor's email address. ::: :::Paragraph{listStyleType="disc" indent="2"} **Requestor Justification:** Displays the reason for the access request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Country:** Displays the associated country. ::: :::Paragraph{listStyleType="disc" indent="2"} **Expiration Date:** Shows when the request expires (30 days after submission). ::: :::Paragraph{listStyleType="disc" indent="2"} **Approved By:** Displays the approver's email address. ::: :::Paragraph{listStyleType="disc" indent="2"} **Status:** Shows the current request status (Approved or Rejected). ::: :::Paragraph{listStyleType="disc" indent="2"} **Allowed Actions:** Allows approvers to view request details and approve or reject the request. ::: :::hint{type="info"} Approvers can manage requests **only within the account** they are currently viewing. ::: # Approval Request tab To access the **Approval Requests** page, follow these steps: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Bridge Access Management** → **Access Request Management** → **Approval Requests ** 2. This opens the **Approval Requests **tab, where you can view and manage pending access requests that require your review and approval. 3. On the Approval Requests page, locate the request,** click the ellipsis** (...) menu and select **View Details**. The following information is displayed:  - Requested access groups - Requestor email - Requestor justification - Approver role - Approval or rejection comments (if available) - Approval or rejection date and time - Current request status Locate the request you want to review and expand it to view the access group details associated with the request: :::Paragraph{listStyleType="disc" indent="2"} **Access Groups**: The access groups included in the request. ::: :::Paragraph{listStyleType="disc" indent="2"} **Service**: The service associated with the access group. ::: :::Paragraph{listStyleType="disc" indent="2"} **Description**: A description of the access group. ::: :::Paragraph{listStyleType="disc" indent="2"} **Members Count**: The number of members assigned to the access group. ::: # Managing Approval Requests From the **Approval Requests **page, approvers can monitor request status, review request details and take actions such as** Viewing, approving**, **rejecting** or** revoking **access when required. ## Unreviewed and reviewed access requests The **Approval Requests** page enables approvers to review, approve and reject user access requests for the accounts they manage.  The page is divided into the following sections:  - **Unreviewed: **The Unreviewed section displays access requests that are awaiting a decision. Approvers can review request details, including the requested access groups and business justification, and then approve or reject the request as appropriate. - **Reviewed: **The Reviewed section displays access requests that have already been processed. This section provides a historical view of approved and rejected requests, allowing approvers to review request details, approval decisions, dates, and associated comments. Each section displays a table with key information for each request, including the account name, requested access groups, requester email address and the business justification provided by the requester.   Approvers can use this information to evaluate requests and monitor their status throughout the approval process.  ## Approve or reject user access requests To review and either **approve **or **reject **an access request, complete the following steps:  1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to → **Approval Requests** 2. Click the ellipsis menu for the request and choose **Approve **or** Reject **as appropriate. 3. The **Request Details** page will display detailed information about the access request, including the metadata for all requested access groups and the requester's business justification. 4. Details page also provides the capability to **Approve** or **Reject **as appropriate. 5. A confirmation window is displayed, click **Confirm approval** or** Confirm Rejection**. If rejecting a request, you must provide a rejection justification before confirming the rejection. After the request is submitted, its status is updated to **Approved** or** Rejected**, the approval date is recorded, and a confirmation notification is displayed.  ### In-App & Email approver notifications Approvers receive **In-app** and **email **notifications whenever a new access request is submitted, for an account or access group and requires their review. Notifications provide the information needed to evaluate the request and take appropriate action. In-app notifications provide approvers with the information they need to quickly review and take action on newly submitted access requests within the accounts they manage. The In-App notification contain the following details: - **Title**: Access request for \ or \ - **App name**: - **Request details**: Requestor justification description and expiry date. - **Link**: Approval Request page. The email includes the following details: - Requestor name - Account ID - Account name - Requested access groups - Country - A direct link to the request that routes the approver to **My Approvals** for review and action - Contact information for Support # Revoking user access Revoke access allows **administrators** to remove previously approved access when it is no longer required. When access is revoked, the user is removed from the associated access group, and the revocation reason is recorded for auditing purposes. Administrators can revoke individual requests or multiple approved requests in a single action. Follow these steps to revoke a user's previously approved access: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Bridge Access Management** → **Request Management**. 2. Locate the approved access requests. Approvers should be able to revoke **multiple approved access **at once. Only the approved requests can be revoked. 3. Select **Revoke**. 4. Enter the reason for revoking the access. 5. Review the request details and select **Confirm**. When access is revoked, an **email notification** is sent to the affected user informing them that their access has been removed. :::hint{type="info"} Revoking access removes the user's membership from the associated access group but retains the request record for auditing and tracking purposes. ::: On the **Approval Requests** page, locate the request, click the ellipsis (...) menu and select **View Details**. The following information is displayed: - Request metadata - Revocation reason - Approver role - Approval date and time - Current request status # Retention period for Access Requests Access requests are retained based on their final status to support audit requirements while keeping the system clean and efficient. - **Expired**, and **Revoked** requests are retained for **30 days** from the date they enter that status. Rejected requests are retained for 90 days. - The **30-day retention period** begins when the request is moved to the Rejected, Expired or Revoked state. - **Approved** requests continue to be retained for as long as they remain in the Approved state, consistent with current behavior. - If an approved request later changes status, the retention rule associated with the new final status is applied. - Requests are **automatically removed from the UI** once their retention period expires. [title] About access tags [path] Administration/Bridge Access Management/Access Tags/ # Tag-based access control Using conditions and a set of tag variables, you can add a policy to scope access based on the tags that have been applied to a resource. Access can be controlled based on a tag that exists on the resource. Tag-based access control provides additional flexibility to your policies by allowing you to define access policies with tags. :::hint{type="info"} - Access tags are visible account-wide in all Services; avoid using personal information. - Access tags must always be in the `key:value` format. Think of it as a string to isolate two logical parts. For example, *project\:projectname*. The Kyndryl user interface (UI) makes this distinction very clear. - Access tags, both key and value, are case sensitive. ::: # What is a resource? A resource is any item that is created or owned by an application, such as Virtual Machines (VM), orders, and provider connections. # What is a resource group? A resource group helps you organize your resources in a way that best fits within your business. With resource groups, you can quickly grant users access to one or more resources at the same time. So, a resource group is a group that contains one or more resource attributes that maps to a collection of similar resources. # What is an attribute? An attribute is an element or metadata of the resource that helps identifying the resources, such as AssetID, OrderID, virtual machine in a specific region or virtual machine of a given provider. # Use case: Assigning access tags in policy authoring Access tags are designed for integration with ABAC. When authoring an access policy:  - You can define policies like:  - **Allow access to resources where Project=Finance**  - **Deny access if Environment=Prod**  - Tags can be used across users, access groups, and service identities for granular access control.  [title] Audit [path] Administration/ Within a account, actions are recorded via an service. These records provide a reliable foundation for security and compliance, enabling you to monitor and verify activities that affect operations or procedures. The service uses the existing roles to manage the audit capabilities. These roles are: - Platform Administrator - Platform Viewer # page navigation Navigate the page with confidence by following straightforward steps, helping you feel assured in managing audit data efficiently: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **** → **Service Operations **→. The **Audit **page displays all user and system actions across Bridge services, where you can view and track activity to ensure transparency, compliance and accountability. # page components The page displays the following components: - **Filter:** Filter actions by date range, event type, initiator, outcome, or observer. As you filter your results, tags will appear at the top of the window. The Clear All option is always available in case you need to remove the filters. - ** table: **A table of events with select details for each event. - **Export: **This option allows exporting the log data in CSV or JSON format. - **Settings: **This option is only available with Admin permissions. This allows us to set the log retention to 30,60 or 90 days. ## table The table shows all actions based on your filter selections, sorted chronologically for each app or service. Each row contains details for a single event. The following columns each display a single type of information: - **Initiator:** User who created the action/log. The user associated with the event. - **Action**: What action was triggered - **Event type: **Provides information about the status of a resource or its attributes and properties. - **Monitor:** Characterizes events that provide information about the status of a resource or of its attributes or properties. - **Control: **Characterizes events that reflect or provide information about the application of a policy or business rule, or more generally express the outcome of a decision-making process. - **Activity: **Characterizes events that provide information about actions having occurred or intended to occur and initiated by some resource or done against some resource. - **Date:** The time at which the event occurred. - **Target (Endpoint):** The resource or endpoint where the action was performed. - **Outcome:** Status of the request, which can be In progress, Success, or Failed. - **Observer (Module):** App/Service in which the action got triggered. - **Status code: **API code :::hint{type="info"} The exported audit file includes significantly more audit metadata than what is shown in the UI. ::: ## Retention and archival Retaining audit data is essential for regulatory compliance, security investigations, operational monitoring and internal audits. As organizations grow, audit services must provide scalable and efficient storage to support increasing volumes of audit records while maintaining fast access to historical data.    To address long-term audit and governance requirements, the Audit Service now retains audit data for** 365** days in the Elasticsearch database. This retention period enables teams to retrieve and analyze historical audit data for a full year, supporting comprehensive investigations, trend analysis, compliance reporting and data-driven decision-making.   The Audit Service supports the following retention periods:  - 30 days - 60 days - 90 days - 180 days - 365 days Audit data older than the supported **365-day retention period** is not available and will not be displayed. If an error occurs while applying a date range within the **365-day retention limit**, verify that the selected date range is valid and falls within the supported retention period, and then try again.  You need to have admin permissions to update the retention period. Once the permission is granted, click the **Settings** button. A window will appear, allowing you to select the data range you need and save the results. A pop-up message indicating that the settings have been saved successfully will appear at the top of the page. ## Export Creating clear audit reports is essential in today’s business environment. They showcase operational effectiveness, build stakeholder trust, and help identify risks and compliance issues. Additionally, strong audit reports enhance accountability and governance. Users can export audit data in CSV and JSON formats, ensuring transparency. The export includes all relevant information, which can be filtered by date range, observer, (apps/services), initiator and outcome. Requests for sensitive data, like IP addresses, will be rejected and will not appear. To export specific audit logs: 1. Select the **Export** button; a pop-up window will appear. If no filters are applied, all data will be exported. When filters are used, only matching data will be exported. 2. Select your preferred format: .CSV or. JSON; there is no default option. 3. Select the **Export** button. An export preloader appears, and once the export finishes, a toast notification appears at the top. [title] 06. Administration [path] / [title] [path] / [title] Access Groups [path] Administration/Bridge Access Management/ **Access Groups **enables administrators to organize users and Service IDs into groups, simplifying access management and allowing permissions to be assigned and managed at scale across services. By assigning access policies to groups rather than individual users, administrators can simplify identity and access management, improve governance and maintain consistent permissions across teams and workflows. Access groups can be used to grant role-based access to different types of users, manage Service ID permissions for automation and integrations and create temporary groups for project-specific access requirements. This centralized approach helps streamline access administration while supporting security and compliance objectives. # Prerequisites  The following prerequisites must be met to create and manage Access Groups: - You must have the **Administrator** role assigned to your account.  - Users and [Service IDs](docId\:I2WXFQP2tstQi7GfvOF18) must exist in the account before being added to groups.  - Only administrators can create, modify or delete groups or assign policies.  # Access Groups page The **Access Groups** page provides a centralized view of all access groups in your Kyndryl Bridge account. From this page, administrators can monitor and manage group-based access by reviewing the total number of access groups and their classification. Summary cards provide a quick overview of access group distribution across the account, including: - **Total Groups:** Displays the total number of access groups in the account. - **Bridge Groups:** Displays the number of predefined Bridge Groups available in the account. - **Service Groups:** Displays the number of Service Groups associated with services in the account. These cards help administrators understand the current access group landscape and manage permissions and access assignments more effectively. Access groups are organized into the following sections on the Access Groups page: - **Bridge Groups:** Predefined access groups provided by Kyndryl Bridge. These groups cannot be customized and are used to manage access to Bridge platform capabilities. :::Paragraph{indent="1"} The Bridge Groups section displays information such as the **Access Group** name and **Description** and provides a **View details** action to review additional information about a selected group. ::: - **Service Groups:** Access groups associated with a specific service. Administrators can create and manage these groups to control access and permissions for service-related resources. :::Paragraph{indent="1"} The Service Groups section displays information such as **Access Group **name,** Description**, **Member Count** and provides actions to **View details** or **Delete** a group, depending on the available permissions. ::: Use the **Filter by service **option in the **Service Access Groups **section to narrow the list of access groups by service. The **Service **column displays the service associated with each access group, helping you quickly identify and manage the user's access to specific services. The **Access Groups** page also enables administrators to view group details, manage memberships, and create Service Groups to support service-specific access requirements through the **Add Access Group** option. :::hint{type="info"} By default, **Bridge Groups** are predefined and cannot be customized. ::: # Accessing the Access Groups page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → → **Access Groups**. # Managing Access Groups The **Access Groups **page allows administrators to view, create and manage access groups within a account. From this page, you can review existing groups, add or remove users and Service IDs, assign access policies and manage permissions for groups based on business and operational needs. For more information about Bridge access groups, see the table in [Inviting new users](docId:7caOs2IBiKFBH9x-bz51X). ## Creating an access group To create an access group, complete the following steps: 1. On the Access Groups page, click **Add Access Group**.  2. In the **Add Access Group** window, provide the following information: - **Service**: Select the service for which you want to create the access group. This drop down will display all the services that are associated with the logged in account. - **Access group name**: Enter a unique name for the access group. The name must start with a letter and can contain letters, numbers, underscores (\_), spaces, and hyphens (-). Access group names must be unique within the selected **service**. If the entered name already exists, the system displays an error message and prevents the creation of a duplicate access group - **Description: **Enter a brief description of the access group to help administrators understand its purpose and intended use. The description can contain up to 100 characters. 3. Click **Add Access Group**.  Once the group is created, it will appear in the list of **Service Access Groups**.  ## Adding service IDs to an access group  To add a service ID to a group, complete the following steps: 1. From the Access Groups page, locate the access group that you want to manage. 2. Click the **ellipsis menu (⋮)**, and then select** View details**. 3. Navigate to the **Service IDs** tab within the group.  4. Click **+ Add Service ID**.  5. Select one or more service IDs and click **Add Service ID**.  The Service Access Group details page displays the associated **Service Name **and **Service ID**, making it easier for administrators to identify the service linked to the access group. Once all available Service IDs have been added, the button is disabled. To learn more, see [Service IDs](docId\:I2WXFQP2tstQi7GfvOF18). :::hint{type="info"} Once all available Service IDs have been added, the button is disabled.  ::: ## Assigning access policies to an access group To assign an access policy to an access group, complete the following steps: 1. From the Access Groups page, locate the access group that you want to manage and select it to open its details. 2. Navigate to the **Access Policies** tab.  3. Click **+ Assign Access Policy**.  4. Select the **service** you want to assign, followed by **Scope** and **Role.** 5. Click **Assign**.  To learn more, see [Access Policies](docId\:nb3bZm-bsA3w7AEFpbDzs). Custom groups require manual policy assignment. Default groups come with pre-assigned policies but can be extended with manual policy assignment with different scope.  :::hint{type="info"} - Policies associated with **Platform** and with **Administrator** role, cannot be removed  - Policies associated with All Identity and access enabled services with any role, cannot be removed  ::: ## Adding or removing users from an access group You can add or remove users from an access group to ensure that access permissions remain aligned with users' roles and responsibilities: 1. Click the **overflow** menu next to the access group that you want to manage. 2. Select **View Details**. The following two actions are available: - To **add** users, select **Add Member**, choose one or more users, and then select **Add**. - To **remove **a user, locate the user in the members list and select the **Delete** :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/cV_jsDIVpCCeGRqbdNkZW-20260602-173349.svg" alt caption width="57" height="57"} icon next to their name. 3. Confirm the action when prompted. ## Deleting a Service Access Group Administrators can delete Service Access Groups that are no longer needed to help maintain an organized and manageable access structure. Follow these steps to delete a Service Access Group from the system. 1. On the Access Groups page, scroll to the **Service Access Groups** section and locate the access group that you want to delete. To quickly find a specific group, use the Search field to filter the list. 2. In the Actions column, click the **ellipsis (...)**, and select **Delete Group** from the menu. :::hint{type="info"} - Default Bridge Groups cannot be removed; only custom Service Access Groups can be deleted.  ::: ## Editing membership You can update a user's access group membership after they have been added to the account. To learn more, see editing user membership under [Users](docId:7caOs2IBiKFBH9x-bz51X). [title] Secure SDLC Governance Dashboard [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ security concerns are addressed in large part by supplemental tools used by your team to expose potential vulnerabilities and to understand the range and nature of remedial actions to prevent security breaches. The Secure dashboard provides reports and scoring to assist security assessments using data accumulated from these tools. The Secure SDLC Governance Dashboard presents a table with six columns: - **Applications Name:** The name given to the application associated with a set of security tools at the time the application was created. - **Security Champion:** The e-mail address of the designated Security Champion for the application. - **Maturity Assessment report:** A link to a Sharepoint site containing a report with data regarding the application, aggragated from the secuirty tools composing the application. - **Last Maturity Assessment:** The last date an assessment was made using the tools associated with the application. - **Maturity Assessment Score:** A relative security health score assigned by the application based on data collected by the tools associated with the application; lower scores are associated with greater security vulnerability. A minimum score of 8 is deemed acceptable. Scores lower than 8 appear in red and scores of 8 or higher appear in black. - **Security Tools:** A list of security tools associated with the application. # Secure SDLC Governance Dashboard setup The Secure SDLC Governance Dashboard presents data acquired by security tools associated with a defined application. The application is defined using the Application Configuration feature. The feature prompts you for specific information such the application name, the tools you are using for each phase in the SDLC (in this case Security) and the Secuirty Champion. Use the following procedure: 1. List all your security applications. 2. Classify them by logical use. For example if you have some security tools that you use for user management and other tools for resource management, classify them accordingly. These classifications form the applications you will create in the Application Configuration feature. 3. Refer to [Application configuration: starting document](docId:4RH7DChSgjfxve349U0f5) 4. Navigate to **Settings and Utilities** →**Tools Configuration**. 5. Click the **Bring your Own Tools** tab. The service defaults to the **Create New Token** tab. 6. Enter a name for your token in the **Name** field. 7. Select Insights Controller for **Token Type**. 8. Click **Create**. 9. Call the Insight Controller API to enable your maturity reports. # Toggel: vulnerable services vs. all services By default, the dashboard shows only services that contain vulnerabilities, which means not all services are displayed. Click the Show All toggle to display all services for selected applictions, regardless of vulernability. [title] Connections management vaults [path] Administration/Connections Management/ # Internal vault In this scenario, connection details such as access keys, tokens, secret keys and similar information are stored in our Kyndryl internal vault using MongoDB. # External vault For customers with their own vault configuration, the connection details are stored in the customer's vault. However, the connection metadata is still retained in the Kyndryl internal vault. In these cases, all connections will be routed through the external vault, with Kyndryl having read-only access. A reference ID is generated and stored to connect to those credentials in the external vault. Therefore, all connections will go through the external vault, and Kyndryl will have secure, read-only access to the stored credentials, ensuring safety. # Pre-requisites: - The HashiCorp Vault instance must be accessible to . in the DCP environment. - Vault is configured with the appropriate authentication methods, such as App Role and Policies. Connection-Admin and Platform Viewer access must be granted to the Connection Manager. - The HashiCorp role ID and secret are currently active. - Additionally, the tenant ID of the account must be configured with the external vault. - Configure Connection-Manager to use the External Vault. # Configure to use external vault This configuration is specific to an account, and it is required since the vault-adapter is deployed in the same cluster as the connection-manager service. **API: **`PUT api/security/v1/vaults/config` | **Parameter** | **Type** | **Required** | **Description** | | ------------------------------------------ | ------------------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | string | Yes | Name identifier for the external vault configuration | | client\_url | string | Yes | The URL endpoint for the external vault adapter service.Make sure the client \_url is set to to \/api/security/v4/internal/externalvault-adapter. | | read\_only | boolean | No | Whether the vault connection is read-only (default: true) | | is\_default | boolean | No | Set this vault as the default credential provider | | is\_external | boolean | Yes | Indicates this is an external vault configuration | | id | string | No | Unique identifier for the vault configuration | # Configure external-vault-adapter for Hashi Corp Vault for the account Ensure the AppRole has permission to read secrets from the required paths. Make sure the roleId and secretId are generated by your HashiCorp Vault instance with appropriate policies. The URL must include the protocol **API:** `PUT /api/security/v4/internal/externalvault-adapter/configs` | **Parameter** | **Type** | **Required** | **Description** | | ------------------------------------------ | ------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------- | | id | string | Yes | Tenant identifier (typically the account/tenant ID) | | type | string | Yes | Vault type identifier (must be “hashicorp”) | | config.credentials.roleId | string | Yes | Hashi Corp Vault AppRole role ID | | config.credentials.secretId | string | Yes | Hashi Corp Vault AppRolesecret ID | | config.configuration.namespace | string | No | Vault namespace (for Vault Enterprise) | | config.configuration.url | string | Yes | Hashi Corp Vault server address | | read\_only | boolean | No | Whether the adapter should operate in read-only mode (default: true) | # APIs When using external vault configuration, the credentials array remains empty and credRefId is mandatory. - The reference ID must always be a Base64-encoded string, as the /character cannot be parsed in the API path. The reference ID will be decoded while accessing the vault. **API:** `POST /api/security/v3/connections` | **Parameter** | **Type** | **Required** | **Description** | | ------------------------------------------ | ------------------------------------- | ----------------------------------------- | ---------------------------------------------------------- | | credRefId | string | Yes | Reference id of the secret in vault. base64 encoded string | | displayName | string | Yes | Display name for the connection | | connectionCategory | string | Yes | Category of connection (e.g., “cloudProvider”) | | brokers | array | Yes | List of broker services that can access this connection | | provider.type | string | Yes | Provider type (e.g., “aws”,“azure”, “gcp”) | | provider.credentials | array | Yes | Credentials array (empty when using external vault) | | provider.configData | object | Yes | Provider-specific configuration data | | provider.configData.accountNumber | string | Yes | Cloud provider account number | | provider.configData.additionalInfo | string | No | Additional configuration information | # Retrieve credentials in clear text **API:** `GET /api/security/v3/internal/connections/", "secretKey": "" }, "options": {}, "version": 0 ``` [title] Quotations [path] Catalogs/Bridge Service Catalog/ # Request a quotation 1. From the page, select the service of your interest. 2. Select **Request a Quote** located next to the service package of your choice. 3. The configuration page opens. Depending on the type of service you selected to quote, a series of configuration steps needs to be completed before you can continue to the next step. 4. Once your configuration needs have been completed, select **Review**. 5. Review the information entered by clicking the chevron down arrow or the **Expand All Configured Items** toggle. If required, select **Edit** to change or add additional details. Otherwise, select **Submit** to finish. You will be redirected to the **Console Quotations** page. An email will also be sent confirming this request. For more information, see [Managing quotations](docId\:Hcrn9D6C0OltIz6Jg1FAO). :::hint{type="info"} At any point during the quotation process, you can select **Save for later** to save your quotation as a draft and complete it at a more convenient time. ::: [title] Deploy dashboard table view details [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Deploy module/ When you click on Deployment view details from the table view, a new dialog appears with the technical service details of the deployment and its configuration. The following elements are displayed in this dialog. - **Tool**: Name for the tool engine it belongs to - **Deployment summary**: includes status, application, duration, release, environment and deployment date - **Duration**: represents the time duration taken for deployment. - **Tabs**: include **Templates**, **Resources**, **Events**, **Logs**, **Input parameters** and **Output parameters** - **Templates**: the name of the template is displayed at the top, followed by the tabs **Overview**, **Config**, **Imports**, **Operations **and **Manifest** :::hint{type="info"} Other tool engines, such as Ansible, GoCD, etc., will present different tabs when view details are accessed. ::: For integration with other deployments tools, see: [Supported APIs](docId\:MH_sBk5zH61v56SDUI22p). [title] Atlassian Bitbucket, Bitbucket Cloud and Bitbucket server configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ Bitbucket is a tool that gives teams one place to plan projects, collaborate on code, test, and deploy. It provides one place for teams to collaborate on code from concept to Cloud, build quality code through automated testing, and confidently deploy code. # Bitbucket cloud For to pull data from Bitbucket Cloud, you must configure a Bitbucket Cloud account. will require the following information to create a Bitbucket Cloud account: 1. **Name**: peer account name. It could be any string and is used only for reference. 2. **Host**: Bitbucket cloud Host URL. 3. **Auth Type**: Authentication to be used for a given Bitbucket client. It has a value shown as token, which can be used for API token-based Authentication. For API token-based authentication, the following authentication fields are required in addition to common fields: 1. **User:** Username for Bitbucket. This is generally the username with which the user logged in to Bitbucket. 2. **APIKey:** Personal access token, generated from the following menu selection: your profile and settings → personal settings → app passwords The application also requires the following Bitbucket Cloud permissions: | **Permissions type** | **Name** | | ------------------------------------------------- | ------------------------------------- | | Account | read | | Workspace membership | read | | Projects | read | | Pull requests | read | | Issues | read | | Wikis | read and write | | Snippets | read | | Webhooks | read and write | | Pipelines | read | # Bitbucket server Bitbucket Server is self-hosted Git repository collaboration and management for professional teams. supports your use of Bitbucket Server. This topic describes the configuration requirements for this tool. For to pull data from Bitbucket Server, you must configure a Bitbucket Server account. will require the following information to create a Bitbucket Server account: 1. **Name**: peer account name. (Any string; used only for reference) 2. **Host**: Bitbucket server Host URL 3. **Auth Type**: Authentication to be used for a given Bitbucket client. It has a value shown as token, which can be used for API token-based Authentication. For API token-based authentication, the following authentication fields are required in addition to common fields: 1. **User:** Username for Bitbucket. Generally the username with which user logged in to Bitbucket. 2. **APIKey:** Personal access token, generated from the following menu selection: your profile and settings → personal settings → app passwords. The application also requires Bitbucket Server: Choose whether the account belongs to Bitbucket server version. # Configuration The user needs to select the workspace for Bitbucket Cloud. Please note that Bitbucket server doesn't support workspace. considers **default** as a workspace for Bitbucket server. The user needs to select the projects or repos which need to be tracked through the tool. For this purpose, tracking can be done at two levels: - Project Level: This will track all the repositories comprising this project. - Repository Level: This will track that particular repository. # Project 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 **Project** for Project 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. Then, select any project to be tracked and select configure. [title] Configure Azure boards and repository [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ A configured Azure DevOps connection is essential for successful data extraction from Azure Boards in the context of . Similarly, the requirement is to set up an Azure Cloud and Server connection to enable effective data integration from Azure Boards and Azure Repos. Anticipate future support for the following Azure tools as integral elements of our expanding offering: - **Azure Pipelines**: This powerful tool enables you to build, test and deploy using CI/CD that is language, platform, and cloud-agnostic. It offers seamless connection capabilities with GitHub or any other Git provider for continuous deployment. - **Azure Test Plans**: These tools instill confidence in your testing and shipping process. Utilize manual and exploratory testing tools to ensure robust product delivery. - **Azure Artifacts**: This feature allows you to create, host and share packages within your team and effortlessly add artifacts to your CI/CD pipelines with a single click. The integration of these advanced tools extends the robustness of our platform and ensures streamlined operations and superior output quality. - **Access Rights**: The connection should possess read permissions for the specific projects and work items we intend to synchronize, ensuring the necessary access for data retrieval. The following items are prerequisite to integration: - Azure DevOps Account: User must have an active Azure DevOps account. If user don't have one, user can sign up for free on the Azure DevOps account website. - Organization Membership: Ensure that Azure DevOps account is part of at least one organization. User need to be a member of an organization to access its projects and repositories. - Access Policy as Platform Administrator and Administrator: Ensure that the user creating the connection has the necessary access policies. The Platform Administrator role is required to create and manage connections effectively. The DevOps Intelligence Administrator role is also required to create and manage configurations. currently supports Azure DevOps APIs with version 7.0. Ensure that your Azure DevOps account is on a compatible version to ensure optimal functionality. # Integration of Azure Boards and Azure Repo with The process for onboarding Azure Boards comprises the following steps, each of which is a multistep procedure: 1. Create a Personal Access Token. 2. Create a connection. 3. Configure the application. 4. Onboard the Azure Board technical service. # Create a Personal Access Token Use the following procedure to create a Personal Access Token: 1. Navigate to Azure homepage. 2. Click **Access User settings** → **Personal access token** → **New Token**. 3. Ensure the Organization field is set to All accessible **organizations**. 4. Grant **Read** permissions for **Work Items**, **Code** and **Project and Team** fields. 5. Alternatively, for full access, choose **Full Access** to use the same PAT for pulling data from all Azure APIs. # Create a connection To pull data from Azure Boards, you must establish a connection between and GitHub Actions. Use the following procedure: 1. Click **Settings** → **IAM** → **Connections** → **Add New** → **Add connection**. 2. Select **Add Connection**. 3. For Azure Boards Cloud and Azure Boards Server: 1. Provide a local connection name. 2. Set the Host as the Azure DevOps cloud Host URL 3. Choose Authentication type as 'token'. For Azure Boards Server (server as host), use the toggle switch to set the host information to **Azure DevOps Server**. :::hint{type="info"} When the sync-all is enabled, all the organization and repositories for which the user has access will be synced. When the Archive is enabled, the connection is archived for future use. ::: # Configuring for Azure Boards, recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent section Configuring Azure Boards for , legacy customers. ::: Having created a connection, you must now configure the application. Use the following procedure: 1. Click **Settings & Utilities** → **Application Configuration**. 2. Select an existing application or create a new application. 3. Navigate to **Add Tools** step. 4. Select the phase as **Plan**. 5. Click **Add Tool Configuration**. 6. For Tool engine select **Azure Boards**. 7. Complete the configurations, presented in the following tabs: - **Release** - **Work Item Format** - **Bug Formats** - **Bug Severity** - **Bug Status** 8. Click **Add Configuration**. # Onboarding the Azure Boards technical service You must now onboard the technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configurations**. 2. Click on Overflow menu for the chosen application and click on Onboard Technical Service. 3. Select the plan for which you want to configure Azure Board. Note It would display all the phase for which this tools has been configured for the application. 4. For **Tool engine**, select **Azure Boards**. 5. For **Connection**, select the appropriate connection name from the dropdown list. You must also select tracking for organizations and repositories. # Organization tracking For Organization tracking, use the following procedure: 1. Select an existing application or create a new application. 2. Navigate to the "Add Tools" step. 3. For **Phase**, select **Plan**. 4. Click **Add Tool Configuration**. 5. For **Connection**, select the appropriate connection name from the dropdown list. 6. Select the Organization you want to track. Leave the **Projects** field unpopulated. # Repository Tracking For Repository tracking, use the following procedure: 1. Navigate to → **Settings & Utilities** → **Tools Configuration** → **Add Configuration**. 2. For **Tool Engine**, select **Azure DevOps**. 3. For **Connection**, select the appropriate connection name from the dropdown list. 4. From the **Organization** field, select the Organization containing the repository you want to track. 5. From the **Project** field, select the repository you want to track. # Deleting the Azure Boards technical service The administrator may, at will, delete the Azure Boards technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for**Plan**. 4. Click **Delete Technical Service**. 5. Click Azure Boards for **Select Tools Configured**. The service displays the **Select Organization** field 6. Select the appropriate organization. The service displays the **Select Repository** field. 7. Select the appropriate Repository. 8. Click **Delete**. # Configuring Azure Repo for recent customers :::hint{type="info"} The procedures in this section are valid only for customers onboarded 6 June, 2024 or after. ::: Use the following procedure to configure the for Azure Repo: :::hint{type="info"} Tools must be configured for a specific application in a specific DevOps phase. In step 2 of the following procedure you are choosing the application and DevOps phase to associate with Azure Repo as part of the configuration procedure. ::: 1. Click** Settings & Utilities** → **Application Configuration**. You will see a list of existing applications. 2. Select the existing application for which you want to configure Azure Repo or create a new application. 3. Click the overflow menu (vertical ellipsis) on the Develop row for the selected application. 4. Select **Add New Tool Configuration** from the overflow menu. The service displays the Add Tool Configuration form. 5. Select Azure Repo for **Tool Engine**. The service displays the Pull Request Status field. 6. Enter the status of the pull request for the current version of Azure Repo. 7. Click **Submit**. # Onboarding Azure Repo After configuring Azure Repo, you must onboard the technical service. Use the following procedure: 1. Click the overflow menu for the selected application. 2. Select **Onboard Technical Service**. The service displays the Onboard Technical Service form. 3. Select **Develop** for **DevOps Phase**. The service displays the Tool Engine field. 4. Select **Azure Repo**. The service displays the **Select Connection** field. 5. Select the appropriate connection. The service displays the **Select Organization** field. 6. Select the appropriate organization. The service displays the **Select Projects** field. 7. Select the appropriate project. The service navigates to the Application Configuration page. 8. Click **Onboard**. 9. You now have the option of clicking the overflow menu for Develop and selecting **Edit/Delete Tools Configuration** to confirm that Azure Repo has been fully configured. # Deleting Azure Repo as a technical service The administrator may, at will, delete the Azure Repo technical service. Use the following procedure: 1. Navigate to → **Settings & Utilities** → **Application Configuration**. 2. Expand the application to view all associated phases. 3. Click the Overflow menu for **Develop**. 4. Click **Delete Technical Service**. 5. Click Azure Repo for **Select Tools Configured**. The service displays the **Select Organization** field 6. Select the appropriate organization. The service displays the **Select Repository** field. 7. Select the appropriate Repository. 8. Click **Delete**. [title] 09. Support [path] / [title] Build Table view [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Untitled/ When you click the Technical Service View Details from the Table View, a new dialog appears with the service details. The following elements are displayed in this dialog: - The **Build Details** plus the name of the technical services in question. - Two tabs that display different build information: **Details** and **Analysis history**. - The next item in the technical services details view is a time frame with the following selections: - **1D**: 1 Day, last 24 hours - **7D**: Last 7 Days - **14D**: Last 14 Days - **2M**: Last 2 Months - **3M**: Last 3 Months - **6M**: Last 6 Months - **Custom duration**: A custom date range within 6 months # Details tab The Details tab presents two graphs: **Build status** and **Build duration**. # Build status The Build Status represents the status of total build requests for the selected period. The Build Status data is presented in a bar graph governed by two axes. The **Passed** Builds are represented in green color, and the **Failed** Builds are represented in red color. The Build Status bar graph presents two axes, described as follows: - **X-Axis**: The X-axis corresponds to the timeframe in which builds took place. By hovering over the graph, the following data is presented: - **Duration:** The cut-out date for quantified builds. - **Total Builds:** The total number of builds for the timeframe. - **Group:** Either Passed or Failed builds. - **Y-Axis **: The Y-axis corresponds to the total number of Builds in the selected timeframe. By placing the cursor right above a bar, in alignment with the center of it, the following information is displayed: - **Duration:** The cut-out date for quantified builds. - **Total builds:** Total number of builds for a specific category (Passed or Failed). - **Group:** Either Passed or Failed builds. :::hint{type="info"} This graph allows you to click on either one of the **Passed** or **Failed** check boxes at the bottom only display data for a specific build status. ::: # Build duration Build Duration represents the total duration of builds for the selected period. The Build Duration data is presented in a bar graph governed by two axes. The Build Duration bar graph presents two axes, described as follows: - **X-Axis (Duration):** The X-axis corresponds to the timeframe in which builds took place. By hovering over the graph, the following data is presented: - **Duration:** The cut-out date for quantified builds. - **Execution Duration:** Duration of execution measured in seconds. - **Group:** Passed category of Builds. :::hint{type="info"} The **Build Duration** graph only presents data for the Passed builds. ::: - **Y-Axis (Execution Duration (Average in seconds):** The Y-axis corresponds to the Execution duration measured in seconds. # Analysis history The **Analysis history** tab presents a table that provides **Build Executions** data in a tabular form and enables a detailed view of each Build. Each row in the table displays information for Builds, separated by columns of information type: - **Build id:** The ID associated with the Build. - **Status:** The build status (Passed or Failed). - **Duration:** The build duration is measured in seconds. - **Build engine:** The Build tool source. - **Build at:** The date and time when the build took place. - **Build URL:** URL generated by the Build engine. :::hint{type="info"} Only the Build at column can be sorted, and above this table, you will find a **Settings** icon that allows changing the table settings to show or hide pre-selected columns. ::: [title] Priority Notifications across all tenants [path] Administration/Bridge Notification Service/ Platform Administrators can create and manage **Priority Notifications** from the **Bridge Operations tenant Control Tower **to communicate important information across the organization. These tenant-level notifications can be displayed to users across all accounts and regions or targeted to specific audiences based on business needs. Priority Notifications require users to acknowledge the message before continuing, helping ensure critical announcements are seen and acted upon when necessary. These notifications help keep users informed about critical platform updates, service disruptions, maintenance activities and other important events, reducing confusion and minimizing unnecessary support requests. Administrators can create, manage and target notifications across all accounts or specific accounts to ensure important information reaches the intended audience while avoiding notification fatigue. Administrators can create notifications and update them as requirements change and delete them when they are no longer required. # Key capabilities Priority Notifications enable administrators to communicate critical platform information to users at the tenant level. The main capabilities are grouped into notification management and notification delivery with user acknowledgement. **Notification management:** Capabilities related to creating, configuring, targeting and maintaining Priority notifications: - Create Priority Notifications. - Configure notification title, message, severity, duration and status. - Publish notifications across all accounts or selected accounts. - Filter and target notifications by region and account. - Save notifications as: - **Draft**: The notification has been created and saved but is not yet available to users. - **Upcoming**: The notification has been configured and is scheduled to become visible at a future date or time. - **Active**: The notification is currently displayed to the targeted audience and is available for user acknowledgement. - Edit existing notifications. - Delete notifications when they are no longer required. - Notifications are automatically removed after their configured expiration date to help keep communications relevant and up to date. **Notification delivery and user acknowledgement: **Capabilities related to how notifications are presented to users and how users interact with them. - Display notifications across all accounts by default. - Deliver notifications only to selected accounts when targeting is configured. - Require users to acknowledge notifications. - Keep unacknowledged notifications visible until acknowledged or expired. - Maintain acknowledgement status for users across multiple accounts. - Preserve read and unread status when users switch between accounts. # Administrator configured notifications across tenants Platform Administrators can create and manage notifications that are displayed across multiple accounts and regions within a tenant. These notifications help communicate important information to a broad audience, ensuring consistent visibility and awareness across the organization while allowing administrators to target specific accounts or regions when needed. ## Create Priority Notifications across tenants When creating Priority Notifications, you can choose to display the notification **across all accounts and regions** or target it to **specific accounts and regions**. The notification audience is determined by the selections made in the **Region **and **Accounts **fields during the notification creation process. This flexibility allows administrators to distribute important announcements broadly across the accounts or focus them on a specific account on business or operational requirements. Follow these steps to set up a notification across accounts: 1. Sign in to **Kyndryl Bridge** and open the **Navigation Menu**. 2. Select **Control Tower**. 3. Navigate to **Notifications Management**. 4. The **Notifications Management** page opens, select **Priority Notifications** tab. 5. Click **+ Create Priority Notifications.** 6. Enter the following required information: - **Notification Title**: Enter the title of the notification. The title can contain up to **250 characters**. - **Message Content**: Enter a clear and detailed message describing the information, announcement or event that users must acknowledge. Maximum **1000 **characters. - **Severity**: Select the notification severity level: - **Critical**: Indicates urgent information that requires immediate attention. - **Warning**: Highlights information that users should be aware of. - **Info**: Provides general informational updates. - **Start Date**: Specifies when the notification becomes active and visible to users. - **End Date**: Specifies when the notification expires. Notifications can remain active for a maximum of **365 days**. - **Account Selection (Optional)**: Select this option to display Priority Notifications to a specific set of accounts instead of all accounts. **By default**, notifications are displayed **across all accounts**; however, when account targeting is enabled, you must select more than one account. - **Filter by Region**: Select one or more regions to narrow the list of available accounts and simplify account selection when configuring the notification of the audience. Only accounts associated with the selected regions are displayed. Available region filters: :::Paragraph{listStyleType="circle" indent="2"} EU Shared = "eu" ::: :::Paragraph{listStyleType="circle" indent="2"} CA Shared = "ca" ::: :::Paragraph{listStyleType="circle" indent="2"} US Shared = "us" ::: :::Paragraph{listStyleType="circle" indent="2"} AP Shared = "au" ::: :::Paragraph{listStyleType="circle" indent="2"} Japan Shared = "jp" ::: :::Paragraph{listStyleType="circle" indent="2"} India Shared = "in" ::: :::Paragraph{listStyleType="circle" indent="2"} EU Restricted = "eu-r" ::: :::Paragraph{listStyleType="circle" indent="2"} US Restricted = "us-r" ::: To display the notification to all accounts across all regions, leave the region selection set to **All Regions**. When individual regions are selected, the **All Regions** option is automatically cleared. The region filter displays a counter (for example, 3 Regions) indicating the number of selected regions. - **Select Accounts**: Choose the accounts that should receive the notification. 7. Click **Create**, **Save Draft** or **Cancel**: Closes the page without saving changes. After selecting **Create**, a success message is displayed to confirm that the Priority Notification was created successfully. ### Considerations when selecting an account: :::Paragraph{listStyleType="circle" indent="2"} The account list is automatically filtered to show only accounts that belong to the selected regions. To display the notification across all accounts, leave the account selection set to **All Accounts**. ::: :::Paragraph{listStyleType="circle" indent="2"} At least **two accounts** must be selected when creating a targeted account notification. ::: :::Paragraph{listStyleType="circle" indent="2"} If additional accounts are added later by editing the notification, the notification is automatically displayed to users in the newly added accounts. ::: :::Paragraph{listStyleType="circle" indent="2"} Only users within the selected accounts can view the configured Priority Notifications. ::: :::Paragraph{listStyleType="circle" indent="2"} The accounts selected when creating or editing a Priority Notifications are displayed in the **Accounts** column of the **Priority Notifications** table, allowing administrators to quickly identify the notification audience. ::: ## Edit Priority Notifications across tenants A Platform Administrator can update the accounts and regions associated with an existing Priority Notifications by accessing** Bridge Operations tenant (Control Tower).** This process allows administrators to modify the notification audience and save the changes to update the notification configuration. Follow these steps to edit an existing notification: 1. From the **Notifications Management** page opens, select **Priority Notifications** tab. 2. Locate the notification you want to edit in the **Priority Notifications** table. 3. Select the **ellipsis menu (⋯)** for the notification and select **Edit**. 4. Update the required notification settings. Select **Update** to save your changes. 5. After the notification is successfully updated, a confirmation message is displayed and the Priority Notifications table is refreshed to reflect the updated notification details. ### Considerations for editing a Priority Notifications: - When editing a notification, all existing notification settings are pre-populated with the current values. - Existing region and account selections remain available and can be modified as needed. - The selected audience can be expanded by adding additional regions or accounts. - Status changes take effect according to the selected notification configuration. - If the notification audience is configured for specific accounts, more than one account must remain selected. Otherwise, an error message is displayed. - Notifications continue to follow their configured duration and are automatically removed after their expiration date. ## Delete Priority Notifications across tenants Platform Administrators can delete a Priority Notifications that is no longer needed. Deleting a notification removes it from the **Priority Notifications** **table **and prevents it from being displayed to users across all associated accounts and regions. Because this action cannot be undone, review the notification details carefully before confirming the deletion. Follow these steps to delete a notification: 1. From the **Notifications Management** page opens, select **Priority Notifications** tab. 2. Locate the notification you want to edit in the **Priority Notifications** table. 3. Select the **ellipsis menu (⋯)** for the notification and select **Delete.** 4. A confirmation message is displayed to prevent accidental deletion, review the notification details carefully before proceeding. 5. Select **Yes, delete it!** to permanently remove the notification or **No, keep it** to cancel the deletion and return to the Priority Notifications table. After the notification is successfully Deleted, a confirmation message is displayed and the Priority Notifications table is refreshed to reflect the updated notification details. :::hint{type="info"} Deleting a Priority Notifications is irreversible. ::: ## View Priority Notifications across tenants When a Priority Notification is configured to display at sign-in, a **pop-up notification **appears in the upper-right corner of the page after the user signs in to Kyndryl Bridge. Select **Read Now** to open the notification side panel, and then select **View All Priority Notifications** to access the **Priority Notifications** details page. ### Notification details page From this page, users can view and filter Priority Notifications, helping them stay informed about important updates, alerts and announcements relevant to their accounts. The Notifications page can also be accessed by following this path: 1. From the Kyndryl Bridge main menu, select **Home**. 2. In the left navigation menu, expand **Bridge** and select **Notifications**. 3. On the **Notifications** page, select the **Priority Notifications** **tab**. ## Notification behavior across accounts When a Priority Notification is configured for multiple accounts, the following behavior applies: - Priority Notifications are displayed in all accounts included in the notification audience, including Operations accounts when configured. - Users see the same notification in every account that is part of the selected audience. - Notifications maintain a single acknowledgment state for each user across all included accounts. Once a user acknowledges a notification in any included account, it remains acknowledged across all other included accounts, eliminating the need to acknowledge the same notification multiple times. - If a notification has not been acknowledged, it remains unread and continues to appear when the user switches between included accounts. - The notification continues to be displayed across all included accounts until the user acknowledges it. To learn more about Bridge Notifications service, see [Bridge Notification Service.](docId\:Cc4Sf-ex6YCcA3P06YELV) . [title] Tag Definitions [path] Administration/Bridge tag management/ The **Tag Definitions **empowers administrators to create and manage consistent, pre-defined tag keys and the necessary constraints for tag values. Tag Definitions are a powerful tool in . They streamline the management of similar tag keys, eliminate duplication, save time and make your tag management more efficient. By using tag definitions, you can be more productive in your tag management tasks. # Access Tag Definitions Access **Tag Definitions** to view and manage existing Tag Definitions, create new tags and maintain consistent tagging across : 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Tag Management** → Bridge Tag Management 2. The **Tag Definitions** page displays, providing a centralized view of all existing tag definitions and available actions for managing them. # Tag Definitions page Tag Definitions page provides a centralized view of all tag definitions available in Kyndryl Bridge. From this page, administrators can search, filter, create and import tag definitions to support consistent resource classification, governance and reporting across services. The Tag Definitions page includes the following **components**: - **Search key**: Search for a specific tag definition by tag key name. - **Filter**: Refine the list of tag definitions based on defined criteria. - **Create Definition**: Create a new tag definition. - **Import Definition**: Import one or more tag definitions from a supported file. ## Tag Definitions table Provides a centralized workspace for managing tag definitions and supporting tagging governance across . The table displays all available tag definitions, including: :::Paragraph{listStyleType="disc" indent="2"} **Tag Key**: The unique name of the tag definition. ::: :::Paragraph{listStyleType="disc" indent="2"} **Tag Category**: The category assigned to the tag definition. ::: :::Paragraph{listStyleType="disc" indent="2"} **Value Type**: Indicates the type of values allowed for the tag. ::: :::Paragraph{listStyleType="disc" indent="2"} **Status**: Shows whether the tag definition is active or inactive. ::: # Tag Definitions categories Select a **Category** to classify the Tag Definition according to its functional or operational domain. Categories help organize tag definitions and promote consistent tagging, governance, reporting and resource management across . The following categories are available: | **Category** | **Description** | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Application Management | Refers to managing IT health and ensuring business application availability, focusing on application types and their dependency on IT infrastructure. The performance of applications depends on the stability of components such as servers, networks and storage systems. | | Asset Management | Encompasses the entire lifecycle of managing assets, from procurement to disposal, including financial aspects like license management and relies on Inventory Management. | | Automation | Refers to all content related to automation, regardless of the technology used. This includes the success/failure of automation and opportunities for further improvement. | | Backup and Resiliency | Refers to all content related to data backup, archival storage, redundancy and resilience. | | Digital Workplace Management | Refers to all content associated with end-user device support, management, and related services. Like a mainframe, it has its own category as it is typically managed separately. Other categories will also have workplace content. | | Environment Build and Decommission | Refers to all aspects of infrastructure build-out, including network, servers, operating systems and software installations. It also addresses system integration in the Service and Systems Management environment, focusing on backup and support and their effects on operational stability. Registering the new server updates records for traceability and readiness. | | Event Management | Covers all content related to system monitoring and management, including events from any monitoring technology. | | Growth | Refers to all content associated with opportunity development and business growth for Kyndryl. | | Hardware and Software Currency | Refers to tracking End of Life and End of Support for hardware, Operating Systems and Software. It offers Kyndryl opportunities to collaborate with customers to improve their currency position, leading to better service levels and lower costs. | | Identity and Access Management | Refers to all content associated with Identity and Access management and their systems. | | Inventory Management | Refers to all content related to the Inventory, including both Kyndryl-owned and customer-owned items. This encompasses devices, operating systems and installed software. It also includes efforts to optimize hardware and software to improve efficiency and reduce costs. | | Mainframe Management | Refers to all content related to the mainframe, categorized by technology type due to distinct skills and management. Other categories, such as Inventory, will also include mainframe content. | | Network Management | Covers all content related to the Network, including management and configuration. Performance and Capacity are expected to encompass the network in their end-to-end perspective. | | Performance and Capacity | Refers to all content related to performance and capacity management, regardless of technology type. | | Security and Vulnerability Management | Covers all aspects of system and environment security, focusing on adherence to best practices and compliance standards like ISO and GDPR. Key elements include patch management and vulnerability assessments to mitigate risks and ensure compliance. | | Service Maintenance | Refers to all content related to daily technical operations, including data availability, audit logs, command histories and certificate expiration. Supports day-to-day operations. | | Service Management | Refers to all content related to Service Management, including Meantime Between Outages, Root Cause Analysis, Critical Situation Management and SLA Management. It encompasses topics related to tickets, specifically Incident, Problem, Change and Service Requests, as well as use cases for viewing current situations and ticket volumes. | | Storage Management | Refers to all content associated with Storage, its management, and configuration. It is expected that Performance and Capacity will also include Storage as part of their end-to-end perspective. | | Sustainability | Refers to all content associated with sustainability, carbon footprint, and environmental concerns. This category focuses on measuring and actively reducing ecological impacts. | | Transformation Management | Refers to all content associated with Kyndryl programs and projects. This can include information on the progress of various aspects of the transformation. | # Managing Tag Definitions Tag administrators can edit, use templates and delete tag definitions. To edit Tag Definitions follow these steps: 1. From the Tag Definitions table, l**ocate the tag definition** that you want to manage. 2. Click the** ellipsis (⋮)** in the Actions column. The following actions are available for the selected tag definition: - **Audit information**: Here, you can find the owner information, creation date, last user who modified the item, and the date of the latest update. - **History**: The history record is tracked only for definitions in the active state. The changes tracked are only at the metadata level. - **Edit**: A details page opens, allowing administrators to modify it. Only the **Key Name** will be read-only. - **Use as Template**: Administrators can clone the existing definition, except for keys. Categories, constraints, and scope are pre-populated when this option is selected. An edit page opens where you can make the corresponding updates. - **Delete**: Administrators can delete the current definition. # Creating Tag Definitions You can create definitions with all basic details (tag key, description, tag categories), constraints and scope (optional). Additionally, you can customize tag categories if needed. Follow these steps to create Tag Definitions: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Tag Management** → Bridge Tag Management 2. The **Tag Definitions** page displays, click **Create Tag Definition** to begin creating a new tag definition. 3. Complete the required information, including the tag key, category, description and value type. 4. Click the **save** button to go back to the previous steps and **edit **the tag without losing the tag creation progress. ## Basic details 1. Continue to edit the Tag completing the basic details of the tag definition: - **State: **Define the status of the new item. If you select active status, the definition will be available for all users. Otherwise, If a new tag key is saved in a draft state, those tag keys will not be available. By default, the tag definition for a new tag key is set in **Draft** state. - **Key: **This is a required field. You can select a key from the drop-down menu (case-sensitive) or create a new one by clicking the **Create Key + **link. To avoid duplicate items, the key for tag definitions must be unique; otherwise, an error message is displayed indicating the duplicate issue. If a tag definition attempts to be created for a tag key that already exists without a definition, the system will display an error message. The tag management allows tag keys with a minimum of 1 character and a maximum of 256 characters, including digits from 0 to 9 and special characters (!@$%\*();: \_ - / \\). - **Description:** This is a required field. Add a description for the definitions that do not exceed 100 characters. - **Tag Categories:** Tag categories help organize and manage tags. You can select categories from the drop-down menu (Operations, Location, Security, Finance, Cost Center, Business Unit, Automation and Technical) or customize a category that suits your needs. Please note that the system does not permit duplicate tag categories in the same account. 2. After all details are added, click the **Next **button. ## Define constraints 1. Define a value type for the tag definition. By default, this is set as a string value. - Value Type: This field is required. Only one value type can be selected per tag definition. - **Regex Pattern: **Add a regular expression (set of strings). - **Enumerated List: **Define a list of allowed values here. - **String: **Add a sequence of characters. 2. Click **Add Constraint +** link based on the value type previously selected - Enumerated list: Enter the values of the list separated by a comma. - Regex: Enter the string set. - String: Define the number of characters allowed. - Min chars count. By default, it sets a minimum of 3 characters. - Max chars count: By default, it sets a maximum of 100 characters. - Special character allowed? Set a list of allowed characters. 3. After all details are added, click the **Next **button. ## Define scope (Optional) Scope determines the boundaries within which tags are allowed to be performed. The attributes that would be used to define the Scope are Provider and Resource Type. This allows you to specify the context in which the tag is applicable, making your tag management more precise and efficient. By default, **All** option is selected, indicating provider and resource types are applicable across all providers. Follow these steps to define the scope: 1. **Define the provider scope: **You can select one or more supported providers (AWS, Azure, GCP, IBM, Local, among others) from the drop-down list. 2. **Define the resource type: **Based on the selected provider, the resource type field shows the applicable tag definition. You can choose one or more resource types. 3. Once the scope is delimited, click the **Next** button. ## Review This is the most important step of the process. Confirm all details added are correct for the tag definition about to be created. Review all tag definition details to ensure the information is accurate and complete: 1. If any changes are needed, click the corresponding step link and update the information. 2. When all details are correct, click **Submit**. A confirmation message displays: *“Tag definition created successfully. You have successfully created \[tag key name].”* 3. To cancel the operation, click **Cancel**. A confirmation message displays: *“Are you sure you want to cancel? You will lose your edits for this tag definition. This action is permanent and cannot be undone.”* 4. Click **Confirm** to cancel the operation and discard all changes or click **Nevermind** to return to the tag definition and continue editing. # Importing Tag Definitions into These definitions imported into the system would be in an active state and immediately available to bridge applications/services. Tag definition import capability would be available for both account-level tags and for [Global Tags](docId\:pBvNOfKqugyUqJzyHoR_w) (Global control plane). The display of data remains consistent with the current tagging process. After importing, users can view, edit, or delete tags. Follow these steps to Import Definitions: 1. From the page, click **Import Definition**. The Bulk Import Tag Definitions window displays. 2. Read the note carefully from the import UI, as it outlines the mandatory and optional attributes essential for a successful import. Without these, the imports will fail. A CSV & JSON template sample is provided, including all required attributes, eliminating potential errors during the process. 3. Ensure the Tag keys are unique 4. Drag and drop a file. Otherwise, you can browse a file from your device. 5. Click **Upload**. :::hint{type="info"} If a tag category added through the import file already exists in the system as an OOB tag category, the existing description will be displayed in the UI. ::: If the tag definition is imported at the account level (DCP), it is an account-specific tag; if it is imported from the global plane (GCP), it is a global tag and is automatically prefixed with 'Global\_tagname'. To stay updated, monitor the toast notification currently displayed in the upper-right corner of the screen. A successful tag import notification indicates that your process is complete and that the new tag definitions will remain in an **Active** state within the system. If you see a partial or failed bulk import notification, recheck whether the required attributes were added correctly in the uploaded file. ## In-App notifications for Tag Definition The bulk import capability for tag definitions enables delivery teams to upload tag definitions in bulk eliminating the need for manual entry. Imported definitions are automatically activated and ready for use by Bridge applications. Users receive in-app notifications on the import outcome and can download a detailed report to review results and identify any errors. This ensures efficient onboarding of tag definitions and improved visibility into the import process. As the process is asynchronous, users receive updates indicating whether the import is: - **Successful**: Indicates that all tags definition everywhere were imported successfully, including the total count of imported tags. - **Unsuccessful**: Indicates that the import failed completely, and no tags were imported. - **Partially successful**: Indicates that some tags were imported successfully while others failed, including counts for both. ## Tag Definition import report   Notifications include an option to download a detailed Tag Definition import report. The import report provides a detailed, **downloadable summary** of the tag import results, enabling users to quickly validate which tags were successfully imported and identify any failures. The import report is available from the in-app notification for all import outcomes (successful, unsuccessful, and partially successful). It contains the following columns: - **Tag key**: The identifier of the tag being imported. - **Tag value**: The value associated with the tag. - **Status**: Indicates whether each entry was **Success** or **Failed.** - **Reason for failure**: Provides an explanation for failed entries. Common failure reasons may include tag key already exist (in the system, duplicate tag key (duplicate key within the file) or No tag key available etc. Tag definition import report complements in-app notifications by offering a row-level view of the import outcome for better troubleshooting and auditability. [title] SonarQube Enterprise Edition configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Secure module/ SonarQube is the leading tool for continuously inspecting the Code Quality and Security of codebases and guiding development teams during Code Reviews. For to pull data from SonarQube, you must configure a SonarQube account.The setup for DevOps integration with SonarQube, requires several procedures, most of which are in , but the initial procedure requires access to the SonarQube console. # Prerequisites The following items are prerequisite to configuration: - **SonarQube Account:** The administrator should have an active SonarQube account on the instance for which the connection is intended. - **Access to a SonarQube Instance:** Ensure that you have access to the specific SonarQube instance where the projects, test suites and test cases are hosted. Use the URL or web address of the SonarQube instance user want to connect to. - **Project Membership:** Users must be part of the SonarQube projects you intend to access. Ensure that users have the necessary project membership to retrieve information about projects, test suites and test cases. - **Access Policy as Platform Administrator and **&#xNAN;** Administrator:** Ensure that the user has the necessary access policies. The user should have the Platform Administrator role to create and manage connections effectively. Users must also have the DevOps Intelligence Administrator role, which allows them to create and manage configurations. Review and execute the content in the following sections in the order they are presented. # Integration of SonarQube with The process for onboarding SonarQube comprises the following steps, each of which is a multistep procedure: - Create a Personal Access Token. - Create a connection. - Configure the application. - Onboard the SonarQube technical service. # Creating a SonarQube access token Use the following procedure to create a SonarQube access token: 1. Navigate to the top right corner of the SonarQube homepage. 2. Click on your profile picture and select **My Account**. 3. Go to the **Security** tab. 4. Provide the token name. 5. Click on **Generate**. # Creating a connection Establishing a connection to SonarQube is prerequisite to configuring the service. Use the following procedure: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Service Operations** → **Connections Management ** 2. From the left navigation menu, select **Tool Connections**. The **Tool Connections** page is displayed. 3. Click **Add Connection** to create a new tool connection. 4. Choose Connection type as **SonarQube.** 5. Select in **Supported apps** drop down. 6. Provide **Connection name **and other non-mandatory field information. 7. Click **Nex**t 8. Enter th**e Host: ** - SonarQube API URL of the SonarQube Host (e.g.,https\://sonarqube.kyndryl.net/). 9. Click** Next** and enter the **Username** and **APIkey** which have access to projects which need to be pull on . # Configuring for SonarQube for Secure phase, recent customers :::hint{type="info"} This procedure is valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent Configure for SonarQube, legacy customers. ::: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **ToolChain \&Pipeline ** → **DevOps Intelligence **→ **Settings & Utilities **→ **Application Configurations** 2. Select an existing application or create a new application. 3. Navigate to **Add Tools** step. 4. Select the phase as **Secure**. SonarQube is compatible in Test and Secure phases. 5. Click **Add Tool Configuration**. 6. Select Secure Categories **Static Scan**. 7. Select SonarQube for **Tool engine**. 8. Complete the required information, categorized by the three tabs: - **Release**: The tool configuration inherits the release prefix and variable from the application. To override these values at the tool level, click the **Edit** button and make the necessary changes. Changing the values here will not affect the release prefix and variable set in the application. Data will be pulled only if releaseName can be extracted from branchName, making releaseName identical to branchName. Data will also be pulled for branches with the main parameter is set to true, apart from the identified release branches. - prefix signifies the starting sequence of characters for releases, with the default value being empty. - variable signifies the starting sequence of characters for releases, with the default value being empty. - use the release ID to identify release names and the release branches. - **Severity**: considers severity category to be captured into five levels. Map your applications bug severity with predefined severity levels (BLOCKER, CRITICAL, MAJOR, MINOR, INFO) - **State**: - Map your bug status to two states: **Resolved** or **Unresolved**. - Select all the bugs for which status is Resolved, all those for which bug statuses which is Unresolved. 9. Click **Add Configuration**. # Configuring for SonarQube for Test phase :::hint{type="info"} This procedure is valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent Configure for SonarQube, legacy customers. ::: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → → **Settings & Utilities **→ **Application Configurations**. 2. Select an existing application or create a new application. 3. Navigate to **Add Tools** step. 4. Select the phase as **TestSecure**. :::hint{type="info"} SonarQube is compatible in Test and Secure phases. ::: 5. Press **Add Tool Configuration**. 6. Select SonarQube for **Tool engine**. 7. Complete the required information categorized into two tabs, **Release** and **Test Analysis parameter**. See the previous usage notes for \*Release title construction. Provide the environment name to be used for analysis in **Test Analysis**. 8. Click **Add Configuration**. # Onboarding the technical service Having configured DevOps Intelligence to pull data from SonarQube, you must now onboard it as a technical service. Take in consideration the following caveats: - SonarQube can be configured only at the project level. - Multiple metrics can be selected against projects. - Metrics is merely way to restrict which data is available to users for a given project. - SonarQube syncs only data available with connections configured against it. - At the project level, technical services are always configured as mutually exclusive – i. - If two users having the same privileges attempt to onboard technical services for the same project, only the first user is allowed to create the technical service; it will not be listed for the second user to onboard. ## To onboard technical services 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → → **Settings & Utilities **→ **Application Configurations**. 2. Click Overflow menu for the chosen application and click **Onboard Technical Service**. 3. Select the phase for which you want to configure SonarQube. 4. Select **Secure** category. 5. Select the tool engine as **SonarQube**. 6. Connection - select the connection name from the drop down. ## Deleting the SonarQube technical service The administrator may, at will, delete the SonarQube technical service. Use the following procedure: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → → **Settings & Utilities **→ **Application Configurations**. 2. Expand the application to see all the associated phases. 3. Click the Overflow menu associated with the phase (**Test** or **Secure**) 4. Click **Delete Technical Service**. In the case of **Secure** phase, you must also select the **Secure** category as **Static Scan**. 5. Select the tool engine as SonarQube. 6. Select the Project. 7. Click **Delete Technical Service**. # Reviewing test suite data in After has been fully configured, displays all test suites being tracked by SonarQube in the table view at the bottom of the Test page. The view provides general information about each test suite such as status (how many tests were Skipped, Passed, Failed and Blocked), Total number of tests in the suite, and the execution date. Detailed information about each suite are available by clicking the overflow menu for that test suite and selecting **View Details**. responds by navigating to the Details page for that suite, where additional information regarding activity and history is available. The Activity tab presents a graphic presentation of the tabular data on the table. The Historical details tab presents additional details such as Code Smells and Bugs. On both tabs you have the option of selecting a time frame for testing from the Duration control located in the upper right. # Configuring for SonarQube, legacy customers :::hint{type="info"} This procedure is valid only for customers onboarded before 6 June 2024. ::: Use the following procedure to configure DevOps Intelligence for SonarQube: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → → **Settings & Utilities **→ **Application Configurations**. 2. Select SonarQube as the **Tool Engine**. 3. Under **Connection**, select the appropriate connection name. 4. Select the project and metrics you want to track in . Specific metrics are optional; will track all default metrics. Please take notice of the following service configuration caveats: - Configurations can only be configured at the project level. - Multiple metrics can be selected against projects. - Selected metrics restrict data to that required for a given project. - only syncs the data available from the selected connection configured against it. - At the project level, service configurations are always configured as mutually exclusive. That is, if two users having the same privileges attempt to create service configuration for the same project, only the first user is allowed to create the service configuration. This is because after the first user has completed the configuration process, the project is already configured. The project will ***not*** be listed for the second user to configure. [title] DSRR Candidacy [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ The **DSRR Candidacy** page provides a centralized experience for monitoring work items as they progress through the DSRR process. It enables Release Managers and Development Managers to track approval readiness, review pending sign-offs, identify violations and exceptions, and determine whether work items are ready to advance through DSRR Entry and DSRR Exit stages. Approver configurations are defined in the **DSRR Approval Management** page, and the required approvers have been assigned for each approval type. These prerequisites allow the system to accurately validate approvals, track compliance and support release readiness decisions. # Roles and permissions The DSRR Candidacy page is available to users with access to . Available actions depend on the user's assigned role. | **Role** | **Permissions** | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - **Release Manager** | * View DSRR status. * Send notifications to stakeholders. * Approve and reject DSRR Entry and DSRR Exit reviews.  * Manage exceptions. * Review approval readiness and sign-off compliance. * Only Release Managers can send notifications and perform approval or rejection actions. * Can update the Mandatory Approval Needed option in DSRR Approver Management. | | **Development Manager** | - View DSRR status.  - Monitor approval progress.  - Review outstanding sign-offs.  - Identify responsible approvers.  - Track violations and exceptions.  - Monitor work item readiness throughout the DSRR process. | # DSRR Candidacy access Follow these steps to enable the features: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services **→ **Platform Services **→ **Toolchain & Pipeline** → **DevOps Intelligence.** 2. From the left navigation menu, navigate to** DevSecOps & Software Readiness Review** 3. On the **DevSecOps & Software Readiness Review **page Select **DSRR Candidacy Timeline** tab. ## DSRR Candidacy page The **DSRR Candidacy** tab provides a high-level view of application readiness throughout the DSRR process. It helps you track approval status, identify items requiring attention and monitor progression through DSRR Entry and DSRR Exit stages. The **Release Readiness Summary** section displays key metrics that provide insight into the current state of work items and approval activities. The following summary cards are available: - **DSRR Entry Pending Signoff: **Displays work items that are awaiting one or more required approvals before completing the DSRR Entry stage. For each work item, you can review outstanding approvals, identify responsible approvers, view approval status information, and determine which sign-off requirements must be completed before the item can proceed to the next stage of the release readiness process. - **DSRR Entry Approved: **Displays work items that have met all required DSRR Entry approval requirements and are ready to proceed to the staging phase. Work items in this section have completed all mandatory sign-offs configured in DSRR Approval Management and are prepared for the next stage of the release process. - **DSRR Exit Pending Signoff:** Displays work items that are awaiting one or more required approvals before completing the DSRR Exit stage. For each work item, you can review outstanding approvals, identify responsible approvers, view approval status information, and determine which sign-off requirements must be completed before the item can progress toward production readiness. - **DSRR Exit Approved: **Displays work items that have satisfied all DSRR Exit approval requirements and are ready to proceed toward production release. Work items in this section have completed all mandatory sign-offs configured for the DSRR Exit stage and are prepared for production deployment. - **DSRR Exceptions: **Displays work items that received DSRR approval even though one or more required approvals were not completed. Exceptions typically occur when a Release Manager overrides outstanding sign-off requirements and approves the work item, providing visibility into approval overrides during the DSRR process. Separate counts are provided for DSRR Entry and DSRR Exit exceptions. - **DSRR Exit Violations**: Displays work items containing invalid approvals, such as sign-offs completed by users who are not designated approvers for the corresponding approval type. Violations help identify situations where approvals were provided by unauthorized users rather than the approved contacts configured for that approval type. Separate counts are provided for DSRR Entry and DSRR Exit violations. ## Work Items table The **Work Items** table provides detailed information about items within the selected DSRR readiness category. Use it to track approval progress, assess release readiness and identify work items that require attention before progressing to the next stage of the DSRR process. Select the **Information** icon next to a work item to view additional approval and readiness details. Work items can also be searched, filtered and reviewed individually to help you quickly locate specific items and examine their approval and release readiness status in greater detail. The following information is displayed in the table: - **Ticket**: Unique identifier of the work item. - **Feature** **Title**: Name of the feature, user story, or work item. - **Application**: Application associated with the work item. - **Type:** Type of work item, such as Feature, User Story, Bug and Data Science (DS). - **State**: Current stage of the work item in the DSRR process. - **Target**: Planned release date for the work item. - **Status**: Current approval status, including pending sign-offs, pending review and approved. Users can perform type-ahead **searches **using** Ticket ID**,** Title**,** Application **and **Work Item Type, **making it easier to locate specific DSRR entries. Users can also **filter **records by **Work Item Type** to narrow the displayed results and quickly locate relevant records. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/AwOqmZV191ZUtD3nSi4iJ_image.png) # DSRR stages Work items pass through **DSRR Entry **and **DSRR Exit **approval stages. Before a work item can be approved for merge or release, the system validates the required tags and conditions, including **DSRR Entry approval **and completion of the **risk and impact fields**. The validation applies to both standalone work items and work items linked to a parent. Together, these stages provide a structured approval process that helps improve governance, visibility and release readiness throughout the application lifecycle. ## DSRR Staging Entry The **DSRR Entry** stage verifies that all required approvals have been completed before a work item can proceed to the next stage of the release process. Required sign-offs are determined by the **DSRR Approval Management** configuration. The following sign-off approvals are available and can be configured as required approvals for a work item: - Product Delivery Manager (PDM) - Architecture - UX - SVT - DevOps - TechOps Approval requirements may vary depending on the application and configuration. Only approvals marked as mandatory in the **Release Readiness Approver Management **page must be completed before the work item can progress through the DSRR process. ## DSRR Exit The **DSRR Exit** stage validates production readiness before a work item progresses toward release completion. During this stage, the system tracks approval status and highlights items that require attention before they can advance to production. DSRR Staging Exit required approvals include: - DSRR Staging Exit required approvals are: - QA(IST) - Runtime Security - Engineering - Operations - EA Certification - Security - Documentation This categorization provides visibility into the current status of work items and helps ensure all required approvals are completed before release progression. # Viewing Sign-off details Use the sign-off details view to review approval status, approval history and release readiness information for a specific work item. This information helps you understand the current approval stage, identify any pending approvals and determine what actions are required before the item can proceed through the DSRR process. Follow these steps to view a work item information: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services **→ **Platform Services **→ **Toolchain & Pipeline** → **DevOps Intelligence.** 2. From the left navigation menu, select **DSRR Candidacy **feature. 3. In the Work Item table, locate the work item and click on the **Information (i)** icon associated with it. 4. The **Sign-Off Details** panel provides detailed approval and release readiness information for the selected work item. - Select **Review & Act** to review approval requirements, sign-off status and pending actions. If you have the required permissions, you can take action directly from this panel. - Select **Close** to return to the associated Azure DevOps work item and review DSRR Entry and Exit details, approval progress and sign-off information. # Work items approvers Each work item is associated with one or more approvers who are responsible for providing the required sign-offs before the work item can progress through the DSRR process. The following considerations apply to approver assignments: - Approvers are configured in the **DSRR Approval Management** page for each approval type. - Multiple approvers can be assigned to an approval requirement. However, only one approval from the designated list of approvers for that approval type is required to fulfill the approval requirement. - Only sign-offs submitted by **authorized approvers **are considered valid. Sign-offs provided by users who are not assigned as authorized approvers are identified as **Violations**. - Only users with the **Release Manager** or **Development Manager** role can modify approver assignments in the DSRR Approval Management page. - Changes made to approver assignments are automatically reflected in the DSRR Candidacy page. # Work Item approval Only **Release Managers** can review sign-off status, send notifications to stakeholders with pending approvals and approve work items. Before performing approval actions, Release Managers must create a valid **ADO connection** through **Connection Management**. This connection is required to synchronize DSRR approval actions and status updates with the associated ADO work items. :::hint{type="info"} The connection name must use the format **DSRR\_user**\_**ID**. The user ID can be obtained from the user's token or tenant information. To learn how to create a connection, *Tool connections - Home*. ::: Follow these steps to approve a work item from DSRR Candidacy: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services **→ **Platform Services **→ **Toolchain & Pipeline** → **DevOps Intelligence.** 2. From the left navigation menu, select **DSRR Candidacy **feature. 3. Select a work item and click **Review & Act.** ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/tvpJnUyl17g3ixvPiSdGW_image.png) 4. The **Review & Act - DSRR Entry** dialog opens. Select the **Approve** tab and review the work item information. 5. Select **Approve. **A confirmation notification is displayed indicating that the approval was successful. 6. The system automatically updates the** DSRR status in ADO**, synchronizes the approval with the associated ADO work item, and **adds an approval comment** to the work item history. The following comment is automatically added: *Approving the selected work item(s) for DSRR Entry. All signoff criteria have been reviewed and met.* # Pending approval notifications **Release Managers** can send notifications to stakeholders when required approvals are still pending. Notifications are delivered through **email **and **In-App **notifications to the approvers responsible for completing the outstanding sign-offs, helping ensure approval requirements are completed in a timely manner. Automated reminder emails are sent before DSRR calls to notify approvers about pending actions. The email template summarizes pending approvals, outstanding sign-offs and the approvers responsible for completing each action so that release-tracking activities can be reviewed before the call. This procedure allows authorized users to send a notification to approvers who have not yet completed the required approval actions for a work item: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services **→ **Platform Services **→ **Toolchain & Pipeline** → **DevOps Intelligence.** 2. From the left navigation menu, select **DSRR Candidacy **feature. 3. Select a work item and click **Review & Act. You can also **click on the **Information (i)** icon associated with the work item. 4. The **Review & Act - DSRR Entry** dialog opens. Select the **Notify** tab and review the work item information. 5. Select **Send Notification**. Notifications are sent through both **Email** and **In-App** channels. A confirmation notification is displayed indicating that the notification was successful. After a notification is sent, use the confirmation message to verify that the reminder was delivered through the available notification channels. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/uv8LiNJX37b--MY9WHi7J_image.png) # Work Item rejection Only users with the **Release Manager** role can reject DSRR reviews. Reject a work item when it does not meet the required approval or release readiness criteria. Rejection prevents the item from progressing through the DSRR process and provides feedback to the work item owner, allowing them to address the identified issues and resubmit the item for review. Follow these steps to reject a work item: 1. From the Kyndryl Bridge main menu, go to **Services **→ **Platform Services **→ **Toolchain & Pipeline** → **DevOps Intelligence** 2. From the left navigation menu, select **DSRR Candidacy **feature. 3. Select a work item and click **Review & Act.** 4. The **Review & Act - DSRR Entry** dialog opens. Select the **Reject** tab and review the work item information. 5. Click **Confirm Rejection**. A confirmation notification is displayed indicating that the rejection was successful. ![](https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/0alycllxfzshV11w68dNs_image.png) 6. The system automatically updates **the DSRR status in ADO**, synchronizes the rejection with the associated ADO work item, and **adds a rejection comment **to the work item history. The following comment is automatically added: *Rejecting the selected work item(s) from DSRR Entry candidacy. Please address the outstanding signoff requirements before resubmitting.* ** [title] Access Policies [path] Administration/Bridge Access Management/ Access Policies grant one or more roles to a subject (user, service ID or access group) over all resources or a set of resources based on attributes or tags. Policies extend permissions without changing a subject’s original role. The following principles define how access policies work: - Assign a platform and custom roles within a single policy. - Choose **All resources** or **Resources based on attributes** (attribute-based access control using tags). - Attribute-based scope takes effect only when the subject and target resources share the selected tags or attributes. :::hint{type="info"} Only administrators can view, assign or modify access policies. Other users cannot view or manage access policies. ::: # Assigning an access policy to a user 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → → **Users Groups.** 2. Click the **overflow** menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/JndGM9EedPv0uB0o6JMpp-20260601-221027.svg" alt caption width="57" height="57"}next to the user that you want to modify. 3. Select **Edit Membership**. 4. Navigate to the **Access Policies** tab. 5. Click **+ Assign Access Policy.** 6. Select the **Services** that you want to assign. 7. Select the **Scope**: All resources or Resources based on attributes. 8. Select roles (Platform roles, service roles, custom roles, or a combination of the three)). 9. Select **Assign**. # Assigning an access policy to an access group :::hint{type="info"} A similar flow applies when assigning policies to service IDs or access groups from their detail pages. ::: # Learn more ****[Assigning access policies to an access group](docId\:HZc4qy5Gh7gwkLHfYsAyC), and [Assigning an access policy to a service ID](docId\:I2WXFQP2tstQi7GfvOF18). [title] Subscriptions [path] Catalogs/Bridge Service Catalog/ # Subscribe to a service 1. From the page, select the service of your interest. 2. Select the **Subscribe** button for the fixed price package offering of your interest. 3. The configuration page opens. Since this is a limited scope, no configuration needed, quick start program, all you need to do is review the information provided, confirm your interest in subscribing to the service, and select **Review**. Otherwise, select **Cancel**. 4. Once again, you may review the information entered by clicking the chevron down arrow or the **Expand All Configured Items** toggle. If required, select **Edit** to change or add additional details. Otherwise, select **Request Subscription** to finish. You will be redirected to the **Console Subscriptions** page. An email will also be sent confirming the subscription has been requested. For more information, see [Managing subscriptions](docId:7mgKVCrIQfwEMqDUB54Et). :::hint{type="info"} Only services that have a "no configuration needed" set price program will have the subscribe button enabled. ::: # Customers with an existing contract The subscription process may vary for customers with an existing contract for one of our services. After selecting the service from the page, select **Submit Request** for a Kyndryl representative to review your request and activate your service. At this point, the system will prompt you to view your request in **Console**, or to continue navigating the . [title] Administrator configured notifications [path] Administration/Bridge Notification Service/ The Administrator view provides a centralized interface to configure and manage notifications. Administrators can create and manage priority and service-based notifications to define recipients and control key attributes such as status, severity and duration. Access is limited to users with administrative permissions, making it the primary entry point for setting up notifications, while end users consume them through the platform interface. Users with the appropriate Bridge roles can access notification settings through the following navigation path: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Notifications Management** The following notifications are available: - Service-based notification (In-App/Email) - Priority notification (In-App) # Service-based notifications set up (In-App/Email) Notification templates define the structure and content of notifications. Templates are centrally managed in a Git repository where application teams contribute, validate templates and build pipeline processes before they are made available across accounts in Kyndryl Bridge Console. They enable administrators and services to standardize how notifications are created and sent, ensuring consistency across the platform. Templates are typically used by applications or services to generate notifications dynamically based on events. ## Creating Service-based notifications Service-based notification templates are configured through a Git-based template, where administrators define whether notifications are delivered via **In-App, email** or **both** channels. - Define how notifications are structured, triggered and delivered within the platform. - Control notification channels (In-App and email). - Control the target audience. - Add or remove recipients as needed through the Kyndryl Bridge Console. :::hint{type="info"} Only users with the **Administrator **role can create Git templates for notifications in the Git repository, ensuring that template creation is performed by an authorized role. ::: Notifications are created through Git template which contains this information: - **Application/Service**: Enter the application or service from which the notification is generated. - **Events:** Define the events for which the notification is generated. For example, workflow events, manual actions and scheduled jobs. - **Title:** Defines the name of the notification. - **Description:** Add a short description. This is the message displayed in the In-App notification channel along with the notification title. - **Severity for the notification:** Defines the priority level of the notification. Available options are **Critical, Error, Warning, Success **and** Info**. - **Type of notification:** Select the type of notification. If no relevant option is available, users can add a new notification type. - **Select Notification Channel:** Select the notification channel for a particular notification. Available options include **In-App only**, **Email only** or **both In-App and email** (default selection). - **Recipients: **Define the users or groups who will receive the notification. **Account-level notification:** Broadcast to all users in selected accounts. **User-level notification: **Targeted to individual users or access groups within an account. :::hint{type="info"} If an account-level notification is selected, the notification in the UI is displayed as Active. If a user-level notification is selected, the notification in the UI is displayed as Draft. ::: - **Links:** Add links, if required, for direct actions (e.g. “Download report”) . This is not a mandatory field. - **Languages**: Define the preferred language in the template. A total of 12 languages are currently supported for notifications, and the default language is English. This is not a mandatory field. :::hint{type="info"} If email is selected as a notification channel, the fields shown below must also be completed by the administrator. ::: ## Notification template structure Notifications can be configured using notification templates. Templates are centrally managed in a Git repository, where application teams contribute and validate templates through build pipeline processes before they are made available across all accounts. Email templates should include clearly defined default sections to guide users when setting up notifications. The following outlines the email notification template structure: - **Default sender**: Uses noreply\@bridge.kyndryl.com as the standard sender address for all email notifications. - **CC and BCC**: Allow additional recipients to receive copies of the email notification. - **Subject line (mandatory)**: Concise and descriptive, clearly reflecting the purpose of the notification. - **Salutation**: Includes a personalized greeting using the recipient’s name or group. - **Message body**: Includes the core details of the event or action. - **Actions: **Add actions as part of the email, such as: Instructions and direct-action links or buttons. - **Footer Section: **This section includes the following details: Thank-you note and signature. ## Viewing Service-based notification set up Once the template structure is defined, notifications are displayed in the Kyndryl Bridge Console under the Service Notifications tab. In the Notifications Management page, under the Service Notifications tab, a table is displayed to provide an overview of all configured notification templates. This table includes the following columns: **Notification Title, Type, Topic Name, Application/Service, Channels, Languages, Events, Severity** and** Status.** Follow the steps below to view notifications in the UI: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Notifications Management** → **Service Notifications.** 2. View the list of notification templates and events, where notifications created using the template described above are displayed. 3. In the notification title column, select the drop-down arrow to expand and locate the template. 4. The expanded view displays additional template configuration details in a table format. This table includes the following columns: - **Event:** Specifies the trigger associated with the notification (for example, login). - **Short Description: **Provides a brief summary or message related to the event. - **Language: **Indicates the language configured for the notification (for example, en). - **Recipients: **Lists the users or groups who receive the notification. ## Editing Service-based notifications Users can update recipients, delete notifications and download templates. Administrators can add or remove recipients for each notification type, including individual users and access groups, as needed. If users need to modify any other metadata beyond these options, they must make those changes in the Git template. Follow the steps below to edit service notification: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Notifications Management** → **Service Notifications.** 2. In the notification title column, select the drop-down arrow to expand and locate the template. 3. Select the toggle menu and click **Edit**. 4. On the **Edit Recipients for Success Event **page, select the required audience from the recipient list: - **Entire account**: Send the notification to all users - **Access groups**: Target specific groups of users. - **Individual users**: Send the notification to selected users ## Enabling and disabling Service-based notifications Administrators can control whether a notification is active by enabling or disabling its template. This helps manage which notifications are sent to end users and prevents unnecessary or irrelevant alerts. 1. Go to** Notifications** page. 2. Locate the template (active or disabled). 3. Select the three-dot menu (More options) next to the template, and choose** Enable** or **Disable**, as needed. If you select **Disable**, the template status changes to disabled, and notifications triggered by this template are no longer sent to end users. If you select **Enable**, the template becomes active and notifications associated with this template are sent when triggered. ## Priority notifications set up (In-App) Priority notifications are visible across the platform once created. Active notifications are immediately displayed, while upcoming notifications are scheduled based on configured dates. Users are required to acknowledge these notifications to ensure critical information is received. For Priority notifications, users will see a pop-up prompting immediate awareness and acknowledgment. The following attributes define the configuration of Priority notifications and control how they are displayed and managed: - **Title:** The notification title (maximum 250 characters). - **Severity:** Defines the importance level, indicating the urgency and impact of the information by categorizing it as **Warning,** **Critical**, or** Info**. - **Duration:** Define how long the message needs to be retained in the info message table, max 365 days allowed from the current date. These info messages are auto removed after the end date. - **Status:** Defines the state of the notification, indicating whether it is **Active, Upcoming or Draft**. ## Creating Priority notifications from scratch Follow these steps to create a new priority notification: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Notifications** → **Manage Notifications** → **Priority Alerts.** 2. Click the **Create Priority Alert **button in the top-right corner. 3. Enter the required details (such as title, message content, severity, and duration) to define how and when the notification is delivered. 4. Click **Create** or **Save for Later** Once saved, users are redirected to the Priority notifications table, where the updated notification is displayed. ## Managing Priority notifications Manage notifications by updating or deleting them after creation. Based on their status and administrator role permissions, administrators can edit details, adjust settings or remove notifications as needed. Follow these steps to manage Priority notifications: 1. On the **Manage Notifications** page, find the notification you want to manage and review its status (for example, active, upcoming or draft). 2. After identifying the notification, select the three-dot menu to access available actions. Choose **Edit **to update details such as content, severity, or duration or select **Delete** if it is no longer needed. 3. **Save** Click ## Viewing Priority notification set up Administrators can review existing priority notification configurations and verify notification details. Follow these steps to view priority notifications you have created: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Notifications Management** → **Priority Notifications.** The **View All Priority Notifications** takes users to the Priority Notifications details page, where they can view current priority notifications as well as previously received notifications. ## Modifying existing notification set up - Any modification on the notification set up (In-App or Email) can be done by the consuming applications/services via template - Platform Admin, Operator and Editor should be able to **enable **and **disable** the notification from the **API**. [title] Understanding Bridge Access Management [path] Administration/Bridge Access Management/ The main benefit of Kyndryl authorization model is to improve the user experience and add value by converging all authorization and access management in one single place to better govern the capabilities of all services, and to make it available to be consumed by other digital solutions. Other benefits include: - Manage authorization for services consistently and securely in one single place. - Manage authorization for all digital solutions using the authorization model consistently and securely. - Simplify the management of permission scopes for the right resources. - Assign permissions intuitively to the correct user groups and assign users to groups effectively with access groups. - Implement a consistent and effective attribute-based access control (ABAC) strategy across services and your organization’s access needs. - Enable the grouping of permissions according to organizational needs by creating [custom roles](docId:3ZNA7gPTiwBpL13QXE27c). - Find familiarity with industry standard terminology and authorization models to easily comprehend and work with services. - Create consistent ABAC and role-based access control (RBAC) configurations across the board that is intuitive and simple to adopt. - Support the capability to manage ABAC for resources in the different cloud providers or any other technologies connected to the platform, making it easy to group resources securely. # Understanding concepts manages out-of-the-box role-based access controls, custom roles, access groups, access policies, and attribute-based access controls. This authorization model improves the user experience by increasingly converging all authorization and access management in one single place to better govern the capabilities of all services. - [Users](docId:7caOs2IBiKFBH9x-bz51X): The page allows you to manage and regulate user access, so you can control the type of roles and permissions that your collaborators have in your applications. The benefit of the Users page is that you can quickly see the details of the users added to make sure your users are onboarded into your services and applications. - [Access Groups](docId\:HZc4qy5Gh7gwkLHfYsAyC)**:** To simplify the permission administration for a many users, the administrator organizes the access and create a collection of different access groups. An access group is a group for organizing users, service IDs, or a combination of both into a single entity that facilitates assigning access policies to multiple subjects at a time. An access policy grants one or multiple roles to all or a set of resources so that specific actions and permissions can be taken within the scope of the specified target resources. Basically, an access policy is the way in which an access group gets permission to perform actions within the platform. - [API Keys](docId\:xFTW8fInm1eYUfKPg7fly)**:** API keys are normally used to track and control connections and performance of how the system interface is being used; thus, it provides authentication in the calling of a program to another API to confirm a project is authorized for connection. API keys are an initial step in cloud API security by providing the connecting API with a password-like code with a defined set of access rights. - [Service IDs](docId\:I2WXFQP2tstQi7GfvOF18)**:** A service ID identifies a non-human user such as a system service or subscription. Since the service ID is not tied to a specific user, if a user is removed from the system, the rest of the team can continue using the subscription or service.  - [Roles](docId:3ZNA7gPTiwBpL13QXE27c)**:** Adding roles can help you define a set of actions and permission that a user can perform in the applications. Alternatively, these actions may often vary from your own permission needs;  allows you to create custom roles combining different actions. - [Access Tags](docId:4uNGb4hdEmNoILtQg1oLi)**:** The tag schema is a  service that allows you to set policies governing the use of tags. Access tags allow you to set policies governing the use of tags in the  services to help you organize your reports, and monitor and enforce compliance. You can also use your own tools/other services or the provider’s native portal for tag management while still being able to track against a central tag schema to ensure compliance. [title] Bridge Service Catalog [path] Catalogs/ is your single destination to explore, learn about, and subscribe to Kyndryl services and other solutions, including those with partner components, via a digital interface. The allows you to explore a vast catalog of Kyndryl services and solutions categorized by service type, industry, or region. # Accessing the From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Catalogs** → . Once in the page, you have different ways to find a service: - Browse the **Featured Services** carousel. - Use the search box and filter parameters. - Explore by **Categories**. The following filter parameters are available: - **Category** - Applications, Data and AI - Cloud Services - Digital Workplace - Security and Resiliency - Core Enterprise and zCloud - Network and Edge - **Region** - Asia Pacific (APAC) - Europe, Middle East, and Africa (EMEA) - Japan - United States of America (USA) - North America - Latin America - **Industry** - Automotive - Banking and Financial Markets - Chemical, Oil and Gas - Communications and Media - Government - Healthcare - Insurance - Manufacturing - Retail - Travel and Transportation - **Deployment** - onPrem - Hybrid - Cloud - **Type** - Infrastructure - Platform - Software - Security - Backup - Monitoring - **Subscriptions** - Existing contract (BYOL) Multiple filters can be selected to narrow down the search results. You can select one or more filter options by choosing one or more service categories and service attribute categories for the search. Choose your preferred service option from the service page, and once in the **Service Details** page, select: - **View Services:** An overview and description of your service provides basic information. - **Schedule a Consultation:** Schedule a 30-minute free consultation with a Kyndryl expert if you are still unsure if a service subscription suits your business needs or requirements. For more information, see [Consultations](docId:1WhSa4L9StGLwt4csIK-W). - **Request a Quote: **Based on the service configuration that you need, obtain an accurate cost before committing to the purchase. For more information, see [Quotations](docId\:P4dkF8B-XX5vLfiaC2V6w). - **Submit Request:** With one click, you can subscribe to a service in cases where a service offering has a set price. For more information, see [Subscriptions](docId\:DyVKGBHtueLb5tM9gfyJI). Each service in the catalog comes with a description that includes benefits, resources, and customer stories, among other details. This allows you to discover, compare, and select new services and solutions. These solutions help businesses modernize applications, automate operations, and move businesses forward. :::hint{type="info"} Only logged-in users with a account can request a quote or subscribe to a service. ::: [title] Bridge Tag Management [path] Administration/ As part of the common services, offers a robust centralized service that simplifies the work of tag administrators. They can add standard tags consumed by various applications integrated with , all from a single, convenient source. Enterprises can leverage this to ensure consistent data tagging, thereby enhancing the accuracy and reliability of their analytics. The service handles the tags at two different levels: - **Account-level tags**: Account-level tags are created and managed from the [Tag Definitions](docId\:Bk-pJYH9CGZyhqfXthEV3) and [Tag Repository](docId\:FmC8-WunznzvenBj11JSI) pages. - **Global-level tags**: Global tags are created and managed from the [Global Tags](docId\:pBvNOfKqugyUqJzyHoR_w) page. # Prerequisites Make sure you have one of the following roles to create and manage tag keys and their values on the Tag Definitions and Tag Repository pages: - **Tag Administrator**: Enables users to manage the lifecycle of tag-key-value pairs. - **Platform Administrator**: Administrative rights across the platform. Follow the steps below to add platform roles directly to a user: 1. Navigate to the Understanding page. 2. From the left navigation panel, locate **Users Management**. 3. Locate the **Assigning access policies directly to a user** section and complete **steps 1, 2, and 3.** 4. Complete the information as in step 4 of Assigning an access policy directly for a user - Services: **Platform** - Scope: **All Resources** - Roles: Select **Tag Administrator** or **Tag Viewer**, based on access requirements 5. Select **Assign.** # Tag management navigation Tags are managed externally to the Inventory service and are instead handled as an administrative service. To access the Tag Management service, click the hamburger icon and select **Tag Management**. From the pop-up menu, select **Manage & Administer** and then select **Tag Management** service. The left navigation bar contains two icons representing the two Tag Management pages: - **Tag Definitions:** Enables the creation of tag definitions in accordance with the procedures found in Tag definitions. - **Tag Repository:** Enables adding and deleting tags. Refer to Tag repository for details. # Glossary - **Tag definitions:** Tag definitions provide an automated governance and validation mechanism for tags. The Tag Definitions page enables administrators to create and manage consistent, predefined tag keys and constraints for tag values, thereby streamlining tag key management and eliminating duplicates. All tags created through tag definitions are validated and available in the tag repository. This page enables you to create, view, use as templates and delete tag definitions, thereby enhancing efficiency in tag management and increasing productivity. - **Tag repository:** The tag repository provides efficient storage and management of tags for Kyndryl Bridge apps and services, ensuring consistent tagging across all applications. It centralizes access to both governed and ungoverned tags, allowing tag administrators to maintain an organized and up-to-date repository. Additionally, it shows which apps/services use specific tags and can flag undefined tags or those with non-compliant values. - **Account level Tags:** Tags that are added by users (Customers, admins, or Kyndryl admins) in the scope of an account. These tags can be used on assets within the account. - **Global/Kyndryl Owned Tags:** Tags that can be used across accounts. Global tags are predefined & managed centrally from the global control plane. Can be used by multiple Organizational Unit (OU) IDs/Accounts. - **Governed Tag:** All tags that have a tag definition, i.e., validated tags. - **Un-Goverened tag:** All tags that do not have a tag definition, i.e., Unvalidated tags. Each service can decide whether to apply unvalidated tags to its assets. - **Tag Insights:** - Tag usage: Displays the name of the App(s)/services using the tag. Displays unused tags. - Flag tags **Missing definition**: Flag tag values that are not aligned with the defined tag value constraints. # Administrative control An Administrative Control capability (API Only) at the account level allows administrators to decide whether to enable the direct addition of tags to the tag repository. By default, tags are added through a tag definition process to maintain standardization and control. However, administrators can choose to allow or block the creation of tags (key/value pairs) directly in the tag repository based on their account's specific needs. When enabled, users with the tag administrator role can: - Create a new tag Key/Value pair from the tag repository page and save it. - Import tags. When disabled, users with the tag administrator role: - Cannot add/create tags directly into the tag repository. - Cannot import tags. # Set admin control using API This call allows you to configure and review the administrative settings. :::BlockQuote **PUT:** /api/tags/v2/settings ::: Updates the administrative control. Parameter: Set to true or false \[string] enable :::BlockQuote **GET:** /api/tags/v2/settings ::: Fetches the admin settings for tag management. Response :::BlockQuote 200: Admin control updated. 400: No setting modified. ::: [title] Application Inventory [path] FAQs/ :::ExpandableHeading ### What is ? is a unified platform that consolidates fragmented application data from multiple sources—such as ServiceNow, Dynatrace, CMDBs, and discovery tools—into a single, trusted view. It standardizes this information into a common model, maps dependencies, and provides a foundation for modernization planning, Inventory governance, and topology insights. ::: :::ExpandableHeading ### Why is important for modernization? Before modernizing, organizations must understand their current application landscape. provides a clean, accurate, and enriched baseline view of all applications, enabling data-driven decisions, risk assessment, and prioritized modernization roadmaps. ::: :::ExpandableHeading ### How does integrate with my existing tools and data sources? It connects to a variety of enterprise tools—such as CMDBs, observability platforms, and discovery solutions—and automatically consolidates, standardizes, and enriches data, reducing manual reconciliation efforts. ::: :::ExpandableHeading ### Does support Bring your own Data? Yes. supports Bring Your Own Data in the Onboarding phase. It helps the user by providing tools that enable to convert your data into a consumable format. ::: :::ExpandableHeading ### What are the three main components of ? - &#xNAN;**:** Centralized visibility and governance for your application landscape. - **Topology Visualization:** End-to-end mapping of application, infrastructure, and data dependencies. - **Application Modernization Intelligence:** AI-powered insights for prioritizing and executing modernization. ::: :::ExpandableHeading ### How does help identify modernization opportunities? By combining Inventory data, dependency mapping, and, KPIs defined to identify modernization  candidates, assesses technical debt, evaluates risk, and aligns opportunities with business priorities. ::: :::ExpandableHeading ### Who benefits from using ? Stakeholders across the organization— Solution Architects, Chief Architects, Application Owner. Site Reliability Engineers, IT Ops Admin, GTM (pre sales), CIOs, Inventory managers,—gain tailored views and insights to make informed decisions. ::: :::ExpandableHeading ### How is the modernization roadmap created? The three pillars— , Topology Visualization, and Modernization Intelligence—feed into an **Actionable Priority Roadmap**, which outlines what to modernize, when, and how, based on cost, risk, and business impact. ::: :::ExpandableHeading ### Can support both cloud migration and on-premises optimization? Yes. It provides recommendations for cloud readiness as well as optimization of existing on-prem environments, ensuring modernization strategies are balanced and cost-effective. ::: :::ExpandableHeading ### How does ensure data accuracy and trust?  Data from multiple sources is reconciled and normalized into a **Common Data Model**, eliminating inconsistencies and creating a reliable baseline for assessments and decisions. ::: :::ExpandableHeading ### How quickly can organizations see value after adoption of ? Organizations typically start seeing actionable insights within weeks of onboarding, as data ingestion, normalization, and dependency mapping are automated and rapid. ::: [title] Pattern-based policies [path] Administration/Bridge Access Management/Untitled/ Converged Bridge Access Management supports attribute-based policies, policies that apply to all resources and resource pattern-based policies. Patter-based policies can be assigned directly to users, access group and Service IDs, providing flexible control over resource access. Resource pattern-based policies allow administrators to define a resource pattern (resource CRN) and apply one policy across multiple resources that match the specified pattern. Administrators can also configure a policy for an individual resource when more granular control is required. Administrators can create, view, assign, update and validate resource pattern-based policies through the **Assign Access Policy** workflow. During authorization, access evaluation includes the resource pattern-based policies associated with the user or the access group to which the user belongs. The OKTA FGA authorization engine evaluates these policies to determine whether access is allowed for resources that match the configured pattern. # Resource pattern definitions A resource pattern identifies the resources that a policy applies to. When a wildcard (\*) is included in part of the pattern, all values are accepted in that position. Example resource pattern: - crn\:v1\:dx\:local\:iam\:global\:delivery\:public\:domain:\* Example individual resource identifier: - crn\:v1\:dx\:local\:insights\:global:5c306798dec5.1\:public\:dashboard:1aeb4e99-2c80-43f1-93bf-b55c2953d346 # Pattern validation rules and allowed characters Consider the following guidelines when creating pattern definitions to ensure values comply with the required validation rules and contain only supported characters: - Only the following characters are allowed in the pattern: uppercase letters (**A-Z**), lowercase letters (**a-z**), numbers (**0-9**), colon (**:**), asterisk (**\***), underscore (**\_**), period (**.**), forward slash (**/**), and hyphen (**-**). - Spaces are not allowed in the pattern. - The colon (**:**) acts as a separator between pattern segments. - When the wildcard character (\*) is specified between colons (for example, :\*:), no other characters can appear between the colons. The colon character (:) is used only as a part separator and cannot be included as a value within any part of the pattern. - The wildcard character (**\***) cannot be combined with any other character. - The API validates the pattern and rejects any value that contains characters outside the allowed character set. - The allowed character pattern is: **\[A-Za-z0-9:.\*\_/-]**.\* - A part value may be empty (for example, ...\::...). # Assign a pattern-based policy The steps for assigning a pattern-based policy are the same for Users, Access Groups, and Service IDs. The only difference is the entry point used to access the entity. Follow the steps below to assign a **Resource based on patterns **policy: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Access Management** → **Bridge Access Management**. 2. From the left navigation menu, select **Users**, **Access Groups** or **Service IDs**, depending on the entity. :::hint{type="info"} Learn more: **Users:** To learn more about how to assign policies to a user, see [Users](docId:7caOs2IBiKFBH9x-bz51X) **Access groups**: To learn more about how to assign policies to an access group, see [Access Groups](docId\:HZc4qy5Gh7gwkLHfYsAyC) **Service IDs**: To learn more about how to assign policies to a Service ID, see [Service IDs](docId\:I2WXFQP2tstQi7GfvOF18) ::: 3. Locate the user, access group or Service ID, you want to configure and click on **+Assign Access Policy** workflow. 4. When assigning the policy, select **Resource based on patterns** in the **Scope** field. 5. Enter the **resource pattern definition**. The resource pattern must use the required colon-separated format. Invalid patterns cannot be saved and an error message is displayed. 6. To verify the assignment, open the **Access Policies** tab and confirm that the policy is displayed with the **Resources based on patterns** scope. Once the policy is assigned, access is granted according to the configured resource pattern and authorization is evaluated against the matching resources. # Editing access group pattern-based policies Policies assigned to an access group can be edited when policy settings need to be updated. Changes to an access group policy can affect all users who inherit access through that access group. 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration **→ **Bridge Access Management** → **Access Groups**. 2. On the Access Groups page, locate the access group whose policy you want to modify and select the access group name. 3. Select the **Access Policies tab**. 4. Locate the policy under the **Access Policy Name** column and select the policy name. 5. Select **Edit**. 6. Update the policy configuration as required and save your changes. [title] Introduction to Tool Chain Management [path] Catalogs/Tool Chain Management/ A is a collection of tools that work together to automate and streamline software development and operations. Common benefits include the following: - **Integrate tools:** Integrate tools for each phase of the lifecycle: - Plan - Develop - Secure - Test - Deploy - Monitor - Operate - **Automate workflows:** Automate workflows to speed up processes and make them more efficient. - **Help identify issues early:** Help teams identify issues early so they can prioritize and address them expediently. **Improve user experience:** A can help ensure an optimal user experience by identifying issues in real time. ## Description For many organizations, the tool chain comprises a significant number of disparate tools in the context of individual applications. Depending on the DevOps phase of a given application instance, different tools might be necessary to address the requirements for a specific application in a specific phase. For example, Azure is often used in the planning phase, but it might not be the only planning tool required by the development team. Likewise, Jenkins and GitHub might be used in the Build phase, Jenkins for some applications, GitHub for others. The decision of which tools to use for which applications at which phase can vary greatly, which means that for some organizations the permutations can be significant. management addresses three problem areas: - **Understanding the stable of current support tools:** Many of tools sanctioned by teams are open source, which means it's possible that individual teams might take it upon themselves to use GitHub while others build a Jira Infrastructure. Workflows and standard practices and operating procedures can devolve and become chaotic. In such situations visibility is highly desirable. - **The engineering team is dependent on these tools:** Engineers rely on these tools to set processes and ensure the integrity of those processes so that they understand and can report what is being delivered when and by what means. Understanding the health and status of these tools is critical to the performance of teams at every phase. - **Compliance and Security concerns:** The Security and Compliance Organization (CSO) has a vested interest in whether the tools used by the DevOps teams meet the compliance and security policy and regulations that govern the business. CSO visibility into tools currently in use is also a significant concern. addresses these issues, enabling centralized visibility. Existing tools are visible for each application at each phase, the status of each tool is available, and compliance and security concerns can be understood and quickly allayed or addressed. ## roles User actions in are role-driven. Actions are granted as privileges associated with roles assigned to individual users. The following roles currently exist in the system: - **Administrator role:** Create, delete, update, or view defined in the application. - **Editor role: **Update and view the and delete the list of tools defined in each phase. - **Viewer role: **View the listed in the service and refresh the tool status for all tools in . [title] [path] / [title] Overview [path] Administration/Bridge Access Management/ provides the foundational framework to govern and control user access to services and resources. It supports both Kyndryl teams and customer organizations by offering scalable, secure and policy-driven access management. ensures users can access only what they need, when they need it, based on their role, identity and attributes, while adhering to enterprise security and compliance standards. By implementing across the Bridge platform, teams gain a centralized visibility and control over authentication, authorization, reducing risk and simplifying operations in complex hybrid environments. defines who can do what on which resources. - Roles are collections of permissions used as building blocks. - Access policies grant one or more roles to a subject over all resources or a scoped set. - Service IDs are non-human identities for applications, agents and automations. - API keys are scoped credentials used by users or service IDs to authenticate system-to-system calls. # Prerequisites and personas The prerequisites define the minimum requirements needed to access and manage the service, while the personas define the types of users who interact with and the permissions and responsibilities assigned to each role. ## Prerequisites The primary prerequisites are: - A Bridge account with administrator role or equivalent permissions for management tasks. - Bridge services registered to Kyndryl Platform Central, so they appear in the **** main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="28" height="28"} > **Services** when creating roles and policies (Platform appears by default). ## Personas The following user personas have been defined: - **Administrators**: Create custom roles, assign policies and manage service IDs and API keys end to end. - **Operators and contributors**: View roles and policies, manage their own API keys, request policy changes. - **Viewers**: Read-only access, can manage their own API keys if allowed by the policy. [title] Access Tags [path] Administration/Bridge Access Management/ Access Tags in enable organizations to define and manage resource-level access control through a simple and scalable key-value tagging system. This feature empowers administrators to organize, restrict and assign access policies based on defined access tags, ensuring secure and efficient resource management. Non-Administrative users can only view access tags created for the account. They can neither create nor delete access tags.  This update introduces the ability to create and delete account-wide access tags using a key-value format. These tags can then be used when authoring access policies for users or access groups, especially when choosing attribute-based access control (ABAC).  With access tags, you can manage resource segmentation, enforce fine-grained access control and streamline policy definitions using standardized labels. For instance, tags like **Environment\:Dev** or **Project\:Finance** can help enforce which users can access which environments or project resources.  # Prerequisites  To create or delete access tags:  - You must have the **Administrator** role in the account.  # Accessing the Access Tags page From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration**→ → **Access Tags** # Creating access tags  To create an access tag, complete the following steps: 1. On the Access Tags page, click **Add Access Tags**.  2. Enter a **Tag Key** (e.g., Environment)  3. Enter a **Tag Value** (e.g., Dev)  4. Click **Add tag +** to add multiple tag entries (up to 10 total).  5. Click **Add Access Tag** to save.  # Validation and error - Each key\:value pair must be **unique**.  - Access tags, both key and value, are case sensitive.  - If a tag already exists, an error will display:  - "The newly added key\:value pairs must be unique."  - "Key already in use. Please enter a unique value."  - "Value already in use. Please enter a unique value."   # Deleting access tags 1. To delete access tags, locate the access tag and select the **Delete** :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/cV_jsDIVpCCeGRqbdNkZW-20260602-173349.svg" alt caption width="57" height="57"} icon next to their name. 2. Confirm the action when prompted. :::hint{type="info"} Access tags cannot be edited, they can only be created or deleted.  ::: # Learn more [About access tags](docId:7Q1S54C9uxdaANZ9uYhHQ) [title] Connections Management [path] Administration/ Establish and manage connections to your preferred cloud services and technologies, ensuring secure and efficient integration. enhances services capabilities by connecting to various external technology providers in a single place, allowing them to interact with the platform. This process is part of the configuration steps required to start using any service and application. You can establish a new connection within minutes and securely store credentials centrally. After setting up the connection type, a set of technology providers recommended Identity and Access Management (IAM) security policies need to be configured to enable the full potential value of services and applications. The following roles are required to perform activities in the page: | **Permission name** | **Description** | **Roles related to** | | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------- | | security.connections.create | Allow to create connections | Administrator | | security.connections.delete | Allow to delete connections | Administrator | | security.connections.update | Allow to update connections | Administrator | | security.connections.view | | Administrator
Viewer | | security.connections.test | Allow to test connections | Administrator
Viewer | | security.vaultconfig.create | Allow to create Vault Config \[Only API] | Administrator | | security.vaultconfig.delete | Allow to delete Vault Config \[Only API] | Administrator | | security.vaultconfig.view | Allow to view Vault Config \[Only API] | Administrator | | security.connectionstypes.view | Allow to view connections metadata | Viewer | # Accessing From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → . The is divided into 4 pages, which you can access by clicking the corresponding icon from the left panel menu. - [Cloud connections](docId\:sg8Svl5kKw9ZT8yTr0beW) - [Content connections](docId\:Q9R9ieASy9K_dz7sUiiyq) - [Tool connections](docId\:GjyVwKv-F-VML42pwU8cr) - Authentication connections Within a account, all connection activities, including creation, modification and deletion in , are recorded by an audit service, providing a reliable foundation for security and compliance. [title] Support tickets [path] Support/ Only users with an enterprise account are allowed to create support tickets. By limiting access to specific accounts, we maintain the integrity of the system and ensure that we provide the level of support needed for customers and users. If you do not have account, visit the [portal page](https://www.kyndryl.com/us/en/bridge) and sign up for an account. :::hint{type="info"} Creating support tickets for the Inventory service follows a separate process. For support options and instructions, see [Open Incident and General Requests ](docId\:PSoRJKgYI1C-8tqVwPEXv). ::: # Creating a request ticket You can create a support ticket from these two places, after logging into your account: - The footer of any page: Select the **Create Support Ticket** link at the bottom of the page. - The Support Tickets page: Select **Create Request**. In the Create Request page, you can request assistance for or for any of the services that you are subscribed to. Fill out the intake form with the following information: 1. **Where are you experiencing this issue?** - The possible options to choose from include the itself (issues in the or spaces), or any of the services that you are subscribed to. :::hint{type="info"} If you are not subscribed to any services, this field is not displayed on the intake form. ::: 2. **How extensive is the impact of the issue you are facing?** - **Low**: Single user / Any Environment – Select if your issue is only impacting you, but in any environment (Development, Staging, Production). - **Medium**: Multiple users / Any Environment – Select if your issue is impacting a larger number of users in any environment (Development, Staging, Production). - **High**: Entire Organization / Production Systems: Select if your issue is impacting your production environment for your entire team. 3. **How urgent is this for your ongoing work?** - **Minor: **Minimal disruption to experience without impacting business operations. - **Moderate:** Noticeable impacts on experience without preventing the use of the service. - **Critical:** Prevents using the service or significantly impacts the ability to use it. 4. **Question or Issue title** 5. **Please provide us with some details** - Make sure to explain in detail what the problem you are experiencing is, and what steps were taken to reproduce the issue. 6. Click **Create** to submit your ticket. :::hint{type="info"} After you have submitted your ticket, you will be redirected to  Support page. This is the place where you can track the progress of your tickets. ::: # Tracking the progress of your request To learn how to manage support tickets, see [Managing support tickets](docId\:rpRZidQjrz2CHla6of0lr) [title] Logging & Monitoring [path] Administration/ The Logging Service provides a common logging experience in by surfacing application and runtime logs through a shared Grafana-based dashboard. It enables application developers, SREs and operations teams to efficiently access service logs from within Bridge for troubleshooting and analysis. The Grafana observability stack is a lift-and-shift implementation of the AIOps logging stack within Bridge. The Grafana sync service automatically creates new Grafana organizations whenever new tenants (accounts) are onboarded, ensuring account-level segregation within Grafana dashboards. The service also adds users to the appropriate organizations based on permissions. The following capabilities extend the existing logging experience for users: - Provides a common logging experience for apps and services through a shared Grafana-based dashboard. - Provides UI entry points to display application and runtime logs from within Bridge. - Automatically creates dedicated Grafana organizations for newly onboarded tenants to support account-level segregation. - Integrates with roles,** IA** and **SSO** to provide governed access to logging dashboards. - Supports context-aware log access based on the selected account or tenant, ensuring users can view only the log data they are authorized to access. - Users can filter logs by service to support faster issue of isolation and debugging. - If services want to display logs in a specific format, such as starting with a **tenant ID **and the **Bridge Logging Service **can support that. - Supports log download for offline analysis. - Logs are retained in Grafana for a period of **30 days**. - Logs are retained through container restarts and can be queried across restarts. For example, if a pod is deleted and recreated, logs from both the old and new pods can still be queried. - Supports both** redacted **and **unredacted logs**. For example, sensitive data such as IP addresses and email addresses can be redacted. # Access Logging & Monitoring Use Logging & Monitoring to access the **Logs** dashboard, monitor system activity and troubleshoot issues through Grafana-based observability tools. Follow these steps to access Loggin & Monitoring: From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Administration** → **Service Operations** → **Logging & Monitoring**. Access to the Logging & Monitoring service is available to** App Developers** and **Delivery/Operations **users with the **Platform Admin or Platform Viewer **role. Available features and log visibility are limited to authorized Bridge accounts and tenants based on assigned permissions: - **Platform Admin: **Platform Admins can view, download and manage logs, including access to redacted logs and the ability to switch between applications. These permissions are assigned to Admin platform roles. - Observability.logs.view - Observability.redactedlogs.view - Observability.logs.download - Observability.logs.switchapps - **Platform Viewer:** Platform Viewers can switch between applications and view logs, including redacted logs, and can download logs when permitted. These permissions are assigned to platform viewers: - Observability.logs.view - Observability.redactedlogs.view - Observability.logs.download - Observability.redactedlogs.view # Log data retention Although log data is retained for a maximum of **30 days **and automatically deleted after the retention period, a key capability of the logging service is that logs remain available even if pods restart. This helps preserve log history across application lifecycle events and supports troubleshooting without losing log data due to pod restarts. # Download logs The platform admin would be able to download the logs in plain text (txt) or JSON format. [title] GitHub and GitHub Enterprise configuration [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/Develop module/ GitHub provides version control through an open-source distributed version control system, which enables your entire codebase and history to be available to every developer and allows for easy branching and merging. supports your use of GitHub and GitHub Enterprise. This topic describes the configuration requirements for both tools. For to pull data from GitHub, you must configure a GitHub account. # Pre-requisites 1. **Initial GitHub configuration**: Follow the steps in subsequent sections of this topic. 2. Configure Webhook: To ensure proper data synchronization, you must configure Webhook as part of the GitHub integration. Click here for details: [GitHub Webhook configuration](docId\:Zq0J-dl3DYuBbeSzVhD_t). # Integration of GitHub with DevOps Intelligence The process for onboarding GitHub comprises the following steps, each of which is a multistep procedure: 1. Create a Personal Access Token. 2. Create a connection. 3. Configure the application. 4. Onboard the GitHub technical service. # Create a GitHub token The Application requires the following information for GitHub: **Name:** Local account name. It could be any string and is used only for reference. - **User:** Username for GitHub. Generally, the e-mail ID with which the user logged in to GitHub. - **Token:** Personal access token. The personal access token requires permissions within the following recommended scopes: The application also requires to set up permissions: 1. On GitHub, navigate to the main page of the repository. 2. Under your repository name, select **Settings** → **Developer settings** → **Personal Access Tokens** → **Generate new token**. # Create a GitHub Enterprise token The Application requires the following information for GitHub Enterprise: - **Name:** Local account name. It could be any string and is used only for reference. - **Host:** Git API URL of the Git Host. eg, API URL will take the form `https://github.domain.com`. - **User:** Username for GitHub Enterprise. Generally, the e-mail ID with which the user logged in to GitHub Enterprise. - **Token:** Personal access token. The personal access token requires permissions within the following scopes: The Application also requires the following GitHub Enterprise credentials: - **GitEndPoint:** GitHub Enterprise - **Host:** `https://github.domain.com` - **Name:** User's Name - **User:** a\_user\@domain.com - **Token:** your personal access token # Create a connection Before GitHub and can exchange information, you must establish a connection between the two services. Use the following procedure: 1. Click **App Manager** → **IAM** → **Connections** → **Add New** → **Add Connection**. 2. Choose Content Provider as GitHub. 3. Provide a local account name for reference. 4. Add the Host Git API URL of the Git Host (e.g., `https://github.test.net`). 5. Enter your GitHub account user name. 6. Enter the token you created in the Create a Token section. - If you are using a Proxy Adapter, provide the ProxyID UUID. A proxy adapter is necessary when you want to access a service or system with a different interface than your application expects - When Sync is enabled, all organizations and repositories accessible to the user will be synced. - When Archive is enabled, the connection is archived for future use. # Secure alert synchronization - **Pre-requisites** - GitHub personal access token. - Token user needs to have secure alert access enabled. For  to pull data from GitHub and GitHub enterprise, you must provide the following permissions: # Repository permissions - On GitHub, navigate to the main page of the repository. - Under your repository name, select Settings. - In the "Security" section of the sidebar, select Code security and analysis. - Under "Access to alerts", in the search field, start typing the name of the person or team you'd like to find, then select a name in the list of matches. - Select Save changes. Only one user credential can be used to pull information at a single time for a specific application. This avoids reaching the IP rate limit. For more information regarding  secure alerts see: [Secure alerts dasboard.](docId\:MrPFfez9p-F1WGUnDPSin) :::hint{type="info"} For the GitHub Enterprise account: If the administrator has set a limit on API calls, optimizes its process of fetching data and will take around 1000 calls each hour. This is to make sure no other tasks using the credentials are hampered. Once the limit is exceeded we see a message depicting the same on `sync` page of GitHub. ::: [title] Access Request Management [path] Administration/Bridge Access Management/ **Access Request Management** provides a centralized experience for managing access to accounts and access groups through a single interface. Users can view their account memberships, assigned access groups and current permissions; request access to additional accounts or access groups; and track the status of submitted requests. By bringing access requests and approvals into , the solution simplifies access management, provides greater visibility into access status and request history and reduces the need to switch between multiple applications. For approvers, a dedicated approval workspace streamlines access governance by enabling them to review, approve, reject and revoke access requests, helping ensure efficient and secure access management across accounts and access groups. # Access Request Management page The **Access Request Management **page includes summary cards, action tiles and navigation tabs that provide visibility into your account access and access groups, while enabling you to request, track and manage access from a single location. The following elements are available on the page: ### Page elements The following elements are available on the Access Request Management page to help users view account access, manage access requests and request additional access when needed: :::Paragraph{listStyleType="disc" indent="2"} **My Accounts: ** Displays the total number of Bridge accounts the user currently has access to. ::: :::Paragraph{listStyleType="disc" indent="2"} **My Access Groups: **Displays the total number of access groups assigned to the user across their accounts. ::: :::Paragraph{listStyleType="disc" indent="2"} **Request Access: **Allows users to request access to a new Kyndryl Bridge account or request membership in a different access group within an existing account by clicking *Request Access*. ::: The following **tabs **allow users to view account access, track access requests and, if authorized, manage and review access requests for other users: :::Paragraph{listStyleType="disc" indent="2"} **My Accounts **tab**: **View the Bridge accounts you can access and review account-related details. ::: :::Paragraph{listStyleType="disc" indent="2"} **My Requests** tab**: **View and track submitted access requests, including their current approval status. ::: :::Paragraph{listStyleType="disc" indent="2"} **Approval Requests **tab: Allows approvers to review, approve, reject or revoke user access requests for the accounts and access groups they manage. ::: :::hint{type="info"} The **Approval Requests** tab is available only to users with approver roles, such as **Administrato**r or **Kyndryl Account Manager**. ::: # [title] Dynamic Scan dashboard [path] Services/Platform Services/Toolchain & Pipeline/DevOps Intelligence/ The** Dynamic Scan** dashboard provides a centralized view of **Dynamic Application Security Testing (DAST) **results collected from **Tenable.io** within . The dashboard enables development and security teams to review vulnerability findings, analyze severity metrics, monitor scan activity and identify applications and technical services that may require remediation. Users can review high-level vulnerability trends through dashboard visualizations and access detailed scan information for onboarded applications and technical services. Applications are onboarded to **Dynamic Scan** through the **Application Configuration** process. Once an application is configured, vulnerability and scan data collected from Tenable.io become available in the** Dynamic Scan **dashboard. This allows users to review scan results, vulnerability counts, severity information, scan dates and associated technical service details from a single interface. # Access Dynamic Scan Follow these steps to access the **Dynamic Scan** dashboard that includes visualizations for critical and high vulnerabilities and provides access to detailed vulnerability information for technical services: 1. From the main menu :inlineImage[]{src="https://archbee-image-uploads.s3.amazonaws.com/QU1TIK52ntw5Jsos0uOt5/NK7Yw9tQgnlqBGwu7eG4H-20260601-205917.svg" alt caption width="57" height="57"}, go to **Services** → **Platform Services** → **Toolchain & Pipeline** → . 2. From the left navigation pane, select **DevOps Overview**. 3. Navigate to **Secure **application and expand it and select **Dynamic Scan**. # Dynamic Scan page The **Dynamic Scan** page provides access to Dynamic Application Security Testing (DAST) results collected from Tenable.io. Users can review vulnerability information for onboarded technical services and applications, analyze severity metrics through dashboard visualizations and access detailed scan results from a centralized interface. The page also includes filtering, search and data management options to help users identify and investigate security findings ## Page Components The following two charts provide a visual summary of the technical services with the highest number of security findings identified by** Tenable.io** scans: - **Top Technical Services by Critical Vulnerabilities: **This chart highlights the technical services with the highest number of critical vulnerabilities identified by Tenable.io scans. The visualization helps users quickly identify applications that may require immediate attention and remediation. - **Top Technical Services by High Vulnerabilities:** This chart displays the technical services with the highest number of high-severity vulnerabilities. The visualization provides a quick view of services that present significant security risks and may require prioritization by application owners and security teams. ## Dynamic Scan Table The **Dynamic Scan** table provides a detailed view of vulnerability findings for onboarded technical services. It helps users monitor application security posture, identify services with the highest security risks, and review the most recent scan results from **Tenable.io**. The table includes the following information: - **Technical Service**: The technical service or endpoint that was scanned. - **Application**: The application associated with the technical service. - **Vulnerabilities**: The total number of vulnerabilities identified during the scan. - **Critical**: The number of vulnerabilities classified as Critical severity. - **High**: The number of vulnerabilities classified as High severity. - **Last Scan**: The date of the most recent dynamic scan. - **Secure Engine**: The security scanning engine used to perform the scan, such as **Tenable**. The table can be filtered using the available search and filter options, allowing users to focus on specific applications, environments and vulnerability findings. Search works for non-numerical columns. Users can navigate to a detailed view for a technical service to review additional vulnerability information, scan metrics, severity breakdowns and related security findings. ## Dynamic Scan details To view** Dynamic Scan details**, select a URL from the **Technical Service** column in the Dynamic Scan table. The **Dynamic Scan Details** page opens and displays summary metrics, including total vulnerabilities, critical vulnerabilities, high vulnerabilities, scan engine and last scan date, along with detailed vulnerability findings for the selected URL. The **Dynamic Scan Details** table provides detailed information about vulnerabilities identified for the selected technical service URL. This information helps users analyze security findings, understand their impact and prioritize remediation activities: - **Plugin**: Unique identifier assigned to the vulnerability check performed by the scan engine. - **Name**: Name of the vulnerability or security finding. - **Family**: Category to which the vulnerability belongs. - **URI**: The affected URL or endpoint where the vulnerability was detected. - **Severity**: The vulnerability severity level, such as Critical, High, Medium, or Low. - **Description**: Summary of the vulnerability and its potential security impact. - **Action**: Allows users to download vulnerability details for further analysis and reporting. # Dynamic Scan for Onboard Technical Service When editing or creating an **Onboard Technical Service**, select **Dynamic Scan** from the available scan options for** Secure Categories**. This enables the technical service to display and track **Tenable.io** DAST results, allowing users to monitor vulnerabilities, scan status and security posture for the selected application or service. Once **Dynamic Scan **is enabled for a technical service: - A **Dynamic Scan** filter is added under the **Secure** section, allowing users to filter and view technical services configured for dynamic security scanning. - A **Dynamic Scan** column is added to the **Onboarded Technical Services** table, providing visibility into whether dynamic scan data is enabled and available for each technical service. - Users can quickly identify which technical services are configured to display **Tenable.io** DAST scan results within DevOps Intelligence. - Tenable will be added in Tool configuration once onboarded. For information about onboarding and managing technical services, see [Onboarding Technical Services](docId\:N8JPAv40LQcQwHWa6WSNV). [title] Subscription access [path] FAQs/ :::ExpandableHeading ### What is subscription access group automation? subscription access group automation creates customer access groups during subscription (via Broker or subscription flow) and assigns predefined IAM roles to those groups. ::: :::ExpandableHeading ### What is the purpose of this feature? This feature standardizes role-based access control for workflows during subscription and ensures personas receive appropriate permissions without manual configuration. ::: :::ExpandableHeading ### What happens when a customer subscribes to ? When a customer subscribes to , the system automatically: - Creates required customer access groups - Maps each access group to the correct role. - Enables the groups for use by Workflow Service (workflowsvc) ::: :::ExpandableHeading ### Which personas and roles are supported? Supported personas and roles are as follows: | **C********CMM persona** | **IAM role** | **Access group** | | ---------------------------------------------------------------------------------- | ----------------------------------------- | --------------------------------------------- | | Owner | CCMMEvidenceControlOwner | Ccmm\_Evidence\_Control\_Owner | | Approver | CCMMEvidenceApprover | Ccmm\_Evidence\_Approver | | Reviewer | CCMMEvidenceReviewer | Ccmm\_Evidence\_Reviewer | | Support Admin | CCMMSupportAdmin | Ccmm\_Support\_Admin | | Administrator | CCMMAdmin | Ccmm\_Administrator | | Viewer | CCMMViewer | Ccmm\_Viewer | ::: :::ExpandableHeading ### Are access groups created automatically? Yes. Access groups are automatically created during the CCMM subscription process and mapped to the corresponding roles. ::: :::ExpandableHeading ### Can existing subscriptions use this feature? Existing subscriptions are not automatically updated. If new access groups are required, users must unsubscribe and resubscribe to for the updated configuration to reflect. ::: :::ExpandableHeading ### Who is responsible for role creation? The application team is responsible for creating IAM roles and defining associated permissions. ::: :::ExpandableHeading ### How are roles used in workflows? Once assigned, roles are inherited by users added to the respective access groups. The Workflow Service (workflowsvc) uses these roles to execute workflows based on assigned permissions. ::: :::ExpandableHeading ### Does this change require any manual configuration from customers? No manual configuration is required for new subscriptions. Access group creation and role assignments are handled automatically during the subscription process. ::: **** [space] Release Notes (/release-notes) [title] June [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # June 5, 2025 ## Discovery & Inventory Common Discovery can now extract virtual machine (VM) resource details from the OCI provider based on the account credentials and connections added to the IAM connection. Upon successful discovery, OCI asset details can be accessed through the Common Inventory Service. ## DevOps Intelligence - DevOps Intelligence has expanded project tracking support for Azure Boards, to include team-level tracking during the Plan phase. Tracking at both the Organization and Team level enhances the extensibility and user experience of DevOps Intelligence. - DevOps Intelligence now supports Bring Your Own CLT (Change Lead Time) API, enabling your team to use data collection systems of your choosing beyond those supported by native integration. ::: :::ExpandableHeading # June 4, 2025 ## General enhancements As part of the ongoing tag management efforts, enhancements have been released to improve the user experience. - **File samples:** Users can download a sample of CSV and JSON files to understand the required import attributes, including mandatory fields 'Tag Key' and 'Tag Values.' They can add their data to these files and upload them. - **Visibility of tag constraints:** You can now see the applicable rules when adding tag values to the tag repository. Clear messages inform you about minimum character counts and rules for special characters. - **Tag definition:** Now, the tag category and its respective values are displayed in the view details of a tag definition. - **Save the progress of your tag creation: **To enhance the user experience, you can easily save tag definitions after editing a step. - **Tag key constraints: **Tag keys in tag management support up to 256 characters, including numbers (0-9) and special characters such as !@$%\*();:\_-\\./. Both tag keys and values should have a minimum length of 1 character. - **Definition compliance column:** A column has been added to indicate whether a tag has a formal definition, outlining its usage, permissible values, or purpose. ::: [title] August [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # August 27, 2025 ## Container Cluster Management (CCM) **Enhanced UI:** The left navigation panel on the Container Cluster Management landing page has been replaced with a tab navigation option. Users can now toggle between Container Cluster Management data and the Controller Service APIs page, enabling more efficient navigation. ## Platform Services - Tag Management **Global tag available across all organizational units:** Managing tags in the Shared Commercial Infrastructure is challenging because the process of updating multiple instances and values across accounts is labor-intensive. Tags need to be added for every customer, and any changes to a tag's value require updates to every instance. To address this issue, Bridge now offers Global Tags. These tags can be created and accessed across all Organizational Units (such as Global, Account, Country, Market, etc.). This feature simplifies administration and reduces the complexity associated with managing multiple tags, which is often necessary in traditional systems that require duplicating tags for each account. ::: :::ExpandableHeading # August 20, 2025 ## Platform Services - Tag Management **Administrative control available in the tag repository page: **An administrative feature has been introduced at the account level for managing the creation of tags (key/value pairs) directly in the tag repository. Administrators can control whether tags can be created directly, allowing only governed tags or permitting both governed and ungoverned tags. ## DevsecOps **Cluster Alerts page has been enhanced:** To improve the customer experience and make it easy to find relevant information, the **Node Alerts** tab on the alerts page is now rebranded as **Cluster Alerts**. Alerts related to pods will be found under the "Pod Alerts" tab, and all other alerts will be in "Cluster Alerts". ::: :::ExpandableHeading # August 13, 2025 ## Discovery & Inventory **Sink template customization**: The new sink template feature allows users to define custom field mappings in ServiceNow directly from the UI. It supports JSON import, export, and update options during registration, eliminating the need for hardcoded values or manual API updates, and enabling greater flexibility. ## Console **AIOps Global menu now available in Kyndryl Bridge: **The AIOps Global menu is now available in Kyndryl Bridge to enjoy a unified and seamless navigation experience. Key features include: - Consistent navigation: Access all AIOps operations directly within Kyndryl Bridge. - Improved usability: Follow Shidoka 2.x design standards for a modern, intuitive interface. - Enhanced productivity: Minimize context switching between platforms, accelerate access to relevant actions and insights, and streamline workflows with fewer clicks. **Connections management link now available in Bridge Console Administration menu: **The Connections management link is now available under the Administration menu. This enhancement streamlines admin access-related activities, ensuring a more efficient and user-friendly experience. Key capabilities include: - Easy access and improved navigation: Enhance overall navigation and usability within the platform. - Streamlined admin activities: Manage all admin-related tasks more efficiently from a single location. **Enhanced Console tour: **The Console tour has been enhanced with a new modal-based format that supports videos and images for a more engaging user experience. Key benefits include: - Easy access and improved navigation: View the Console tour pop-up at login or access it anytime from the Support section. Explore key features and learn how to navigate the Console efficiently. - Improved efficiency: Focus on the most important sections and features to save time and reach what you need faster. - Personalized experience: Skip or disable the tour based on your preferences. Here are the options available in the Console tour: - Let’s Go: Launches a Getting started with Console guide, highlighting key features and navigation. - Skip: Jumps to the Help & Support section. After clicking Done, the pop-up will not show again. - Don’t show again: Prevents the pop-up from displaying on future logins. - Consistent guidance: Deliver the same tour experience across all account types, while showing different welcome pages for ACME and non-ACME users. ## DevOps Intelligence **Ability to search and select repositories for technical services:** To enhance the efficiency of the onboarding process for technical services and mitigate loading difficulties associated with large repositories, a feature has been implemented that allows users to search, filter, and select repositories. This functionality streamlines the experience for DI users, enabling them to identify and choose the appropriate repository with greater ease. ::: :::ExpandableHeading # August 6, 2025 ## DevSecOps Foundation **New Actionable Insights:** Actionable Insights have been updated to enable keener observability of container performance and reliability. **Enhanced data presentation:** Relevant data fetching is now presented in near real-time, enabling quicker response times to container potential performance and reliability degradation. **Init containers are now supported:** Container Cluster Management now displays Init Containers, their status, and logs. In the event that an Init Container exits with an error, the container stays in a pending state. The Init Container logs record such errors, enabling administrators to troubleshoot the problem and optimize resource uptime. ## Platform Services - Tagging **Tag storing capability is now available in Tag Management:** As part of the ongoing tag management efforts, tag storing capability has been enabled and will allow applications to keep tag information in one place instead of storing it separately. The repository also tracks the lifecycle of these tags. In the tag repository table, the "used by" column shows which applications are currently using each tag. ::: [title] Latest releases [path] Release Notes/ :::hint{type="info"} If a month is not listed, no releases were published during that month. ::: :::ExpandableHeading # Administration ## August 2026 **August 12** **Enhancement****** **Enabled Regional Operations workspaces in workspace switcher:** Console users can now easily discover and access Regional Operations tenants under a dedicated workspace category in the Kyndryl Bridge workspace switcher, improving navigation and providing a consistent experience across platform services. This update standardizes account labels and naming conventions while maintaining existing access controls. *** **August 5** **Enhancement****** **Enabled default activation of Platform Services during new account onboarding**: All approved Platform Services are now automatically enabled when a new account is created, ensuring a consistent onboarding experience, reducing manual steps, and improving time-to-value for customers. This update eliminates errors caused by missed selections while preserving governance and audit tracking. The following Platform Services are enabled by default during account onboarding: - Discovery & Inventory - Container Cluster Management - Topology - Provisioning Orchestration Automation Service - DevOps Intelligence - Bridge Data Foundation - Bridge Policy Service - Knowledge & AI Foundation - Go To Market *** ## May 2026 **May 13** **Enhancement****** **Improved authorization management with Platform Central:** Bridge Connections Manager, Tag Management, and Audit Service now use the converged Bridge authorization service for centralized authorization. This backend update eliminates the need for multiple systems, streamlines request routing through updated endpoints, and improves reliability without impacting the end‑user experience. ::: *** :::ExpandableHeading # Audit ## January 2026 **January 20** *** **Bridge audit service available in APIs**: Multiple Audit Services—Bridge, AIOps, and Control Tower— have been merged into a single API, providing a unified view of audit timelines and statuses for Site Reliability Engineers (SREs) and developers. This scalable solution eliminates duplicate services, streamlines operations, and enhances governance. The integration improves maintainability and reusability while reducing administrative overhead. A common framework guarantees consistent behavior and a uniform user experience across all applications on Bridge. ::: *** :::ExpandableHeading # Bridge Access Management ## September 2026 **September 30** **Enhancement****** **Improved navigation for self service Access Request Management capability: **All Kyndryl users can now easily reach Bridge Access Request Management from the Access Management section under the Administration menu and raise new access requests and view their existing access details. *** **September 23** **Enhancement****** **Retention period (TTL) for access requests in self service access request management: **Administrators can now benefit from automated retention management for self service access requests management, helping reduce data clutter, improve system performance and support audit compliance. Rejected and expired requests are automatically removed after 30 days, while revoked requests are retained for 90 days before deletion. Cancelled requests, including those cancelled by the requester, are retained for 30 days from the date they reach the expired state. Approved requests remain visible until their status changes, ensuring continued access to relevant request history when needed. *** **September 9** **Enhancement****** **Added notifications service for Bridge Access Management requests:**  All Kyndryl users and Kyndryl approvers now receive automated notifications through the Kyndryl Bridge notification service for Bridge Access Management requests. Approvers are notified when new requests are submitted, while requestors receive updates when requests are approved, rejected or expired. This enhancement improves visibility into request status and helps streamline the account access approval process. Learn more: [Bridge Notification Service](docId\:Cc4Sf-ex6YCcA3P06YELV) *** **September 2** **Enhancement****** **Added service name mapping for access groups**: Administrators can now view the mapping between service access groups and service names in Bridge Access Management. This enhancement provides clearer ownership information, helps identify the service associated with a group and reduces the risk of errors during updates or deletions. Learn more: [Access Groups](docId\:HZc4qy5Gh7gwkLHfYsAyC) *** ## August 2026 **August 26** **Enhancement****** **Introduced resource pattern-based policies for Kyndryl Bridge Access Management**: Kyndryl Bridge developers can now define authorization policies using resource patterns in Bridge Access Management. This enhancement introduces a third policy type, alongside the existing **all resources** and **resource based on attribute **policies. Administrators can apply policies consistently across multiple matching resources while continuing to configure policies for individual resources when more granular access control is required. This enhancement reduces repetitive policy creation and simplifies authorization management across related resources. As a result, it improves governance, operational efficiency and scalability within Bridge Access Management. Learn more: [Access Policies](docId\:nb3bZm-bsA3w7AEFpbDzs) *** **Enabled user access revocation for Bridge Access Management: **Kyndryl approvers, DPEs, account managers and account administrators can now revoke previously granted account access directly from the access request management workflow. In addition to approving and rejecting requests, approvers can remove unnecessary or outdated access assignments from a single location, helping maintain accurate permissions, support compliance requirements, and ensure access remains aligned with current business needs. *** ## July 2026 **July 22** **Self-service Access Request Management is now available: **Kyndryl users can now request access to Kyndryl Bridge accounts and access groups directly from a single Bridge Access Management self-service experience. The capability enables approver personas to review, approve, or deny access requests through a structured workflow. It also provides users with a single pane of glass to view their associated Kyndryl Bridge accounts, permissions and access groups. This helps delivery and consult teams rely more on Kyndryl Bridge for both service operations and access requests. The experience reduces friction caused by ARMS dependency on Kyndryl VPN, especially for teams working through customer VPNs. By bringing access request management into Bridge Access Management users can avoid unnecessary VPN switching and context changes. This improves user experience, strengthens access governance and supports broader Kyndryl Bridge adoption. *** **July 15** **Enhancement****** **Service Access Management removed from the menu**: The Service Access Management menu option has been removed from the main menu. All user access management capabilities are now consolidated under Bridge Access Management. This provides a single location for authorized users to view and manage user access, as well as administer access groups and policies across and converged services. Existing user access and permissions remain unaffected. *** ## June 2026 **June 24** **Enhancement****** **Bridge IAM and ARMS synchronization enhanced:** This enhancement introduces a bi‑directional synchronization between Bridge IAM and ARMS to support a feedback-driven access governance model aligned with SOC compliance requirements. Bridge IAM now supports all active Bridge accounts and tenant‑scoped access groups in ARMS. In parallel, ARMS continues as the system of record for access requests, approvals, and governance decisions, with all approved access grants and revocations automatically synchronized back to Bridge IAM. This separation of responsibilities ensures consistent governance execution, improves visibility and control over access boundaries, and prevents stale or non‑compliant access across the platform. *** **June 17** **New Okta FGA authorization system introduced: **A new Bridge authorization system based on Okta FGA is now introduced. As part of the IAM Convergence strategy, Okta FGA now serves as the central authorization engine, enabling consistent access control across Bridge and AIOps services. Okta FGA has been enabled for a defined set of Bridge accounts, while others continue to use the existing Bridge authorization system. This update centralizes access control and improves consistency and security across services. *** ::: *** :::ExpandableHeading # Bridge Tag Management ## July 2026 **July 22** **Enhancement****** **In-App notifications now available for Tag Repository import:** The Tag Management service has adopted In-App notifications for bulk tag imports to keep tag administrators and platform administrators informed about the import status. Notifications indicate success, partial or failure with tag counts and include an option to download a detailed import report with status and failure reasons for better transparency. Learn more: [Tag Repository](docId\:FmC8-WunznzvenBj11JSI) *** **Enhancement****** **In-App notifications now available for Tag Definition (schema) import in Bridge Tag Management:** Tag administrators now receive real-time In-App notifications for Tag Definition (schema) import actions including successful, failed and partially completed imports. This helps them quickly understand outcomes, identify issues and take corrective action without leaving the platform. Learn more: [Tag Definitions](docId\:Bk-pJYH9CGZyhqfXthEV3) *** **July 8** **Enhancement****** **Editing tag values is now available in Tag Management: **Bridge Tag Management now supports updating existing tag values within an account. This enhancement closes a key gap in tag lifecycle management by enabling users to modify tag values directly, ensuring Bridge Tag Management now supports complete Create, Read, Update, and Delete (CRUD) capabilities for tag administration. *** ## April 2026 **April 8** **Enhancement****** **Tag management now supports bulk importing of tag definitions: **The ability to import tag definitions is available for both account-level tags (Distributed Control Plane) and global tags (Global Control Plane). This feature significantly reduces the time required to add tag definitions (tag schema) individually through the user interface, making it easier for tag administrators to import multiple tag definitions at once. Moreover, once imported, these definitions are activated and become immediately available for use by various applications and services in Bridge. The system meticulously tracks all tag definition creation details, ensuring comprehensive oversight. ::: *** :::ExpandableHeading # Connections Management ## September 2026 **September 2** **Enhancement****** **Added credential expiry tracking in Connections Management:** Connections administrators can now set expiry dates for stored credentials across all supported technology providers, including cloud connections, content connections and tool connections. This capability helps monitor credential lifecycles, prevent service disruptions caused by expired credentials and support compliance with security best practices as additional technology providers are introduced. Learn more: [Cloud connections](docId\:sg8Svl5kKw9ZT8yTr0beW) *** ## June 2026 **June 18** **Enhancement****** **Connections Management is now adopted in Bridge Audit service:** Platform administrators and viewers can now access audit logs for connection management activities, powered by the Bridge Audit service. Key user actions including connection creation, modification and deletion are automatically recorded, providing enhanced transparency, traceability and governance across the platform. *** ## January 2026 **January 21** **Enhancement****** **The connections manager now supports HashiCorp's external vault**: A generic adapter has been developed to connect to an external HashiCorp Vault, with the capability to be adapted to other external vaults in the future, enabling easy extensibility. The external vault enables secure read-only access to sensitive information for Bridge applications via the connections manager, ensuring scalability. Learn more: [Connections management vaults](docId\:c8M4609nV6cecGkdd6jYR) *** **Bridge audit service available in APIs**: Multiple Audit Services—Bridge, AIOps, and Control Tower— have been merged into a single API, providing a unified view of audit timelines and statuses for Site Reliability Engineers (SREs) and developers. This scalable solution eliminates duplicate services, streamlines operations, and enhances governance. The integration improves maintainability and reusability while reducing administrative overhead. A common framework guarantees consistent behavior and a uniform user experience across all applications on Bridge. ::: *** :::ExpandableHeading # Console ## September 2026 **September 23** **Enhancement****** **Enabled cross-account dashboard promotion**: Account administrators can now promote custom dashboards to multiple accounts without recreating data sources, widgets, or configurations. This enhancement improves reuse of standard dashboards, accelerates rollout across accounts, and ensures consistency in layouts and visualizations. *** **Enhancement****** **In-app notifications for Widget Builder and Dashboard Assembler**: Authorized account users now receive in-app notifications when widgets or dashboards are submitted for review, approved, rejected, shared, or when ownership changes. This update improves transparency, accelerates approvals, and reduces manual follow-ups by keeping creators and administrators informed in real time. This feature is not applicable to the ACME account. *** **September 9** **Added ability to use Data Fabric as a data source in Widget Builder**: Customers can now select Data Fabric as a data source, explore schemas and tables, write custom SQL queries in an integrated editor, and save results as reusable datasets for creating custom charts. This feature improves flexibility and enables advanced analytics within the Kyndryl Bridge platform. *** **September 2** **Enhancement****** **Cross-account widget promotion and reuse now supported in Widget Builder**: Teams can share and reuse approved widgets across accounts without recreating visualizations. This capability accelerates dashboard creation, reduces duplicate effort, promotes consistency, and delivers insights faster while preserving account-level data boundaries and access controls. *** **Enhancement****** **Improved dashboard publishing and personalization in Dashboard Assembler**: Dashboard Assembler now offers better publishing workflows and personalization options. Customer account administrators can now quickly search, filter, and manage dashboards more efficiently, while consumers can customize layouts and reset them to default without affecting the published version. These enhancements improve usability and reduce administrative effort. *** **Enhancement****** **Dashboard ownership transfer now available**: Customer account administrators can transfer ownership of custom dashboards between Kyndryl Bridge users within the same account, ensuring dashboards remain manageable when the original owner is unavailable or leaves the organization. This update preserves existing configurations, publishing history, and access settings while enabling seamless continuity. *** **Enhancement****** **Promote widget configurations across environments in Widget Builder**: Customer account administrators can now promote data source definitions, widget configurations, and related assets from development to staging or production without manual recreation. This enhancement reduces deployment time, minimizes errors, and ensures consistency across environments through a controlled, repeatable promotion workflow. *** ## August 2026 **August 26** **Enhancement****** **GenAI assistant availability across all Kyndryl Bridge Console pages**: Console users can now access the GenAI assistant from any page within Kyndryl Bridge Console, removing the need to return to the landing page. This update improves discoverability, ensures a consistent experience, and enables uninterrupted AI assistance throughout the platform. *** ## July 2026 **July 29** **Enhancement****** **Enabled Bridge Home page personalization by managing visibility of role-assigned dashboards**: Console users can now hide role-assigned dashboards from their dashboard bar without losing access. Hidden dashboards can be restored at any time through the Dashboard Management panel. This update reduces clutter, improves usability, and preserves organizational governance and role-based permissions. *** **July 22** **Enhancement****** **Improved navigation clarity with standardized masthead and page titles**: Console users now see standardized masthead titles showing the parent category, while service and application names appear in breadcrumbs or as the main page titles. This update creates a clear, intuitive hierarchy, reducing context confusion and enhancing brand consistency across Kyndryl Bridge. *** **July 1** **Create and share custom dashboards: **Account administrators can now build custom dashboards with existing widgets and share them securely using role-based access controls (RBAC). Approved dashboards appear on the **All Dashboards** page for easy discovery. Authorized users always see the latest updates, ensuring alignment and governance through an approval workflow. *** **Enhancement****** **Pin and favorite dashboards for a personalized Console experience:** Console users can now favorite frequently used dashboards or pin them as tabs on the Console Home page for quick access. Pinned dashboards open directly within the Console, reducing navigation to frequently used dashboards. Preferences are saved per user, allowing each user to create and manage a personalized workspace. Learn more: [Global navigation](docId\:mPOJAK2f0JDnP8wR-liZk) *** ## June 2026 **June 10** **Enhancement****** **Welcome banner enhanced in Bridge Console: **The Bridge Console now has a configurable and dismissible welcome banner that maximizes dashboard space while preserving key context. Users can collapse or dismiss the banner to reduce clutter and improve usability for data-dense views and smaller screens. Banner preferences persist at the user profile level across sessions, accounts, and devices. Once dismissed, the banner remains hidden until it is restored from the Widget Library (Dashboard Manager). The banner defaults to a collapsed state on smaller screens, ensuring a responsive and space-efficient experience. *** **Enhancement****** **Services menu redesigned:** The Console introduces a redesigned Services menu that organizes offerings into a structured, domain-based navigation model, replacing the previous flat and service-heavy layout. Services are now grouped under clearly defined domains with a distinct separation between Kyndryl Services and Platform Services, enabling a more logical and intuitive browsing experience. This update improves discoverability, reduces cognitive load, and allows users to locate and access services more efficiently. The scalable structure supports the onboarding of new services while preserving existing permissions, favorites, and navigation behavior, ensuring a seamless and consistent experience. *** **Enhancement****** **Administration menu redesigned:** The global main menu now includes a dedicated Administration menu that centralizes administrative capabilities into a structured, role-aware experience across Bridge. This update replaces the previous Manage & Administer menu and organizes capabilities into functional categories. Existing administrative tools remain unchanged, while role-based access control (RBAC) ensures that users can access only authorized capabilities. Legacy capabilities are labeled as (legacy), and external-link behavior remains consistent. This enhancement improves discoverability, simplifies navigation, and enables faster access to administrative tools through a consistent and scalable platform experience. *** **Recently Viewed introduced in Console: **The Console includes a Recently Viewed option that captures and displays the last accessed pages and dashboards directly within the global navigation menu. The list updates dynamically based on user activity and displays up to 10 recent items, allowing users to quickly return to previously viewed content without manual configuration. In multi-account environments, it maintains a separate history per account to ensure account-specific visibility. The feature enforces existing access permissions across sessions and provides a streamlined navigation experience. *** **Enhancement****** **Favorites menu redesigned:** The Favorites menu is now available in a dedicated flyout in the navigation header instead of the main navigation, enabling quick access to frequently used pages. Users can mark or remove items as favorites directly from supported pages and view them in a centralized panel. Each user can maintain up to 10 favorites, with prompts to remove an existing item when the limit is reached. Favorites are stored per user per account and persist across sessions, improving navigation efficiency and enabling a more personalized, streamlined experience. *** **Enhancement****** **Catalog navigation redesigned:** Catalog navigation introduces a dedicated Catalogs section in the navigation menu, replacing the previous Enterprise Catalogs menu. All available catalogs are now centralized in a single, structured view, enabling users to browse and access catalogs directly from the navigation panel. This update improves discoverability and usability, reduces navigation effort and ensures users can access only authorized catalogs through a consistent and scalable model. *** **Enhancement****** **Console menu redesigned: **The Console navigation is redesigned to improve clarity, consistency, and ease of use. **Home** is now **Bridge Home**, **Intelligence** is now **Dashboards**, **Actionable Insights** is now **Operational Insights**, and **AIOps IT Health Indicators** is now **AIOps IT Health Indicators Dashboard**. A new **All Dashboards** entry is available under **Dashboards**, while **Business Service Insights** and **Business Console** are now labeled as legacy applications and identified with launch-out icons. The navigation order is also standardized, and a new **Favorites** feature allows users to pin frequently used items for quick access, helping users navigate more efficiently and find content faster. *** **Enhancement****** **Consolidated Knowledge & AI capabilities in Service menu:** Knowledge & AI capabilities are now available under a dedicated Knowledge & AI section in the Console Service menu. Core applications have been re-homed from Manage, Administer, and the Agent Library is introduced as a new entry. This update provides a single, intuitive access point, reduces navigation complexity, and improves discoverability, while preserving existing permissions and functionality. ::: *** :::ExpandableHeading # Container Cluster Management ## September 2026 **September 30** **Enhanced cluster optimization with the configuration assistant model: **Site reliability engineers and operations teams can now identify underutilized Kubernetes clusters and receive data science-driven downsizing recommendations. The feature analyzes historical cluster utilization data to generate optimization insights, including current and recommended node counts, helping teams reduce infrastructure costs and improve resource efficiency. *** ## March 2026 **March 18** **Utilization Insights now available: **SREs now benefit from utilization and capacity insights, enabling preemptive action in the context of CPU and memory over-utilization and under-utilization. The new dashboard presents the count of cluster utilization with the ability to drill down for additional details on each cluster. *** **March 11** **Enhancement****** **F1 Dashboard now supports Container Cluster Management Actionable Insights:** Users of F1 dashboard now benefit from additional insights produced by Container Cluster Management, extending their environment observability and their ability to take preemptive action. *** **New role-based dashboard:** Limited to subscribers assigned the Capacity & Performance Engineer role, this dashboard enables capacity engineers to view clusters in the context of over- and under-utilization and over-committed clusters. The dashboard enables an efficiently acquired, keen understanding of current capacity and the ability to preemptively balance resources for maximum cost efficiency. *** ## February 2026 **February 25** **Enhancement****** **CCM now fully integrated with Application Portfolio**: Site Reliability Engineers can now consult CCM with confidence that application names in the CCM dashboard are correct, minimizing possible confusion. To that end, CCM is now fully integrated with Application Foundation. *** **February 18** **Persistent Volumes**: A new insight enables Site Reliability Engineers an at-a-glance assessment of cluster Persistent Volumes, enabling preemptive action in near real-time. Persistent Volume Inactive and Orphaned are now supported. *** **Persistent Volume Claims**: Container Cluster Management offers Site Reliability Engineers an at-a-glance assessment of cluster Persistent Volume Claim utilization, allowing preemptive action and resource balancing as needed in near real-time. Persistent Volume Claims utilization insights are now supported as Underutilized, Overutilized, and Running Out. ::: *** :::ExpandableHeading # Continuous Controls Monitoring & Management ## July 2026 **July 1** **New Control Library dashboard is now available:** Continuous Controls Monitoring & Management now introduces a Unified Compliance Framework (UCF) with multi‑framework control mapping, enabling users to view controls across standard cybersecurity frameworks. This dashboard helps teams manage compliance at scale without navigating siloed standards, resulting in less duplication, clearer coverage, and faster progress toward readiness. *** ## May 2026 **May 6** **Risk Insights dashboard is now available**: This new dashboard provides a unified view of enterprise risk across compliance, exposure, patch management and asset lifecycle. Users can quickly see where risk originates, how it is weighted and which areas need attention, supporting proactive and informed decision‑making. Standardized risk indicators, transparent weighting and consistent severity levels clarify how key metrics contribute to the overall risk score. ::: *** # Data Foundation ## September 2026 **September 23** **Introduced data discovery in the data registry:** Data catalog administrators can now search regional data planes for unregistered datasets, review schema details, and register tables in one step. This helps make more trusted data available for analytics and dashboards while preserving existing role-based access controls. *** ## August 2026 **August 19** **Enhancement****** **Added new filters and dashboards for incoming data monitoring:** Data operations engineers can now filter incoming data by contact ID, customer name, and hostname, and access three new dashboards: Incoming Vulnerability Management Data, Incoming Mainframe Data, and Incoming Security Healthcheck Data, for improved visibility and analysis. *** ## May 2026 **May 13** **Enhancement****** **Improved multi-tenancy filtering and tenant scoping:** A new multi-tenancy filter has been added at the query layer with support for dual lookup keys, along with table-level tenant metadata to better define tenant scope. These updates improve filtering accuracy and prevent incorrect tenant tagging, especially for global tables. *** **May 6** **Enhancement****** **Enhanced broker registration to GCP IAM:** Broker registration to the Global Control Plane (GCP) and Identity & Access Management (IAM) now includes initiating the migration of access policies from the Distributed Control Plane (DCP) to GCP, supporting a unified IAM model. This enhancement helps improve consistency and governance of access across services. The update applies to data engineers using standard Bridge access groups and does not introduce any immediate change to existing user access. *** **Enhancement****** **Bridge Regional Plane apps updated: **The Bridge Regional Plane applications have been aligned with the Argo Deployment Framework to ensure consistency and streamline operations. Integrating AIOps capabilities is critical for proactive monitoring and management in the Kyndryl Platform Region (KPR) environment, with the aim of significantly improving system reliability and operational efficiency. *** **Tokenization and detokenization capabilities are now available for specific Elasticsearch indices:** Kyndryl Bridge introduces tokenization and detokenization to protect sensitive data by enforcing authorization, encrypting data, and securely storing it via Manetu. Sensitive fields are replaced with UUID/IRI tokens, enabling secure access, controlled detokenization for authorized users, and improved compliance through seamless tokenization of existing data. Manetu secures sensitive information by validating authorization, encrypting it, and safely storing it. It uses unique Internationalized Resource Identifiers (IRIs) for externally stored anonymized tokens. A policy engine regulates access by replacing sensitive fields in Elasticsearch with UUID/IRI tokens, while only Manetu retains the encrypted data. Authorized users can detokenize data as needed, and Logstash helps migrate and tokenize existing data to improve security and compliance. *** ## March 2026 **March 11** **The Data Registry page is now available in Kyndryl Bridge Data Foundation: **Bridge users can easily access and explore domains, subdomains, and tables in one place. There is an option to create a table to visualize better how the data is generated and how the indices are displayed. This capability saves time by reducing the need to search across multiple systems. It also improves data analysis across other applications that leverage Data Foundation, enabling the creation of detailed query layers. *** ## February 2026 **February 25** **The data registry page is now available in Data Foundation**: Users can easily access and navigate domains, subdomains, and tables from different catalog types within one interface. The data registry provides information from Data Lake, Elasticsearch, and MongoDB, which simplifies data discovery and enhances visibility into access policies and schema versions. This streamlined approach saves time by eliminating the need to search through multiple systems. Additionally, it enables users to better analyze data from other applications, allowing them to create comprehensive query data layers. *** **Enhancement****** **Extensions Console UI enhancements: **The extensions console has been updated to enhance the user experience, in accordance with Shidoka v2 guidelines. The extensions instance page has introduced a new field for custom extension environment variables. The catalog settings feature has improved logic and has been rebranded as the extension's registry. Furthermore, UI enhancements have been implemented to deploy extensions within the Instance creation wizard to improve the common catalog experience. Users can now use a view-only experience, edit draft extensions, and have date-time field labels display correctly while browsing extensions in the UI. Extension instances can now be rolled back to the previous release if they fail during an upgrade. *** **Enhancement****** **Extensions Service enhancements: **The extensions service has also been updated to comply with Shidoka v2 guidelines. The database schema setup has been automated for improved efficiency when the extension service starts. The extensions service now allows deleting shared instances of an extension along with their associated subscriptions. Additionally, it includes a feature to check for duplicates, which displays the name and an error message if duplicates are found. *** **Enhancement****** **Extensions Controller enhancements: **The extensions controller application now supports new Azure-scheduled T-shirt sizes for extensions. The default persistent volume size has also been reduced from 10 Gigabytes to 1. Significant fixes were also applied to support special characters within JSON fields passed from users of the extensions UI. *** :::ExpandableHeading # DevOps Intelligence ## October 2026 **October 14** **Introduced Dynamic Scan Visibility with Tenable.io integration: **Development managers, CISOs, release managers and security champions can now access Dynamic Application Security Testing (DAST) results directly within DevOps Intelligence through the integration of Tenable.io. The new Dynamic Scan Visibility experience provides centralized visibility into runtime security vulnerabilities, including vulnerability summaries, application security posture, scan coverage and detailed findings for onboarded technical services. Users can filter results, analyze vulnerability trends and drill down into detailed scan results to support remediation efforts and security risk management. *** **Enhancement****** **Enhanced DSRR entry and exit workflow and approval governance:** Release managers can now manage DSRR entry and exit activities through a redesigned card-based experience. Enhanced approval validation helps ensure that required criteria are met before approval. Automated tagging and state transitions reduce manual effort and improve process consistency. Updated notifications and reminders help stakeholders stay informed and take action on pending approvals in a timely manner. *** ## June 2026 **June 24** **GitHub secret scan integration is now available for DI: **DevOps Intelligence now integrates with GitHub Secret Scanning to ingest and surface secret scan alerts within the platform. Users can identify exposed sensitive data and monitor secret exposure trends through the Security & Compliance Posture widget on the Secure overview page, with detailed alert information available in the Secret Scan page. *** **June 17** **Enhancement****** **Multi-level JFrog repository support is now available for DI:** DevOps Intelligence now supports multi-level repository selection in JFrog. Users can onboard specific folders or images instead of entire repositories, improving precision, reducing unnecessary data ingestion and ensuring accurate artifact attribution.DevOps Intelligence *** ## April 2026 **April 29** **Secure Alerts are now available:** Secure Alerts are now available in the Release Management dashboard, giving Security Champions a quick, at‑a‑glance view of security alerts for an application or technical service. This visibility helps them identify security issues early and take timely action as part of release readiness. *** **April 22** **Enhancement****** **Expanded application services view for Security pages: **Users can now view all services associated with selected applications in addition to only those with identified vulnerabilities, enabling a more holistic understanding of application security. Users can now also filter items and export the filtered content to supported report formats such as CSV. *** ## February 2026 **February 11** **Enhanced open source license compliance categories**: The security champion can now easily set licensing priorities and reduce compliance lapses using the updated License Compliance Details table. The table now includes the following compliance categories: denied, need approval, allowed, and uncategorized. Learn more: [DevOps Intelligence user interface](docId\:iV9_a8FQeLZztNr95F3Nu) ::: *** :::ExpandableHeading # Logging & Monitoring ## July 2020 **July 1** **Logging & Monitoring service is now available in Bridge: **Bridge now provides a common logging service for application logs, enabling faster troubleshooting through unified visualization, monitoring and log‑to‑trace correlation in Grafana. Users gain reliable, advanced monitoring across applications and services, with secure, account‑based visibility enforced by Bridge IAM and seamless switching between services to view logs in one place. *** **Enhancement****** **Converged GCP IAM is now available for the Bridge Logging service: **The Bridge Logging service now adopts the new converged Global Central Plane (GCP) IAM, leveraging Bridge IAM as the unified authorization layer to enable consistent and centralized access control across the platform. ::: *** :::ExpandableHeading # Managed Network Services ## August 2026 **August 12** **Enhancement****** **Enhanced tool selection for network onboarding: **Console users can now choose one or more tools, NetBox, Zabbix, or BackBox, in the Tool Selection section before submitting a CSV file. Unselected tools are skipped, and their fields show as a hyphen in the results, providing flexibility and clarity in the onboarding process. Learn more: [Onboarding Network Devices](docId\:P5KA-M_5g8ThZ3Tj5d97m) *** **Enhancement****** **Improved device onboarding visibility and network onboarding experience: **Console users now see accurate tool resubmission status indicators with real-time table updates during active processes, reducing confusion and improving progress tracking. The updated CSV template clearly marks mandatory and optional fields to lower upload errors and streamline onboarding. Learn more: [Onboarding Network Devices](docId\:P5KA-M_5g8ThZ3Tj5d97m) *** ## July 2026 **July 15** **Enhancement****** **Automated network device data collection for onboarded devices:** Network device inventory is continuously updated with automated data collection scans, reducing manual effort and improving data accuracy. This provides a trusted foundation for network management, security monitoring, and compliance reporting. *** **July 1** **Network Device Status widget added: **Executives can now use a Network Device Status widget to view overall network health and drill down into details. This new visualization shows key characteristics, related IT service management (ITSM) tickets, application overlays, usage, performance, and trends, helping teams quickly identify and resolve potential issues. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **Simplified navigation to Managed Network Services: **A simple, unified navigation path to Managed Network Services provides greater efficiency for users, enabling quicker adaption and greater navigation retention. Learn more: [Managed Network Services landing page](docId\:bA8Fg2naO4M5rXii67KL1) *** **New Managed Network Services widgets available in Console: **Console users can now find widgets that display network devices by vendor, firewall vendors and load balancer technologies. This provides clear visibility into vendor distribution and technology usage, helping improve compliance, reduce vendor sprawl, support standardization, and simplify network management and troubleshooting. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **Incidents Over Time detail page created: **Executives can now drill down into an Incidents Over Time detail page for a deeper view of incident trends and related data. This page consolidates historical patterns, IT service management (ITSM) tickets, and key metrics, helping stakeholders analyze root causes and take proactive steps to maintain network health. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **Incidents Over Time widget added: **Executives can now access an Incidents Over Time widget to track and visualize incident trends. The widget displays historical patterns and related data, enabling stakeholders to monitor network health, identify recurring issues, and drill down for detailed analysis to support faster resolution. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **Network Device Status widget details page created: **Executives can now access a Network Device Status widget details page that provides an in-depth view of network health. The page consolidates key characteristics, IT service management (ITSM) tickets, application overlays, usage, performance, and historical trends, enabling faster insights and drill-down analysis to address potential issues. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **Network Device Type widget details page created: **Executives can now use the network device type widget details page to drill down into comprehensive network data. The page displays device characteristics, related IT service management (ITSM) tickets, application overlays, usage, performance metrics, and historical trends with forecasting, helping stakeholders assess network health and identify potential issues quickly. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** **New widgets are now supported: **Two new utilization widgets are now available to enable an at-a-glance assessment of critical resource utilization: **CPU Utilization **and** Memory Utilization**. Users can quickly assess which devices are running critically low on these CPU and Memory availability. Learn more: [Supported Widgets](docId:8UEPCDvSO1FAxYXhJcqAN) *** ## June 2026 **June 10** **Enhancement****** **Network device onboarding enhanced with progress indicator: **The device upload experience is now enhanced with a visual progress indicator and real-time feedback, enabling users to easily track onboarding status and gain better visibility into network inventory uploads. Users can now see the progress of device uploads in real time, indicating progress as it occurs. *** **Enhancement****** **Onboarding process enhanced:** Administrators now have a streamlined onboarding process when failures occur, increasing efficiency and minimizing onboarding time. The onboarding service now validates onboarding data, and reports errors during the process. Administrators can then correct errors and resubmit the device list with minimal effort. *** ## April 2026 **April 8** **Onboarding network devices to Network Configuration Management tool now supported:** Network devices can now be onboarded to the Network Configuration Management tool using the current consolidated onboarding process. The consolidated onboarding process ensures network devices are onboarded concurrently to all tools in the Network Service Hub stack. ::: *** :::ExpandableHeading # Notifications Management ## September 2026 **September 2** **Introduced priority notifications across all accounts: **Platform Administrators can now create and manage priority notifications across all accounts and regions or target them to specific accounts and regions. These tenant-level notifications require users to acknowledge important messages, helping organizations communicate critical platform updates, maintenance activities, service disruptions and other important announcements. Administrators can configure notifications as well as create, edit and delete notifications as needed. Notifications remain visible until acknowledged or expired and are automatically removed after their configured expiration date. *** ## July 2026 **July 22** **Enhancement****** **Bridge Notification Service now available in Bridge Operations: **The converged Bridge Notification Service is now available in the Global Control Plane through the Bridge Operations tenant, also known as Kyndryl Platform Central (KPC). Currently, the Service Based Notification is enabled in control plane. As a shared Kyndryl Bridge service, it can be adopted by all control plane services to publish and manage notifications consistently. This convergence reduces duplication, improves visibility and provides a consistent notification user experience. Notifications are received in near real time making it easier for users to monitor activities, status changes and important events across Kyndryl Bridge. Learn more: [Bridge Notification Service](docId\:Cc4Sf-ex6YCcA3P06YELV) *** **July 8** **Unified Notification Service in **&#xNAN;**: **The launch of the converged Notification Service brings together the previously separate , and Service notification capabilities into a single common notification service with one unified API. As a shared service, it can be adopted by all applications and services across the platform to publish and manage notifications consistently. This convergence reduces duplication, improves visibility and provides a consistent notification user experience, making it easier for users to monitor activities, status changes and important events across . It supports both service-based notification (generated against an event) and priority notifications (info messages). more: [Bridge Notification Service](docId\:Cc4Sf-ex6YCcA3P06YELV) ::: *** # Orchestration Catalog ## September 2026 **September 30** **Enhancement****** **Orchestration Catalog integrates with Bridge Access Management**: Orchestration Catalog Services now connects with Bridge Access Management during onboarding. This enhancement enables tag-based access control so policies and roles can use access tags for more granular automation access. Learn more: [Access Tags](docId:4uNGb4hdEmNoILtQg1oLi) *** [title] 07. Release Notes [path] / [title] January [path] Release Notes/2025 Release Notes/ ::::ExpandableHeading # January 29, 2025 ## DevOps Intelligence **Team-level tracking for Azure Boards:** DevOps Intelligence has expanded project tracking support for Azure Boards, to include team-level tracking during the Plan phase. Tracking at both the Organization and Team level enhances the extensibility and user experience of DevOps Intelligence. **Bring your own CLT API:** DevOps Intelligence now supports Bring Your Own CLT (Change Lead Time) API, enabling your team to use data collection systems of your choosing beyond those supported by native integration. ## Container Cluster Management (CCM) **Enhanced user interface presentation for Actionable Insights**: The collection of Actionable Insights is now presented in the context of four categories: :::Paragraph{listStyleType="disc" indent="2"} Security and Compliance ::: :::Paragraph{listStyleType="disc" indent="2"} Reliability ::: :::Paragraph{listStyleType="disc" indent="2"} Performance ::: :::Paragraph{listStyleType="disc" indent="2"} Optimization ::: :::Paragraph{indent="1"} A more facile, at-a-glance assessment is now supported. ::: :::: ::::ExpandableHeading # January 15, 2025 ## DevOps Intelligence **Enhanced UI presentation on select features**: DevOps Intelligence presents an enhanced and simplified UI presentation. - **Consolidated Global Filter**: The Global Filter has been reduced to a single dropdown menu that enables the selection of both applications and duration. - **Unified details presentation**: The details pop-up panel, accessed by clicking on View Details in the Table View, has been replaced by a complete details page. ## Platform Foundation **Tag definitions are now available in Common Services: **A tag management service is now available in Kyndryl Bridge. This is a centralized tag management service that helps you to have better control of the tags created to organize your applications and services. As the first stage, the tag definitions page is available to create and manage governed tags. To ensure consistent data tagging, tag definitions provide the following capabilities: :::Paragraph{listStyleType="disc" indent="2"} It empowers tag administrators to create and manage consistent, pre-defined tag keys. ::: :::Paragraph{listStyleType="disc" indent="2"} Manage the lifecycle of Tag keys. ::: :::Paragraph{listStyleType="disc" indent="2"} Unique keys to eliminate any possible duplicate key. ::: :::Paragraph{listStyleType="disc" indent="2"} Enforce standard tag values through the use of constraints. ::: :::Paragraph{listStyleType="disc" indent="2"} Tags categorization. ::: :::Paragraph{listStyleType="disc" indent="2"} Specific scope to limit where tags are applicable. ::: :::: [title] August [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # August 15, 2024 ## Kyndryl Bridge **Banner message for user synchronization**: A new banner notifies users that their data is being synchronized before they can access any subscribed services. This feature enhances user experience by providing clear communication and reducing confusion. ## Platform Management **Automatic removal of platform notifications**: Platform notifications older than 90 days are now automatically removed from the Kyndryl Bridge platform to improve application performance and reduce message clutter. ## Service Provider **Quotation history logs available**: Users can now view history logs for all quotation records on the Service Provider Dashboard. These logs include the date, user name, attribute, and updated values. ::: :::ExpandableHeading # August 8, 2024 ## Platform Management **CollabDrive report available**: Users can now view and download the list of files uploaded to CollabDrive during the last 90 days. An approval flow has been established for update requests to properly govern any actions taken on the Bridge accounts. **Approval Flow for Account updates**: An approval flow has been established for update requests to properly govern any actions taken on the Bridge accounts. ## Services Catalog **DWS IT support subscriptions approvals**: DWS IT Support subscriptions allows Account Managers to validate and add required subscription details (Start Date/End Date and approvals comments if any) before approving the subscription. **Kyndryl Modern Device Management Services can be integrated:** Now, DWS Subscription Device Management is available in Kyndryl Bridge ## Kyndryl Bridge **New Private catalog category in global switcher**: The Kyndryl Bridge global switcher now includes a ‘Private catalog’ category, where users can access private catalogs such as the Program Management Portal (PgMp). This enhancement provides users with a centralized way to quickly access and manage their private resources. ::: [title] February [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # February 28, 2024 ## Cost & Asset Management - KCNS **Cloud Native Oracle Cloud Asset Extraction**: CAM has enhanced its FinOps capabilities with the integration of Oracle Cloud as a supported adapter for asset extraction. This development addresses the need for custom adapter creation, which previously added significant time and cost to onboarding projects. The Oracle Cloud adapter simplifies the asset extraction process, leading to more efficient onboarding and optimization in cost management for customers using Oracle Cloud services. This feature is available across all Kyndryl editions and empowers users from Enterprise IT Finance to provide better cost transparency and understanding of IT spend from Oracle Cloud, extending across multiple cloud providers, business lines, and operational teams. **Cloud Native Oracle Cloud Asset Tag Extraction**: Cost & Asset Management now integrates Oracle Cloud as a supported adapter for cost extraction, enhancing the efficiency of onboarding and cost management for Oracle Cloud services. This update reduces onboarding time and costs and improves spending visibility and management, which is applicable across all editions. It enables Enterprise IT Finance teams to achieve a more transparent and effective understanding of IT expenditures related to Oracle Cloud. **Cloud Native Oracle Cloud Cost Extraction in CAM**: Cost and Asset Management now includes Oracle Cloud as a supported adapter for cost extraction, streamlining onboarding and optimizing cost management. This update offers a more efficient approach for customers deploying services on Oracle Cloud, reducing both onboarding time and costs. With this integration, users gain enhanced visibility into cost trends and can manage their spending more effectively. The solution's benefits extend across all editions, providing comprehensive cost transparency and enabling Enterprise IT Finance teams to facilitate a clear understanding of IT spending from Oracle Cloud. **UI upgraded to Angular version 16 in Cost & Asset Management**: With the Angular 16 upgrade, now we have enhanced UI performance, new features to the UI framework, and improved security (All security vulnerabilities are fixed). **New Commitment-Based Discounts dashboard available in Cost & Asset Management**: Users can now access details and recommendations for pricing on services from Azure on a dedicated dashboard. This feature is accessible only after enabling a feature flag. **Renamed Feature - Add to Graph**: The "Add to Graph" has been renamed to "Compare Costs" for enhanced clarity. ::: :::ExpandableHeading # February 23, 2024 ## Services Catalog **Ability to add repeated configurations on request for quotations**: To improve the user experience and better organize the quotes solicitations, you can now use a recurrent configuration when requesting a quote for several data centers. In this way, you can manage the quote information of several data centers under one single request. ## Console **Digital Workplace Service (DWS)**: DWS can now be integrated with the Bridge Console, allowing subscribed existing users to take advantage of the fully integrated experience within Kyndryl Bridge. ::: :::ExpandableHeading # February 21, 2024 ## DevOps Intelligence **Release parameters can now be configured by users in Release Management**: DevOps Intelligence Release Management now supports the configuration of application release parameter values, such as maximum number of critical bugs, Code Coverage, and Failed Functional Tests, etc. This new capability provides customized insight for release managers making go/no-go decisions for each application at each release, maximizing production quality. This extended support is possible because of the introduction of a new role, Release Manager, which enables release management for individual applications. Users assigned the Admin role can configure release parameters at the tenant level. **Elite category now supported for DORA Benchmarking**: DORA has introduced a new benchmarking category, Elite, which is supported by DevOps Intelligence. This new category provides enhanced insight into your organization’s comparative performance. ::: :::ExpandableHeading # February 16, 2024 ## Service Provider **User profile capability now available**: To improve the customer experience, personalize recommendations, and monitor user activity for security and fraud prevention, a user profile is created based on your basic details and access information. **History log functionality is now available for mobile devices**: To improve the mobile experience, users can now review the history logs of all requests. You can refine your results using the dropdown menu available for each filter. ## Services Catalog **Error message displayed for failed requests**: To inform authorized users when requests cannot be completed, an error message is displayed for the following unsuccessful scenarios: - Request for Consultation - Request for Quotation - Request for Subscription - Assessments - Request to access the Services Catalog from a non-permitted account ::: :::ExpandableHeading # February 9, 2024 ## Service Provider **Secondary navigation menu available:** To ensure a consistent Kyndryl Bridge experience across all pages, a secondary menu has been added where you can access the following pages: - Home - Consultations - Quotations - Subscriptions - Notifications - Workbench **Ability to define hidden and visible fields for Service Provider customers**: Users can define internal and external fields on service configurations, provisioning questions, and service elements during the account configuration. If the fields have been marked as internal, only users with the Admin role can view the corresponding fields. ::: :::ExpandableHeading # February 8, 2024 ## Container Cluster Management (CCM) **Amazon CloudWatch now supported**: Users benefit from real-time visibility into their cloud platform to facilitate troubleshooting, ensure availability, and minimize impact on business operations. ::: :::ExpandableHeading # February 2, 2024 ## Service Provider **User Access Management enhancements**: Administrators can add new members and include them in an access group easily. The Access Management page under the access group tab now displays the "Add existing members" and "invite new members" options when no users have been invited. ::: ## ## [title] September [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # September 25, 2024 ## Service Provider **Marketo integrated in Kyndryl Bridge**: Now, you can view the current status from ATLAS and update the status accordingly. ::: :::ExpandableHeading # September 11, 2024 ## Container Cluster Management (CCM) **Physical limits are now available on Nodes details**: The Monitoring tab of the Nodes details page now shows the Physical limits of CPU and Memory, along with the 'Request', 'Limit', and 'Usage' of CPU and Memory. **Pod entries are now expandable for viewing logs**: Users can now view logs for individual pods on the Pods tab of the Nodes details page. ## DevOps Intelligence **E-mail IDs no longer masked**: Contributor IDs or Contributor names (depending on the Development tool) are now included on the Develop Detail page as a standard presentation. The option to mask this data has been removed. ::: :::ExpandableHeading # September 4, 2024 ## Services Catalog **Tags introduced for Bridge Services**: Deployment Strategy and Type tags are now available for Bridge services on the Service Details page. Services can be labeled with up to four different tags, such as on-prem, hybrid, cloud, infrastructure, platform, software, security, backup, and monitoring. **New categories added to Services Catalog**: Deployment Strategy and Product categories have been added to the Services Catalog to help users filter and search for services. **Services Catalog updated**: The user interface of the Bridge service catalog has been updated to improve the user experience. ::: [title] July [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # July 31, 2024 ## DevOps Intelligence **SonarQube Enterprise Edition now supported**: DevOps Intelligence has expanded tool support to include SonarQube Enterprise Edition, accommodating your DevOps stable of tools. **New test category, Blocked, supported**: DevOps Intelligence now supports **Blocked** test cases, expanding report statuses to include test cases that could not be performed because of any blockers. **QMetry now supported**: DevOps Intelligence has expanded tool support to include QMetry for test management, accommodating your DevOps stable of tools. ::: :::ExpandableHeading # July 24, 2024 ## Cost & Asset Management **FinOps maturity widget release for Kyndryl Bridge and CAM**: This widget offers a clear view of on-demand, reserved instances, and savings plan consumption across AWS and Azure. Users can compare their consumption with FinOps benchmarks, enhancing the management of commitment-based discounts by highlighting patterns and trends. It allows benchmarking against industry standards, identifying areas for improvement, and enabling informed decisions for efficient cloud resource management. ::: :::ExpandableHeading # July 17, 2024 ## Kyndryl Bridge **Enhanced global navigation**: The Kyndryl Bridge account switcher now displays the name of the account being viewed to help users better understand the account context and expedite daily activities such as support and demos. ## Console **Enhanced Console experience**: The user experience in Kyndryl Bridge Console has been improved to streamline interactions. Enhancements include UI changes in text formatting and alignment, and improved hover state behaviors. These updates are implemented on the Chrome and Firefox browsers. ## Services Catalog **New Azure Stack HCI Assessment for existing customers**: Users with an existing Azure HCI Stack subscription can now access the full Azure Stack HCI Assessment native integration from Bridge. This assessment allows you to evaluate the solution and integrate on-premises systems with Azure, enabling you to run virtual machines and containerized workloads locally while connecting to Azure for cloud-based services such as observability, security, and unified operations. Future enhancements will include integration with Console via widgets and storage of assessment results within Bridge. ::: :::ExpandableHeading # July 11, 2024 ## Platform Management **Activation email enhancements**: To improve the account activation process and reduce the number of expired invitations, a new permission allows only permitted users to resend the activation email to users. **Personal accounts deletion**: Administrators can now trigger an account offboarding to initiate a soft deletion for personal accounts with a long period of inactivity. Email notifications will automatically send to designated users. **Control Tower UI updated**: The user interface of the Control Tower has been updated to improve the user experience. ## Services Catalog **UI page enhancements**: To improve the customer experience, the following pages have been updated: - Request for Quote - Request for Subscription - Request for Consultation ::: :::ExpandableHeading # July 4, 2024 ## Kyndryl Bridge **Terms and Conditions updated**: All Kyndryl Bridge users are now required to review and accept the Terms and Conditions before using any Kyndryl services. ## Platform Management **Enhancements to account ownership**: The Kyndryl Bridge team can now change the account owner after the account onboarding process is complete. This technique allows the transfer of account ownership to account managers or delivery partners following the initial setup. **New access groups available for Kyndryl AIOps**: New service-specific access groups have been created to view, operate, and administrate the Kyndryl AIOps service ## Services Catalog **STAAR subscription available in Kyndryl Bridge**: STAAR is now integrated in Kyndryl Bridge, which allows users to submit subscription requests for this service. ::: [title] June [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # June 28, 2024 ## Console **CollabDrive widget available in Console**: To improve the customer experience for CollabDrive, a widget can now be added to the dashboard where users can view reports and assessments easily. This widget contains the date, document name, and document category, as well as an option to view all documents. **CCM UI enhancements**: The CCM service page has been improved so users can view vital statistics related to the availability, health, and design of the containers. ::: :::ExpandableHeading # June 26, 2024 ## Containet Cluster Management (CCM) **View by Application and View by Environment filter support has been added**: Users can now filter CCM data by environment and application, enabling a focus on clusters within specific implementations. ::: :::ExpandableHeading # June 21, 2024 ## Services Catalog **New Bring Your Own License (BYOL) subscriptions available**: Users can now submit subscription requests for these services from Kyndryl Bridge: - VESA - Standard BaaS - Managed Apps ## Kyndryl Bridge **Enhanced global navigation**: Kyndryl Bridge global navigation has been unified and simplified for a more intuitive and consistent use across the entire platform. The new Global Switcher serves as a centralized hub to switch between services, catalogs, portals, and navigate through Bridge settings and Services settings, such as Access Management, IAM, and Connections. It also includes the capability to pin service items for quick access. ::: :::ExpandableHeading # June 19, 2024 ## Compliance and Security Operations **Compliance and Security Operations dashboard updated**: The user interface of the dashboard has been updated to improve the user experience. ::: :::ExpandableHeading # June 12, 2024 ## Container Cluster Management (CCM) **Pods in CrashLoopBackOff**: CrashLoopBackOff is a Kubernetes status indicating that a pod is failing to run successfully. CCM now identifies Pods in a CrashLoopBackOff status and provides root cause and recommendations to repair the underlying issue. **Pods restarted**: CCM provides insights on the pods that were restarted in the last 24 hours and provides the root cause and recommendations. Pods in pending state: CCM identifies pods that are in a pending state with root cause and recommendations for remediation. **Pods with pending state**: Shows the list of Pods that are in a pending state. **Pods with Singleton design**: CCM identifies pods that are designed to run as a single instance. ::: :::ExpandableHeading # June 7, 2024 ## Services Catalog **Subscription price text updated**: The text for subscription pricing of non-fixed price services has been updated to improve clarity. ::: :::ExpandableHeading # June 5, 2024 ## Compliance and Security Operations **New Top 2 Affected Compliance Regimes widget on Kyndryl Bridge**: The Top 2 Affected Compliance Regimes widget is now available on Kyndryl Bridge Console. **New Critical & High Risks Introduced by Asset Changes widget on Kyndryl Bridge**: The Critical & High Risks Introduced by Asset Change widget is now available on Kyndryl Bridge My Console. ::: [title] 2024 Release Notes [path] Release Notes/ [title] November [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # November 27, 2024 **Platform Foundation** **New key supported in IAM usersetting APIs**: A new key has been added to the IAM APIs, “landingpage”, which is now populated on the user’s profile page, enabling a more complete profile presentation. **AIOps account data now available in Bridge**: Account data from AIOps implementations is now included in your Bridge account, enabling an association of AIOps data with specific accounts. **Streamlined user management**: Existing users added to additional accounts will receive an email notification rather than an email invitation, circumventing the requirement for any action on the part of the user. ::: :::ExpandableHeading # November 13, 2024 ## Services Catalog **Updated Services Catalog home page**: The Services Catalog home page user interface has been updated to improve the user experience. Key improvements include refined search and filter capabilities, an optimized Featured Services section, and a new FAQs Overview section directly accessible from the home page with navigation links to detailed pages. ::: [title] October [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # October 9, 2024 ## DevOps Intelligence **GitHub Actions is now supported for DevOps Intelligence Deploy**: DevOps Intelligence has expanded support of GitHub Actions to include Deploy. ::: [title] October [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # October 15, 2025 ## Discovery & Inventory **Manually refresh Discovery scan:** Users can now trigger a discovery scan, refreshing their data at will. Users are no longer required to wait for hourly automated discovery scans. They can now refresh discovered data at will with a single click, enabling real-time asset updates that ensure current surveillance of their IT estate. ::: :::ExpandableHeading # October 1, 2025 ## DevOps Intelligence **View all technical services for specific applications:** With a single click, navigate to an application details page containing a consolidated list of technical services onboarded for the application, for quick reference, and assess whether technical services are missing from the application. **Two new security parameters for Release Management:** Release Management supports two additional security parameters: **Critical Vulnerabilities** and **Denied Licenses**. These new parameters enable enhanced decision-making for *go-no go* release triggers and assist them in understanding the security posture of releases. ::: [title] May [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # May 21, 2025 ## DevOps Intelligence **New Secure Dashboard:** DevOps Intelligence introduces the Secure SDLC Governance Dashboard. The Secure dashboard provides reports and scoring to assist security assessments using data accumulated from supported tools. This new dashboard further enables support for a staff Security Champion, encouraging an enhanced focus on security. ::: [title] May [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # May 31, 2024 ## Console **Subscription History logs available**: A centralized page has been added that shows all updates made on the subscription record. This history log provides information on who performed the update, fields updated, description of values, and the date and time when the action was performed. Additionally, all records can be exported in .CSV format. ::: :::ExpandableHeading # May 24, 2024 ## Support **An internal status page is available in Kyndryl Bridge**: The Internal Status Page is now available for all Kyndryl Bridge internal users to subscribe to and receive notifications about outages and maintenance on Bridge. **Bridge Support enhancements**: The Bridge Support ticketing system now automatically responds to support tickets raised by end users, acknowledging their issue and providing a ticket number. **New user dashboard accessible**: The Bridge Experience Center now features a dashboard displaying response times to users on each Kyndryl Page. **Scanning ability for Docker images**: The Bridge microservice Docker images are now scanned with JFrog's X-Ray tool, aligning with the tools provided by Kyndryl's CISO/CIO. **Redis SaaS is now available in Kyndryl Bridge**: The Bridge development environments can now consume Redis SaaS. **Atlas MongoDB has been upgraded to version 6.0**: Bridge Platform applications in non-production environments can upgrade their Atlas MongoDB to version 6.0. ## Services Catalog **Bring Your Own License (BYOL) subscription for AIOps**: Now, users can submit subscription requests for AIOps services from Kyndryl Bridge. ::: :::ExpandableHeading # May 5, 2024 ## DevOps Intelligence **Streamlined application onboarding workflow**: Onboarding technical services into DevOps intelligence is significantly easier with a new application onboarding mechanism. Users can now create applications and provide associated metadata in a single pane and then onboard relevant technical services as part of a new, seamless workflow. **Environment filter now available for Deploy**: Users can now filter deploy data by environment, enabling a more focused data set. ::: :::ExpandableHeading # May 1, 2024 ## DevOps Intelligence **Release Management Dashboard parameter drill-down**: The Release Management feature now supports a drill-down capability to expose details of all release parameters for each release, enabling a more thorough analysis. **UI for Tool Mapper creation**: DevOps Intelligence now supports creating tool mappers in the UI, providing a more efficient method of pushing data to DevOps Intelligence and leveraging the bring your own tools mechanism. ::: [title] January [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # January 31, 2024 ## Cloud provider **Cloud provider ingestion status data available**: Users can now view ingestion status in the Costs and Asset dashboard, recommendation job status in Insights, Anomalies, and Discount pages, and tag recommendation and tag compliance job status in Tag Management pages. ## Cost dashboard **Compare costs table is available in the Costs Dashboard**: Users can view a table with the total cost and timeline information. ::: :::ExpandableHeading # January 26, 2024 ## Service Provider **Pagination options enhancements for dashboards**: To quickly find a particular record of interest, users can now increase the results displayed to 50, 75, or 100 items per page for the following pages: - Subscriptions - Quotations - Consultations - Notifications - Users (Access Management) ::: :::ExpandableHeading # January 24, 2024 ## Reports **Reports can now be downloaded for Develop pages**: DevOps Intelligence now enables users to download data on the Develop dashboard. The user can download data in Excel format and send reports to those who do not have access to DevOps Intelligence or want to perform additional analysis on the consolidated Develop dataset. ::: :::ExpandableHeading # January 19, 2024 ## Console **Dashboard Management enhancements**: Now, users can search for specific widgets, filter the dashboard management side menu by widget provider, or view tech history facts in the information banner. **Dashboard Management enhancements**: The Dashboard Management allows users to add two or more grouped widgets (widget bundles) into existing or new dashboards. Additionally, you can filter your search by widget bundle. **Widget preview/ info in grid mode**: Users can view detailed information of your available widgets by using grid mode (including widget preview and slide out into effect). ## Support **Contact support for anonymous users**: Kyndryl Bridge now features access for non-logged-in users to contact support. Thanks to a support form, users can communicate with the Bridge Support to troubleshoot issues. **Internal Status page**: A status page has been created to inform Kyndryl collaborators of any outage, partial outage, or maintenance on Bridge. **Yammer/Viva Bridge support communications**: A communication page is available in Yammer for support-related queries. ::: :::ExpandableHeading # January 17, 2024 ## SDLC **DevOps Intelligence is extending its enhancements on Secure in SDLC**: New out-of-the-box support of Qualys for Container Security and CodeQL for open-source license compliance provides broader and deeper Secure support. ::: :::ExpandableHeading # January 12, 2024 ## Console **Dashboard Management enhancements**: Now, users can search for specific widgets, filter the dashboard management side menu by widget provider, or view tech history facts in the information banner. Widget bundle capability: The Dashboard Management allows users to add two or more grouped widgets (widget bundles) into existing or new dashboards. Additionally, you can filter your search by widget bundle. Widget preview/ info in grid mode: Users can view detailed information of your available widgets by using grid mode (including widget preview and slide out into effect). ## Support **Major incident management workflow and governance implemented for Bridge**: A process has been put in place to correctly resolve major incidents as soon as possible, restore IT services, and fulfill our customers' business mission. **PagerDuty report**: A PagerDuty report has been created to check incident responses from various teams. **Bridge Support health summary**: A summary dashboard counts the total of incidents based on severity, status, priority, and other details. ::: [title] July [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # July 30, 2025 ## Platform Services - Connections Manager **Upgrade the connections manager to Shidoka 2.0 version: **The Common Connections Manager delivers centralized control and monitoring for all connections, streamlining the management of database connections, external APIs, and network connections. With the launch of Shidoka 2.0, this functionality has been significantly enhanced to boost efficiency and elevate the user experience through key updates: - A direct link to Connections Management is now prominently featured under the **Manage & Administer** menu. - The link to the Connections module has been eliminated from the DCP IAM. - The Connections Management left side panel allows you to quickly access: **Cloud**, **Content**, **Too**l, and **Authentication **connections. ::: :::ExpandableHeading # July 23, 2025 ## DevSecOps **Init containers now supported: **f an Init Container exits with an error, it remains in a pending state. The Init Container logs record such errors, enabling administrators to troubleshoot the problem and optimize resource up-time. ::: :::ExpandableHeading # July 9, 2025 ## DevOps Intelligence **Environment Management partially upgraded to Shidoka 2.0: **The Environment Management module, has begun transitioning to the Shidoka 2.0 design system. This partial upgrade enhances the visual consistency and user experience across the application, aligning with Kyndryl’s latest design standards. Further updates will continue to bring full Shidoka 2.0 compliance across all components. **DevOps Intelligence upgraded to Shidoka 2.0: **DevOps Intelligence (DI) has been fully upgraded to the Shidoka 2.0 design system, delivering a modernized user interface and consistent visual experience. This enhancement aligns DI with Kyndryl’s latest UX standards, improving usability and ensuring a cohesive look and feel across the platform. **ToolChain Management upgraded to Shidoka 2.0: **ToolChain Management (TCM) has been fully upgraded to the Shidoka 2.0 design system. This update enhances the overall user experience with improved visual consistency, modern UI elements, and alignment with Kyndryl’s latest design standards. ::: :::ExpandableHeading # July 2, 2025 ## DevOps **Enhanced GitHub data synchronization: **Support for implementing a GitHub Webhook has been added to ensure complete data synchronization between GitHub and DevOps Intelligence, for more accurate reporting. ::: [title] 2025 Release Notes overview [path] Release Notes/ [title] March [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # March 19, 2025 ## Common Services **Tag repository now available in Common Services: **The tag management service provides a centralized solution for creating and managing validated and unvalidated tags, overseeing their entire lifecycle in a secure environment to enhance efficiency and effectiveness. As the first stage, the [tag definition](docId\:Bk-pJYH9CGZyhqfXthEV3) process sets the foundation for the tag management system. The tag repository is a central hub that stores standard-governed tags (validated) and ungoverned (unvalidated) tags. It is a single source for accessing a categorized set of tags for operational, financial, and security purposes, demonstrating its versatility and importance in tag management. Key capabilities include: - The system stores governed tag keys created through a tag definition flow, allowing tag values to be added from the tag repository. - The repository enables direct creation of ungoverned tag key-value pairs, ensuring all tags are managed efficiently. - It also displays whether tag values comply with defined constraints, helping maintain data integrity and ensure accuracy. ::: :::ExpandableHeading # March 5, 2025 ## Discovery & Inventory **New Cloud Provider Oracle Cloud Infrastructure (OCI) is now available:** Common Discovery can now extract virtual machine (VM) resource details from the OCI provider based on the account credentials and connections added to the IAM connection. OCI asset details can be accessed through the Common Inventory Service upon successful discovery. ::: [title] March [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # March 27, 2024 ## DevOps Intelligence **Release comparison available in Release Management**: The release manager can now make decisions based on improvements from the previous release. Characteristics of the current release, such as code coverage, unclassified bugs, and skipped tests etc., are measured and compared to those in the previous release. An improved or degraded rating is accordingly assigned, for example, 30% improvement in code coverage. ::: :::ExpandableHeading # March 20, 2024 ## Cost & Asset Management **AWS Container Metering in Cost Allocation**: Users can now leverage AWS container metering to achieve granular cost allocation for resources used within containerized environments. This feature supports Kubernetes environments, including AWS EKS and AWS Fargate, and enhances the precision of cost management for clusters, CPU, and memory based on namespace utilization. ## Shared Services **Job Management enhancements**: The Job Management page has been enhanced and now includes the last run status for jobs under job actions. ::: :::ExpandableHeading # March 13, 2024 ## Shared Services **Seamless transition of existing customer tenants from Core+ to Foundation**: Migrated users can now use Foundation capabilities in Shared Services such as access policies, access groups, connections, and permissions. ::: :::ExpandableHeading # March 8, 2024 ## Services Catalog **Ability to cancel active subscriptions**: Now, users have the capability to request a subscription cancellation and stop using and paying for the service. You can request to cancel subscriptions recently submitted or already active and select a cancellation reason from the dropdown menu. ## Console **Resiliency Orchestration (RO) Software is now available in Kyndryl Bridge**: Resiliency Orchestration Software has been integrated with Kyndryl Bridge, and users can access this service from My Console. ::: :::ExpandableHeading # March 1, 2024 ## Services Catalog **Network Managed Services (NMS) are available in Bridge**: NMS is a service integration that adds value to users by becoming the starting point to navigate through multiple Kyndryl systems. Now, users can integrate this service into Bridge. **Global Resiliency Framework (GRF) BaaS is available in Bridge**:  Now, users can integrate GRF BaaS in Bridge, which provides a collaboration platform and information. **Backup as a Service (standard) is available in Bridge**: Now, users can integrate Backup as a Service (standard) in Bridge, which minimizes the risk of potential data loss and reduces additional workload. **Patch Management is available in Bridge**: Patch Management is now visible in the Kyndryl Bridge App Switcher. Currently, users with the corresponding permissions can control who can view the Patch Management link on Bridge Services Catalog. ::: # ## [title] December [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # December 3, 2025 ## Container Cluster Management (CCM) **Kubernetes Secret details now available:** Container Cluster Management has added a details page to view the JSON code of individual Kubernetes Secrets, enabling SREs to evaluate the structure of specific Secrets. ## Platform Services - Connections Management **Dedicated roles for Connections Manager are now available: **The Bridge Connections Manager lacked a dedicated role for managing connections and relied on general roles such as Platform Admin and Platform Viewer. These roles had broad access to Bridge features, underscoring the need for dedicated roles for Connections Manager tasks. To clarify responsibilities and ensure accountability, the Connections Manager now has two dedicated roles: Connections Administrator and Connections Viewer. ::: [title] April [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # April 10, 2025 ## Common Services **Bulk import is now available in Common Services: **As part of ongoing tag management efforts, the [Tag Repository](docId\:FmC8-WunznzvenBj11JSI) page allows bulk importing of tag key-value pairs via JSON or CSV files while removing duplicate tags for better organization. The bulk import from external sources has the following capabilities: - The system imports unavailable tags to the repository without duplicating tags and values. - If a tag key with the same name already exists, it will adhere to the current tag rules. - The system will notify you of each entry's success or failure. ::: [title] April [path] Release Notes/2024 Release Notes/ :::ExpandableHeading # April 26, 2024 ## Services Catalog **Search Functionality in Service Catalog**: Customers can now search for services by entering items in the search bar using terms from the title or any of the sections of the Service details page. If multiple words are entered in the search bar, the result is shown as one sentence. Otherwise, a message indicating no results are found will be displayed. ## Support **CollabDrive included in the Console Welcome Experience**: To elevate the customer experience effortlessly and share vital documents with ease, CollabDrive is now part of the existing walk-through for first-time users on Console. **Ability to rename the documents tab in CollabDrive**: CollabDrive is not only a place to hold documents, but also to collaborate with the customer. Now, the Documents tab has been renamed CollabDrive to properly identify the capability being accessed and avoid confusion for our customer users. ::: :::ExpandableHeading # April 17, 2024 ## Cost & Asset Management **Enhanced Segment Capacity in CAM Cost Trends Analysis: **The CAM platform has been enhanced to allow up to 50 segments in cost trends charts. This allows users to add as many segments as necessary for a more personalized and insightful view of cost trends. ::: :::ExpandableHeading # April 12, 2024 ## Services Catalog **New categories added in the Catalog**: Multiple filters can be selected to narrow down the search results. Users can select one or multiple filter options by selecting one or many service categories and service attribute categories for the search. **Bring Your Own License (BYOL) subscription enhancements**: The BYOL subscriptions view capability has been refined to improve the user experience for mobile and tablet devices. ## Console New recommended service offerings widget: The new widget allows users to go from Console to Services Catalog and get GenAi-powered recommended services based on customers’ current subscription, browsing history, and profile. In addition, an explainability feature is available, which makes it possible to provide a dynamic textual explanation for selecting and ranking, making the recommendation process more transparent. ## Service Provider **Request for Subscription (RFS) pending cancellation upgraded:** When customers request cancellation of the RFS, the service provider can now revert the request to “in progress” or “submitted status” instead of just canceling it. This allows service providers to reach out to customers and revert the status and continue with the request as needed. **Service Details:** To enrich how information is displayed for the services in a web form format and published in the catalog, the data can be added in rich text format for the Bridge service details page. **Error message displayed for failed requests:** To inform users when requests cannot be completed, an error message is displayed for the following unsuccessful scenarios: - Request for Consultation - Request for Quotation - Request for Subscription - Reach FAQs or the Support page ::: :::ExpandableHeading # April 4, 2024 ## Container Cluster Management (CCM) **Perform Day 2 actions in private container cluster**: CCM now supports creation and deletion of namespaces and resources across Private Container Cluster. **Reskin of CCM Dashboard: **The CCM dashboard got updated to match Shidoka. **Enable Actions from CCM: **CCM being a common service in Kyndryl Bridge has enabled its support for creation and deletion of namespaces and resource across all major hyperscalers. ::: :::ExpandableHeading # April 3, 2024 ## DevOps Intelligence **DevOps Editions to be consolidated:** DevOps has withdrawn support for multiple price list editions and now supports only one edition, Single Edition. Tenant owners have been notified separately through email regarding this migration. ::: [title] September [path] Release Notes/2025 Release Notes/ :::ExpandableHeading # September 24, 2025 ## Platform Services - Notifications **Bridge in App Notification is now available: **As the first step towards making In-App notifications a converged common service, all In-App notifications from AIOps, Bridge, and Services are now grouped in one place and accessible from a single location within Bridge. This update eliminates the need to navigate to different sections within Bridge to access notifications, providing a consistent notification pattern. There are still three separate notification systems running, and their functionality remains unchanged. This release focuses on enhancing the user experience of In-App notifications. ## Container Cluster Management (CCM) **Enhanced cluster health assessment:** The Cluster table on the Container Cluster Management landing page now contains active links to details for clusters classified as Unhealthy. Specifically, the service presents details of the following health parameters: - Node Health - Critical Alerts - Memory Over Committed - CPU Over Committed This enhancement enables quick, at-a-glance assessment of specific clusters, enabling preemptive action ahead of potential failures. **Tailored health parameter thresholds are now supported:** Administrators can now set thresholds for supported cluster health parameters to accommodate their organization, enabling flexibility for each organization. ## Discovery & Inventory **Inventory name and navigation changes: **Kyndryl Bridge is consolidating all Inventory services to a centralized focal point, simplifying user access. To that end, the following name changes have been implemented to unify all references to Inventory services: - Common Discovery is now Discovery Management - Common Inventory is now Discovered Data The following services are now part of the larger Bridge Discovery & Inventory services: - Application & Resources - Discovered Data, formerly Common Inventory - Discovery Management, formerly Common Discovery - Product Dictionary, formerly Product Catalog Workstation Inventory - Infrastructure and Cloud Inventory, formerly Inventory Services - Inventory Insights **Cloud data is now available in Infrastructure and Cloud Inventory:** Cloud data is now being harvested from the Discovery service as part of Inventory unification. Users now have a centralized dashboard for all inventory data, providing a coherent view of all assets. You can now view various cloud resource categories, such as compute, database, storage, network, and Kubernetes/containers. The following providers are supported: - Oracle OCI - IBM Cloud - Azure - Google Cloud Platform **Synchronize Discovered Tags with Tag Repository Service:** Bridge Inventory has been enhanced to align with the Tag Management system, eliminating duplicate and non-compliant tag repositories. All discovered, newly created, updated, or deleted tags are now pushed to the centralized Tag Repository, ensuring standardization and compliance across Bridge services. This includes automatic retries for failed tag pushes to maintain consistency. **Authorization added to missing APIs:** Authorization checks have been implemented for unprotected APIs in specified areas. Ensuring a high level of security, adhering to role definitions, this enhancement protects sensitive data in alignment with best practices for API security. ::: :::ExpandableHeading # September 19, 2025 ## DevOps Intelligence **Release filter now available**: DevOps Intelligence now supports a release filter for Open Source License Compliance and Container Vulnerability. In addition to the global filter, which allows specification of Application and Duration, you can now filter for a specific release, providing even finer detail for your performance assessments. :::