Resolving service requests is very process oriented and follows a specific flow of actions. This defined process allows for consistency, ease of reporting, and follow-up activities when necessary. The following list is a high-level overview of the preferred flow of activities:

Visio to SharePoint Designer

Many times when you are designing a workflow it helps to visualize the actions, logic, and overall structure. One way to draw out that visualization is by designing UML (Unified Modeling Language) diagrams. Microsoft Visio can be used to create just such a diagram. If you were to model the service request workflow steps in Visio and flesh out additional actions, you would see a diagram similar to the following:

As you can see from this workflow diagram, the underlying logic can become very complex as the number of steps and actions increases. One powerful new feature in SharePoint 2010 is the ability to design and transfer workflow diagrams between Visio Premium 2010 and SharePoint Designer 2010. It is important to note that this capability is available only in Visio Premium 2010; the SharePoint Workflow template is not included in the Standard or Professional editions of Visio 2010.

Transferring a workflow between Visio and SharePoint Designer is powerful because it allows a nondeveloper user to mock up the workflow structure in Visio and export it to a .VWI file. This .VWI file can then be imported by a developer or power user into SharePoint Designer 2010 for additional work. The process of designing, exporting, and importing can occur as many times as necessary. It is also possible to perform a one-way export of a workflow from SharePoint Designer 2010 to Microsoft Visual Studio 2010 when you need to have access to more APIs and workflow options. This is a one-way export, however; you cannot export from Visual Studio to SharePoint Designer.

Note

The preceding diagram was created by importing into Visio the exported SharePoint Designer 2010 workflow that you will be designing later in this chapter. You will be shown how to perform this process after you implement the workflow.

You have already identified that the help desk solution is going to have a diverse set of users accessing similar data. Even though the data is similar, each group of users is concerned about different interpretations or views of the data. In this light, SharePoint audience targeting may make sense to implement. Audience targeting is not a security feature, so you should not rely on it for limiting access to specific user groups. Instead, audience targeting is a way to direct specific users to a defined view of the data.

In a high-level overview of your scenario, end users want to enter service requests and check the status of their requests. Help desk users are interested in detailed information about all service requests that are not yet resolved. IT managers are interested in process metrics and finding trends in those metrics.

To serve the various user types, you could go one of two ways. The first is to define multiple pages with individualized content and configurations. The other is to define one common page that has audience-targeted content. Because of the complexity and additional work required to configure audiences, this chapter will not make use of this approach, but it will describe aspects of it should you want to implement it.

Users make up one portion of the solution. Another portion relates to the data that is to be captured. The following list contains a number of the data types that will be required:

Your organization might require additional data to be captured. These data types should serve as a basis to build upon if necessary. You will be building these data types into the SharePoint site infrastructure by using out-of-the-box components.