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
Overall, the six phases for building custom SharePoint Solution
are:
1.
Data and security
2.
Data views and hosting pages
3.
Workflows
4.
Non-functional content.
5.
Testing
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.
Project Sites
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.
Requestors
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.
Request Review
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.
Request Processing
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.
Power Users
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.
Phase completion
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.
Next
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.
No comments:
Post a Comment