Categories and subcategories - 'inheritance of rules/users
Have a customer that is prototyping/developing Customer Service. - (btw: this is an ONSITE install)
The customer contact has set up a somewhat more elaborate structure that what may be usual, in that there are many sub categories, and subs under that.
If this is the best way to go about adressing needs aside , the question is: Can a subcategory be set to 'inherit' from parent. I.e If category x has members 123 and default y and assigment method is (some value), then, these values will apply to all subs under the main ? As far as I can see, there is nothing in the interface that will do so.
Are we missing something ? is this at all doeable... and, if so, where ?
thank you
Alle Svar (1)
Hi, Eirik.
I´m not sure if this will be the exact answer to your question. But this is how we solved it at support.
We took a bit different approach to this at support.
So instead of building a deep hierarchy only with only categories we build two different hierarchies.
We used the standard category function for keeping all team-related things apart.
The Swedish team has its own 2 categories and the Norwegian team has its own and so on.
But we had several things that were not related to who had to do the request but rather what the request was about, and this structure was is the same for all the teams or at least for all support teams.
What we did was build a hierarchy structure in a separate table and used it for putting requests in the right area, you can call it some kind of categorization.
So the standard categories are used for the team structure and where in the organization the requests are and who should handle it.
And the custom table (Support product area) is where in the product structure the question was about.
I used this forum post as the foundation for building the structure.
https://community.superoffice.com/sv/technical/forums/api-forums/service-crmscript/cannot-create-a-hierarchical-table/
I have one table where I add the items. And then I have a table relation pointing back to the same table.
And then relation to this from the ticket table.
As you can see the item “Target” has a relation to “Dashboards & Target” and that one has a relation to “ Navigator 100”
Some limitations exist and are good to know about.
There is no “soft delete” meaning that if you delete a value in the list then the information is gone from all requests with this value.
And you can´t do big restructuring after you have started to use the system since it can be problems with the hierarchy levels after you moved them around.