Collaboration with customers or external users

[Carsten Severin _KUMAVISION_]

In almost every of our projects, we face the challenge of collaborating with customers. However, for data security reasons, we do not want to allow external users access to our instance. Nevertheless, we face the challenge of sharing data and work items across departments and working on them together with our customers.

We currently synchronize these instances with the Backbone Work Sync for Jira (Two Way Issue Sync) app from K15t, which works very well and basically meets our needs exactly.

How do you deal with such challenges? What are your experiences?

[Calvin]

Honestly part of our issues is the "business side" essentially the business both wants to "not share tickets" but also "do share tickets".

And you can't exactly have it both ways, I find its best to have a clear process otherwise it gets murky in a "I'm a manager and I think my project should be available to a customer BUT if a customer sees something they shouldn't now I'm angry because they have access to see the mean comment I made on their requirement" haha.

In any case for us we sort of have a few tiers:

1. Trusted customers - these have their own account and access to specific projects as part of their onboarding process.
   • These customers only have access via an email we provide them by our own domain. That way we can not only revert access to the project/site but the email itself.
2. Confluence Only view - These users only have access to the Confluence space, in this space only certain tickets, updates etc are provided and the space itself is available for the customer.
3. If its small pieces of work we also use Jira Service Management, we have a Service Request with a ticket on the portal here was can provide updates. This is more useful for smaller and simpler updates/changes.
4. This is a little annoying but we do have some reports that are sent to an Outlook email which is then forwarded to certain users via an Outlook rule. This is mostly a JQL query so they can review stories and see status updates etc in wider level.
   • We are however looking at connecting analytics to an outside source, this way we can provide reports, ticket info etc to users without requiring sql analytics knowledge. But this doesn't really provide that "collaboration" feel.

[Marcell Bendik]

We have similar security requirements. So we have multiple instances. Internally used and instances for external customers.

We use Exalate to synch work items in between instances.

Challenges:

- the app is one more single point of failure. You need a trained 24x7 support who can restart it if it fails. But setting it up is more complex then your support team would handle. So it is an additional business risk

- the synch add some more latency. If you add all automation steps, the whole process is getting slow for critical incident management for example.

- Atlassian user provisioning is still limited. Once it improves, some of the pains will be taken out from this solution

Good things:

- you can at least create a solution with multiple instances that security approves

- during synch I can map values, so I can show a unified view to the internal teams and the required view for each customer (different naming convention for priority for example). Though it could be achieved working on a single instance

[Antonio Sagansay]

thats good idea.. keep it up..

[Richard Bukovanský]

Customers have "external" AD/Entra accounts synced to JIRA, which are then assigned to the JIRA app access group, the all-customer project access group (which gives them "browse" and "comment/delete own comment" access to the project), and "issue-security-access" groups (one per customer).

Those "issue-security-access" groups are then assigned to issue-security levels (named after the customers) in that all-customer project. Assignment of the security level is enforced at issue creation and on edit.

PMs, Dev leads, etc., also have access to this customer project and to all or some issue-security levels.

Development issues are in separate projects (accessible only to employees), and the dev issues are linked back to those customer issues in the "customer" project. The links are then accessible only to employees, not customers.

[Teodora V _Warsaw Dynamics_]

Hi @Carsten Severin _KUMAVISION_ 

I've been a user of an app that helps companies securely share content outside their Jira and Confluence instances. 

I currently work at the company that built the app, so my general recommendation is to try different options to find the best fit. However, External Share helped our marketing team collaborate with external vendors and share Jira boards or Confluence pages with them during a major rebrand.

[Anne Saunders]

We use Jira Service Management for our clients who stay with us for hosting and support.

For software development clients who want to see certain metrics, we have spreadsheets that use the Jira Add-on for Google Sheets, with the =JIRA() function enabled. 

I wish we could use JSM for both!

[Keith Jones]

We have a couple of processes that we currently use:

1. Short term projects involving outside vendors are in a self-contained Jira space (project). Those external users have access to that particular space only and can fully interact with the boards and work items. 

2. We have some automation and workflows for external vendor communications. One use case may be support requests that we pass along to the external vendor. We then have the automation watching for a reply in a specific format to move the work item along in the workflow.