1. Build a
SharePoint Intake
/ Request List
WES PRESTON
PWR201

2. Session Abstract
Use core SharePoint capabilities (2010 or 2013) to build
a sample solution that manages requests and can be
extended to fit a variety of business use-cases: IT
Requests, site requests, Help Desk, marketing
materials, etc. Replace unmanaged, manual processes
currently used in most organizations with consistent
and measurable business processes. Start with a basic
SharePoint list, extend it with new columns to capture
business details and add role-specific capabilities, views
and simple workflow actions. See examples of using
content types, list permissions and simple SharePoint
Designer processes (NO InfoPath).

3. Intro: Wes Preston
Based in Minneapolis, MN
MVP – SharePoint Server (5 years)
MCITP – SharePoint Administrator 2010
MCTS – SharePoint 2010, Configuration
MCTS – WSS 3.0 and MOSS Configuration
www.idubbs.com/blog
www.trecstone.com
@idubbs
wes@trecstone.com

4. Agenda
Overview
Before the Build
Building the Solution
After the Build

5. Overview

6. What is ‘Intake’?
An ‘intake’ form is a generic name for a list of items that need to be
addressed by someone - a request for action of some type.
Challenges:
◦ When not formalized with a process, requests may be inconsistent or missing
information that requires additional time and effort to finalize
◦ Often these processes originate as un-official requests… when users get the
result they are looking for they come back - forming a habit
◦ The manual scenarios often rely on single individuals with little or no backup
or redundancy where list-based solutions can have more than one person
managing to the list.

7. Examples
LOTS of examples out there – both generic and specific to your business
or organization:
SharePoint site request – A good first example and useful as the
organization is ramping up on the platform
Project request – Business users requesting a new project be created /
started. Submitted to a PMO for assessment
Issue Tracking – Issues or defects need to be captured, catalogued,
delegated and resolved.
Onboarding / Off-boarding process – Lots of separate tasks associated
with these processes to be tracked, etc.

8. Business Case
Which scenarios are good candidates for a SharePoint solution?
Why are we building this?
There needs to be a good results-based reason to spend time developing a
solution – if not why spend the time…
Save time for users
◦ More defined process
◦ Set expectations
◦ Consistency
Save time for people managing requests
◦ Metrics on request volume, type, etc.
◦ Ability to prioritize and delegate
◦ Process captures all required data at time of request

9. Scenario: Site Requests
The sample used in this presentation is a request for a new SharePoint
site.
The manager of the SharePoint team wants to know how many requests
are being made over time. How many are coming in, what people or
teams are making the requests.
The person or team creating the sites needs to have a way of managing
the requests: Which are complete, who’s working on which site, how to
set up security, etc.
A standardized process will allow for management of the requests,
consistency and completeness of the requests, a way to communicate
the status of the request and reporting on requests.

10. Before the Build

11. Information Architecture
Where is the solution going to live?
◦ As part of an existing site?
◦ As a stand-alone site?
◦ As a sub web of another site?
What type of list should be used?
◦ Custom
◦ Tasks
◦ Issues

12. Metrics, ROI, User
Adoption
If you want to demonstrate improvement you need to:
◦ Determine what needs to be measured
◦ Take any measurements or create estimates while the existing process is still
in place
User Adoption:
◦ Talk about it NOW rather than trying to figure it out after a solution is built
◦ What can you build that users will be chomping at the bit to get access to?
◦ What is something new you can offer them (functionality)?

13. Governance
Who owns the process? Who is responsible for what’s working and
what’s not working?
What are the Service Level Agreements being made surrounding the
requests?
◦ How long will it take to create a site once it’s been requested (and/or
approved)
Communication:
◦ What email or other notices are sent out, to whom, at what stages, etc…
◦ What information can be found on the site (status updates, notes)

14. Requirements
How formal and detailed any requirements need to be is determined by
the standards of the organization, though some minimal expectations or
desires should be defined:
◦ What are the team managing the requests looking for?
◦ How to see my assignments
◦ Know who to contact with questions about the request
◦ Report on the volume of requests and activity
◦ What are users looking for?
◦ More feedback or access to the status of the request
◦ Who to contact with questions or updates

15. The Build

16. The List
Easiest and quickest way to get a list and form in place is to create a
consolidated list of all the fields that will be needed for all users.
◦ Name of site
◦ Description of site
◦ Site Type
◦ Site Owner
◦ Site Admin
◦ Assigned to - SharePoint Team member tasked with creating the site
◦ Notes – Notes for use by the resource creating the site
◦ Site Status – Status of the build/provision process
◦ Created Date – Tracks the date of the request

17. The List
New Item looks like this by
default… ->
For everyone…
Which is too much…

