Allow deactivation of Topics

@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.

@jenniferlegate We do.

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

@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!

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

@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.

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. 

@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"?

@khachaturse It's great news to hear that this idea might be moving forward. The more smooth the transition the better (of course), but your description of the effects strikes me as reasonable. My priorities would be, as @kierstenkollins implied:

1. Retention of historical data.
2. The continued ability to route and assign approvals based on what requestors select.

@kierstenkollins yes, we will not ask you to move to the new service completely until we have the migration plan. Historical data will not be lost, but you would create new request forms and submit requests through the new service.

@khachaturse 

For the new request system, what would happen to the data that is currently in Workfront for the topics and topic groups for long time users of the system? We only have a few request queues for Admin needs for various tools and we heavily use the topic groups for reporting to quickly see the work broken out month over month. Will a migration plan be provided to customers for data if current objects go away in the system?