In my previous article, I spoke about the process by which we begin building our solution, Lean Six Sigma (80/20), and what we can use to do so. Let’s look now at what each of these are, their constraints, and how we can get around them.
Limitations. So, what are some of these hard limits that affect the decision on what medium we use? To begin, SharePoint/Microsoft Teams support up to an unlimited number of items. Now, I know what you are saying: but I can only get 5,000 items in a SharePoint list or library. While this is true, the limit is based upon direct access to the content in the list, not what can be stored. You can get around this by indexing your columns, which removes the amount of data that can be stored and accessed. Side note: technically, 30 million is the true limit to the number of items that can be stored, but if you are handling 30 million items, SharePoint isn’t your best storage medium.
On the other hand, Microsoft Teams has different limits which focus on your team size, not the data being stored. For example, you can have up to 999 members in a team.
With that said, SharePoint Online becomes a great starting point for building a solution; however, if you determine that you will be storing 5 million records a year, you may want to consider the use of SQL instead.
Wait, why didn’t I mention Dynamics? Well, like SQL, there is no set limit on the amount of data being stored since this is an Enterprise Application, but the benefit of implementing Dynamics isn’t about no limits. The benefit you get from Dynamics is the fact that there are already prescribed column definitions, data definitions, views, analysis, etc., and that you don’t have to rebuild if you were to create those solutions from scratch. The 80/20 rule plays a big part here as to which storage medium you will use from the beginning.
When deciding on your storage medium, focus on size constraints, security constraints, and data definition. By focusing your attention on each of these elements, the right decision will be easy to make.
Extensibility. Next let’s talk about extensibility; after all, typically no base storage medium will give you all the capabilities you need to get to a final solution. We all know that building an application on SQL gives us unlimited options, but the downside is that our development costs are super high. With this in mind, the 80/20 can be an issue here as storage is typically only 20% of our 80% need.
To build a complex process which is executed by a user, we’ll have to implement some type of front-end interface. Microsoft has done a great job of giving us solutions, like ADO.NET for accessing the data, and VS.NET, PowerApps, Microsoft Flow, and/or PowerBI for updates and analysis. PowerApps is great for building applications, and is useful not just for SQL applications but for SharePoint applications as well.
Business Processes. Let’s focus now on the business process which makes up your application. There are several options we can use for managing a business processes, including Microsoft Flow, Workflow Manager, and SharePoint. There are more external services available, but for now let’s focus on the ones available through and connected to Office 365.
Microsoft Flow gives us the ability to create simple or complex workflows which will interact with multiple data sources. The data source can be SQL, Email, SharePoint, Google, or just about anything that has a REST interface attached. Furthermore, you can execute many operations to store or use data from any of these data sources all at once. Before, you would have to use a solution written using Visual Studio or VS.NET to do this; but, now with Flow, the need to build your own solution is greatly diminished. For example, if a user wants to trap emails sent to Support, they can send them to a Support solution built in SharePoint.
Workflow Manager is an open workflow management service which can be added onto your Windows Server. With that service and using custom code, we can create any number of workflows which connect to any number of systems and data sources. Because of the custom nature, there will be a need for VS.NET to implement, but that doesn’t mean we need to write code to make it happen. If we search through GitHub, there are many Windows Workflows that we can leverage to quickly implement our processes. Config modifications are required, not code modifications.
SharePoint Workflows allows us to interact with SharePoint content and external content. For example, I could use a SharePoint Workflow (2013) to execute a process based upon a SharePoint item, then update a remote database with the information contained within the item. The door doesn’t swing both ways though. You can only capture changes that are made using SharePoint, not the other data source. For that, you’ll want to use either Microsoft Flow, if possible, or Workflow Manager because you may find the activities in SharePoint are just not strong enough. For example, as a part of Employee Onboarding you may want to have new users created in Active Directory (AD) as a part of the onboarding process. Out of the box, SharePoint doesn’t offer this activity, but by using a product like “HarePoint” you can, which means you can decrease your costs.
Final Thoughts: This article has focused on the constraints of the Data Sources we have at our disposal, and tools we can use to create and manage the business processes our solutions might need. In the next article, we’ll delve into the User Interface that your users will use to interact with these elements, and some of the technology we can use for implementation.
To get a notification when part three of this guide is published, subscribe to the blog.