Filter on a routed issue's path data? | Community
Skip to main content
N
NickVa7
New Member
November 25, 2020
Solved

Filter on a routed issue's path data?

  • November 25, 2020
  • 2 replies
  • 738 views

Hi WF Community,

We have a custom form called Incident Triage Requests. Folks attach and fill out this form on issue records. Those issues records are originally logged against any project in the system.

We have a routing rule set up on a specific project called Incident Triage Requests that routes issues logged to any project using the Incident Triage Request form to this project.

Example:

  • Issue A is logged against Project 1
  • Issue A has an Incident Triage Request form attached to it
  • Issue A gets routed from Project 1 to the Incident Triage Request project

THE ASK

Since these issues no longer belong to their originating projects (Project 1 in the example above), is there a way to still access the originating projects data in a report query (e.g. the Actual Completion Date of the originating project)?

Hope that made sense.

Thanks.

Nick

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by imgrund

    Hi - can I ask why you are moving the request? We have our system set-up where every project becomes its own mini-request queue so that the shared teams (i.e. Print Studio, Reg Ops, Web Ops, etc.) have access to the information on the project and view access.

    If you'd like to have info from the original project, curious why you move it to a Triage Request Project? Why not keep it on the original project and just create a report that looks at all issues with the "Incident Triage Request" form? (It is called Category ID in reporting)

    2 replies

    imgrund
    Adobe Employee
    imgrundAdobe EmployeeAccepted solution
    Adobe Employee
    November 30, 2020

    Hi - can I ask why you are moving the request? We have our system set-up where every project becomes its own mini-request queue so that the shared teams (i.e. Print Studio, Reg Ops, Web Ops, etc.) have access to the information on the project and view access.

    If you'd like to have info from the original project, curious why you move it to a Triage Request Project? Why not keep it on the original project and just create a report that looks at all issues with the "Incident Triage Request" form? (It is called Category ID in reporting)

      ElenaDooley
      ElenaDooley
      Level 4
      November 30, 2020

      I second that, Anthony. We recently set up "mini request queues" in our project templates as well with great results and an improved process! We did the same thing with reporting so that the report now filters for category ID (custom form) rather than the request queue.

      N
      NickVa7Author
      New Member
      November 30, 2020

      Hi Anthony,

      Funny enough, I am trying to find out the same thing (why it house to route to a specific project). I didn't set it up, but my guess is because they initially wanted it as a Help Request queue, which would run through the Requests tab, and not attached as a custom form to individual projects.

      Since there doesn't seem to be an easy way to achieve my above request, I think I'll push to get rid of the routing rule (and specific project), and just have folks continue to attach the custom for to individual projects (and we'll use a report).

      Thanks for the response.

      Nick

      imgrund
      Adobe Employee
      imgrundAdobe Employee
      Adobe Employee
      November 30, 2020

      Yeah, that seems the best idea in my opinion. For our Print Studio, we do have a request queue as well. We did do combined reporting at first, but they had me separate it a few months ago so that issues on projects are one report widget on a dashboard and then there is another report widget on the dashboard that is just requests from the Ad Hoc request queue.

      Terms & ConditionsAccessibility statement

      Loading footer...