Create Outlook forms to track support requests
So, you’re sitting in your weekly support team meeting, and the topic of the day is support request tracking. Like a dog chasing its tail, the conversation runs in circles around the same arguments:
- You need to do a better job of tracking support requests.
- You don’t have money to buy some expensive help-desk product.
- You don’t have time to build a really functional application.
- You really need to do a better job.
This week, though, you’ve been doing some reading over at TechRepublic, and you’re ready. “How about a custom Outlook solution?” you say, brightly. You suggest putting a Support Requests folder on your Exchange server’s Public Folders and publishing a custom form for everyone to use. Add some custom views, and Voila! You have a support-tracking solution that is effective, inexpensive, and available quickly.
As one would expect, you get the job of putting the new Support Request system together. Now what? Where do you start?
In this Daily Drill Down, I’ll introduce you to Outlook forms and show you how to build and deploy a folder-based Support Request system. Along the way, you’ll learn about using and customizing the standard forms that come with Outlook, creating your own data elements to track what you want to track, and making your custom form both attractive and useable. You’ll also learn about the various places your form can live and how to use a folder’s custom views to make the form even more useful. By the time you’re finished, Outlook Forms will no longer be a forgotten solution.
The first step is to decide what type of form you need, and to do that, you need to understand something about Outlook items, forms, and folders.
Every collection of data in Outlook is an item. A mail message, a contact, and an appointment are all considered items. Of course, they are not all the same type of item; their types are determined by the forms used to create them. The form name is stored in the Message Class field of the item in the format IPM.StandardFormName. For example, a contact based on the standard Contact form would have a message class of IPM.Contact.
When you build your custom form, you typically begin with one of the standard Outlook forms and then add the functionality you want. You also give your custom form its own name, which is tacked on the end of the regular form name. So, if you built a custom Contact form to track suppliers, you might name it IPM.Contact.Suppliers.
Once you use a form to create an item, the item has to be stored somewhere. That somewhere is in a folder. Every folder in Outlook can hold only one type of item—an important point to remember as you begin to plan. Why? Because each standard form contains built-in functionality, and you will want to match that functionality to the needs of your application.
In essence, an Outlook folder corresponds to a table in a database. Each item in the folder corresponds to a record, and the form is essentially the table definition, as it gives structure to the data stored in each item. Your first task, then, is to decide what type of data you want to store in your “table” (folder). Is it mainly information about people? Then start with a Contact form. Is it something you want to be able to e-mail to people? Then begin with the Message form.
Your second design task is to decide how the items are going to be created. Think about the people who will use the form. Can they all get to a common folder? If you are using Exchange, you can build a folder-based solution in Public Folders and simply have people post into that public folder. On the other hand, if some people are remote or if they don’t have access to Exchange, then you’ll need to build an e-mail-based solution.
For this sample solution, you’re going to build a folder-based Support Request system using a single shared folder and a single custom form. Since support requests are basically tasks, use the Task form as your starting point. To keep things simple (and so that anyone running Outlook can try this out without having to also use Exchange), put the folder in your Personal Folders on your own machine.
Make a new folder
Inside Outlook, show the Folder List by choosing View | Folder List. Right-click on Outlook Today and choose New Folder. In the dialog box, name the new folder Support Requests, set it to hold Task items, and place it directly under Outlook Today. When asked whether to add a shortcut for this folder to the Outlook bar, choose Yes.
Start the new form
To build a new form, choose Tools | Forms | Design A Form. In the dialog box, look in the Standard Forms Library, click on Task, and then click Details. You’ll notice that this form has a message class of IPM.Task, just as it should. Next, click Open.
The form then loads and goes into Design mode. Across the top of the form you’ll see a series of tabs. Each of these tabs is attached to a page that can be used as part of your form. The ones without parentheses around the names will be visible when the form is in use; the others will be hidden.
Select the (P. 2) tab to bring that page to the front. It is currently empty, but it is going to be our main page. Why (P. 2)? That’s because on most of the standard Outlook forms, you cannot modify the main page. So what we need to do is display the second page and hide the first page and the Details page.
With the second tab displayed, choose the menu item Form | Display This Page. Then choose Form | Rename Page and give the page a useful name like Support Request.
Next, select the first tab, Task. With Task selected, go to the menu item Form and deselect Display This Page. Do the same thing for the Details page. Now when the form runs, the only page displayed will be your custom page.
Mark the form as yours
The last three tabs on the form are All Fields, Properties, and Actions. Let’s add some data to the Properties tab.
If you plan on doing lots of Outlook Forms work, you’ll want to take the time to fill in all these fields (see Figure A). The Category and Sub-Category fields allow you to organize your forms by function. In addition, you can give each form a number for yet more organization and tracking and a version number. Of all these, I think the Version field is the most critical for troubleshooting, so it’s the one field I always fill in.
Moving down the page, there is a Contact field where you can enter the form designer’s name (that would be you) and Description field. To the right, you can choose a special icon to be used with your form (in two sizes), and you can protect the form design with a password so others can’t mess with your masterpiece.
Finally, there is the Send Form Definition With Item checkbox. Don’t use this unless you have to, as it can greatly increase both network traffic and the storage requirements of your items. It should only be used if the recipient of your item will not have access to the form library.
Publish the form
Once you have set all these fields as needed, you are ready to publish the form for the first time. But where? To have the form serve as the basis for many items, you have to publish it to a forms library. For this, you have three choices:
- Your own Personal Forms library—This library is inside your mailbox and is only accessible to you. You get to these custom forms by using the Choose Form command on the File menu.
- An Outlook folder—This can be a folder in your own Personal Folders (like the Support Request folder I made above) or a public folder in Exchange. The custom form will only be available when that particular folder is in use.
- The Organizational Forms library—These forms are available to everyone in the organization (using the Choose Form command) and are stored on the server.
For the purpose of this example, you’ll want all support requests to go into the Support Requests folder, so publish your form to the folder using Tools | Forms | Publish Form. From the drop-down menu, choose Outlook Folders and browse to the Support Request folder. Select it, click OK, and in the remaining dialog box, give your form a display name of Support Requests and a form name of SupReq. As you type, you’ll see that the form name is appended to the message class, resulting in IPM.Task.SupReq. Finally, click Publish.
Adding fields and functionality
Okay, you’ve got a form published, but what does it do? Nothing! To make your form usable, you must add controls and bind them to fields. To do this, use the Toolbox. Turn on the Toolbox (if it’s not already on) by clicking the toolbar button that looks like a hammer and wrench.
Now, stop. Yes, that’s right—don’t put a single control on that nice, blank form page until you first put a pencil to a nice, blank piece of paper. Make a list of the data elements you need, the data type for each, and whether the data element will be automatically calculated or manually entered. Also, give some thought to what type of control to use for each data element. Once you have thought through the data design on paper, you are ready to start implementing your design on the form.
Putting the controls in place is easy. Just choose the control you want from the Toolbox and then click on the form where you want to place the control. Once you’ve dropped the control on the form, you can drag it into place and resize it until your heart’s content. You can use the various commands under the Layout menu to align controls with one another, resize the controls to each other or to the grid, and lots of other timesaving actions. I won’t take the time now to go through these, but I suggest that as the last step in your design work, you check the Tab Order on your form. Nothing is more disconcerting than to have the focus jump throughout the form as you tab through it.
Once you add a control, you have to set a number of properties before it can actually do anything. Right-click the control and choose Properties. When you do, you’ll see three tabs in the Properties dialog box. Let’s look at each one.
The first tab is Display. Here, you can choose a name for the control (how it is referred to in code, if at all) and a caption (what the user will see, if anything). While you’re not going to be writing any code in this exercise, I still would advise using a standard naming convention for your controls’ names. For example, every text box should have a name beginning with txt. (For more information, search at msdn.Microsoft.com for naming conventions.) The other settings on the Display page are self-explanatory, so let’s move on to the Value tab.
The Value tab is where you bind the control to a data field. These data fields are what will show up in the columns of your various views. When you click the Choose Field button, you will see all the categories of existing fields in the location where you published your form. You can pick one of these to bind to, or you can click the New button and create your own. If you do, you’ll have to give the field a name, a data type, and a display format. (See why you should spend time with the pencil and paper first?)
For our Support Request form, I added the following controls and bound them as shown in Figure B below.
|This table shows the standard task fields.|
Figure C shows how the form looks when completed.
Figure D shows the form as it appears when being filled in with a support request.
You’ve created your folder, built your form, and published it to the folder. You’re all set, right? Not yet. There are still some steps to complete before you can use your solution.
First, you need to make your form the default form within the folder. Right-click on the Support Requests folder, choose Properties, and in the subsequent dialog box use the When Posting To This Folder drop-down menu to choose your Support Requests form. (You may need to browse to find it.) Now, whenever the folder is open and users click the New button on the toolbar, they will create a new item based on your custom form.
Next, you need to build some custom views. Again, before you start, it’s a good idea to take some time with pencil and paper and decide what sorting and filtering you want in your views. Building views is pretty simple; just choose View | Current View | Define Views, and in the dialog box either edit an existing view or choose Copy to use an existing view as the basis for a new view that you then customize (Figure E).
|Use Define Views to customize a view for your Support Request folder.|
One of the most important settings in this dialog box is at the bottom. If you check Only Show Views Created For This Folder, then users will only see your custom views, and not all the views available for Task folders, in the View menu and on the View drop-down menu.
For the Support Requests folder, I designed four custom views: a basic listing, a view grouped by priority, one grouped by status, and one grouped by type (See Figures F-I).
|Using custom views, you can see your support requests ordered by basic listing.|
|You can group your support requests by priority.|
|You can view support requests by status.|
|You can also group your support requests by type.|
To review, here are all the steps required to build a basic Outlook Forms solution that is located in a folder:
- Decide what type of standard Outlook form most closely fits your need.
- Create a folder either inside your local Personal Folders (if only you will use this) or in the Public Folders area (if others will also use it) that will hold the types of items you chose in step 1.
- Create a new form based on the standard form you have chosen. Display the pages you need and hide the regular pages. Set properties and publish the form to the appropriate location, giving it a new name as you do.
- Add controls to the form and bind them to either existing fields or to new fields you create.
- Set other properties of the controls as needed.
- Check the tab order of the form.
- Set the new custom form to be the default form for the folder.
- Define whatever custom views you wish in the folder.
That’s it! There’s a lot more you can add, including extending the functionality by using VB script or by setting up custom actions, but this is enough to get you started. Custom Outlook Forms solutions can often be the best bang for your buck out there. Give them a try!
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.