After moving a ticket across projects I want that the old URL to be still accessable.

[nina.bluemel]

I have two projects with different agents.

In Project A a ticket get's validated. If the ticket is fine and ready for the support we will move the ticket to Project B.

The customers are in both projects the same.

They save the URL (from Project A) on a confluence page during the ticket creation. But after moving the ticket the URL is not reachable any longer. Is there an option that the Link from Project A is redirected to Project B?

Thanks for your help

[Mike Bowen · Accepted solution]

Hi @nina.bluemel 

When you move the ticket to Project B, how are you doing it? Please provide the steps? 

Do both projects have exactly the same fields, workflow? Also are you moving the ticket prior to saving the link in Confluence? 

I was able to replicate your request and this is what I found: 

-Mike

[nina.bluemel]

Hi Mike,

For moving the Ticket I go over the three dots menu on top right in the ticket.

Select "Move"

In the Move options i select the new Project. (Issue Type is the same) In the next step I change the status to open.

The Projects have different workflows.

Both Projects have exactl the same fields.

The customer is saving the Link in confluence after ticket creation. So before I move the ticket into Project B.

[nina.bluemel]

During trying to explain what I am doing I figured that I actualy forgot a step at the end and didn't populate the Request Type afterwards. Now it is working.

Thanks for your help @[deleted]  :)

[Nic Brough -Adaptavist-]

Requests don't have awareness that they have been moved.

The underlying issues do, so your agents can go to the old issue url and be redirected to the new one, but requests don't do that because of the different structure and potential visibility.

Moving issues between projects/portals is not recommended.  It suggests a broken process.  I'd recommend merging the projects and portals and reviewing your process.

[nina.bluemel]

Hi Nic,

thank you for your answer.

Problem with merging the projects would be. That the internal comments from Project B should not be seen from the Agents in Project A. The Agents from A are external and should not see anything from our internal process or discussion in Project B.

[Nic Brough -Adaptavist-]

You should not be moving issues.  If something needs working on in another service desk, then create a linked issue in the other service desk.  Your customers retain their links, the data remains consistent, and you can tell people "this went to team B, we'll let you know when it comes back to team A" and automate updates on A when B is accepted/closed etc

[nina.bluemel]

But if I create a new ticket I have to put way more effort in the ticket. I need the excact same fields. Possible the informations from the comments.

Team A won't get the Ticket back at the end anyway.

I don't really get why it is so bad to move the tickets.

My Problem is solved as well as I made a mistake and didn't populate a field which is required to be visible correctly in the portal for our customers.

[Mike Bowen]

I agree with @Nic Brough -Adaptavist- though, moving tickets is a bad idea. Linked issue is the way to go. Support Tickets stay with Agents, linked tickets go to DEV or 2nd Line Support or whoever. Projects can be locked down easily. 

-Mike

[nina.bluemel]

Maybe for the understanding of the set up.

Project A has three Agents  - two customers who need to be the assignee and to do a review before they say the ticket is fine. The last one is myself as admin.

Project B is than our client specific project with our usual support team and normal support workflow.

If I move the ticket I don't have to do anything else to give our support all relevant information.

If I create a new ticket to link them I have to fill in all fields again. As my support cannot see the tickets in Project A.

What exactly do you mean with "Projecs can be locked down easily"?

[Mike Bowen]

Hi @nina.bluemel 

Is Project A there for Approval purposes? If approved by customer and yourself then move to Project B? 

By locked down I meant if you don't want people in one project seeing comments or tickets in another, it is easy to prevent this from happening, by setting permissions or roles. 

[nina.bluemel]

Hi

yes Project A is for Approval purposes and if approved I move it to Project B.

Also Project A has a "Backlog" for Requests which are nice but not relevant for the current project phase.

With permissions can I also say. As long as the ticket is in the status "client review" Agent1 and 2 can write internal comments but as soon as the ticket is "Ready for B" they cannot see the new internal comments? Couldn't figure a good other way out during setting everything up. I am open for good ideas and considerations. Even if I guess I won't get it through management to change everything again. But might be really usefull for the next client.

Thanks for your advice

[Mike Bowen]

Hi @nina.bluemel 

Whatever works for you is great, but from what you have described it doesn't sound an efficient use of your time, especially if folk are having to update a confluence page with links and you are having to do manual steps to move tickets to a new project, not to mention your approval process before all this gets moved to a new project. 

To give you an idea what I run, and I'll show you how we have a very similar setup to what you are doing, but in one project. 

In this Jira Service Desk project we set up customers (external or internal users) into organisations, and link the organisations to queues, which are owned by the agents. The customers log requests via the Customer Portal. Requests are broken into Issue Types. (we have multiple issue type in the project).

The default issue type doesn't have approval linked to it. Customers simply log requests and they arrive in the All Open Requests queue where the agents pick them up and work on them. Here is the workflow. 

Another issue type is Professional Services, which requires approval before they can be worked on by our agents. Approvers can be customers and internal managers (e.g. myself) or a group of people. At the ticket creation step I can force the reporter to select the approvers. If a request is rejected by approver(s), it goes into the Backlog. If a request is accepted (must be accepted by customer and internal manager) it goes into Awaiting implementation (or the All Open Requests Queue) and gets picked up by agents who will deal with the request as per normal. 

The above workflow would be very similar to what you are doing over two projects, but can be achieved in one project and remember one project can have multiple workflows linked to it depending on the Issue Type being used. 

Agents can communicate to customers (visible to all) or they can communicate internally (not visible by customer). Agents can also link the request to other projects (e.g. DEV team, or DevOps team), but customers will never have visibility on this, nor can they see comments or anything made my Dev or DevOps. They only see their requests and or the comments from the agents made to them. 

Basically everything you said can be achieved in one project. Food for thought! 

-Mike