SharePoint 2010 is a rich and fully-featured software platform right out-of-the-box, ready to tackle any organization’s document management, workflow, and intranet-oriented tasks. Many organizations that I work with on a daily basis operate quite happily with a professionally-configured, out-of-the-box SharePoint Server routing documents, managing document history, and presenting users with basic business intelligence.
There are times, however, that software’s out-of-the-box capabilities only satisfy 80% of a given organization’s software needs. Consider the following scenarios, each one a fairly commonplace occurrence in the SharePoint consulting world:
An organization has been using an old ASP web site to track refunds for its products for the past twelve years. The customer service and accounting staff have become dependent on this old application’s ability to manage refunds in bulk by setting them all to “paid” with a single button click. While this software offers awesome list management capabilities, this client explicitly requires a toolbar at the top of the page to manage refund metadata in bulk.
An enterprise division wishes to use the SharePoint software as a hybrid CRM and document management system to keep track of projects, client relations, and gather all client-related documents in one place. It is certainly well-suited to this need, however, this organization will be creating dozens of new sites over the course of a given month. Creating sites from templates, then customizing them for each client has been deemed too time-consuming for this division’s office manager. They require a site where client information can be sourced from their existing SQL Servers or filled out using a form, then this information is used to create the structure and pages of the client site.
Both of these scenarios are challenging if not downright impractical to solve using UI-based, out-of-the-box configuration. Given the strict requirement for a button on the list page in the first scenario, it’s going to be downright impossible to implement without a custom Web Part. You might be able to programmatically create sites in the second scenario using workflows based around an InfoPath form, however, this is hardly the most elegant solution.
This is exactly where custom development comes into play. Web Parts can be dropped onto any Web Part Page in SharePoint 2010 to enable advanced list management, programmatic workflows, data integration, and even creating sites and collections! SharePoint consultants such as myself use Visual Studio 2010’s rich suite of SharePoint development features to quickly write and deploy these custom controls. I’ll be speaking to the beauty of Visual Studio and SharePoint integration in another article, but from a very high-level, take it from me: Developing custom Web Parts is a snap using Visual Studio 2010.
To conclude, this software is a product that offers a lot right out of the box, but offers a whole lot more when you couple it with some custom Web Parts and advanced configuration. And let’s face it: You deserve the solution that works for you. So if you really want to unleash the power of this software for your business, talk to a consultant and find out how we can customize SharePoint for you!