This page outlines common use cases for leveraging our Azure Sync for Jira Assets app, along with best practices and tips to integrate it seamlessly into your workflows and processes. If you have additional ideas for its use or any questions about its capabilities, feel free to reach out to us by submitting a ticket at https://support.sykorait.com.

IT Asset Management (ITAM)

Synchronization of Azure resources is an integral part of a broader IT Asset Management (ITAM) process. It can seamlessly integrate with other key IT service management (ITSM) processes such as:

• Service Request Management: Enabling efficient handling of resource requests and provisioning.

• Incident, Problem, and Change Management: Facilitating smooth coordination in addressing incidents, troubleshooting problems, and managing changes to Azure resources.

• Service Portfolio and Service Level Management: Supporting the alignment of Azure resources with the services offered and ensuring compliance with agreed service levels.

• Cloud Asset Cost Management: Helping to track and optimize the costs associated with cloud-based assets, ensuring financial transparency and accountability.

Open

IT Asset Management (ITAM)

This broader scenario defines a predefined service portfolio with services that can be ordered via the support portal, along with the necessary Azure infrastructure to support them. The workflow typically follows these steps:

1. Service Selection:
   End users can browse and select predefined service offerings via the support portal. For example, a user might request a new virtual machine in Azure. During the selection process, the user can specify parameters such as RAM size, disk capacity, location, and more.

2. Service Request Management:
   Once the service is selected, the request ticket is generated and managed through the Service Request Management (SRM) process. This step may optionally involve an approval workflow.

3. Request Approval:
   After approval (either manual or automatic) the SRM process uses an assigned Terraform template to provision the required Azure infrastructure.

4. Tag Assignment:
   The SRM process also assigns all necessary Tags, ensuring that the newly created Azure resources are linked to the ticket, the service, and other relevant objects.

5. Azure Sync to Jira Assets:
   Azure Sync for Jira Assets synchronizes all this information, bringing the data into Jira Assets within Jira Service Management (JSM).

6. CMDB Integration:
   The Azure data is now available in the Jira Assets Configuration Management Database (CMDB), where it can be utilized for further tasks or assignments.

7. Incident/Change/Problem Ticket Assignment:
   If a new ticket is created (Incident, Change, Problem, etc.), either a user or the system can select and assign the relevant Azure resources.

8. Service and Application Mapping:
   Services and applications can be mapped to Azure resources using the assigned Tags.

9. Cost Management:
   If Azure costs are imported, automation can be used to assign those costs to the corresponding Azure resources, applications, or services for better financial management.

Overview of your Azure infrastructure, CMDB

Once Azure data is synchronized into Jira Assets, it can be used to generate valuable insights and support decision-making. Some of the key questions that can be quickly and easily answered include:

• Geo Locations of Resources: In which geographic regions are my resources located?

• Compliance Check: Are any resources deployed in unauthorized or non-compliant geographic regions?

• Resource Distribution: Which subscriptions have the highest concentration of resources?

• Unused Resources: Are there any unassigned or underutilized resources that could be optimized or decommissioned?

• Impact Analysis: What are the potential consequences of removing a specific resource from the infrastructure?

Open

Overview of your Azure infrastructure, CMDB

These capabilities make it easier to track, analyze, and optimize Azure assets across the organization.

Risk Management:
A complete and up-to-date CMDB is also essential for effective risk management. By understanding the relationships and dependencies between resources, teams can proactively identify and mitigate risks, ensuring greater operational resilience and compliance with regulatory requirements.

Asset Assignment to Tickets and Services

To streamline the integration of asset data into Incident, Problem, and Change Management processes for improved tracking, prioritization, and impact analysis.

Asset data plays a crucial role in processes such as Incident, Problem, and Change Management. Users or systems can select the affected asset(s) directly through custom fields, or assets can be retrieved indirectly via the affected services or applications.

Benefits of this scenario include:

• Accurate Ticket Prioritization:
  Ticket priority can be accurately set based on the criticality of the affected resource, ensuring that high-impact issues receive appropriate attention.

• Resource Monitoring:
  The number of tickets associated with specific resources or resource groups can be tracked and reported, helping to identify problematic or high-maintenance assets.

• Service-Level Reporting:
  Reporting can also be extended to the service or application level, providing visibility into how often specific services are impacted by asset-related issues.

• Impact Analysis:
  You can perform impact analysis on tickets, tracing the effects of assigned resources to the services or applications they support, allowing for a deeper understanding of the ripple effect of an issue.

