Sending knowledge base links from an internal JSM project to external customers

[Philipp Roeschke]

I have the following scenario:
We have 2 Confluence Spaces and 2 JSM projects. The projects are each classified as "internal" and "external". This means that the external project is only filled with customers who are invited manually.
The customers of the internal project are imported via our Azure AD.
For each of these projects, 1 space from Confluence was linked as a knowledge base.
We would now like customers from the internal project to be able to send article links to external customers without the external customers being part of the internal project.
We have tried to link the Confluence Space, which is linked as KB in the external project, also in the KB of the internal project. However, when sending a KB link from the linked Confluence Space of the external project, the link is converted and displayed as an "internal article" for the external customer.

What we basically want is the following:
- Give internal customers the option of sending links from the Confluence Space of the external project
- these links should originate from the Confluence Space of the external project
- external customers should only be able to access the space of the external project (via the knowledge base in JSM)

Do you have another idea for this scenario without using Confluence licences?

[Philipp Roeschke]

Unfortunately, it seems that customers searching for articles from project 2 in project 1 still see this link: https://encavis.atlassian.net/servicedesk/customer/portal/14/article/46694401
This means that if the customer is not stored in project 2, the link is always generated from the portal of project 1, right?

[Philipp Roeschke]

That would be one possibility.

[Philipp Roeschke]

Now that I have tested the scenario again, I can see the following:

If 2 Confluence Spaces are linked in Project 1, whereby one of these Spaces is also linked in Project 2 in parallel, and I as a customer from Project 1 search for an article in the portal which is linked in Project 1 and 2, the link to the article is displayed in the same way as the portal via which the article is accessed.

e.g. here:

The article is created in a Confluence Space, which is linked via both projects.
If I now search for this article via the portal from project 1, I get the following link to the article: https://encavis.atlassian.net/servicedesk/customer/portal/14/article/46694401

If I go via the portal of project 2, I get this link: https://encavis.atlassian.net/servicedesk/customer/portal/15/article/46694401

So the difference is which portal you use to search for the article.

It seems to me that the link is therefore not static, but changes depending on access to the portal.

[Philipp Roeschke]

Hello Laura,
thanks for the quick response. The scenario is difficult to describe in text form, but I'll try to explain your points step by step.

Project 1:
- internal customer via Azure AD Sync
- Knowledge base with a linked Confluence Space
- the customers have no agent role

Project 2:
- Internal customers who are invited to the project by invitation
- Knowledge base with linked Confluence Space
- The customers have no agent role

- The projects are strictly separated from each other

Scenario:
The internal customers from project 1 want to forward a KB article to an external recipient (the recipient can be a customer from project 2, but does not have to be). An attempt has been made to export the individual articles as PDFs via the portal, which does not appear to be possible natively.
I was therefore wondering whether it is also possible to copy the link that is displayed in the browser when opening the Jira Portal and send it. However, in order for the customers from project 2 to be able to open this link, they must either:

1. be a customer from project 1 or (as I had hoped)
2. we link the Confluence Space from Project 2 to Project 1 and thus give the customers from Project 1 the opportunity to access the Space from Project 2, which the customers from Project 2 have access to anyway.