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 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).

Intro: Wes PrestonOwner / Principal Consultant – TrecStoneBased in Minneapolis, MN

Certification, etc.MVP – SharePoint Server (5 years)MCITP – SharePoint Administrator 2010MCTS – SharePoint 2010, ConfigurationMCTS – WSS 3.0 and MOSS Configuration

Contact:www.idubbs.com/blogwww.trecstone.com @idubbswes@trecstone.com

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 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.

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.

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

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.

Before the Build

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

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)?

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)

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

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 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

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 over time.

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.

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.

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

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.

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

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

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.

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

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.

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

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 change

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

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.

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.

References Content Types to Modify Fields Displayed in NewItem and EditItem Formshttp://sarahlhaase.wordpress.com/2011/03/21/using-content-types-to-modify-the-newform-aspx-and-editform-aspx-pages/

JS Link Primer – Blog Posthttp://www.idubbs.com/blog/2012/js-link-for-sharepoint-2013-web-partsa-quick-functional-primer/

Thank You