HelpSpot Help Desk Software | HelpSpot Blog | HelpSpot Support

Best way to track component being supported?

#1

I’m working on importing all of the items for our old issue-tracking system (only around 26,000 items…), and I need a way to track what component is being supported and import those values from our existing system as well.

Obviously the best way would be to just add a user-defined field with a combo box where the component can be selected. However, after looking at how this type of field in stored in the database, I’m worried about the future integrity of the data, since the combo box items aren’t stored in their own table with a record for each item that has a permanent ID and cannot be deleted.

Using tags is a possibility, but that’s a lot of check boxes that would show up on every issue. We would be able to mark something as being in 2 different components (sort of possible with the way we track things), but I don’t know if it’s worth the mess it would make of the interface.

Does anybody have any suggestions?

#2

Well the combo box information is not stored in individual rows, but the results are. They’re with the request in columns called Custom1, Custom2, etc. So you could insert them into the DB and as long as you have matching entries in your predefined list it should all work OK.

Using reporting tags would also be a good way to do it. If you feel the list is too long you could make more granular categories so the rep tags could be spread over more categories.

Version 2 of HelpSpot will have multi-select custom field boxes which will make large lists a bit easier to deal with as well, but it will be some time until v2 is out.

#3

Yes; I see where the (text) values are stored.

“So you could insert them into the DB and as long as you have matching entries in your predefined list it should all work OK.”

That’s not a good long-term solution for us; renaming a component later on will not be fun.

Are there any plans to create a true relational storage system for user-defined fields in the near future? There are 2 ways to go about it that both work about equally well. I’d be happy to discuss it with you in more detail if you’re interested.

I would add the functionality myself, but unfortunately, I don’t have that option. :-/

#4

I see what you’re saying. One problem with renaming though is that it will change the history of older requests. So at the time of the old request the component was named X now it’s Y. In the old request it should really be X not Y. The way it works now, when looking at a closed request you would see the correct information. Of course you could have deleted flags, etc in a relational model.

This would be a significant change so I’m can’t commit to it, but I’ll definitely take this into consideration. There will be several new custom fields in version 2 along with custom field grouping, as that gets closer we’ll take a look at how this type of storage model may fit in.

#5

Right. There should definitely be a warning on renaming as well. However, an example is changing a component of “ACH” to be “Electronic Payments” instead. I don’t want to manually go into the tables and issue UPDATEs any time we want to change something.

And yes, a deleted flag is the other big thing. If we ditch a component, I want to pull it off the list without screwing up the history. That’s a huge deal. Since the fields are just stored as text, I assume any filters will still work OK for generating reports if a custom field option gets deleted?

#6

Sure I see what you mean.

The filter would still work, unless you edited it. That would probably not allow you to pull it up in that manner.

We’ll definitely take a look and see if doing a relational table for the custom predefined fields is possible.

#7

Ok. At least I have a plan. I’m going to stick with a custom field for now.

Thanks.