18. The List
And the default All Items view will look something like this:
Which is ok for starters but will get cluttered over time.

19. Forms
Crawl approach - Start with out of box (OOB) forms as just shown.
Walk approach – Use the Content Type method for editing the NewItem
experience for users.
Edit with SPD
◦ 2010 allows for code or design view editing
◦ 2013 allows for code editing (and may allow JS Link as well – TBD)
InfoPath can be used when necessary but require additional skill set.
Custom web forms can also be used when necessary, but will require
more effort and a different skills set.

20. Forms
Content Type approach uses all OOB and SharePoint Designer (SPD)
solutions to limit the fields that are displayed during the new item
creation and uses a SPD workflow to enable all fields to be displayed
once a new item is created.
Steps:
◦ Create a ‘new item’ and ‘display item’ content types
◦ Add a workflow to switch the content type upon item creation – transparent
to the user.
Steps for this approach are in a blog post by Sarah Haase
(see References) but is a little different when doing in 2013 on the
content type creation.

21. Content Types
‘New Request’
- As seen by users when initial
request is made
◦ Title
◦ Description
◦ Site Type
◦ Site Owner
◦ Site Admin
‘Display Request’
- As seen by the process
administrators
◦ Title
◦ Description
◦ Site Type
◦ Site Owner
◦ Site Admin
◦ Assigned To
◦ Notes
◦ Site Status

22. Workflow
Create a simple SPD workflow that kicks off when a new item is created.
This changes the content type of the item so that when the item is then
viewed (there can be a short lag here while the workflow does it’s
thing).
In this particular example I’m also setting the default value of the Status
field.

23. Views
As with many solutions, views are key to smooth user experiences.
Creating views that are relevant to each role is critical to good user
experience.
Depending on the scope of the solution, you may be able to achieve this
all on a single (Home) page, possibly including targeted content, or need
to create separate pages – ‘mini dashboards’.
Creating views using the ‘Me’ filter generally provides a lot of value

24. Views
Home page – Could be based on ‘recent requests’.
My Requests – This can get a bit dodgy when someone is making
requests for someone else.
Assigned to Me – For the team provisioning the sites to be able to
quickly see which requests have been assigned to them.
Unassigned – For the person delegating site provisioning to quickly see
which requests need to be assigned.
Not Complete – See an overview of the sites requested but not yet
competed. This could use some conditional formatting (JSLink) to
highlight requests getting older

26. Pages
Additional pages can be created as needed to fit specific content or
role-based requirements. In the site request context there really are
only two main users – the people requesting sites and the people
provisioning the sites.
For example:
◦ Documentation on how to use the request form (Wiki)
◦ SLA information (Wiki)
Note for 2010: Content can be added as a wiki or as a content page.

27. Pages - Instructions
Even with the simplest functionality, having some instruction is good for
the user experience and setting user expectations.

28. Pages - SLA
Information about a Service Level Agreement doesn’t have to be very
long, just long enough to communicate the expectations to users and
requesters.

29. Navigation
Navigation can be provided in whatever way is most beneficial to the
users, though it may be influenced by style guidelines of the
organization.
Options include:
◦ Promoted Links web part (NEW)
◦ A Links list and web part
◦ Quick Links bar (left side) and top navigation links

30. After the Build

31. Metrics and ROI
Now that the new system / process is in place:
◦ Re-measure the same metrics as before
◦ Report on the change

32. Continue to improve…
You will need to determine how far you want to go with the solution.
You can keep building more and more functionality to further automate,
better document, better communicate, better tailor to specific roles,
etc…
Typical / Suggested Improvements:
◦ Additional simple workflows
◦ Notifications
◦ Advanced SPD or .NET workflows
◦ Use Access Services for more complex data relationships
◦ InfoPath forms

33. Quick Recap
This example shows just one possible solution to one possible scenario.
There are many tweaks and approaches that can be used to do it
differently to suit each organizations needs.

34. Try It Yourself!
Play with many of these
features in Office365
◦ http://office.microsoft.com
/en-us/business/compare-
office-for-business-plans-
FX102918419.aspx
◦ I recommend the E1 plan
as a test platform – but you
need to Trial with
something else in the ‘E’
group. You get all the
Enterprise features.

35. References
Content Types to Modify Fields Displayed in NewItem and EditItem
Forms
http://sarahlhaase.wordpress.com/2011/03/21/using-content-types-to-
modify-the-newform-aspx-and-editform-aspx-pages/
JS Link Primer – Blog Post
http://www.idubbs.com/blog/2012/js-link-for-sharepoint-2013-web-
partsa-quick-functional-primer/

36. Thank You