One of the hottest topics in the SharePoint world is the “Death of InfoPath”. Everyone has a different opinion of the tool and its value but one thing is certain, Microsoft is no longer investing in it and hasn’t for a while.
Microsoft is retiring InfoPath and investing in new forms technology across SharePoint, Access, and Word. InfoPath 2013 is the last release of the desktop client, and InfoPath Forms Services in SharePoint 2013 is the last release of InfoPath Forms Services. InfoPath will be supported for next 10 years, but there will be no new innovation. Sure it’s going to be supported until 2023, but most companies are posturing for a long term replacement now. Forms are highly ubiquitous for just about any organization big or small. In lieu of the InfoPath announcement Microsoft has provided some light (ok very light) guidance on how to tackle forms requirements going forward. While there is little guidance being provided around how to migrate current forms solutions, here is a list of forms solutions that Microsoft has provided to consider when evaluating your companies forms requirements.
Consider these forms solutions:
- Excel Surveys
- Access Web Apps
- Forms for SharePoint Lists (FoSL)
- Structured Documents
- App Forms
Each of the items above provide a forms solution with SharePoint, but they all work very differently and each have pros and cons. If you are looking for an InfoPath replacement or if you simply need a forms solution to integrate with SharePoint, understanding the gaps to available options is important. In this post I want to focus in on one of them, Access Web Apps. In particular I want to provide some guidance on the limitations of this particular solution to be aware of.
To provide some context, here is a brief description of what Access Web Apps are. An Access Web App is a database that you use in a standard web browser, but which you design and modify in Access 2013. The data and database objects are stored in SQL Server or Microsoft Azure SQL. This data can be shared within your organization using on-premises SharePoint 2013, Office 365 Small Business, or Office 365 Enterprise.
With any solution there are a few drawbacks that you should be aware of...
- No Workflows
Each Access Web App that’s published to SharePoint comes along with its own standalone SQL database. Since the Access Web App data is in a separate SQL database and SharePoint can't see it, you can't create SharePoint workflows as a result. This is probably the most impactful drawback of the Access Web App solution because workflow is a very common requirement for most forms solutions. As a result SharePoint becomes a simple & limited front end UI to the Access data but nothing more. If you want to build a SharePoint form that involves critical business processes, you won’t be able to use Access Web Apps.
- SharePoint Permissions & Security
Each Access Web App has a related standalone SQL database. As a result it is a best practice to create each SQL database in a separate environment from your primary SharePoint environment. This causes a bit of duplication when it comes to the data itself, as it will now reside in more than one place. In addition each database needs to be set up using “mixed-Mode” authentication. This can be a concern for some DBA’s who would prefer the use of Windows-based authentication since it can be more secure. The user is authenticated differently based on how they navigate to the Access Web App. If they navigate through the parent site, Windows Based Authentication is used. If the Access Web App is accessed directly, SQL authentication is used. By default the Access Web App inherits from the parent sites security settings.
At the table level there is no way to separate user’s ability to edit and read various tables in the back end SQL server. If you can edit records in one table, you can edit records in all the tables within the app. At the record level there isn't a way to separate who can create a record vs. who can edit a record.
- Publishing Limitations
Depending on the complexity of the Access solution, some tables may not be publishable to SharePoint. This is dependent on the features you are using within the table/solution. There is a compatibility checker that is run when you try to publish your Access table to SharePoint. As a result there may be parts of your Access solution that you want to make available in SharePoint, but are unable too. For example Access Web Apps do not support the use of the Visual Basic Programming language (VBA’s), only macros. Lastly when publishing to SharePoint, all primary keys must be auto numbered and compound primary keys are not supported. If you are using VBA as a part of your solution, you won’t be able to use Access Web Apps.
- Inheritance
To get your Access data over to SharePoint, you have to create (publish) a new SharePoint site with the Access Data. It’s a lot like any other SharePoint sub site. However, one of the key differences here is that you can't break inheritance here like you can with a traditional sub site. This is very limiting if a different security model is needed for the Access Web App than what is being used in the parent site. This is quite common for a forms solution to have to do this. If you need to break the security model being enforced by your parent site, you won’t be able to use Access Web Apps.
- SharePoint Audiences
SharePoint has its own security model that allows a site owner to easily manage access to site content. This is one of the benefits of the platform because site owners can implement the security to the solutions and data to fit their specific security requirements. In addition to a user’s individually assigned security level, SharePoint also provides the ability to use both User Audiences and User Groups. SharePoint Audiences are dynamically created based on a set of rules. If users meet the criteria they will automatically become a member of the audience. The audience is compiled regularly using a background SharePoint job. Unfortunately SharePoint audiences cannot be used within an Access Web App without imbedding the forms solution within another web part where an audience setting can be applied. If you are using SharePoint audiences to maintain dynamic logic based access to areas of your site, you won’t be able to accomplish this with the Access Web App without some additional work. While this isn’t a showstopper it does entail extra work and configuration.
There are pros and cons to any currently available forms solution. Most of the time it’s pretty easy to find information on what each of them can do. Most people find out what they can’t do through arduous trial and error or by learning the hard way after the fact.
Quick Apps for SharePoint
I recently lead a webcast on the SharePoint forms topic titled “RIP InfoPath. What to do with your SharePoint Forms?” a few weeks ago. I encourage you to watch the on-demand webcast if you're using InfoPath to build SharePoint forms.
In closing did you know that Dell Software offers a code-free enterprise grade SharePoint forms solution? Well we do! It’s called Quick Apps for SharePoint. The Quick Apps suite provides the ability to drastically improve native SharePoint forms and address many other common customization needs. As most of you know it’s rarely just about forms. There are often other needs that are directly related to forms such as data viewing/filtering, charting & KPI’s, site navigation, and line of business integration to name a few. All of these needs are covered in the Quick Apps product.
