IT RBLS blog

Microsoft Teams en Power Automate - IT RBLS

j.wellink@itrbls.com (Joris Wellink) — Thu, 09 Jul 2026 10:28:59 GMT

In een moderne werkomgeving draait alles om efficiëntie en samenwerking. Microsoft Teams is een van de meest gebruikte tools voor communicatie en samenwerking binnen bedrijven. Maar wist je dat je met Power Automate de functionaliteiten van Teams kunt uitbreiden en automatiseren?

Met de integratie van Microsoft Teams en Power Automate kunnen bedrijven taken zoals het automatisch ontvangen van meldingen, het plannen van vergaderingen en het beheren van goedkeuringsprocessen eenvoudiger en efficiënter maken.

Wat is Microsoft Teams?

Microsoft Teams is een communicatie- en samenwerkingsplatform binnen Microsoft 365, waarmee teams kunnen chatten, videobellen, bestanden delen en samenwerken aan documenten in een gedeelde omgeving.

Wat is Power Automate?

Power Automate is een low-code automatiseringsplatform binnen Microsoft Power Platform, waarmee bedrijven handmatige taken kunnen automatiseren via workflows die worden geactiveerd door gebeurtenissen in verschillende applicaties.

Hoe werkt de integratie tussen Microsoft Teams en Power Automate?

Via triggers (gebeurtenissen die een automatisering starten, zoals een nieuw bericht in een Teams-kanaal) en acties (de stappen die Power Automate uitvoert na een trigger, zoals het sturen van een melding).

Voorbeelden van automatiseringen met Microsoft Teams en Power Automate

Automatische meldingen bij nieuwe e-mails, goedkeuringsprocessen in Teams beheren, automatisch taken aanmaken in Planner, dagelijkse samenvatting van meldingen in Teams, en Teams-vergaderingen automatisch plannen.

De voordelen van Microsoft Teams koppelen met Power Automate

Efficiëntere samenwerking, minder handmatig werk, verbeterde productiviteit, naadloze integratie met Microsoft 365, en gebruiksvriendelijk dankzij het low-code karakter.

Automatisering in Microsoft Teams met Power Automate bouwen

1. Ga naar Power Automate via flow.microsoft.com en log in met je Microsoft 365-account.
2. Klik op ‘Nieuwe Flow maken’ en kies het type flow.
3. Selecteer een trigger, bijvoorbeeld ‘Wanneer een nieuw bericht wordt geplaatst in een Teams-kanaal’.
4. Voeg acties toe.
5. Test je workflow en activeer deze.

Wat is CI/CD (Continuous Integration & Delivery)? | IT RBLS

Iris Beumer — Thu, 09 Jul 2026 10:04:03 GMT

In de dynamische wereld van data en BI (Business Intelligence) zijn snelheid, betrouwbaarheid en efficiëntie essentieel. CI/CD (Continuous Integration & Continuous Delivery/Deployment), een methode die al breed wordt toegepast in softwareontwikkeling, biedt ook grote voordelen voor BI-projecten. Door CI/CD in BI te implementeren, kun je dataflows, ETL-processen en dashboards sneller, geautomatiseerd en foutloos uitrollen.

Met een sterke CI/CD-strategie verminder je handmatige fouten, versnel je deployments en verbeter je de consistentie van data-oplossingen. Of je nu werkt met Power BI, Microsoft Fabric of SQL-databases, een geautomatiseerd deploymentproces zorgt voor een gestroomlijnde workflow en betrouwbare rapportages.

In deze blog lees je wat CI/CD is en hoe je het optimaal inzet voor BI-projecten!

Wat is CI/CD?

Continuous Integration (CI) en Continuous Deployment (CD) zijn inmiddels onmisbare processen binnen softwareontwikkeling. Ze maken het mogelijk om sneller, efficiënter en betrouwbaarder software te ontwikkelen en te implementeren.

Continuous Integration (CI) draait om het continu integreren van nieuwe code in de bestaande codebase. Dankzij CI kunnen teams fouten vroegtijdig opsporen, wat leidt tot minder bugs en een soepeler ontwikkelproces.

Continuous Deployment (CD) gaat een stap verder door wijzigingen die door de tests heen komen, direct naar productie te sturen, zonder handmatige tussenkomst.

Hoe werkt een CI/CD-pipeline?

