Request Queue set up best practices

[CBuckwal]

Are there pros and cons to having multiple request queues? We have one main request queue with many topic groups by team and another smaller queue for confidential requests. A new team is requesting a different (more complex) request queue set up that would require another separate queue. Is there a reporting downside to multiple request queues? Thanks

[VictoriaLinn]

Hi @CBuckwal - The main difference will be that for reporting you might need to add both request queue options in the filter, so impact may just depend on how many reports you have with that criteria.

The pro of multiple request queues is generally permission sharing like you mentioned with confidential queue. If you separate them out then you can determine who can submit to each. It also helps if you have a group admin structure in place so that if they make edits to a request queue it isn't impacting other teams.

[MoniqueEvans]

In addition to @VictoriaLinn's response I will share the tip I was told a couple of years ago that has stuck with me from @tylerholt-Adobe; your request queue should be based on the pool of requestors. In the past I would build my queues based on the people doing the work but ran into problems when a requestor would have access to ask for something they shouldn't. For example, a Sales person requesting new packaging or photography. Instead we now build a queue for the Sales department and a different one for the Product division. This allows for sharing to be streamlined and then via assignments and reporting we are able to let the Photography and Packaging teams see all of their requests in an organized way.

[KellieGardner · Accepted solution]

Like @MoniqueEvans, I tailor our queues to the requesting audience that way I can limit what they see instead of creating clutter. Limited clutter helps with adoption in my opinion. The easier it is for users to find what they need will keep them coming back. 

From a reporting perspective, it might actually make it easier to report on just specific queues or topics but like @VictoriaLinn said for current reports (depending on what they are), you will probably need to update some filters if it doesn't appear to be pulling in the correct data.

My biggest suggestion with creating new request queues is when it comes to custom forms or fields. Try to use what you have to build the forms instead of going down the path of creating tons of custom fields for your forms. This will make reporting and management easier as the system grows. (example: if this new team wants a field that 's named Launch Date and you already have a field name Go Live Date - push to use the existing field in the form vs creating a new one that serves the same purpose).

[CBuckwal]

Thanks for all your responses to my questions. The information you all provided is very helpful.