Inzichten

Wat de implementatie van de Jira Connector voor Microsoft 365 Copilot ons leerde

Wanneer organisaties aan de slag gaan met Microsoft 365 Copilot, kijken ze vaak eerst naar de informatie in hun Microsoft 365-omgeving. SharePoint, Teams, Outlook en OneDrive vormen logische vertrekpunten. Maar een groot deel van de waardevolle bedrijfskennis bevindt zich buiten het Microsoft 365-ecosysteem.

Veel waardevolle bedrijfsinformatie zit juist in externe platforms zoals Jira, Salesforce, ServiceNow en andere bedrijfstoepassingen. Wil je Copilot breder inzetten dan voor het opstellen van e-mails of het samenvatten van vergaderingen, dan moet het ook toegang krijgen tot de systemen waarin projecten, supportverzoeken, klantinteracties en bedrijfsprocessen daadwerkelijk worden beheerd.

Onlangs implementeerden we de Microsoft Jira Cloud Connector. Daarbij kregen we een goed beeld van hoe de connector in de praktijk werkt, waar hij echt waarde toevoegt en welke aandachtspunten bij de implementatie komen kijken. In deze blog delen we onze belangrijkste ervaringen en lessen.

Wat Copilot-connectors precies doen

Microsoft 365 Copilot-connectors maken informatie uit externe platformen toegankelijk binnen Microsoft 365. Ze verbinden bedrijfssystemen met Microsoft 365, zodat Copilot niet alleen kan werken met informatie uit bijvoorbeeld SharePoint, Outlook en Teams, maar ook met relevante informatie uit andere bronnen.

De informatie uit die gekoppelde systemen wordt geïndexeerd en kan vervolgens als context worden gebruikt wanneer Copilot een antwoord genereert. Zo krijgt Copilot een completer beeld van de informatie binnen de organisatie en kan het relevantere antwoorden geven.

Voor de gebruiker gebeurt dit grotendeels op de achtergrond. Die stelt gewoon een vraag, waarna Copilot relevante informatie uit verschillende gekoppelde bronnen kan meenemen in het antwoord. De geïndexeerde informatie kan bovendien worden gebruikt binnen Microsoft Search, Copilot Chat, Copilot Search, Microsoft 365 Copilot en verschillende soorten agents.

Bij de Jira Cloud Connector betekent dit bijvoorbeeld dat Jira-issues, zoals supporttickets, samen met de bijbehorende opmerkingen beschikbaar worden voor Copilot. Daarbij blijven de bestaande toegangsrechten behouden. Gebruikers krijgen alleen informatie te zien waartoe ze ook in Jira toegang hebben.

Zo wordt informatie uit Jira onderdeel van de bredere kennisomgeving binnen Microsoft 365 en kan Copilot ook die informatie gebruiken om gebruikers beter te ondersteunen.

Beveiliging en privacy

Een logische vraag bij het koppelen van Jira aan Copilot is wat er gebeurt met de bestaande toegangsrechten. Krijgt iedere gebruiker plots toegang tot alle informatie in Jira? Het antwoord is nee – tenminste, als de connector correct is geconfigureerd.

Copilot-connectors kunnen de bestaande toegangsrechten uit het bronplatform respecteren. Wanneer iemand een zoekopdracht uitvoert of een vraag stelt aan Copilot, controleert Microsoft of die gebruiker toegang heeft tot de onderliggende Jira-content. Alleen informatie waarvoor de gebruiker de juiste rechten heeft, wordt vervolgens getoond.

Tijdens de configuratie kan je instellen hoe die toegangsrechten worden toegepast. We raden sterk aan om dit vanaf het begin correct in te richten, ook tijdens een pilot of testfase. Zo kan je meteen beoordelen of de connector voldoet aan de beveiligings- en governance-eisen van de organisatie en voorkom je dat gebruikers onbedoeld toegang krijgen tot informatie die niet voor hen bestemd is.

De meerwaarde van Jira binnen Copilot

Een van de belangrijkste voordelen van de koppeling tussen Jira en Microsoft 365 Copilot is dat informatie makkelijker vindbaar wordt.

Zodra Jira-issues zijn geïndexeerd, verschijnen ze in Microsoft Search naast SharePoint-documenten, Teams-gesprekken en andere content binnen de organisatie. Gebruikers hoeven daardoor niet meer vooraf te weten in welk systeem bepaalde informatie staat om ze terug te vinden.

De meerwaarde wordt nog duidelijker in Copilot Chat. Stel dat een gebruiker een terugkerend technisch probleem onderzoekt, dan kan Copilot tegelijkertijd relevante informatie uit e-mails, Teams-gesprekken, ontwerpdocumenten en Jira-issues samenbrengen. Zo ontstaat een completer beeld dan wanneer elk systeem afzonderlijk wordt geraadpleegd.