Een CI/CD-pipeline is een geautomatiseerd proces dat ervoor zorgt dat codewijzigingen snel, veilig en betrouwbaar worden ontwikkeld, getest en uitgerold naar productie.

Stap 1: Versiebeheer (Source Control) – Alles begint bij een code repository, bijvoorbeeld in Git (GitHub, Azure DevOps of GitLab).

Stap 2: Continuous Integration (CI) – Automatische builds en tests via tools zoals Azure DevOps Pipelines.

Stap 3: Continuous Deployment (CD) – Automatische uitrol naar test- en productieomgevingen (Staging en Productie).

Waarom is CI/CD belangrijk voor softwareontwikkeling?

Bedrijven die CI/CD implementeren profiteren van snellere ontwikkelcycli, hogere softwarekwaliteit en een verbeterde gebruikerservaring. Door automatisering van deployments kunnen Power BI-dashboards en datasets efficiënt worden beheerd, kunnen Power Apps gecontroleerd en veilig worden geïmplementeerd en kunnen ETL-processen in Fabric betrouwbaar en schaalbaar worden uitgerold.

CI/CD en testen: waarom geautomatiseerd testen cruciaal is

Een CI/CD-pipeline bevat vaak meerdere lagen van geautomatiseerde tests: unittests, integratietests, functionele tests, performance tests en security tests, elk gericht op een ander aspect van kwaliteit en betrouwbaarheid.

Hoe bouw je een effectieve CI/CD-pipeline?

Stap 1: Kies een versiebeheersysteem zoals Git.
Stap 2: Automatiseer de build en integratie (CI).
Stap 3: Automatiseer de deployment naar testomgevingen (CD).
Stap 4: Monitoring en feedback integreren.

CI/CD en DevOps: hoe werken ze samen?

DevOps is een bredere filosofie die samenwerking tussen development en operations stimuleert, terwijl CI/CD de technische implementatie is die zorgt voor geautomatiseerde softwareontwikkeling en -implementatie. CI/CD is een van de belangrijkste pijlers binnen DevOps.

Populaire CI/CD-tools en platforms

De meest gebruikte CI/CD-tools voor BI-processen zijn GitHub Actions, Azure DevOps, GitLab CI/CD, Jenkins en CircleCI.

Wat zijn Canvas Apps in Microsoft Power Apps? - IT RBLS

Admin — Thu, 09 Jul 2026 10:03:32 GMT

Bedrijven zoeken steeds vaker naar flexibele digitale oplossingen die zich aanpassen aan hun unieke processen. Canvas Apps in Microsoft Power Apps maken het mogelijk om vanuit een blanco canvas volledig op maat gemaakte bedrijfsapplicaties te bouwen.

Met de keuze voor een Canvas App hebben bedrijven de controle over het ontwerp en de functionaliteit van hun applicaties. Canvas Apps kunnen eenvoudig gegevens ophalen en verwerken uit verschillende bronnen, zoals Microsoft 365, Dynamics 365 en SharePoint.

In deze blog ontdek je hoe Canvas Apps werken, welke voordelen ze bieden en hoe IT RBLS jouw organisatie helpt bij het ontwikkelen van slimme, op maat gemaakte applicaties.

Wat zijn Canvas Apps precies?

Canvas Apps zijn flexibele, low-code applicaties binnen Microsoft Power Apps waarmee bedrijven snel en eenvoudig apps kunnen bouwen zonder dat er uitgebreide programmeerkennis nodig is. In tegenstelling tot Model-Driven Apps, waarbij de interface grotendeels wordt gegenereerd op basis van het datamodel, hebben organisaties bij Canvas Apps volledige controle over het ontwerp en de indeling.

Wat is het verschil tussen Canvas Apps en Model-Driven Apps?

Flexibiliteit: Canvas Apps bieden volledige vrijheid om de gebruikersinterface aan te passen, terwijl Model-Driven Apps een gestandaardiseerde interface hebben.
Databeheer: Model-Driven Apps zijn afhankelijk van Microsoft Dataverse, terwijl Canvas Apps verbinding kunnen maken met een breed scala aan databronnen.
Gebruiksscenario’s: Model-Driven Apps voor gestructureerde, datagedreven processen zoals CRM-systemen; Canvas Apps voor maatwerkoplossingen.

Wat is Power Apps?

