5 min read
This is Why You Should Switch from Access to Power Apps
There are various tools available for building internal business applications where data is processed and stored in a relational database. Microsoft Access and Power Apps are examples of this. This blog discusses the growing demand for when and why it's advisable to switch from Access to Power Apps.
Limitations of Microsoft Access
External use
Access was developed by Microsoft 28 years ago and is used for local applications or within an intranet. This means applications are difficult to share with external users. You can move the application to the web with Access Services, but this seems like a rather roundabout method, since under the hood a SharePoint site is created that can potentially be reached from outside with some extra work. This requires setting up an external server — running Windows — to host the SharePoint site, so it isn't limited to internal use only.
Large numbers of users
In addition, Access was developed for small, lightweight applications where not too many users work in it at the same time. If you do work in it with many users at once, you'll notice that the application quickly becomes slow and that you have to wait a long time for a query (which makes up a large part of the actions in Access) to complete. If you want to scale up an application to a larger user group, Access will bring (virtually insurmountable) obstacles.
Mobile applications
The last point is that there's a growing demand for mobile applications that can also perform actions on an (Access) database. It's easy to quickly look something up or write something down on the go, whether in the browser on a mobile device or as an installed app. Mobile use is not supported by Access in any way, so unfortunately this won't be possible.
How are these limitations overcome with Power Apps?
Developing, using, and managing Power Apps all happens in the cloud. This means the applications can be accessed from anywhere. Of course, security can be fully configured in the management environment, where only (guest) users that exist in the Azure AD can be added. In short, users can be managed securely, simply, and clearly.
External and internal use
Because this all happens in the cloud, it's many times easier to share an application than when using Access. Instead of setting up security within the intranet specifically for external users who want to access the application, it's simply a matter of adding them to the Azure AD as a guest user, after which you can immediately invite them to the app. This is faster, more secure, and easier to manage.
There are situations where you'd prefer to keep data internal. Power Apps offers options for this too: while the logic sits in the cloud, the data doesn't necessarily have to. For Power Apps, data sources such as Dataverse (formerly Common Data Service), SharePoint lists, and Excel files can be used, but communication with an on-premise SQL server is also possible. This happens through a Data Gateway that's easy to install and manage. This makes it possible to have a matching data source for every use case.
Large numbers of users
Power Apps supports as many concurrent users as the data source supports. This means Power Apps itself has no limit on concurrent users. The app will keep working quickly for every user, and scaling up to large groups is possible.
Mobile applications
Mobile use is very well supported in Power Apps. It's easy to develop responsive apps that look great and work well on mobile, tablet, and desktop alike. Applications can be accessed in the browser, but also via the Power Apps app, which can be downloaded from the App Store or Play Store. This way, the data can be viewed and edited wherever and whenever the user wants!
| MS Access | MS Power Apps | |
|---|---|---|
| Easily share apps externally | ✗ | ✓ |
| Large numbers of users | ✗ | ✓ |
| Mobile applications | ✗ | ✓ |
| Easy to manage | ✗ | ✓ |
Example: Contract management
For a client, we rebuilt an Access application into Power Apps. The user interface and (business) logic that were woven throughout the entire application were recreated — and improved where necessary — in a combination of Power Apps and Power Automate (formerly Microsoft Flow). In Power Apps, the front end was rebuilt, giving various overviews, forms, and data validation a modern look. For the deeper logic, Power Automate is used. Here, a process can be developed visually using a flow diagram, which can be triggered by, for example, an action in Power Apps, but also periodically at a set time.
The wish for this application was to store the data on an on-premise SQL server. As described above, this was relatively easy to set up, and we were able to quickly build on a solid data model. Power Automate could also make use of the data gateway used, in order to write to the same database where needed. For example, keeping a historical record of changes made to certain tables could be implemented well this way.
Future-proof
This blog described why and how an Access application can be replaced by Power Apps for a future-proof application. We briefly highlighted 3 important limitations of Access, and then explained how Power Apps overcomes them. All of this comes together in the example case described, where we did exactly this for a client. Do you also have an Access application you'd like to make future-proof? Get in touch with us to discuss the possibilities without obligation
This blog was written by Steve Jonk
Low-code Developer at E-mergo