• Entra ID Integration:
  Users or User Groups from Entra ID can be assigned to other asset objects like services or applications. This information can later be utilized for task assignments, approvals, or other workflows, ensuring the right people are involved at the right time.

Service Request Management: Automatic creation of Azure Resources

To enable fully automated provisioning of Azure resources through the service request management process, streamlining cloud infrastructure management.

In a fully automated cloud environment, end users can select from predefined service offerings via the support portal, where they can request the necessary infrastructure (e.g., virtual machines, storage, etc.). Once submitted, the request enters the Service Request Management (SRM) process.

The SRM process may include an approval workflow, depending on organizational policies. Upon approval, the SRM process automatically provisions the requested Azure infrastructure. During this step, Tags are applied to the resources, linking them to the relevant service, application, ticket, and other objects for easy tracking and management.

After the infrastructure is provisioned, including the applied Tags, it is synchronized into Jira Assets using the Azure Sync for Jira Assets app.

In Jira, Automation can be used to automatically assign the newly created assets to other objects, such as services or applications, based on the values of the assigned Tags. This ensures seamless integration of cloud resources into the broader IT management framework, reducing manual effort and increasing operational efficiency.

Historical Data

To provide flexible options for managing historical asset data in Jira Assets, allowing organizations to retain valuable information while accurately tracking the status of Azure resources.

By default, the app retains all asset data in Jira Assets, even after the resources are removed from Azure. However, this may not always align with your specific needs. There are three main options for configuring how historical data is managed:

Keeping All Historical Data (Default Setting):

In this option, once an Azure resource is synchronized into Jira Assets, it remains there permanently, even if the resource is deleted from Azure. The removal of data from Jira must be done manually.

Tracking Deletion Using Status and Other Fields:

This is often the most useful option for common scenarios. Like the default setting, all data is retained in Jira Assets. However, when a resource is deleted from Azure, its status in Jira Assets is updated to "Inactive" (or another custom value).

The setup is flexible: any field can be updated to reflect specific changes. For instance, you can create a "Deleted On" field and update it with the timestamp when the resource was removed from Azure.

This allows you to retain deleted data and their references to tickets, services, etc., while ensuring that you can filter out resources that no longer exist in Azure.

How to Set Up Historical Data Tracking

Step 1: Create Custom Fields for Status Tracking
On your object types in Jira Assets, create fields to hold the status information. You can name and configure these fields with different values. For example, you might use a field called "Status" with two options: Active and Inactive.

Step 2: Configure the Import Definition
Go to the Import Definition and select Edit Mapping. Locate your object type, click the three dots (…), and choose Edit Object Type Mapping.

Step 3: Set the Updater for Missing Objects
In the object type mapping, select the Updater for Missing Objects option. Choose the field you created for status (e.g., "Status") and set the target value (e.g., "Inactive").

You can also configure the Threshold Number, which determines how many times the object must be missing before the update is triggered. Set it to "0" for an immediate update when a resource is missing.

Automatic Removal of Deleted Data:

If you prefer that only the current state of Azure resources is kept in Jira Assets, you can use the Remove for Missing Objects option. With this setting, assets will be automatically deleted from Jira if they no longer exist in Azure. However, keep in mind that this will also remove references to these assets from tickets, services, and other related objects.

Handling Deleted Objects Across Multiple Subscriptions in the same Root Object

If you're importing from multiple Azure subscriptions into a shared root object in Jira Assets, you can now use a single import instance to aggregate data across subscriptions. This reduces the need to configure multiple imports and prevents issues related to the "missing object" check, which previously applied only to individual imports (could lead to the inactivation or removal of asset objects that still exist in other subscriptions).

With the latest multi-subscription feature, this streamlined approach avoids the potential problems mentioned above. You have two options when configuring imports:

1. Import All Available Subscriptions: Automatically imports asset data from all subscriptions the app has permissions for.

2. Specify Individual Subscriptions: You can selectively import one or more subscriptions by listing their IDs, separated by commas, in the import settings.

For detailed setup instructions, see Import Configuration section in our documentation.

Solutions:

• Single Import for Multiple Subscriptions: Use a single import instance to bring in data from multiple subscriptions under one root object, utilizing either of the options mentioned above.

• Separate Root Objects (Optional): If you still prefer to keep subscription data isolated, you can create distinct root objects for each subscription to maintain separation in Jira Assets.

Billing Data

TBD