Expand my Community achievements bar.

Do you have questions about the migration to Adobe Business Platform? Come join our upcoming coffee break and ask away!

Queues Should Be A Standalone Feature


Level 4


Request queues should be independent of projects. Queues play such a huge part of the overall system that having it buried amongst the projects presents a risk and a liability to usability. It is very easy to delete a queue by accident which will greatly affect the instance. If queues were an option similar to templates, it will give system admins greater control



Level 2


Agreed! At the VERY least, an option for Admin (sys or group) that will prevent project deletion without tacit approval from an Admin...?


Level 6


I understand that the structure exists how it does for organizational purposes. That being said, I like the intention behind this. I think if there were to be a toggle in the queue that's an "Admins/Group Admins only can delete" or something like that it would be a great idea!

Ways we've found to work towards preventing this issue (From the WF Training Team):

Put one single Task on the Project that is named something like: "DO NOT DELETE! - THIS IS A REQUEST QUEUE!!!"

Create a Project Status called "Request Queue" that equates to Current and use it for Request Queues; this keeps it out of Reports for other Current Projects.

Add all Queues to their own separate Portfolio so that they are not under Portfolios where others may have permissions. You can create Programs for the different Depts. in your organization.

Route requests to other Projects that serve as "buckets" of work for teams and groups (very common with agile functionality).

On Project Sharing, make sure inherited permissions are removed and other permissions are set so that others can't edit the Project as a whole. With that, make sure an Admin or Group Admin is the owner. Make sure anyone that does have permission knows not to add others unless certain requirements are met.

Create a Template for Request Queue Projects that has a list of tasks informing anyone setting up a queue what steps to take, final task can be to delete all tasks except for one that tells them not to delete.

Hopefully, this helps for the time being!



I totally agree. It's confusing and not that helpful that a Queue would be a project, even though other aspects of requesting and triaging are set up at the instance level.

As a side note, during our rollout, the consultant we had showed us a really useful workaround to prevent it from being deleted:

  • add a Billing Record & label it something like 'DO NOT DELETE THIS BILLING RECORD'
  • give it a 0$ amount and set it to billed

After that, the project shouldn't be deletable because it's got a billing record in it.