De connector biedt ook mogelijkheden voor het ontwikkelen van AI-gedreven bedrijfsoplossingen. Jira-data kan bijvoorbeeld dienen als informatiebron voor Copilot-agents. Die agents kunnen vervolgens vragen beantwoorden over projecten, incidenten, supporttickets of operationele activiteiten, zonder dat gebruikers daarvoor zelf in Jira hoeven te zoeken.

Ook de analytische mogelijkheden van Microsoft 365 Copilot worden interessanter wanneer operationele data beschikbaar is. Copilot kan dan niet alleen informatie uit documenten en communicatie meenemen, maar ook uit systemen waarin dagelijkse werkzaamheden en activiteiten concreet worden vastgelegd.

Belangrijk is dat zoekresultaten en verwijzingen gekoppeld blijven aan het oorspronkelijke Jira-issue. Gebruikers krijgen dus geen losstaande kopie van de informatie te zien. Wanneer ze een Jira-resultaat selecteren, kunnen ze rechtstreeks doorklikken naar het oorspronkelijke issue in Jira voor de volledige context.

Lessen die we hebben geleerd

De belangrijkste les uit dit implementatietraject is dat de mogelijkheden om problemen met Copilot-connectors op te sporen nog volop in ontwikkeling zijn. Er is nog geen eenvoudige manier om alle geïndexeerde content in één overzicht te bekijken of synchronisatieactiviteiten in detail te volgen. Wanneer er iets misgaat met toegangsrechten of identiteitsmapping, kan het daardoor lastig zijn om snel te achterhalen waar het probleem precies zit.

De Connector Index Browser biedt hierbij wel ondersteuning. Hiermee kunnen beheerders controleren of afzonderlijke records correct zijn gesynchroniseerd en welke gebruikers daar, na toepassing van de toegangsrechten, toegang toe zouden moeten hebben.

Een van de uitdagingen waar we tijdens de implementatie tegenaan liepen, was de identiteitsmapping. Hoewel we Microsoft Entra ID gebruikten voor gebruikersinrichting en single sign-on, herkende de standaard ME-ID-configuratie de gebruikers niet correct. Hierdoor konden ook de toegangsrechten niet correct worden toegepast. We losten dit op door over te schakelen naar non-ME-ID en de mapping handmatig in te stellen (Entra ID Property: UserPrincipalName, Non-Microsoft Entra ID User Identity Property: UserName, Expression: .*, Mapping Formula: {0}).

Tijdens het onderzoek naar dit probleem ontdekten we nog een specifiek aandachtspunt binnen Jira. Standaard zijn de e-mailadressen van Jira-gebruikers alleen zichtbaar voor gebruikers binnen dezelfde Jira-organisatie. Vanuit privacyoogpunt is dat logisch. Zo kunnen externe gebruikers bijvoorbeeld niet zomaar formele supportprocessen omzeilen en engineers rechtstreeks benaderen. Voor de Copilot-connector kan deze beperking echter voor problemen zorgen, omdat het e-mailadres van een Jira-gebruiker ook als gebruikersnaam kan dienen. Als het connectoraccount deze gebruikersnaam niet kan zien, werkt de identiteitsmapping niet correct en kan de connector de toegangsrechten niet juist toepassen. Daardoor blijft de geïndexeerde content voor alle gebruikers verborgen. Om dit te controleren, kan je met het connectoraccount de Jira-gebruikers-API raadplegen en nagaan of het e-mailadres van de betreffende gebruiker wordt weergegeven.

Een ander praktisch obstakel kwamen we tegen bij het instellen van het connectoraccount. Voor de synchronisatie gebruikten we een apart Entra ID-account dat via SSO aan Jira was gekoppeld. De uitdaging zat in de autorisatie: de Microsoft 365 Copilot-installatiewizard leidt je hiervoor naar Jira, dat vervolgens het token gebruikt van de gebruiker die op dat moment bij Entra ID is aangemeld. Tijdens onze testfase losten we dit op door het synchronisatieaccount tijdelijk de Entra ID-rol ‘AI Administrator’ toe te kennen. Vervolgens konden we de connector met het juiste account autoriseren en de tijdelijke roltoewijzing weer laten verlopen.

Bij het gebruik van de Connector Index Browser ontdekten we nog een aandachtspunt. Waar Jira werkt met herkenbare issue keys, zoals CS-23223, gebruikt de Index Browser interne numerieke ID’s. Die kan je eenvoudig achterhalen via de XML-exportfunctie van Jira, waarin beide worden weergegeven. Zo kan CS-23223 in Jira bijvoorbeeld overeenkomen met ID 51540, die je vervolgens gebruikt om hetzelfde issue in de Index Browser terug te vinden.

