Operational Checks
Congratulations: you have successfully configured our Importer Application and set your scheduling. Now you can enjoy the automated synchronization of your data source and your selected version of Importer for JSM Assets.
This page applies to all of our Importer Applications listed on the Atlassian Marketplace.
What is next?
We recommend periodically checking the following screens, starting from left to right, and making sure that imports are executed as expected.
1- Notifications For Your Automation Rule
Our applications are designed to notify you if something goes wrong. Please configure the Notifications feature. This way, you check if you received any notifications via your JSM Automation Rule. Depending on your configuration, the notification can be in the form of a Jira Software Issue, JSM Ticket, Email, Slack Message, Teams Message, SMS, etc. If you have the notification, jump to step 5 below.
2- JSM Assets / Object Types
Open your JSM Site / Assets Menu / Object Schema. Select each object type and ensure that you have new objects created or those that have been recently updated.
If you notice one of these in your environment:
Duplicate Objects
Old Data
Incorrect Mappings
Then we recommend that you review the following documents. You may be using the default configurations for Assets, and you can modify them as needed.
Keeping track of the deleted records
Keeping track of the empty values
If you notice that the object values are not correct.
I.e., No labels, empty attribute values
We recommend checking your Jira Automation rules or other automation tools where you edit object values. You may have triggers for ‘Object Created', ‘Object Updated', or 'Scheduled’ in your automation rule, and the objects may be edited after our application finalizes the import, either using the 'Edit Object’ component or via an API call.
3- JSM Assets / Import History
Check your Assets import history and logs. You will find them on the following path:
Your JSM Site > Assets menu > your Object Schema > Schema settings > Import tab > View history button. (Related Atlassian Documentation)
Make sure that all objects are imported properly at the scheduled or manually triggered time.
In case there is a warning message for an object type, then expand the menu and check carefully the top and go down to the bottom. Look for error messages. Some example errors can be:
Error Examples | Description | How to identify | What to do |
|---|---|---|---|
Unique violation | This means there were multiple records in the import having the same value for the unique attribute. | The duplicated value and its corresponding attribute ID are displayed in the error message. Review the Object Type and the Attribute name. | Check your source, and find all the records having the value that you identified in the log. In case there arer multiple values at your source, remove or update the value to fix the data quality issue. |
Objects missing a label | Labels are mandatory fields for every object type. In case there are records without a label, they will be skipped by Assets. | Expand each object type statistics in the import history. Check if the “Objects missing a label“ count. It should be zero. Review the Object Type and the Attribute marked as Label. | If you saw that there are records without a label, check the data source. Make sure that they have the value filled. Once you fix the records, they will be displayed in Assets with the next manual or scheduled import. |
Attribute validation error | Our marketplace applications use different attribute types while building the object schemas to ensure data quality. I.e. Email, URL, Integer, Double. In case the value coming with the import do not match the attribute type, those records are skipped during the import. | The value which failed the validation is displayed in the error message. Review the Object Type and the Attribute type. | Check the data that caused the error to occur. Check the data source and fix the format of the data at source. |
Error Message similar to:
| This means the value for the Publisher attribute is very long in Microsoft Entra ID (Azure AD) and does not fit in a text-type attribute.
This may happen if you created your data model before April 2024. | If the import status is failed, check each object type's details and review the error messages. | You may change the type from text to textarea by following these steps: 1- Open the Object view for Applications. 2- Select the list view. 3- Select the “Bulk actions” menu and “Edit objects” 4- Change the value for the “Publisher” attribute to “Remove” and click save. 5- A menu will pop up for you to confirm the deletion of the values of the Publisher attribute. Click “Save” again. 6- Wait for a while to see the “Bulk update complete” notification on the bottom left side of your screen. 7- Select the “Attributes” tab. 8- Go to the row for “Publisher” and click on the cell for “Type Value” column, select “Text Area” 9- Run another import and validate that all objects are created or updated correctly. |
Error Message similar to:
or
| Maybe because of a release upgrade, Atlassian made some changes and it took time for Assets to recover and fix the index. Asset uses the index to provide answers quickly. Instead of running a DB query every time, it stores the index in memory. However, when the index messes up, the data is not found. In this case, the logs were showing the object keys and saying that they don’t exist. If they don’t exist, how did they have a key, right? | If the import status is failed, check each object type details and review the error messages. | Create a ticket to Atlassian on support.atlassian.com and explain the situation. |
Your error is not listed above? Please send us your error screenshot by creating a ticket, and share your experience. We will be happy to help.
If you don’t see the import in the history, it means the import was not completed. Then check your Importer Application.
4- Your Browser Logs
Some actions are performed via your browser. These create logs on your browser console, and they are not visible on Atlassian’s Forge system. For that reason, you may check if there are any error logs in your browser. Attaching screenshots or exports of these logs to the tickets will help our support team while troubleshooting.
How to access developer consoles in different browsers
Google Chrome
Open the console by selecting Command+Option+J (Mac) or Control+Shift+J (Windows). You can also open the console by right-clicking on the page, selecting 'Inspect', and then clicking the 'Console' tab.
Perform the action that is causing you an issue (e.g., loading a reading list). You will see that the Console tab will fill with information as you make the request. This is the information we need captured in the screencast.
Firefox
Open the console by selecting Cmd+Option+K (Mac) or Ctrl+Shift+J (Windows). You can also open the console by right-clicking on the page, selecting 'Inspect', and then clicking the 'Console' tab.
Perform the action that is causing you an issue (e.g., loading a reading list). You will see that the Console tab will fill with information as you make the request. This is the information we need captured in the screencast.
Edge
Open the console by right-clicking on the page, selecting 'Inspect', and then clicking on the 'Console' tab in the pop-up.
Perform the action that is causing you an issue (e.g., loading a reading list). You will see that the Console tab will fill with information as you make the request. This is the information we need captured in the screencast.
Safari
Click on 'Safari' in the Mac menu bar and select 'Preferences.'
In the pop-up box, select 'Advanced' and tick the checkbox next to 'Show Develop menu in menu bar'. Close the window.
You can then open the console by selecting Cmd+Option+C (Mac). You can also open the console by right-clicking on the page, selecting 'Inspect Element', and then clicking the 'Console' tab.
Perform the action that is causing you an issue (e.g., loading a reading list). You will see that the Console tab will fill with information as you make the request. This is the information we need captured in the screencast.
5- Your Importer Application / Import History
Some of our applications keep the Import History. Depending on the application, you will find them:
Under the Admin tab (I.e., Entra ID Importer, Hubsport Importer, etc.)
In the connection settings (I.e., Intune, Okta, MultiSource, etc.)
The import history will provide information on:
The status of the import process
When the import process started
When data is transferred to JSM Assets, or when it has failed to send the data
How many records have been transferred
This will provide more details on the status. You will be able to understand the typical duration of an import process and compare it with recent imports.
If you notice that there is a start date but no end date, then there are two possibilities:
It is still ongoing
It got interrupted by Atlassian’s Forge Platform
If it is still ongoing, check the previous import durations.
For example, if an import typically takes 30 minutes and has been running for 2 hours, it indicates that it was interrupted by Atlassian’s Forge Platform. Please create a ticket and inform us. We will dig deeper and understand what is going on.
If your application doesn’t have the Import History feature, then when you open your Importer Application, you will find a note at the top regarding the last execution. A standard message would look as follows.
If you see a message like this one:
Then, you need to configure the application as explained in the message. I.e., adding the correct credentials, adding the proper permissions, etc.
If you don’t see any messages, you can check if there is an ongoing import process by clicking on “Check Import Status”. It is located either in the Admin tab or in the Connection settings.
|
A new page will pop up. There, you will find more details on the situation. If you see a cancel button, check the audit logs or debug logs before clicking it. The cancel button cancels the existing import.
In some cases, JSM Assets may become unresponsive and fail to accept new imports. Then, you can cancel the execution and start again.
If your scheduled import is not running, then it may be related to the permissions. Please check if you have removed any user from the group starting with jira-servicemanagement-users- and add it back. Also, make sure that this group has a product relation. Here are the steps:
1- Go to admin.atlassian.com
2- Select yoursite.atlassian.net
3- Select the Directory menu at the top
4- Select Groups on the left side
5- Search jira-servicemanagement-users-yoursite group
6- Select Show details
7- Check the Group product access section.
8- Make sure that it has Jira Service Management as the product and User (agent) role
6- Your Importer Application / Audit Logs
Checking the audit logs on the Admin tab will provide information if a configuration has been changed recently.
7- Your Importer Application / Debug Logs
You can also enable Debug logs and run an import to see how the import process is flowing. In case there is an issue with the configurations or the systems, you would be able to observe them in this menu.
For example, if an import typically takes 30 minutes and has been running for 2 hours, it indicates that it was interrupted by Atlassian’s Forge Platform. Please create a ticket and inform us. We will dig deeper and understand what is going on.
8- Your Data Source
As a final step, you can verify your data source. Make sure that:
The User/client/API credentials are working and valid (some systems have expiration dates for the API tokens, i.e., Microsoft Graph used by Entra ID / Azure AD and Microsoft Intune).
You have the correct permissions defined.
For example, some source systems require additional admin consent in addition to the permission definition, such as Entra ID / Azure AD.
Another common mistake is setting the Graph API permissions as “Delegated”. They need to be “Application”.
Your data is accessible.
There are no Data Quality issues. I.e., emails are in a proper format, fields are filled as expected, etc.
The data source does not have performance issues.
For example, we commonly observe different response times for various customer environments in Entra ID/Azure AD. While one import execution can bring a large amount of data successfully, for another customer, Entra ID / Azure AD may be responding very slowly, and it may cause the application to timeout even though the number of users and groups is much lower than the other.
Important facts:
The source system’s performance varies during the day. (They respond slower during the busy hours).
If the source system has a distributed architecture, then not every region has the same response speed.
The data source is in service. Check your data source’s health status.