Settings and Sharing per Queue Topic

[#1]

Description - When setting up a request queue with different queue topics, it would be really helpful to limit who can see each queue topic.

Why is this feature important to you - This would allow users to only see topics that apply to them while minimizing the number of queue projects in the system.

How would you like the feature to work - Allow for the "Queue Settings" to be applied differently across each queue topic. Each "Queue Topic" would have its own settings with a checkbox to inherit the projects settings or to customize the queue topic's settings. Also allow for sharing within each queue topic so we could provide proper visibility into each topic.

Current Behaviour - For every topic that needs different visibility, a whole new request queue needs built which causes a lot of clutter in the initial request screen.

[#2]

Hi everyone,

We have launched the new intake/requests service for Workfront Planning object requesting. Starting from Q2-Q3 2025 we will start working on expanding the new service to cover Workfront object requests as well. Topics and Topic Groups handling is a top priority for us and we are considering to also add per topic level permissions.

We will provide more details once we have the final solution ready.

Thanks for the idea!

[#3]

Hi everyone, as previously mentioned we are working on a new request service that will replace the current requests system at some point in the future. We are considering considering not including topics and topic groups in the new system but rather represent each topic as a separate request form or representing each topic as a section in the request form, where you can apply skip display logics and control sharing settings for each section.

As we hear from many customers, topics are pretty limiting and new intake service aims to move away from this idea but instead allow you to build routings, conversion object creation automatically based on a pre-defined rules (like Fusion but native).

I am curious to get your feedback on this and happy to chat more around this topic.

[#4]

Our use case for using Topics is:

We have request queues where we have a topic for each department in our company. Then when the requestor submits a form, they have to choose which department they are from. Based on that it is routed to an 'intake' person to vet.

So, in this case, how would it work as you are describing? A separate form for every department? Or skip/display logic on one form? Maybe I misunderstood but doing this in our case would increase the amount of our forms a great deal. We are a big company with a lot of departments. If we use the skip/display logic, then it will greatly increase the size of our one form and make it difficult to manage.

[#5]

That is an excellent question @MarlaDr . No need for multiple request forms. You could just create one form, where you have different sections representing different topics, and apply display logic to show only relevant ones based on the selection of the user. Regarding routing, we imagine routing  to be based on the data submitted by the end-user and not the topic (e.g. If Business Unit 1 is selected in BU field AND Creative Request is selected in Request Type field, then route the request to X person, assign Y person as an approver of the request AND send a notification to X, Y, Z stakeholders). No need to tie anything to a group of topics or ask your end users to choose a routing path during the submission. You would define all the scenarios in the background and the end-user would just need to enter the data into the form.

[#6]

@jon_chen is there an update on this please? and where could I find it?

Thank you!