Microsoft Power Apps is een krachtig low-code platform waarmee bedrijven eenvoudig applicaties kunnen ontwikkelen en bedrijfsprocessen kunnen digitaliseren. Het biedt zowel de mogelijkheid om Canvas Apps als Model-Driven Apps te bouwen.

Hoe werken Canvas Apps?

Canvas Apps maken gebruik van een visuele ontwikkelomgeving: het bouwen van de gebruikersinterface met drag-and-drop, koppelen met databronnen (Dataverse, SharePoint, SQL Server, externe API’s), en het toevoegen van logica en automatisering met Power Automate-flows en Power FX-formules.

Voordelen van Canvas Apps

Volledige controle over de gebruikersinterface, integratie met diverse gegevensbronnen, snelle en efficiënte ontwikkeling, optimale gebruikerservaring op elk apparaat, en flexibiliteit en schaalbaarheid.

Voorbeelden in de praktijk

Veiligheidsinspectie-app, mobiele verkoopapp, HR-onboardingportaal, voorraad- en orderbeheer, en zorgregistratie-app.

Wat heb je nodig voor het bouwen van Canvas Apps?

Toegang tot Microsoft Power Apps, een databron, toegang tot Power Platform-beheertools en een duidelijk bedrijfsproces.

Aan de slag met Canvas Apps

Bij IT RBLS helpen we bedrijven bij het ontwikkelen en implementeren van Canvas Apps die perfect aansluiten op hun bedrijfsprocessen.

Where vibe coding shines for me and where it stopped

j.levoye@itrbls.com (Jeremy Levoye) — Tue, 07 Jul 2026 09:55:25 GMT

I recently built my first Power Platform code app using React/Vite. And the honest truth? I had a working demo in a few hours. That part felt amazing.

So what is “vibe coding”?

Vibe coding is where you build by describing intent to an AI, then iterate by reacting to what it generates. It’s less about writing every line yourself, and more about steering the direction, reviewing what’s produced, and refining it until it behaves the way you want.

The idea: an office table tennis app

In our office we play table tennis a lot, so I built a small app where colleagues can:

Queue up for a match get paired with an opponent
Track the score
And eventually build a simple ranking

Why vibe coding was a perfect start

This is the part where AI shines. You prompt → you get code → and within a short time I had:

Screens and structure
Working navigation
A userflow that could be tested

That “momentum boost” is real, and it’s probably the biggest value of vibe coding.

The turning point: when “working” wasn’t enough

After the first demo, I noticed something important. The app worked, but it didn’t feel like a mobile app yet. It felt like a dashboard squeezed into a phone.

So I started shifting the design toward a mobile-first shell: a “phone frame”, immersive match states, and tighter layouts that stay inside the viewport. This is where the project changed from “generate something” to “shape something”.

A small bug (score correction)

One of the more interesting lessons came from something tiny:

Deducting a point from your opponent sometimes removed TWO points.

That sounds trivial… until you realize what it forces you to confront:

What is the single source of truth for score?
Is score stored as numbers, as an event log, or both?
When you support undo, are you reversing the latest action or just changing a number?

It’s the kind of bug you don’t see in a happy-path demo, but you hit immediately in real play. And it’s also a perfect example of the limit of AI-generated first drafts: AI can generate score buttons fast. But state design (and reliable undo) is where you still need your own engineering brain.

What I learned (and why I still think this is awesome)

This project wasn’t business‑critical. It was a fun office app. But it taught me not only about UX and state, but also about security and long‑term ownership.

When you vibe code, it’s easy to focus on “it works” and forget that generated code is still… your code. And you’re responsible for what it does, what it exposes, and how it evolves. Our internal security approach is built around secure software development: avoiding hardcoded secrets, using secure components, peer review for pro‑code, and controlled releases via pipelines. That mindset matters even for “small” apps.

Security: “works” is not the same as “safe”

AI can absolutely produce code that looks correct and behaves fine in a demo. But AI-generated code can still introduce vulnerabilities and people are often more likely to trust it than they should.

That’s why I think the real rule should be: Never ship code you don’t understand.

Moral of the story

Vibe coding is a brilliant way to start. But the best results still come when you can fine-tune and validate the last 20% yourself. Especially around security, responsiveness, and state correctness.

AI gives you speed. You provide judgement. And honestly? That combination is awesome.

