nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Share Project with external customers

Dennis Poort

Hi,

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!

Accepted answers

All comments

David Bascoulès

Hello, I'm really interested by this subject too ! Thanks

Joe Pitt

If you want them to be able to work they must be a user and consume a license.

unknown

How many unique external clients do you have? I can suggest the following:

Create a "generic" JIRA Account for each of your client (so that it will only consume 1 JIRA account for 1 client). It can represent your client's issues. If you want to track each issue individually, you can ask them to put their names/emails to a custom field.
Utilize the Issue Collectors. This simple feature will allow you to embed a simple javascript to almost any webpage (that can execute a javascript correctly) to create issues against your project. You can create One issue collector for each issue type, per client, and/or per issue type.
Use Confluence. We use Confluence a lot to display/share what I want with stakeholders clients. If you set it up correctly, Data/Gadgets on JIRA can be displayed on Confluence pages without having an account in JIRA.
Custom Webpage. One of the projects that I support created a dedicated webpage that displays JIRA issues, custom boards, custom charts (both based on JIRA's data) utilizing the JIRA API to do its work.
Last, JIRA Service Desk. Your requirements is one of the reasons why JSD is created.

Dennis Poort

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.

Fabrizio Galletti

Just remember that u can use "issue security " to hide issue to other customer

unknown

* 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.

Dennis Poort

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.

zachalig

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).

Dennis Poort

Would you like to consider upvoting my question for upcoming webinar? https://answers.atlassian.com/questions/33157874/answers/35764769

Steven Grossman

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.

Hammad Siddique

can i make more then 1 administrator in jira..????

Brandon Saunders

Still only one method? To consume atlassian licenses? Or use JIRA Service Desk customer's for 2-way communication.

What if I want to have two-way communication between an internal and external user on a regular JIRA Core project?

Ringo Starr

Hi, also my opinion. This is a negative aspect of this otherwise very good product.

Julien Nicolas de Verteuil

Yes and that data also will remain on Google's server forever and you can say goodbye to any IP

Irina Sanikovich [StiltSoft]

We've described three different solutions to collaborate with your external users in Jira in our blog post. https://stiltsoft.com/blog/2018/03/collaboration-on-backlog-with-external-users-in-jira-cloud/

Yes, you can create a shared Jira instance or buy Jira Service Desk. However, you can also create private and public feedback forums in Jira Cloud with no need to create new Jira users.

Josefine Lindskog

Hi!

This sounds very interesting, do you know how to set up a feedback forum in Jira Cloud?

Irina Sanikovich [StiltSoft]

Hi Josefine!

You can find all the required information here: https://docs.stiltsoft.com/display/public/CustomerCase/Managing+Forums#ManagingForums-FeedbackForum

Just let me know if you have any other questions!

unknown

Is there anything similar for JIRA Server?

Chris Cooke Old Street Apps

For those still looking to do this; check out External Share for Jira on Cloud, Server and Data Center

It lets you grant permission to certain external users so they can:

View issues
Add attachments
Add comments.

You can also:

Put expiration dates and password protection on shared links
Choose whether or not to share linked issues.
Customise the email content when sharing links
Manage links sharing afterwards, seeing what's been shared and turning it on or off as needed.

There's also a version for sharing Confluence pages with external users!

External Share screenshot 2.png

joel.murav

@Chris Cooke Old Street Apps - This is a great suggestion on external exposure for clients to our Internal JIRA Org.

Couple follow up questions that i am hoping you can answer for me

1) Does this allow you to ASSIGN Tasks to external users? (currently we are using another tool and want to retire it, but assigning to external users is something we need to solve for first

2) It looks like the App is priced based on your JIRA User count (like all apps are), is this just for your INTERNAL JIRA license users for JIRA-Software? Do external users need licensing too? JIRA-Service Desk wont work for us, as we are agile development consulting firm, so that tool doesnt do the JIRA Needs.

Appreciate your help; let me know if you have any other suggestions or best practices as well

Joe Pitt

Issues can only be assigned to JIRA users that have the assignable permission in the project.

Chris Cooke Old Street Apps

Hi Joel,

We can't currently assign tasks to anonymous external users. No licensing required for these users either though, as you say, it's just tied to your Jira tier, although there is a Light version of the app to get you started.

cokefour

Why can't access to Jira projects work the same way as ActiveCollab for instance? I'm seriously reconsidering using this tool for client projects and go back to something that makes it easy to limit access to individual clients without jumping through hoops to configure groups. If it wasn't for the Service Desk feature I'd probably dump it. I'm going to look into HubSpot's Service Desk and do a bit of cost benefit on this.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-service-desk

jira-software

external