...
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
...
TBD
Historical Data
TBD
...
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:
Import All Available Subscriptions: Automatically imports asset data from all subscriptions the app has permissions for.
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