Related information: Quickstart: Create a code app from scratch

Microsoft Agent 365: what it is, what it costs, and why agent governance matters now

j.levoye@itrbls.com (Jeremy Levoye) — Mon, 06 Jul 2026 14:06:41 GMT

More and more organizations are running AI agents without a clear picture of what they have or who owns them. This is a practical look at Microsoft Agent 365: what it does, what it does not do, how the licenses compare, and who actually needs one.

You already have more agents than you think

Walk into most Microsoft environments today and ask three simple questions. How many AI agents are running in your tenant? Who owns them? What can they touch? You will rarely get a straight answer.

Copilot Studio made building agents almost trivial. A business analyst spins one up on a Friday afternoon. Someone in finance connects one to a SharePoint site. A vendor drops a partner agent into the mix. Six months later you have dozens, sometimes hundreds, and no single list of what actually exists.

This is not hypothetical. It is the same movie we watched with Power Platform. Makers built Power Automate flows and Power Apps faster than IT could track them, and governance showed up years too late. Agents are that story again, only faster and with far more access.

Agent 365 is Microsoft's answer to that gap.

What Agent 365 actually is

Agent 365 is Microsoft's central management and governance layer for AI agents. Microsoft calls it a control plane. In plain language, it is where you register, see, own, monitor, secure and retire the agents in your organization.

It became generally available on 1 May 2026 and plugs into the tools your admins probably already use: the Microsoft 365 admin center, Entra ID, Defender, Purview and Intune. So not a whole new console to learn from scratch.

What it covers:

Inventory. One registry of every agent, whether built with Copilot Studio, Microsoft Foundry, the Agent SDK or an open-source framework, plus partner and self-registered external agents.
Monitoring. Visibility into what agents do, which systems they reach and how they connect.
Ownership. Every agent gets an identity through Entra Agent ID and a responsible owner.
Lifecycle management. Onboarding, approval and a way to switch an agent off when it misbehaves or is no longer needed.
Security. Defender threat protection extended to non-human actors.
Compliance. Data governance and audit through Purview.
Governance. Policies applied centrally instead of agent by agent.

What you can do with it

In practical terms, Agent 365 hands IT and security a set of capabilities that map onto problems teams already have:

Agent inventory. One place to answer "what do we have and who owns it", including the agents you did not know existed.
Monitoring and analytics. Usage insights and a visual map of agent activity and connections, so you can spot the agent quietly calling an external API at two in the morning.
Governance. Apply policy across the fleet instead of trusting every builder to do the right thing.
Security. Extend Defender threat detection to agents rather than hoping they stay inside the lines.
Approval workflows. Register and approve an agent before it reaches production.
Cost management. See which agents drive consumption, since building and running them is billed separately through Copilot Studio or Foundry.
Risk control. Revoke access or stop an agent that starts behaving in a way you never signed off on.

Who is it for

Agent 365 is not for the end user chatting with an agent. It is for the people who have to keep the whole thing under control.

IT and Microsoft 365 admins who run the tenant
Security officers who need visibility and threat protection
Compliance teams who answer to auditors and regulators
Power Platform and Copilot Studio administrators who already own low-code governance and now inherit agents on top

In other words, if you are accountable for the AI landscape as a whole rather than for using one agent, Agent 365 is aimed at you.

How the licensing works

Agent 365 is licensed per user, not per agent. One user license covers all the agents that person uses, owns, sponsors or manages. The agents themselves do not need a license. That is a deliberate design choice: cost follows the humans responsible for agents, not the count of agents, so growing your fleet does not multiply your governance bill.

Note: A "sponsor" is the human responsible for an AI agent. They provide accountability for the agent’s purpose, access, lifecycle, and governance, ensuring every agent has a clear business owner and does not become an unmanaged or orphaned agent.

When the free plan is enough, and when it is not

The free foundational plan gives every Microsoft Cloud customer agent identity, an inventory and basic insights. For a small organization experimenting with a few agents, that visibility can genuinely be enough to start. You get to answer the "what do we have" question before you spend anything.
The paid plan is what you reach for once agents touch sensitive data or run at scale. It adds the advanced governance, security posture, threat detection and data controls that a security or compliance team will ask for the moment agents move beyond a pilot. If you operate in a regulated sector, you will land here quickly.
Two things are easy to overlook here. The first is that the standalone license assumes you already have a qualifying Microsoft 365 base. In practice that means one of the following:

