Status Ext, continued

[lpopejoy]

When the main status changes, it should automatically clear the "Status Ext" field, shouldn't it? I realize that people usage of this field could vary, but it really seems like that Status Ext list should be filtered based on what top level "Status" is chosen. Status Ext should have different values, possibly, for every individual Status value. Right?

[Support Team]

Mmm, no. We're probably not going to delete/clear the value of the Status Ext. when the Status changes. This will create a real problem to some/most users (data loss), and yes, we may make it an option/preference, but we will need to evaluate this. What you refer to here is an hierarchy of statuses. It's interesting though it might makes things less dynamic (the free text option of Status Ext. is versatile). Anyways, thanks for this. Definitely something to think about and consider.

[AN-Tech]

I can see that as being useful. Since we started to use the Status Ext field we do occasionally run into someone forgetting to update the ext. For us the extensions used are unique to the main status. It would be better for us to have it change to a blank status ext then having it reflect an extension that does not make sense for the main status.

[lpopejoy]

Exactly. That's what I was trying to say.

[raymond]

We would NOT want this to clear!

We use the status field for "workflow" and the status extension for, well... the status.

We have set up our system so that "status" can be assigned "0-QUEUED", "1-Assigned", "2-Work in Progress", "3-Completed Pending Approval"... "6-On Hold", etc. For "status extension" we have things like "CA1" (contact attempt #1), "WFV" (waiting for vendor), "SCI" (scheduled), etc. The two are not dependent on each other... we might be waiting for a vendor and the "status" (again, think workflow!) could be changed from "1" to "2" to "6", and back to "2" at any time (etc.).

That said, I can definitely see the benefit of having status extension be specific to the status (the drop down list would change and be specific to the chosen status) -- it would just have to be implemented in a way to allow both systems to work (a check box option of some sort).

cheers!

//ray

[nattivillin]

I agree with Ray, the two can be independent of each other and if one just cleared, we'd be lost as to what is to be done next.

A ext based on the status would be nice, then we could eliminate the ext that dont make sense, but it isnt a real issue.

[raymond]

So how about this for another spin. We have really started to use the ticket Type field to track tickets in groups. For example, we have created types for recurring billing (BILL), tracking tasks (TASK), project based tickets (PROJECT), tickets focused on ordering product (PRODUCT), etc. This works very well and has significantly helped us to quickly filter, group and find tickets.

The thought is: how about having the ability to link the Status Extension list to the ticket Type field. This way, if a ticket were of Type "PRODUCT", and the status were "Work in Progress", the Status Extension would show a list based on the ticket Type (in this case, things related to ordering).

Of course, we would need to have a setting in the Options to (radio buttons)
* Create unique Status Extensions lists based on ticket Status
* Create unique Status Extensions lists based on ticket Type
* Create a universal Status Extensions list

cheers!

//ray

[Support Team]

This is interesting however our first (and possibly not final) thought is that this means tailoring the app to a specific use case that won't fit others. Yes, we understand about putting it optional but overall this makes the system more complex, though we're not saying it's a bad idea, the opposite.

So, here's what we can offer that may work for you now:

Create the Type drop down more detailed and have it either start by the extension or the type, e.g.:

'PRODUCT - Work in Progress'
'PRODUCT - Done'
'TASK - Open'
'TASK - Work in Progress'
'TASK - Done'
...

Yes, we know it's not the same and we understand your suggestion, yet we thought that maybe it will help, here or maybe with another implementation. The idea is that you implement a drop down with 'hierarchy' with a flat list of values.

Hope this helps.

[raymond]

That's what we have done although the list is getting longer which makes it more difficult to work with.

Yes, adding this would make the systems more complex but not difficult to understand and really makes the ticket Type, Status and Status Extension fields flexible and powerful.

That said, while I think this is a good feature to add, we would MUCH rather see more fields available for contacts (with the addition of multi-select boxes), the implementation of projects (which is basically the ability to group, link and nest tickets -- similar to what we can do with Contracts but without loosing the functionality of contracts) or the implementation of a "lead tech" filed for accounts/tickets (adding another level to manage, sort and list accounts/tickets which duplicates the functionality of the Account Manager field).

cheers!

//ray