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
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:
For moving the Ticket I go over the three dots menu on top right in the ticket.
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.
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.
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.
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
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.
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"?
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.
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
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!
Hello there Cloud Community members! Today, we’re thrilled to announce Jira Service Management, the next generation of Jira Service Desk. Jira Service Management touts advancements in IT service ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events