Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Build a
SharePoint Intake
/ Request List
WES PRESTON
PWR201
Session Abstract
Use core SharePoint capabilities (2010 or 2013) to build
a sample solution that manages requests and can ...
Intro: Wes Preston
Based in Minneapolis, MN
MVP – SharePoint Server (5 years)
MCITP – SharePoint Administrator 2010
MCTS –...
Agenda
Overview
Before the Build
Building the Solution
After the Build
Overview
What is ‘Intake’?
An ‘intake’ form is a generic name for a list of items that need to be
addressed by someone - a request ...
Examples
LOTS of examples out there – both generic and specific to your business
or organization:
SharePoint site request ...
Business Case
Which scenarios are good candidates for a SharePoint solution?
Why are we building this?
There needs to be a...
Scenario: Site Requests
The sample used in this presentation is a request for a new SharePoint
site.
The manager of the Sh...
Before the Build
Information Architecture
Where is the solution going to live?
◦ As part of an existing site?
◦ As a stand-alone site?
◦ As...
Metrics, ROI, User
Adoption
If you want to demonstrate improvement you need to:
◦ Determine what needs to be measured
◦ Ta...
Governance
Who owns the process? Who is responsible for what’s working and
what’s not working?
What are the Service Level ...
Requirements
How formal and detailed any requirements need to be is determined by
the standards of the organization, thoug...
The Build
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 ...
The List
New Item looks like this by
default… ->
For everyone…
Which is too much…
The List
And the default All Items view will look something like this:
Which is ok for starters but will get cluttered ove...
Forms
Crawl approach - Start with out of box (OOB) forms as just shown.
Walk approach – Use the Content Type method for ed...
Forms
Content Type approach uses all OOB and SharePoint Designer (SPD)
solutions to limit the fields that are displayed du...
Content Types
‘New Request’
- As seen by users when initial
request is made
◦ Title
◦ Description
◦ Site Type
◦ Site Owner...
Workflow
Create a simple SPD workflow that kicks off when a new item is created.
This changes the content type of the item...
Views
As with many solutions, views are key to smooth user experiences.
Creating views that are relevant to each role is c...
Views
Home page – Could be based on ‘recent requests’.
My Requests – This can get a bit dodgy when someone is making
reque...
Pages
Additional pages can be created as needed to fit specific content or
role-based requirements. In the site request co...
Pages - Instructions
Even with the simplest functionality, having some instruction is good for
the user experience and set...
Pages - SLA
Information about a Service Level Agreement doesn’t have to be very
long, just long enough to communicate the ...
Navigation
Navigation can be provided in whatever way is most beneficial to the
users, though it may be influenced by styl...
After the Build
Metrics and ROI
Now that the new system / process is in place:
◦ Re-measure the same metrics as before
◦ Report on the cha...
Continue to improve…
You will need to determine how far you want to go with the solution.
You can keep building more and m...
Quick Recap
This example shows just one possible solution to one possible scenario.
There are many tweaks and approaches t...
Try It Yourself!
Play with many of these
features in Office365
◦ http://office.microsoft.com
/en-us/business/compare-
offi...
References
Content Types to Modify Fields Displayed in NewItem and EditItem
Forms
http://sarahlhaase.wordpress.com/2011/03...
Thank You
2013 SharePoint Fest DC - Build a SharePoint Intake/Request List
Upcoming SlideShare
Loading in …5
×

of

2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 1 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 2 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 3 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 4 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 5 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 6 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 7 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 8 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 9 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 10 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 11 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 12 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 13 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 14 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 15 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 16 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 17 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 18 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 19 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 20 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 21 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 22 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 23 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 24 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 25 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 26 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 27 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 28 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 29 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 30 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 31 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 32 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 33 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 34 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 35 2013 SharePoint Fest DC - Build a SharePoint Intake/Request List Slide 36
Upcoming SlideShare
Intake Process Itpmo
Next
Download to read offline and view in fullscreen.

9 Likes

Share

Download to read offline

2013 SharePoint Fest DC - Build a SharePoint Intake/Request List

Download to read offline

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

2013 SharePoint Fest DC - Build a SharePoint Intake/Request List

  1. 1. Build a SharePoint Intake / Request List WES PRESTON PWR201
  2. 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. 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. 4. Agenda Overview Before the Build Building the Solution After the Build
  5. 5. Overview
  6. 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. 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. 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. 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. 10. Before the Build
  11. 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. 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. 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. 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. 15. The Build
  16. 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. 17. The List New Item looks like this by default… -> For everyone… Which is too much…
  18. 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. 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. 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. 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. 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. 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. 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
  25. 25. 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.
  26. 26. Pages - Instructions Even with the simplest functionality, having some instruction is good for the user experience and setting user expectations.
  27. 27. 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.
  28. 28. 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
  29. 29. After the Build
  30. 30. Metrics and ROI Now that the new system / process is in place: ◦ Re-measure the same metrics as before ◦ Report on the change
  31. 31. 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
  32. 32. 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.
  33. 33. 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.
  34. 34. 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/
  35. 35. Thank You
  • LisLeckeySwanson

    Sep. 1, 2020
  • ppicara

    Jul. 19, 2018
  • EddieWeir

    Mar. 31, 2018
  • edgarelizondo

    Nov. 1, 2017
  • MelissaDiaz48

    Jul. 19, 2016
  • AngeleenNicewander

    Jun. 20, 2016
  • FatimaAst

    Feb. 3, 2014
  • BuckBradberry

    Jan. 14, 2014
  • avisuj1

    Oct. 17, 2013

Views

Total views

14,986

On Slideshare

0

From embeds

0

Number of embeds

2,905

Actions

Downloads

189

Shares

0

Comments

0

Likes

9

×