Notify Issue Originator for tracking when an Issue is moved to a Queue Project by Routing Rules

[IsaacWu]

Here is some information to hopefully outline this scenario:

• No Fusion is used, but can be suggested as a solution if there is none available in Core Workfront.
• Compliance Request Project - Standalone Queue Project that teammates can access and add an issue by going to the Request queue
• Webdev Pjt Template - This is where I am adding Queue Topics, Routing Rules to route Issues that use the same Custom Form available in the Compliance Request form in the Request queue.

Issues route to the Compliance Request Project just fine. However, because it is not a formal 'request' from the request tab, and instead is an issue generated in the Webdev Pjt, the issue is routed automatically and silently, with no way for the Issue submitter to know where the Issue has gone.

Is there a way to:

1. Keep a 'copy' of the Issue on the Webdev Pjt where the Issue originated from?
2. Link the Issue back to the Webdev Pjt from the Compliance Request Project?

I appreciate your insights! Let me know if I can provide further clarity. 

[skyehansen · Accepted solution]

if I'm reading this correctly, you have a regular queue that sends requests to a compliance project, and then routing in a bunch of other projects that send the issue to the same compliance project, which gets confusing because no one on the project can see if an issue has been sent to compliance. I've seen pretty similar things and I think it will end up being a fusion solve. Probably as you suggested, a copy of the issue stays behind in the web project and the resolution is tied to the original issue that got sent to compliance. When compliance closes their issue, your copied issue closes as a result of that status change.

[Lyndsy-Denk]

A possible alternative is to use reporting to display these issues to each of your audiences. In other words, it doesn't matter where the issue goes because the report keeps a list based on your filters. One report is for the requestor, the other is for the people doing the work on the issue. You can automatically send a report daily to show your audience what objects are relevant to them. So they aren't directly notified upon move, but they're notified by a reminder of where to look at the list of relevant issues.

[IsaacWu]

This is a route I've been looking into as well! Regardless, it's going to be some change management for my team. Thanks for your suggestion!