You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I'm setting up my JSD project and i'm looking at a way to provide support to multiple organizations from this products. Support is provided for software/hardware products for all these orgs/customers.
Looking at a way to categorize the issues/products, i came accross components and the "product categorization" field. Both seem to be able to categorize the products pretty well. I'm aware of the fact components enables you to select assingee to the category, but that's not needed.
I think the multi-level "product categorization" field is what i need and like, but i'm unsure if there are disadvantages compared to components.
are there limitations regarding certain aspects between the two, other than the assignment functionality? regarding reporting maybe?
In case the product categorization field you are talking about is a custom field of type cascading select list, the only disadvantage is, that one has to have system administrative permissions in order to add values to it. Since you do not want to add a default assignee that's about it 😊
If you ever get into the situation of having a second project, that needs to utilize the same field, simply add a second context to your field, that selects the new project.
If you ever seek a rather advanced solution, concluding of assets relating to one another, calculated SLA's, Service Teams for your Products etc, just let me know. We have developed a rather quickly deployable solution called "ITSM out of the box", that may help you out quite a bit.
Anyways, I hope I was able to answer you question accordingly.