In our webdesign company we would like to collaborate on projects with our customers. The desire to share a backlog/kanban board with a customer, and allowing to create new issues and prioritize issues is growing.
However, making each customer a JIRA user is not very scalable for us. Is there really no way to collaborate with customers without making them a JIRA user that counts against the JIRA user licensing?
I'm looking into JIRA Service Desk as well. The agent cost would be a bit high for us as well, but even then, if we were to choose to expand on that license and allow customers to submit tickets, as far as I can see they still can't access project backlog, etc.
The question is probably asked a 1000 times, but it's hard to believe that there is not good solution for external collaboration through ticketing, backlog/board sharing, etc. without making a customer part of your company employees (that's how it feels to me).
All input appreciated. Thanks!
How many unique external clients do you have? I can suggest the following:
Hi @Gabrielle Bautista [ACP-JA] , thanks for your reply. We have hundreds of active unique clients in different companies. Not all of them will have the need of accessing the JIRA active backlog. Let's say we now work with 5 unique clients wanting to have direct control over backlog/sprint etc. and this number is likely to grow. - Sharing a JIRA account it seems for me would be an option if clients could share issues. However, these are totally different companies. We can't allow access cross project. Or do you have some other workflow in mind that I am missing? - Issue Collector. This has some potential. Is it true that this feels like building our own custom Service Desk? I would need to build a portal in which users can login so I can match them against a project? - Confluence: This seems to be focussed on multiple clients within one company, and not to serve multiple different unique companies? And it would be informative only, and not interactible (like creating issues or re-arranging priorities). Or could you clarify on the setup if I am mistaken? - Custom, indeed, kind of like the custom portal on the Issue Collectors right? Is worth considering. - As far as I can tell JSD does not allow collaboration on the project backlog/sprint. It is a ticket issue handler. Report an issue, get it fixed. No access to kanban board etc. Or are you suggesting something different? Thanks for taking the time. Hope you can ellaborate on some things if you can find the time.
* Access to cross projects can be easily controlled via the Project Roles and Permission schemes. You may also want to use User Groups on that regards. In this case, only project-A-user-group can browse/view/work on issues with Project A then project-A-admin-group can administer Project A. Do the same for Project B. * The Issue Collectors can be modified but only modified and cusomized so much. Read it here https://confluence.atlassian.com/jira/advanced-use-of-the-jira-issue-collector-296092376.html * Integrate your JIRA with Confluence and you are in a whole new world. Imagine clients who don't need to have JIRA accounts or even know you use JIRA but they can view issues that are displayed in a Confluence page. They can quickly view their tickets in just Confluence without actually going to JIRA. * Yep, something like that. * You are correct. JSD does not have this JIRA Agile features, it's mostly focused on Support Work in a collaborative environment.
Thanks again for taking the time answering, @Gabrielle Bautista [ACP-JA] . The first comment around cross-project access is still not very clear to me. I understand you can set permissions to allow or deny access to a project per user, but when you say you want to give all customers 1 shared JIRA account, you can't set different permissions. Either way, I don't think this would work for us. As far as I see it, unless we want to create a complete custom portal with an API talking to JIRA (which is also a lot of work when done right) the only other way is still to simply invest in JIRA users for clients that require access to projects (not limited to read) and possibly JSD agent licenses combined with Confluence pages that display issues in widgets, Thanks for pointing that out to me. I find that the model is still very heavily developed around big teams, or small teams with just internal development.
Sorry if I may have confused you with cross project access. I have suggested the 'generic account' (shared JIRA Account) so that your clients can use it for their own project and save license seats. This account can be restricted to their project only. This setup entails "Client A" will have "JIRA Account A" that will only have access to "JIRA Project A". You can use "custom fields" to track who is the real reporter on their side for reference.
Longtime JIRA fan, but I'm recommending that my company leave for another (otherwise inferior) product because easy collaboration and communication with our clients is essential. JIRA should absolutely have a Customer or Stakeholder level user at no additional charge (similar to Service Desk).
This is a really NEGATIVE aspect of being LOCKED in the Atlassian ecosphere. I don't want to have to export data out of JIRA in order for a few specific users to see it. Nor, should I have to consume an account and setup a whole bunch of security (time, effort, $$$).
Google lets me take data, publish it as a web page (public or private), and send out a link. And... the data is dynamic.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot