What are the Benefits of using InfoPath forms in SharePoint?
I’ve been doing research on InfoPath to see how it integrates with SharePoint. The idea of letting users create their own forms offers a lot of power, and could enable people to handle some of the small requests they have on their own. However, outside of creating a form library that is driven by an InfoPath form, InfoPath appears to quickly become a hassle and a hindrance. Sure you can build code to directly talk to the SharePoint Object Model, but then you can only seem to be able to run your forms in the browser.
If you’re going to run everything in the browser, why not just use an ASP.NET form?
Also, besides the basic forms library approach, what other benefits does InfoPath on SharePoint offer?
I like to think of Infopath forms as being a great solution to the age old "form in a word doc" issue that companies have. It moves the task of creating and modifying forms closer to the people who care about the information.
There are tasks that are difficult to achieve in Infopath, but again it depends on the knowledge of the person creating the form more than the technology itself.
For forms that are complex and/or require large throughput, a straight ASP.NET form would be a better fit. As always it is about choosing the correct (cheapest total cost?) technology to solve a problem rather than shoehorning a solution from whatever is lying around.
(i.e. I still don't know enough about InfoPath to make a decision easily all the time).
Here are a few benefits of InfoPath forms over ASP.Net forms.This will, of course, always depend on your mix of requirements, developers, user skill, etc.
Forms are simple to create and modify for people familiar with MS Office
They integrate directly with the metadata in Sharepoint, unlike an ASP.Net form
Workflow Foundation is available through Sharepoint and simpler than using an ASP.Net form
If you're dealing with document-based processes (like work orders, orders, permission requests), it might make more sense to have a repository of the documents, rather than building a reporting structure off the data entered through the ASP.Net form
The documents are ready to be used by a process implemented in BizTalk
The validation and logic are run on the client with no additional programming, many times giving a much better user experience than plain ASP.Net forms
Related
A client's employee base is struggling with using sharepoint UI as an interface. As a result the client is evaluating the option of building a custom UI on top of sharepoint to provide a better user experience; [The other option being to move away completely from sharepoint (non trivial, high cost option)]
My research indicates that you can customize the UI look and feel (but the client is looking for much more).
Another option appears to be to change/improve the experience by building PowerApps
The option I have been trying to assess,is to see if sharepoint provides adequate set of APIs/integration interfaces that allows the user to build a completely independent UI and user experience. Its effort intensive ofcourse, and feels like reinventing the wheel, and am wondering about whether others have faced similar UX callenges, and what possible solutions they might have evaluated, and path they have gone ahead with.
Under the covers, SharePoint is a SQL database and a collection of .NET classes that define each SharePoint object: SPWeb, SPSite, SPWeb, SPList, SPUser list item, document etc. Most of these objects are exposed via web services. Microsoft then built an IIS/ASP.NET based UI for the out of box user experience. There are mobile apps that are not browser based that call the SharePoint REST services to read and update lists and libraries. If you wanted to, you could built your own complete UI based on just about any technology. Is it worth it? Probably not. There are many customization options available, depending on your version of SharePoint.
(If I could post comments... :-) I would then ask: Tell us more about what the users need in the UI that is not supplied by out of the box SharePoint.)
My client uses InfoPath form libraries. They want to phase out the use of InfoPath all together and replace it some alternative.
My idea is to implement custom forms for the same and host it within SharePoint, so that the users can have a web based alternative, in place of client application such InfoPath Form Filler.
What can be the best strategy to achieve this?
If you're sure they want to use browser forms, I'd start by investigating Forms9 and Nintex. I think Qdabra did a webinar on getting your data out of your existing InfoPath forms.
However it might be smart not to rush, since InfoPath is not disappearing for several years. New options are in the works. Microsoft is working on native solutions such as Forms On SharePoint Lists that might meet your client's needs in a year or two. Also Formotus (my company) has app-based form filling solutions and has announced the intent to continue superseding InfoPath, so the right solution may come from there too.
Recommended reading: My blog series on InfoPath Alternatives
http://www.formotus.com/category/infopath-alternatives
So we have a client that is wanting to replace all of their forms they use with digital versions where the data entered into them are stored in a centralized database for reporting. One of the main features required is when financial data is entered into a form, the relevant information should be update in QuickBooks. Specifically, instead of filling out a donation slip, putting it into a file for a donator, bringing up Quickbooks and recording the donation they want to have an application where they enter the donation/donator info which is stored in a database and, using the Quickbooks SDK, updates the daily deposit/donations/etc info in QuickBooks automatically.
My boss is trying to convince me to make a custom application to handle the whole thing, but I've been considering trying to pitch an Infopath + Sharepoint solution to him for the form management. However, I have absolutely no experience with either, so I don't know if any kind of integration with Quickbooks would be possible. So would an integration infopath/sharepoint with Quickbooks be feasible, and can you give me tips on where to look for info on how to implement it. Also, hiring a 'SharePoint Developer' is out of the question. So would a VB.Net/C# developer who has experience with web application development be able to address the programming skills required for a solution?
I'm open to any ideas.
I believe a .NET developer could probably handle this situation. You could possibly write code in the Infopath forms themselves, or create SharePoint workflows (using Visual Studio). It would probably be a decently complex and hard to maintain solution though.
I have not expirience with Quickbooks... If Quickbooks has web services to perform operations you are interested in you most likely will be able to make InfoPath form to collect/submit data.
InfoPath alone (as client application part of Office) may be enough - you should be able to quiclky prototype form you have InfoPath installed. For server side rendering of the InfoPath forms you need Enterprise edition of the SharePoint Server - not sure if this task alone would justify the purchase.
We got an requirement for implementing captial expenditure lotus notes application in sharepoint. It's having nearly five massive forms with all expense calculations and workflows.
What is the suggested approach in sharepoint to implement this?
I would agree that creating a custom ASP.net/SQL server web app would be the way to go if you have some ASP.net programmers available, though I'd recommend against embedding it via a Page Viewer Web Part. You can integrate ASP.net web apps directly in SharePoint, no embedding required.
If you don't have ASP.net programmers available, you can certainly do it in SharePoint and it may not be painful. The key issues are where you need to store your data and how relational the data needs to be. If the requirement is to store data in a relational DB, it becomes complicated to do it in SharePoint.
On the other hand, if you can imagine recreating your application's data as a collection of Excel spreadsheets, then it will be pretty straightforward to do it in SharePoint. In the simplest scenario, you could do all "development" using the SharePoint web interface. You would create a custom list in a SharePoint site for each expense form, then customize the site's default.aspx page to display a link the newform.aspx for each list. If the wokflows are basic notification/approval types, then you can also attach SharePoint built-in workflows to the lists via the web interface.
If you need custom form layouts, custom workflows and dynamic data filtering, then you could use SharePoint Designer to accomplish a great deal of design and development. Without more information about the existing application and workflows, it's impossible to say exactly how you should do it. But make sure you consider what parts of the existing application are requirements and what parts are just legacy functionality. If you can simplify the application, this is a great opportunity to do it.
While you can do it in SharePoint, it will be painful. You may be better off implementing the application as a stock ASP.net/SQL DB application and embedding it into SharePoint with a Page Viewer Web Part.
You can also skin your custom application to look like SharePoint using one of the SharePoint master pages as a template and link to it from your portal.
For added SharePoint integration, you can use Data View Web Parts or the Business Data Catalog (MOSS only) to query your expenditure application database and embed small reports and key performance indicators throughout your portal.
Alternatively to a Custom web app:
Create custom web controls implementing the forms and kicking off the workflows with custom layout pages to host the controls?
A site definition (just feature to add the pages+layouts at a pinch) to host the created pages "just so" in order to rely on "form1.aspx" being available always.
I would not try to "push" OOTB SharePoint functionality envelope to avoid creating custom code. Easier by far to
If you are going to do extensive workflow work in SharePoint be sure to consider buying an add-on like Nintex workflow or Blackpoint. It is almost always worth the expense over creating workflows with Visual Studio or SharePoint designer.
It's not easy to implement a solution for this in SharePoint, but we have a SharePoint App we're releasing in March 2014 which is a great capital expenditure workflow solution. http://budgetworkflow.com
We have had SharePoint where I work for a little while now, but we've not done a lot with it. We have an intranet with hundreds of ASP/ASP.Net applications and I'm wondering what kind of things can be done to integrate with SharePoint to make a more seamless environment? We put documentation and production move requests and so on in SharePoint now, but it pretty much feels like it's own separate system rather than an integrated tool on our intranet.
I've searched around to see what other people are doing with SharePoint but I've been finding a lot of useless information.
A great idea for you would be move your most used asp.net apps to run within the SharePoint site. Each app can be added either as a control directly on a pagelayout or integrated into a webpart (use the webpart to load child controls).
This would allow you to use the flexible moss interface to move the asp.net app into a unified information architecture so people can find the app easily.
SharePoint is really easy to roll out something that works, but creating a seamless intranet does require a bit of thinking outside of SharePoint itself (i.e. what should go where, which users need to see what, navigation structure...)
That is really a lot of work and requires lots of input from people outside the IT area.
A typical intranet portal segments functionality by department. Each department will probably have some custom web-based apps that you might have historically implemented in ASP.Net, and linked to from the intranet portal. With sharepoint you can start bringing the useful bits of those custom web-apps in as modular parts, so that the business owner of the portal can have more control as to how information is structured and displayed to his/her users.
Think dashboards, populated with custom metrics that only make sense to individual departments. That's one of the most obvious places to start. HR, accounting, IT, they all have metrics they want to track and display. They all have legacy systems that they might want to correlate information from. All this can be done in reusable web-parts. Since Sharepoint gives the end-user the control over layout, display, audience control, etc, you don't end up reinventing wheels all day.
SharePoint was designed to be a collaboration portal and document repository. If you have other business processes wrapped up in other internal web sites, you may not get much benefit from converting these sites into SharePoint sub-sites.
However, if there is signifcant overlap in your applications (contact lists, inventory, specs, etc.) you may want to make the investment to combine.
If you have InfoPath, you can create online forms. You can share your docs and edit them online. You can start an approvement workflow on these docs. You can create polls. You can create work groups.
Basically SharePoint is a giant and robust document store, but you can do anything what you can do in any ASP.NET web application. You can create e.g. custom workflows to automate business processes. We've worked for several customers to create corporate intranets and sometimes internet sites, so it really works. :)
But sometimes it's very hard to implement the requested features (a lot of workarounds).
Really its an intranet in a box. We pretty much run all of our day to day development tasks off of it. We keep documentation, track defects, manage people's time off etc. You can migrate your asp.net and asp applications to run under the sharepoint site. In the adminstration section you can set up web applications to run under the same site, but outside of sharepoint's control. That would probably help with the "feel" of it being completely seperate.
Sharepoint is really a shift in the way people have to think about web development and that's the key. You're no longer developing a standalone application, you're adding on to an existing framework. I would put it akin to having "silos of data" vs. a centralized database system which houses all the company's data. Once people realize that everything is connected, it will feel more like a seemless integration. My advice is to actively try and create applications in sharepoint and think about how to migrate existing apps on to it.
How about BI and reporting from an ERP?
When we know IE is uncapable to handle a page with 10000 table rows (without pagination)
Many don't realize but the success of a reporting tool depends on the performance of the grid object used - Excel and the SpreadSheet obj from the defunct Office Web Components are still the #1 in user's (accountants, managers, ceo) choice.
I think it depends on your environment. In our environment, we setup each department with their own pages and we use it for basic information, surveys, and the employee's homepage. We've built Google/Live Search and Weather.com widgets and roll RSS feeds using Tim Huer's RSS control.
One thing you can do is to create web parts to provide access to data from existing applications. Initially they could simply be read-only views, but depending on your experience they could be fleshed out to allow writes.
Another idea is to add links between SharePoint and your applications (assuming they're web based); that will at least allow a flow between them.
I haven't done it, but you could also theoretically skin SharePoint to look like the rest of your intranet.
Create libraries
Form libraries, documents libraries, slide libraries
Create standard or custom lists
Standard lists - announcements, tasks, contacts
Custom lists - suppliers, contractors, inventories, orders
Setup secure team discussion areas
Build shared team calendars
Create simple workflow processes on documents and lists