Microsoft 365 E5. The enterprise plan that already bundles the advanced security and compliance Agent 365 builds on
Microsoft 365 Business Premium. The option for small and mid-size organizations
A lighter base plan with the Defender and Purview Suite added on top. This add-on layers E5-level security (the Defender Suite) and compliance and data governance (the Purview Suite) onto smaller plans, including a frontline-worker edition for Microsoft 365 F1 and F3

The second is that the license covers governance and security only. Building and running the agents is separate consumption through Copilot Studio or Foundry, billed on your Azure invoice.

One thing to watch on the roadmap

Microsoft's longer-term vision goes further than governance. Its documentation describes "agent users", a full identity type where an agent gets its own mailbox, its own OneDrive and a place on the org chart, with a name such as agent@yourtenant.onmicrosoft.com.

Three things to make crystal clear

Agent 365 does not replace Copilot Studio. Copilot Studio builds agents. Agent 365 governs them. You need both, and they are not competing for the same slot.
Agent 365 does not build agents. There is no designer inside it. If someone pitches you a single "build and govern" tool, they are quietly selling you two products as one.
Agent 365 does not replace Microsoft 365 Copilot. Copilot is the user-facing assistant. Agent 365 is the admin-facing control plane. Different audience, different job.

The real challenge ahead

Agent 365 will not do that thinking for you. It gives you the registry, the identities, the policies and the monitoring, but you still need an ownership model, an approval process and someone accountable when an agent does something it should not. Treat it the way the mature organizations eventually treated Power Platform.

Fabric Notebooks ontwikkelen in Visual Studio Code

r.stuij@itrbls.com (Remco Stuij) — Wed, 27 May 2026 06:04:22 GMT

Wat als je Fabric notebooks gewoon in Visual Studio Code kunt ontwikkelen, GitHub Copilot kunt gebruiken tijdens het schrijven van PySpark, én je code nog steeds kunt uitvoeren op een Fabric Spark cluster?

Dat is precies waarom de integratie tussen Microsoft Fabric en VS Code interessant is. Voor veel developers is VS Code namelijk de plek waar het echte ontwikkelwerk gebeurt: code schrijven, snel wisselen tussen bestanden, documentatie bijwerken, Copilot gebruiken en overzicht houden over wat je aan het bouwen bent.

Waarom nu?

Microsoft heeft in de Fabric April 2026 Feature Summary meerdere verbeteringen rondom VS Code benoemd. Denk aan het beheren van Fabric workspace items vanuit VS Code, het bewerken van notebooks met automatische sync naar de Fabric workspace, het beheren van environments en het instellen van een default Lakehouse voor notebooks.

Omdat deze verbeteringen sinds april 2026 beschikbaar zijn, voelt de integratie veelbelovend maar ook nog in ontwikkeling. Sommige onderdelen werken al erg prettig, terwijl andere onderdelen nog wat volwassener mogen worden. Juist daarom is dit een interessant moment om ermee aan de slag te gaan.

Waarom VS Code voor Fabric Notebooks?

Voor mij is het grootste voordeel simpel: VS Code is een vertrouwde ontwikkelomgeving. Wanneer ik aan Fabric notebooks werk, wil ik snel kunnen ontwikkelen, makkelijk kunnen wisselen tussen notebooks en gebruikmaken van de tooling die ik al dagelijks gebruik. Met de Fabric Data Engineering extensie brengt Microsoft een deel van de Fabric-ervaring naar VS Code.

Daarmee voelt notebook development minder als “werken in een browser” en meer als reguliere softwareontwikkeling. Je werkt met notebooks, Lakehouses, Spark job definitions, environments en workspace items vanuit een omgeving die veel developers al kennen. Dat maakt de drempel lager en het ontwikkelproces vaak sneller.

Waar deze integratie sterk in is

De eerste sterke use case is natuurlijk notebook development zelf. Je kunt bestaande Fabric notebooks openen, aanpassen in VS Code en je code uitvoeren op remote Spark compute in Microsoft Fabric. Daarmee combineer je de fijne editorervaring van VS Code met de kracht van Fabric Spark.

Een tweede groot voordeel is GitHub Copilot. Zeker bij het schrijven van PySpark-code kan Copilot helpen met boilerplate, transformaties, markdown-documentatie of het sneller opzetten van logica. Het vervangt je eigen denkwerk niet, maar het versnelt wel veel terugkerende taken.

