Real world advice resulting from building a lot of these things!When you first start customizing SharePoint to enhance its ability to support various business processes, just getting the correct tools selected and configured can be a challenge, learning how to build a system using the myriad of customization options available to SharePoint specialists is a steep learning curve indeed.
However, once you start getting a few projects under your belt, get used to both the features and the quirks of SharePoint and SharePoint designer, you can start to assess the overall approach to custom solutions and develop an approach that improves the efficiency and accuracy of the final solution you build.
That is what this blog post covers. These are lessons learned the hard way, having to deal with the challenge of major changes to the system late in the development cycle, having to redo work multiple times as the end user tests the system and applies it to their real world process, finding out that workflows that worked for your permission level are not working for the security groups you created on the site, finding out a single change to a field used on a list in your site is now causing an approval process to stall and multiple workflows to fail.
This post is, so far, the most efficient and effective approach we have developed for SharePoint customizations.* It includes real world examples of how each phase of the solution development approach are applied.
*SharePoint customizations are solutions developed using SharePoint Designer and SharePoint itself. SharePoint customizations do not include code based modifications made using Visual Studio.
Overall, the six phases for building custom SharePoint Solution are:
1. Data and security
2. Data views and hosting pages
4. Non-functional content.
6. Expose to end users
Data and Security
When creating SharePoint solutions you want to have the data components of the system, the lists, the libraries, any other data sources of the system as defined and complete as possible before moving on to the next phase. The reason for this is that these components are foundational, and any changes made to these components will cause cascading changes to the rest of your system. The changes may result in changes needed to your views, updates to the pages hosting the views and exposing the information to the end user, updates to workflows that used these components, and more.
As much as possible, we want to avoid going back and redoing completed work, so focussing on the data and security groups of your system first is key.
SharePoint data is saved in lists, loosely divided into two categories, lists and libraries. These are the elements of your solution that store the information you are processing, or inform the process. In simple systems, they may include a document library, two or three lists built using standard templates, and a custom list or two. In more complex systems they include multiple custom lists interrelated through lookups, views, and workflow logic. SharePoint security is what controls access and, to a lesser extent the functionality related to the data saved and used by the system.
Any SharePoint solution requires us to ask these three foundational questions:
1. Who is this for?
2. What information do they need?
3. What tools do they need?
Data and Security considers in detail the first two questions asked above and the implications they have within the system you are building.
Who is this for?
This is, quite simply, the most important question you can ask about your system. It doesn’t just define your security groups; it allows you to answer intelligently all of the next questions for configuring any SharePoint solution.
If your solution is a project support solution, then consider both who will be actively participating in the components of the solution (contributing documents and information to lists) and who will be simply consuming the information (project status pages, final versions of project documents made available to wider audiences, etc.). Define these groups; define the user type that will populate these groups.
If your system is a request based system, such as help desk requests, service requests, vacation requests, you will need to define the users of the system (the requestors), the groups involved in the processing of the requests in each phase, and the system power users who oversee and modify the system once it is exposed to the end user group.
This sub phase concludes with defining these groups this will allow us to understand and define the toolsets and data they will be interacting with.
What information do they need?
Now that we know who we are building this for, we can determine what information they need. This allows us to define and build the data storage elements.
In the case of a project support site, you know that one or more project managers are involved, as well as the team that is assigned tasks by the project manager. What information does the project manager need on the site? What information do the Business Analysts? What about technical people such as developers or reporting experts? Each one of these groups would want a different view of the task list used for the project, filtered by the task status and components that are assigned to them. What fields support these views?
They also need access to central project documents. The project manager and business analysts may work on project documents that supporting staff only have read access to, such as the project plan or specifications documents. Think about each group of users, what they are doing, and therefor what information they need. Think about categorizing the project documents so that it is easy to filter and create views that show only the documents each person is interested in. Technical documents describing in detail various components are not useful to all of the project team, so filter these for non-technical participants such as subject matter experts.
Consider all consumers of the information and what specific components of that information those users are interested in.
Request Processing Systems
Request processing systems typically have a number of phases. Each phase it typically associated with one or more SharePoint groups.
In a request processing system, the first group considered is the requesting group. While the request itself may simply be a link to a list form, supporting information such as FAQs, information to inform the request, word or other document type templates for filling out and attaching to the request. An outline of the request process and criteria for determining whether a request is successful or not are all pieces of information a requestor may be interested in.
The next phase of processing in a medium to more complex system is request review, where the incoming request are reviewed for completeness and filtered for duplicates and bad request. This is not a phase that determines whether a request would be filled; it exists to ensure the requests have all information necessary for assessment.
In the request review phase we have a group that needs to review those requests. What information would need to be included in the request to allow this review? Definitely a status to indicate review started, and review ended, also potentially a “assigned to” field to allow the assignment of reviews to specific reviewers to prevent duplicate work. What other field would they need to help review information and prevent duplicates? Requesting departments and request categories? Determine this information so that the appropriately filtered views can be developed in the next phase.
As the request is processed, it moves through multiple phases through different groups responsible for reviewing and approving their phase of the process. What information about the request does each of these groups need? The requests will be filtered on the appropriate phase, what other information do they need to complete their tasks? If the request is a vacation request, then one person may be responsible for ensuring enough vacation entitlement exists before passing the request along for final approval. What information would they need to inform this decision? Not only the days requested from the request, but some way to cross reference whether that specific requestor has enough vacation. This may mean other systems such as internal payroll systems can provide, through BCS and external content types, a read only view of the payroll system vacation component that just exposes the key information they need.
If you have built SharePoint solutions before you may also see a need for various fields hidden from end users used for processing, anything from a calculated field that determines the difference in days between two dates to a field dynamically generated by workflow that puts a link to a specific child list item in a parent list field.
Remember also the power users of the solutions you release who will have the ability to change specific information, such as list that are lookups for the central request list (lists of departments, cost centers, etc.) or list that otherwise inform the process, such as a list used by workflows for email body text. They also may be responsible for updating static content, such as information displayed within content editor web parts. And manage solution security. A carefully designed group of tools and information for the power user group means less administration on the system after release for us, the configuration experts.
The results of this analysis are detailed descriptions of each list and library needed, custom fields in the various lists and libraries, their type, purpose, and any other notes about the field. As you can see, the details of determining who is involved in each phase and what information they need can be a wide and large process. However, considering these factors up front, and detailing the resulting data needs from these factors leads to creating a robust data structure (lists and libraries) within SharePoint that can both strongly support your system and ensure you won’t need to do extensive reworking much later in the Solution development cycle.
This phase ends with creating the various data support structures that result from the analysis, the lists, libraries, and their custom fields on a site created for this purpose.
Now that we have fleshed out our data needs, and built the structures used to host that data, we need to consider how to present that information to our system users. That is what the next blog post covers, Data Views and Hosting Pages.