Scaling Microsoft 365 for External B2B Users: A Legal Services Case Study 

Olena Grischenko: 
OK, Andrew, this is a semi‑structured interview. Today, we’re going to discuss the problem our customers are coming to us with. 

Typically, they start on Microsoft 365 using Office apps and SharePoint, then begin using Power Apps to automate some processes. But as they grow and try to scale, they hit limitations and come to us. 

I wanted to walk through one specific use case. We probably won’t name the customer in the transcript, but one of them is a law firm that we both work with closely. I was hoping you could help by outlining what problems they had, how they tried to approach it initially, and how it was eventually solved. 

Andrew Grischenko: 
Yes. I’ll start by giving a little bit of context. 

One of our clients is a professional services law firm. They specialise in multiple areas of law, including debt recovery, mortgages, property law, family law, and others. 

For the purposes of today’s conversation, a big part of their business is the B2B side, which means their clients are organisations that engage them to provide legal services. 

Olena: 
So this is a B2B scenario, which already explains part of the problem we’re discussing. 

Andrew: 
Yes. One specific case where this all started is that every legal matter begins with a client requesting legal engagement for a particular situation. 

In the context of debt recovery, this happens when someone takes credit but cannot, or does not, repay it. The law firm’s client engages them to handle the legal aspect of that process. 

Olena: 
So when you say “instructions”, who initiates the process? Is it the customer? 

Andrew: 
Yes, the end client initiates the process. Their clients are typically financial organisations that provide credit. 

They may have many of these matters happening at the same time, sometimes hundreds concurrently. 

Olena: 
That scale is an important context. 

Andrew: 
Going back to the problem itself, before any technology was introduced, the process was fairly ad hoc. It mostly relied on emails. 

Olena: 
That makes sense. I touched on this a little bit in my article: emails get lost very quickly, especially when volumes increase. 

Andrew: 
Exactly. That’s the key complaint from both the law firm and their clients. From email communication, you can’t clearly see the status of the matter. 

It becomes a long chain of messages mixed with other communication, not just information related to that specific legal matter. Everything gets diluted. 

Olena: 
Yes, absolutely. 

Andrew: 
What all parties wanted was a secure way of communicating and exchanging information that was clearly tied to a specific legal case. 

Andrew: 
In terms of solutions, the first iteration involved trying several approaches. One of them was using Microsoft Forms to collect initial instructions. 

That worked for capturing some data, but it was one‑way. The submission didn’t lead anywhere after that. 

Olena: 
So it worked for intake, but not for an end‑to‑end process. 

Andrew: 
Exactly. 

They then tried a more interactive approach by creating an app. The first version was a canvas app hosted on SharePoint. Clients and their customers logged into that app. 

This was where they submitted instructions and received status updates. 

Olena: 
Just to clarify. Did they use SharePoint just for documents, or also for structured data? 

Andrew: 
Both. When they used Forms, the data went into SharePoint lists. The app was also built on SharePoint lists and document libraries. 

The app was not built on Dataverse. Status updates were surfaced through SharePoint, and there was a simple integration via Power BI with their internal matter management system. 

Olena: 
So we’re talking about SharePoint lists and document libraries. 

Andrew: 
Yes. There were several lists involved, mainly for exposing status updates coming from the internal system so the client could see them. 

Olena: 
So there was integration involved as well. 

Andrew: 
Yes, a simple integration via Power BI. 

This approach worked reasonably well for one client. But when the business started growing and they wanted to onboard more clients, problems appeared. 

Olena: 
And licensing became part of that problem, right? 

Andrew: 
Yes, that’s a good point. To use the app, clients had to be onboarded into Microsoft 365 as guest users. 

That meant setting them up with the right permissions, placing them into the correct groups so they wouldn’t see data they shouldn’t see, assigning licenses, and granting access to the relevant SharePoint sites. 

Olena: 
So there was the M365 license, the Power Apps license, and then SharePoint access on top of that. 

Andrew: 
Correct. SharePoint was covered by M365, but there was still the Power Apps license involved. It wasn’t premium, but it was still overhead. 

Andrew: 
Then, as they onboarded additional clients, they couldn’t find an easy way to safely separate data. The approach they chose was quite straightforward but expensive -duplicating everything. 

That meant duplicating SharePoint sites, lists, document libraries, Power BI reports, and apps for every client. 

Olena: 
Creating another library and another list for each client. 

Andrew: 
Yes. By the time they reached their third client, they realised this wasn’t a sustainable approach. 

Olena: 
So that’s where the conversation shifted towards building a portal. 

Andrew: 
Exactly. A portal offered several benefits compared to what they had. 

First, it removed the dependency on Microsoft 365 for external users – clients only needed access to the portal. Second, it provides one solution for all clients with proper data separation and security. 

On the backend, staff could see all matters for all clients in one place, which is important because staff typically work across multiple clients. 

Olena: 
That’s actually a really important point. It’s not just client setup – staff need a consolidated view, and with separate SharePoint sites, that’s difficult. 

Andrew: 
Yes. SharePoint makes granular, record‑level security very difficult. You either duplicate data structures or accept fairly limited access control. 

Olena: 
And that’s especially problematic in a legal environment. 

Andrew: 
Exactly. 

With the portal solution, clients can self‑register using multi‑factor authentication. They can submit instructions, upload documents, and track status updates securely. 

Data is stored centrally in Dataverse, and this also supports transitioning from a poorly performing legacy matter management system. 

They can now onboard a new client in about 20 minutes – create the user, upload branding, and they’re ready. 

Olena: 
And if functionality needs to be updated, it’s done once rather than duplicated multiple times. 

Andrew: 
Yes. Since going live and through the pilot, there have been many change requests. But changes are implemented once and apply to everyone. 

Olena: 
That’s great. This case really shows how organisations adopt tools as they grow -starting with email, moving to forms, then apps, and finally realising they need a scalable platform. 

Thank you, this gives us great material. The next conversation can focus on architecture and how everything fits together.