Two SharePoint Embedded Architectures You Must Know About

Mar 05, 2024

I've been playing with SharePoint Embedded during the last weeks. I discovered the two technical architectures you must know about. You don't need to walk the path, I did for you and here you can find my insights.

A busy city compares with open and clean-spaced houses.

Containers are the main element in SharePoint Embedded. So, architecture must be based on them. There are only two kinds of technical approaches when developing your solution. The first one, the most intuitive one, is to have several files per container. The second one, a bit less intuitive, is to have one file per container.

None of them is the best or the worst, everything depends on your requirements.

Let's take a look further and see the advantages and drawbacks of each of them. Some examples of likely projects are explained later too.

Architecture 1 - Several files per container

As I said, this is the most intuitive architecture. Why? Because we are using it in almost all of our daily activities.

Imagine we align containers with folders. We could have several files per folder, like we do with our local folders.

Let's go with another example. Let's set a container like a SharePoint document library. We can manage several files per document library, right? For me, this is the most accurate example. But we can also extend it to the use of Document Sets as well.

Well, you got the idea now. Very simple and very intuitive. Now, we have to evaluate it based on the Container characteristics and features:

There is a limit of 30M files and folders per container. Seems to be enough for almost any kind of application.
There is a limit of 100K containers per application (or container type to be most precise). By mixing both, we can have 300.000M files and folders. Wow!!! Maybe too much).
There is no way to add metadata to files. SharePoint Embedded doesn't support it at the moment of writing this article. So, its name and content are the only way to identify documents.
The container can have its own metadata. You can add properties to it and categorize all documents within it. All will share the same metadata, like a Document Set in SharePoint Online.
Retrieving files is easy. You can get all container files with one request. The unique mandatory parameter that you have to provide is the container ID property.
In terms of security, all files inherit their container permissions. You can also break this inheritance and add some more permissions to files. Take into account that only 5 thousand is the limit of files with specific permissions.
Regarding searching capabilities, you can only search natively by content. No file metadata is allowed as you can understand.

Architecture 2 - One file per container

The second architecture is very simple, one file per container. It could sound strange at the beginning. But, it makes sense in some specific scenarios. So, consider it when deciding the architecture of your solution.

Let's see the features of this architecture:

There is a limit of 100K containers per application or container type. So, only 100K files will be managed.
There isn't a way to add metadata to files. However, having a 1-to-1 relationship (1 container is 1 file) allows us to consider container properties as file metadata. You can manage file metadata natively.
Retrieving files is really complex. You will get only one file per request so, you have to create one request per container. In the case of needing to retrieve the whole set of files (100K), you must do 100K requests to get them. It's not something efficient at all.
Security architecture is simple as well due to the 1-to-1 relationship. As in the previous point, security is managed in the container, so in the file. Any change is easier and there aren't limits to it.
Another feature is being able to search by content and properties. You can create queries to retrieve information querying file content and container properties.

Projects you can explore

Once we've understood the pros and cons of each architecture, it takes time to envision the kind of projects per each of them. Here you have a list of 4 examples per architecture to start with.

In the first case, several files per container, end-users will work with files. This architecture is focused on collaboration, users collaborate on different files. In addition, most likely files can be Word, Excel, or PowerPoint. Finally, it depends on the solution and the requirements.

First Line Workers are the most probable audience in this case. SharePoint Embedded applications rely on Microsoft 365 characteristics. So, it's clear that the company can take advantage of this, providing a set of tools with no additional license.

Let's see a set of projects that go into this architecture:

Team Project Management Platform. A platform where team members can collaborate on tasks, timelines, and resources. Users can create, edit, and assign tasks, track progress, and visualize project timelines.
Online Collaborative Document Editing. A platform where multiple users can collaborate on writing documents simultaneously. Users can create, edit, and comment on Word files together in real-time.
Inventory Management and Ordering System. A system for managing inventory and placing orders collaboratively. Users can update inventory levels in Excel files, generate purchase orders, and track order status. Word documents can be used for documenting inventory procedures and guidelines.
Training and Development Program Platform. A platform for managing training and development programs within an organization. Users can collaborate on Word documents to create training materials. Then, use Excel files for tracking employee progress and assessments. And, finally, develop PowerPoint presentations for delivering training sessions.

For the second case, one file per container, we have to think of very specific and isolated ways of working. This architecture is focused on the user and the task around. Microsoft ToDo is an example of the kind of application that falls under this category.

Here is a list of likely applications that we can develop using this architecture:

Personal Journal App. Users can create and maintain a personal journal where each user has their own journal file. They can write daily entries, add photos, and set reminders. Users can only access and modify their own journals.
Custom Workout Planner. An application where users can create personalized workout routines. Users can specify exercises, sets, reps, and rest intervals to tailor workouts to their specific needs and goals.
Personal Finance Tracker. An application where users track their finances, including income, expenses, and budgets.
Study Plan Organizer. A tool where users can structure their study routines. Users can schedule study sessions, set study goals, and track learning progress in a focused and personalized manner.

Wrapping up

These two architectures are the very basic ways of working with SharePoint Embedded. From now on, you should evaluate which is the one that fits your needs. None of them will fit completely so, a mix could be the answer. My aim here is to give you clues of what you will get using one or the other.

SharePoint Embedded is a very new Microsoft 365 service with great potential. The architecture is only the base to build the solution your company needs. Do you have a third architecture in mind? Share it in the comments.

References

SharePoint Embedded App Architecture: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/app-architecture
Limits and Calling Patterns: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/limits-calling