Ook het snel wisselen tussen notebooks is prettig. Zeker wanneer je werkt aan een oplossing met meerdere notebooks, wil je overzicht houden. In VS Code voelt dat vaak natuurlijker dan steeds navigeren door de Fabric UI.

Daarnaast kun je op verschillende manieren werken. In local mode download je items lokaal, pas je ze aan en sync je ze daarna terug naar Fabric. In VFS mode werk je direct met workspace items als remote bestanden. Je hoeft dan minder met lokale kopieën te werken.Voor notebook-heavy development zou ik op dit moment vooral VFS mode aanraden. Dat houdt je workflow dicht bij de Fabric workspace en voorkomt onnodig lokaal bestandsbeheer.

Mijn praktische workflow

Mijn huidige workflow is vrij eenvoudig. Ik maak de basisstructuur meestal eerst aan in de Fabric UI. Denk aan folders, notebooks en de juiste workspace-inrichting. Voor dat soort structurele taken vind ik de portal op dit moment nog steeds het meest overzichtelijk.

Daarna verplaats ik het inhoudelijke ontwikkelwerk naar VS Code. Daar schrijf en verbeter ik de notebook code, gebruik ik GitHub Copilot, werk ik documentatie bij, beheer ik variabelen en run ik code op remote Spark.

Voor mij werkt die combinatie goed: Fabric UI voor structuur, inrichting en overzicht. VS Code voor development, documentatie en iteratie. Het is dus geen vervanging van de Fabric UI, maar eerder een aanvulling die het dagelijkse ontwikkelwerk prettiger maakt.

Runs monitoren en troubleshooten

Een ander handig onderdeel is het analyseren van notebook runs. Vanuit VS Code kun je recente runs bekijken, details inspecteren, logs downloaden en Spark-informatie openen.

Dat is vooral handig wanneer je wilt begrijpen wat er tijdens een run is gebeurd. Wie heeft de notebook uitgevoerd? Hoe lang duurde de run? Waar ging het mis? Welke Spark logs zijn beschikbaar?

Alle Spark logs zijn direct beschikbaar om verder te inspecteren. Dat maakt troubleshooting toegankelijker, zeker wanneer je veel met notebooks en Spark workloads werkt.

Dingen om rekening mee te houden

De integratie is nuttig, maar nog niet perfect. In mijn ervaring beheer ik sommige structurele zaken liever nog vanuit de Fabric UI. Denk aan het aanmaken van folders, het opzetten van de initiële notebookstructuur en het netjes organiseren van items in de workspace. Folder management voelt in VS Code nog niet zo soepel als ik zou willen.

Ook zijn er nog praktische beperkingen of randgevallen rondom notebookbeheer. Denk aan lokaal notebooks importeren, notebooks kopiëren of hernoemen, afhankelijk van de manier waarop je werkt.

Daarnaast heb ik af en toe een save-error gezien. Niet constant, maar genoeg om alert te blijven. Mijn advies: let goed op de sync-status en ga er niet blind vanuit dat iedere wijziging direct goed is opgeslagen.

Kortom: de integratie is al erg bruikbaar, maar ik zou de Fabric UI nog niet volledig vervangen door VS Code. De beste ervaring krijg je op dit moment door beide te gebruiken waar ze sterk in zijn.

Mijn conclusie

De Fabric Data Engineering extensie voor Visual Studio Code is een mooie stap richting een meer developer-friendly Microsoft Fabric ervaring.

Voor Fabric Notebooks maakt het ontwikkelen sneller, herkenbaarder en beter gestructureerd. De combinatie van VS Code, GitHub Copilot, remote Spark execution, notebook run monitoring en directe workspace sync kan het dagelijkse ontwikkelwerk echt verbeteren.

Is het al perfect? Nog niet. Is het nu al waardevol? Absoluut.

Omdat de nieuwste verbeteringen pas sinds april beschikbaar zijn, verwacht ik dat deze integratie de komende tijd alleen maar beter wordt. Zeker als Microsoft verder investeert in notebookbeheer, folder management en een nog soepelere sync-ervaring.

Voor de officiële setup en ondersteunde functionaliteit verwijs ik graag naar de documentatie van Microsoft.