Tag Archives: SharePoint

SharePoint and the Future of InfoPath

For those who don’t already know, InfoPath’s days are numbered. Microsoft has discontinued releasing InfoPath as part of the Office suite of applications, but will be supported as part of their typical lifecycle cadence of 10 years. I know many business users of SharePoint who have used InfoPath either to create custom List Forms or custom forms for a Form Library, and I am regularly asked “will InfoPath be supported in SharePoint 2016?”. My response is usually “Yes, it will be supported”, but in reality business users should be aware of the changes forthcoming, at least as of the date of this post.

While watching the SharePoint Virtual Summit today several chat dialogs took place between Microsoft staff and attendees, many involving this same topic. I captured what I could and wanted to share it here. The responses to the questions below are from Microsoft staff. Please feel free to comment if you have additional or corrective knowledge about SharePoint and InfoPath you’d like to share as well. Much of this is coming in Feature Pack 2 for SharePoint 2016 (coming Fall 2017).

In summary, InfoPath is still supported and can be used against any SharePoint list or library, but it’s not going to be directly integrated into the UX.

Is there any information available on the proposed replacements for InfoPath and SharePoint Designer?

PowerApps and Flow will be replacing custom forms and workflow design. PowerApps on SharePoint lists is our going forward solution to succeed many classic InfoPath scenarios. It’s the new solution for custom forms in SharePoint.

Will PowerApps fully succeed Infopath forms, or will they co-exist?

Depends on the scenario – PowerApps will enable custom forms in SharePoint, support simpler configuration etc. all of which InfoPath users love using. Watch out for blog posts and Microsoft Mechanics videos.

Can you integrate PowerApps forms with REST services? Just like how you could in InfoPath or custom JavaScript forms?

Yes, we call them custom connectors, https://powerapps.microsoft.com/en-us/tutorials/register-custom-api/

What will happen to any existing deployed InfoPath forms?

You will be able to create equivalent forms in PowerApps. We don’t plan to have a migration tool at this time. We have been rebuilding InfoPath forms with PowerApps to test this out. It does take a slightly different approach, but it is possible to redo most without issue.

Will there be any way or method for customers who use InfoPath currently to convert them to PowerApps without having to recreate everything manually?

This is not available at this time.

What is the path from InfoPath forms to PowerApp or something to replace?

You’ll be able to open the PowerApps designer to build new forms directly from your list – the data stays in place and the new forms just take over for SharePoint.

Eric

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 35 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Developer for General Motors, and also as a consultant.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Show modal dialog form from another site collection

Ever get an error message saying “Refused to display ‘url’ in a frame because it set ‘X-Frame-Options’ to ‘SAMEORIGIN‘.” when trying to load a list form from another site collection in a modal dialog?  Add this to a line right after the last <% Register tag on the masterpage:

Eric

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 35 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Developer for General Motors, and also as a consultant.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Populate a SharePoint 2013 PeoplePicker field using JavaScript/jQuery

Here is a quick and fairly simple way to programmatically populate a SharePoint 2013 People Picker field with a user based on their email address. This example assumes you have more than one People Picker field on the page. You will need:

  • The display name of the People Picker Field
  • The email address of the user you want to add to the People Picker Field

Add the following code to either a Script Editor Web Part (inside <script> tags) or on your page in the PlaceHolderAdditionalPageHead, also in <script> tags:

var dispTitle = "";
var pickerDiv = $("[id$='ClientPeoplePicker'][title='" + dispTitle + "']");
var peoplePicker = SPClientPeoplePicker.SPClientPeoplePickerDict[pickerDiv[0].id];
var usrObj = { 'Key': 'email@address.com'};
peoplePicker.AddUnresolvedUser(usrObj,true); 

In one case, I had to remove the “title” attribute filter from the pickerDiv var to get it to work, but it was the only People Picker on the page, so we were good.

Hope this helps!

Eric

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 35 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Developer for General Motors, and also as a consultant.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Know REST For the Query – SharePoint Saturday Phoenix 2014

Thank you for all who attended my session, below is the video. Big thanks to Becky Bohanon for enhancing the audio!

The slide deck is available here: Slide Deck

The JavaScript file that was used to do all of the REST calls is available here: demo.js

Eric

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 35 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Developer for General Motors, and also as a consultant.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Complete Guide to Making and Parsing REST calls using SharePoint Designer 2013

Recently I needed a sequential workflow that makes a REST call to another website (non-SharePoint), retrieves some JSON data, parses it, and makes decisions based on that data. Oh, and I’m not allowed to use Visual Studio in this case, it has to be SharePoint Designer (ugh). Continue reading Complete Guide to Making and Parsing REST calls using SharePoint Designer 2013

Eric

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 35 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Developer for General Motors, and also as a consultant.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube