I am working on SharePoint enterprise server 2013, and I am trying to find the best approach I can follow to achieve this requirement:-

  1. Our customer has a web page which list their employees info.
  2. Currently the web page (which is an asp.net mvc application) reads its data from external database.
  3. The web page allows users to click on a employee link and a jQuery dialog will be populated showing more details about the associated employee. Also users can search the web page, using employee name.

So currently our customer requested to have this web page shown inside SharePoint site collections. So I am trying to find what are the available approaches I can follow, either to render the web page as-is inside the sharepoint sites OR to build this web page using share-point list

Now I did the following steps:-

  1. Inside a team site collection.
  2. I added a web page.
  3. Then I add a web part of type page viewer, and I specify the external web page url.
  4. And seems it worked well. Where the external web page was shown inside the sharepoint web page.

So can anyone advice on this :-

  1. Is my approach of using the page viewer web part , a valid approach to follow?

  2. Is building a SharePoint list which reads its data from external database, and show a dialog box when click on a employee link ,, something that I can develop easily inside SharePoint?. I mean to have the employees list as a SharePoint list,instead of being an external web page ? but not sure if this is an easy thing to achieve ? also we want the ability to sort the names and extensions based on each dept...

here is a general overview of the list we want to build:-

  • where employees are categorized under dept.

  • and for each dept, users can sort the names & extension.

  • when searching for a name, the web page will show the related branches, with the same categories (per Dept) :-

enter image description here

4 Answers 4


My own opinion is very clear on such matters: keep your MVC Web app, and display it in SharePoint with the Page Viewer Web part, as you already did. To me, this is a good approach, and very cheap. Pros largely outnumber cons:


  • Cheap solution. While developing something specific in a pure SharePoint style (and with respect to the state-of-the-art) would be several days of work.
  • You've already done it, and you understand what happens.
  • Accessing external from SharePoint is "complicated" and requires very specific SharePoint dev skills, while finding resources to maintain an ASP.NET MVC app is much easier.
  • SharePoint has a lot of limitations when it comes to replace a DB; e.g. the (in)famous "5000 items per view (list)".


  • You have to maintain a third-part server for the only purpose of that external Web app... but you can easily host it on a dedicated Web app/pool of the SharePoint server.
  • you have to remove "chrome" from the external page so you don't display logos/menus/navigation/... inside the frame.
  • You don't control permissions from SharePoint.

I'm a SharePoint developer, so I should push for a pure SharePoint dev approach. But I'm honest with my customers and I always offer them the "IFrame" solution first! If it fits the needs, and as it is something simple/clear/supported why going with another difficult approach?

