Two SharePoint Embedded Architectures You Must Know About
Tags: sharepoint, architecture
Published: 2024-03-05 07:30:00

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.

![Busy city compares with open space houses](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0b8cdd8a-d393-4f40-9557-fdfba337d275_1024x1024.png)

**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:

1. **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.
2. **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.
3. **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.
4. **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:

1. **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.
2. **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.
3. **Personal Finance Tracker**. An application where users track their finances, including income, expenses, and budgets.
4. **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 intention 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](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](https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/limits-calling)*