Daarnaast spelen de toegangsrechten van het connectoraccount een belangrijke rol. De Microsoft-documentatie beschrijft welke globale rechten nodig zijn, maar het account moet ook toegang hebben tot de afzonderlijke projecten waarvan je de content wilt indexeren. In onze omgeving betekende dit dat we de juiste rechten op projectniveau moesten instellen, bijvoorbeeld via de rol Project Browser.

Een succesvolle synchronisatie alleen bleek bovendien niet voldoende. Dat Jira-issues zichtbaar zijn in het connectordashboard, betekent namelijk nog niet dat alles ook voor de eindgebruiker werkt zoals verwacht. Controleer daarom of de issues daadwerkelijk in Microsoft Search verschijnen en of Copilot vragen kan beantwoorden op basis van Jira-content, met een verwijzing naar het oorspronkelijke issue. Die controle is belangrijk, omdat Copilot ook informatie uit e-mails, Teams-gesprekken en andere Microsoft 365-bronnen gebruikt. Een correct antwoord betekent dus niet automatisch dat de informatie uit Jira komt. Controleer daarom altijd of Jira daadwerkelijk als bron wordt gebruikt en of het antwoord een link naar het oorspronkelijke Jira-issue bevat.

Voor organisaties die Jira Service Management gebruiken, is het daarnaast belangrijk om te weten welke gegevens via de connector beschikbaar worden. De door Microsoft beheerde connector is vooral ontwikkeld voor standaard Jira-issues. Jira Service Management-projecten kunnen wel worden geïndexeerd, maar specifieke Service Management-velden worden niet altijd meegenomen. Extra velden kunnen in theorie aan de synchronisatie worden toegevoegd, maar verwijzen in de praktijk vaak naar andere tabellen. Daardoor kan de connector de achterliggende informatie niet altijd op een bruikbare manier ophalen. Om dit te controleren, vroegen we Copilot Chat welke velden voor een bepaald issue beschikbaar waren en vergeleken we die met de informatie die we voor onze use case nodig hadden.

Tot slot bleek de voorbeeldcode voor een Copilot-connector die Microsoft op GitHub heeft gepubliceerd een nuttige bron bij het oplossen van problemen. Zelfs als je niet van plan bent om zelf een connector te bouwen, geeft deze referentie-implementatie meer inzicht in hoe de technologie werkt. Dat kan helpen om problemen met synchronisatie, identiteitsmapping of contentverwerking sneller te achterhalen en op te lossen. Meer informatie vind je op Microsoft Learn.

Conclusie

Veel gesprekken over Copilot richten zich nog vooral op informatie binnen Microsoft 365. Dat is een logisch vertrekpunt, maar een groot deel van de waardevolle bedrijfsinformatie bevindt zich juist daarbuiten.

Denk aan platformen zoals Jira, Salesforce en ServiceNow, waarin medewerkers dagelijks projecten opvolgen, klantinteracties vastleggen, supportvragen afhandelen en bedrijfsprocessen beheren. Die informatie is vaak verspreid over verschillende systemen, waardoor het moeilijker wordt om ze snel terug te vinden en met andere informatie te combineren.

Copilot-connectors helpen om die verschillende informatiebronnen met elkaar te verbinden. Ze maken informatie uit externe bedrijfssystemen toegankelijk voor Copilot, terwijl bestaande toegangsrechten en beveiligingsmaatregelen behouden blijven.

Onze ervaring met de Jira Connector was overwegend positief. Tijdens de implementatie kwamen we enkele aandachtspunten tegen, vooral rond identiteitsmapping en toegangsrechten. Zodra de connector correct is ingericht, kan Copilot echter ook relevante informatie uit Jira gebruiken. Voor organisaties die Copilot breder willen inzetten en ook informatie buiten Microsoft 365 toegankelijk willen maken, kunnen connectors dan ook een waardevolle volgende stap zijn.

Over de auteur

Philip Harrison is medeoprichter van CWSI en Head of IT. Met meer dan 25 jaar ervaring in de IT-dienstverlening heeft hij een brede expertise opgebouwd, van gebruikersondersteuning en infrastructuuradvies tot IT-management. Doorheen zijn carrière werkte hij samen met organisaties van uiteenlopende omvang en in verschillende sectoren.

Zijn expertise omvat onder meer mobile device management, netwerk- en serverinfrastructuur, Microsoft-technologieën, Apple- en Android-platformen, virtualisatie, cloud en security. Philip behaalde een bachelor in Computer Science aan Trinity College Dublin en beschikt over verschillende professionele certificeringen, waaronder Credentialed Mobile Device Security Professional (CMDSP). Daarnaast werd hij bekroond met de MobileIron EMEA Outstanding Partner Technologist Award.