If I had to do it from scratch, i.e. the external page does not exist yet: it all depends on the complexity/structure of the data.
[remember I'm a SharePoint developer, so creating WSP-solutions is not a problem to me, while it could be complicated even for a very_good_ASP.NET_dev_who_have_never_played_with_SharePoint]

  • If it's heavily relational, I'd keep the data inside the DB, and would go to develop a Web part/an applicative (_layouts) page. In that Web part/page, I'd request for teh data with standard ADO.NET, and use as much jQuery/any_other_fancy_client_framework as needed to get to the UI result you need.
  • If it can fit into SharePoint lists (including not "too many" rows), I'd store data in lists, and I'd create custom UI (i.e. replacing standard list forms with custom ones) whenever needed.

In all cases the whole thing would take days to develop correctly.

OK, to try to answer last comment from @john G, let's consider more closely what you'd need to build such a solution completely in SharePoint:

  1. You need to store data. I'm not sure I got the big picture, but you could simply use two lists: a list of Departments, and a list of employees. The list of employees has First Name, Ext., etc. columns AND a lookup column to the Departments list. You can even rely on the view capabilities of SharePoint to display the employees list grouped by Department. Also (in SharePoint Server, not in Foundation) you have the "Find an item" box that works great to search directly inline. And when an item is clicked, you view the full details for that employee (could be in a dialog box, if you configure the list to use dialog box, see in Advanced Settings of the list).
  2. In addition to the above approach to surface the data, you can build your own UI, either with Web parts and/or with applicative (_layouts) pages. The main difference between these SharePoint artefacts and a standalone ASP.NET application is: you cannot use MVC here, so only old-school ASP.NET. Main advantages are: simplified deployment/updates accross all the servers in the farm, and you can rely on SharePoint groups to check for permissions.
  • 1
    +1. I was in a project which would have worked better in an MVC application -> Page viewer set up. The solution quickly got complicated as we had to develop an MVC web api and write angular js within a webpart / app (to consume the web services) and hosted it in SharePoint. The solution that you mentioned struck me very late and by that time we were already half way through. And now we are stuck with maintaining both of them. Lesson learnt: Be simple when it comes to SharePoint.
    – Akhoy
    Commented Feb 29, 2016 at 12:34
  • @Akhoy so if i got your point correctly,, in my case since the web page is somehow far from what SharePoint list can offer out of the box, in respect to sort per dept, search , showing additional details inside jQuery, reading the data from external source .. so you are with having this web page developed using asp.net ? rather than trying to modify the built-in SharePoint list to have the current requirement ?
    – John John
    Commented Feb 29, 2016 at 13:31
  • @Evariste thanks for your detailed reply... but if we remove the assumption that we already have the web page developed as asp.net mvc... will you still go with having this type of list as a separate web page , being showed inside SharePoint using iframe ?? as to be honest i do not think i can achieve these features if i use SharePoint list; showing items categorized by Dept, ability to filter items per Dept using name and extension , search results with items being categorized per Dept , showing additional item details inside jQuery dialog ..
    – John John
    Commented Feb 29, 2016 at 13:35
  • 1
    @johnG yes. If it is easier developing your web page the MVC way (and I honestly think MVC is way more easier to work with), then you should do what Evariste mentions since modifying list would bring with it a lot of complexity.
    – Akhoy
    Commented Feb 29, 2016 at 13:44
  • 1
    Edited my answer.
    – Evariste
    Commented Feb 29, 2016 at 14:05
  1. This is by far the easiest approach and very valid if you don't run into the technical limitations of using an iframe.
  2. You're probably right that indexing the site might no lead to the right results when the page is being built with jQuery. You could check if there's a path on the site where you can index te content by following url's. If so, than indexing would probably be ok.
  3. It's probably possible, but if you don't have any experience with this, I would qualify it as rather difficult.

If you're business problem is solved by implementing the page viewer webpart, I would keep it like that. Else try to index the site, ask for an adjustment to make it indexable. I personally wouldn't go the external data route in SharePoint.


In response to Evariste. If you are not very familiair with SharePoint development, please know that writing full trust code is not the recommended way anymore by Microsoft. It is still very good possible and supported, but the recommend way is building outside SharePoint or using javascript/html/css.

  • can you please check my edit, i added extra details about my requirements...
    – John John
    Commented Feb 29, 2016 at 11:50
  • 1
    I would still go with the page viewer webpart and the MVC app. I would only built a SharePoint solution if the data was created and stored in SharePoint. If it's coming from somewhere else a MVC site is by far easier. Another model I've done is build a rest api and use something like Angular (or Knockout) to call the rest api and surface the data in SharePoint with html and javascript.
    – Oak3
    Commented Mar 1, 2016 at 11:44
  • @MartijE so you mean i can build an API using asp.net mvc, then i can develop an APP (either SP-hosted or provider hosted) which call the API and show the data inside a view ?
    – John John
    Commented Mar 14, 2016 at 17:31
  • Not inside a view, but you can use a Content Editor Webpart, or a custom page where you can built your own app in html and javascript (Angular, Knockout, jQuery etc) and call the api.
    – Oak3
    Commented Mar 15, 2016 at 9:49

The iFrame approach is perfectly valid, and I agree with Evariste's answer which does a good job of explaining the Pros and Cons.

There is also a pure SharePoint solution which would take only a little longer to implement, and I feel would be the better approach.

You seem to be aware of BCS, since you have mentioned external lists, but are maybe not aware that BCS can also be used in conjunction with the SharePoint User Profile Service. In short, you can set up a BCS connection to your external database, then in the SharePoint UPS you can map fields from the external DB to properties in user's profiles. SharePoint profiles already have properties for Department, Mobile etc, or you can create your own extra properties as needed.

This will then tie in perfectly to the built in SharePoint functionality. If you use the out of the box search centre, then you already have a people search results page, and you can easily customise the refiner web part to prioritise the properties you are interested in. Or, you can easily take any standard page and add a people search box, people search results and refiner web parts.

Then, if someone searches for "Finance" for example, they will typically see a mixture of documents and people in the "Everything" search results, or they could then choose to search People only. The refiner web part will let them filter down the results by whatever properties you include. When they click a persons name, they go to their profile page and see whatever properties you have decided should be on the profile page, along with an org chart browser. And, they can typically click on any of the properties (such as department) to see related users.

And of course, this ties in with the standard functionality, so if you're looking at a document library for example, and see Joe Bloggs modified a document, you can click on his name and see his profile page with all his properties.

If you want to really show off, you can then also encourage users to fill out other profile details such as the "About me" or "Ask me about" sections. In my profile for example I put "SharePoint" in the "Ask me about" section, so if anyone in my organisation searches for SharePoint they find me.

From a technical point of view, this is all very easy to implement. The difficult part is getting agreement on what properties to include, what should be editable by users and what should not, what should be displayed on a profile page and what should not etc.

This is a good guide to planning user profiles: https://technet.microsoft.com/en-us/library/ee721054.aspx

  • ok thanks for the info regarding user profile and that i can build the user profile using BCS ,, but the thing you did not mentione is how i can build my view ,, i provided an example of the view inside my original question,,,So is this something that can be achieved using SP standard list ?? second question you mentioned i can use BCS with User profile,, but will this create a sharepoint list which lists all the users?? as you are talking about populating users' profiles info using BCS ,, but will there be any list which contain all the users' info ? or i need to build such a list..
    – John John
    Commented Mar 14, 2016 at 17:39
  • Yes, I wasn't very clear about that in my explanation, sorry. It won't create a SharePoint list, it only populates the user profile service, which is then exposed through the search service. To get a list type view, you would use search web parts. There is the standard search functionality, where the end user puts a query in to a search box and gets results, and gets refiners to refine down the results. But, you can also use the search service with predefined queries. Commented Mar 15, 2016 at 10:31
  • You can add either the People Results Web Part or the Content Search Web Part, and give them predefined queries, for example dept="Finance". The web part will then give you a list of all users for the finance department. You can also create custom display templates for your search results, this will allow you to customise exactly how users are displayed in the search results and what properties/data are shown. This is slightly custom, but is only a little HTML and JavaScript, and far easier than custom MVC or other .Net Commented Mar 15, 2016 at 10:34

You could try to use a provider hosted app to use the existing MVC application. See the blog Convert MVC application to SharePoint 2013 provider hosted app

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.