Allow deactivation of Topics

[#1]

Description - Add a toggle switch to queue topics that allows deactivation of the topic.

Why is this feature important to you - When we need to revise a queue by way of omitting a topic, we have two options: delete the topic, which deletes the associated data, or rebuild the queue. A deactivation switch for topics would make queue administration much simpler and efficient. Additionally, it would bring the functionality in parity with many other objects in Workfront.

How would you like the feature to work - Similar to many other objects in Workfront, there would be a simple toggle switch to deactivate a topic. This would hide the topic from general view, but retain detail.

Current Behaviour - We cannot deactivate topics.

[#2]

@William--  your suggestion of a calculated field to capture the original queue topic in case it gets deleted sounds like a great workaround. One question - what would happen if the queue topic is manually change/updated? Would we, in theory, lose the "original"?

[#3]

Hi all,

I just found something via AI that works incredibly well - I've searched all over Experience League, and I don't think this has been posted yet. If it has, my apologies for the duplication.

This worked very well when testing in Preview. It removes the queue topic as an option for new requests, but retains the topic on existing requests for reporting and filtering purposes. 

Modify Queue Details and Topic Visibility: 

• Navigate to the Queue Details of the relevant Request Queue project. 

• Ensure that the option for Issues is checked and Requests is unchecked, and save the changes. 

• Go to the Queue Topics section within the project. 

• For the queue topics you wish to "deactivate" (make no longer visible for new requests), change their associated type from "Request" to "Issue." 

• Return to Queue Details and uncheck Issues, leaving only Requests selected, and save. This will ensure that only the queue topics still marked as "Request" are visible for new submissions. 

[#4]

@JenniferLegate That's a creative workaround for some, as long as you don't use issues. We use  both issues and requests, so this isn't viable for us.

[#5]

@JenniferLegate Do you know if this could work for other types like a bug? This could be a gamechanger for so many people

[#6]

@Lyndsy-Denk - we use only requests for our request queues, so it works great. Are you saying you use both issues and requests in your request queues?

@MoniqueEvans - I wish I could claim authorship on this one, but I cannot. Found it by accident when googling workarounds. I guess it would depend on the "bug" and what objects it affects, but interesting thought!

[#7]

@JenniferLegate We do.

• Requests: Ask for services.
• Issues: Flag something for correction, troubleshooting, or a bug.

[#8]

@Lyndsy-Denk - I can see where this workaround would not work in your situation then. For us, we use our queue topics and also custom fields to "qualify" the kind of request (service vs problem) that is submitted, rather than using issue vs request designation.