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


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Since a lot of you are probably developers, you may have noticed that I’m more on the non-development side of the world. My background includes development, but I’ve since transitioned to IT Pro and then to the business side – focusing on translating business needs to where solutions can be built in the SharePoint platform: from out of the box, to SharePoint Designer and the topics we’re talking about today, to .NET development and 3rd party options.
  • ‘hallway’ conversations may turn into requests… “Can you send me some of the new marketing material?” Which materials?How many?When do you need them by?Where do you want them delivered?A single request may turn into repeated requests – the person that is asked for help becomes the ‘go to’ person for that requestFullfilling requests may take more and more timeAs the person becomes known for that type of request, others also start making requests adding to the workloadA single person processing requests doesn’t make good business senseIs the process business critical?What happens when the person is out of the office or unavailable?
  • Just because there is a manual process doesn’t mean a list-based solution will provide measurable improvement
  • A SharePoint site request could live under a SharePoint team site, a SharePoint ‘platform’ site, within the intranet ‘proper’, or other locations…
  • So, we’ve got some work to do to make the user experience better.
  • Obviously more fields can be added to either as needed…
  • 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