Jira Assets Schemas best practice

Question

I'm just getting started on Jira Assets and have a very general question around Schemas.  Is it better to have a Hardware Schema and a People Schema separate from each other? In my head, starting with a blank schema and then having hardware objects and employee objects and facility objects in one schema would make it easier?

Mark Segall · Answer

To be honest, I have not played much with discovery because most environments I work in have not been using it.  So I'd have to defer to someone else in the community to answer that.

Jim Smith_ogvrwc · Answer

@Mark Segall Thank you for the reply!! <nods> for scalability, having separate schemas for Hardware, Facilities, and Employees makes sense.  The major hurdle I'm facing now is that my company has been maintaining all of hardware asset information on an Excel spreadsheet.  This includes all of the laptops, phones, printers, servers etc and to whom they are assigned and the location.

In building out the different schemas, I'm intending on using Discovery however I'm guessing that I'll need to do a lot of post work making sure that the 973 devices are correctly assigned to the users and to the correct facilities.

Is Discovery easier with a single schema in this instance?

Mark Segall · Answer

Hi @Jim Smith - Whether to have single or multiple object schemas really depends upon how you envision maintaining the environment.

* Will it be a single group that manages everything? If yes, then maybe it's ok but if no, you'll want to consider access control design to ensure people aren't tripping over each other.
* Understanding the asset field and automation impacts - Having to account for multiple object types with varying degree of business logic complexity will make for increasingly complex AQL that needs to be factored into both asset field configuration and any automation rule behavior.  For the latter, you'll also need to think more about any limits.
* Scalability - Right now, you may only be concerned with hardware, facilities, and people. However, it's important to think about the future. Will there be other object types that make more sense residing in their own schema and will those object types need to share say, People data with Hardware?  If the answer is yes to that, it would make sense to split them out now and save the future headache.