Hello again! I hope you’re keen to learn more about Insight. Following on from my previous article where I shared some advice on how to decide what should go into Insight, I’m back to discuss how to structure your objects. In this article we’ll take a look at three top pieces of advice for modelling your data. Again there’s no wrong or right way to this but there’s things to consider to make your life easier.
If you have anything else to add please comment below and share with the community.
1. Split data into logical object schemas
All of your data doesn’t need to go into one huge object schema. We recommend having multiple object schemas based on the use of the data or the owner(s) of the data.
Insight and Jira don’t care which object schemas contain what data. The admin just points a custom field at the data it needs, whatever schema it’s in. And custom fields can pull and push data into multiple object schemas from one issue. Links between objects in one object schema can be made with those in another and queries can be run across different schemas. Object schemas are mainly there to make our lives easier rather than for Insight itself.
Breaking your data down into different object schemas is both more user friendly and easier to maintain. Teams such as the finance or HR departments who may need some information from Insight, don’t need to be bombarded with information they don’t care about. It’s also easier to ask one team to do a regular check of data quality on one object schema, than it is to ask them to check only certain parts of one large object schema.
And finally, each object schema can have its own permissions so if you have sensitive data you can keep that hidden from certain users.
2. Federate your data
If you have a perfectly usable database or source of information somewhere and there are processes already in place to keep it updated, the data doesn’t need to be moved into Insight. Instead it’s likely better to create a copy of the relevant data using integrations and have those integrations run on a schedule to update the Insight information.
Insight comes with a number of importers and integrations (not all are available in Cloud right now but we’re reviewing the integration needs now) including CSV, JSON, LDAP, ServiceNow, Device42, AWS, Azure, Google Cloud, and more. With these importers and integrations, the information you need to make decisions can be made available in a Jira issue/Insight itself, but you’re not maintaining two separate copies.
A really common example we see of this is people using the LDAP importer to sync Insight with the Active Directory. Now you have all of your users easily available and you can run the sync periodically to keep it updated.
Sometimes people will create separate object schemas for this imported data, other times people integrate them into bigger object schemas. If the data is going to be used in multiple places then it makes more sense to have it as a separate object schema.
With the integrations, we recommend not bringing every bit of data available into Insight as per the previous article. You can decide what does and doesn’t make it into the object schema when setting up the integration. You also shouldn’t update this data within Insight itself unless you also push that change to the original source of data otherwise you’re going to end up with conflicting data.
If there’s not a pre-built integration available then you some other options. The first is to export the data as a CSV/JSON file periodically and have the Insight CSV/JSON importers bring them in on a schedule. Alternatively, you could create a relatively empty object and give it a URL attribute that links to the other database where more information can be found. This option is good if you just want agents to be able to view the information and don’t want to search or report based on it.
3. Avoid reusing the same attributes everywhere
If an attribute is used in many places and has the same repeated values then often it makes more sense to make it its own object type. For example vendor. You could have an attribute called vendor for the object types laptop, phone, printer, monitor etc. And for each object you would need to type (or import) the vendor name for that particular laptop or phone.
This is fine, but it’s more efficient to have an object type called ‘Vendors’ and set each vendor as an object. This is for a number of reasons:
You may want more than just the vendor name. Maybe you want other information related to the vendor such as support contact number or links to contracts. You don’t want to have to repeat this for every laptop and every phone. Just have it once and link to the vendor object. This also helps if you want to do elements of vendor management within Jira too.
The vendor will always be standardised now, meaning reports are easier to run. If you wanted to check the number of incidents vs vendor you can be confident you’re not missing something because someone wrote Micrsoft or Aple.
If the vendor rebrands or needs to be changed in some way you only need to update it in one place.
Vendor is just one example but others include business importance levels, deployment environments, departments, locations etc.
That’s all for my tips on structuring your data. Do you have any more? Or any questions? Comment below!
Charlotte NicolaouAtlassian Team
Hi Everyone, In this tutorial, we will show you how you can monitor an SLA, and send notifications before or after the SLA has been breached. SLA Threshold Trigger The SLA t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events