1. Introduction
2. Benefits of going green with SharePoint
3. Knowledge Management – Going green
4. Go Green – Green Benefits of Content Management

Introduction
Organizations are constantly looking for ways to cut costs, but don’t realize that those cost cutting measures may also have positive environmental effects that can increase goodwill and shareholder value.

Microsoft SharePoint solutions provide tremendous return on investment, but also make your organization more environmentally conscious or “green” by cutting the consumption of paper. Many organizations around the world are utilizing IT solutions to realize their green initiatives. One such technology is Microsoft Office SharePoint 2007

For example: There are government-sponsored green initiatives currently underway. In 2003, the United Nations Economic Commission for Europe enacted a strategy to form a “Roadmap for Paperless Trade”.
(http://www.unece.org/cefact/publica/ece_trd_371e.pdf)

The commission discovered that by moving from paper document processes to electronic technologies, they increased security and transparency in supply chains (Trading industry) and provided both the business sector with higher revenues and costs savings.

Benefits of going green with SharePoint
Information and Communications Technologies are transforming our world on a daily basis. SharePoint enables organizations to control the creation, routing, approval, and publishing of documents. Many organizations use documents in paper format such as invoices, patient records, insurance forms, and corporate policies. These documents are typically copied and dispersed to wherever they are needed—often too many disparate locations. By converting these paper based documents and processes to electronic procedures, a single copy can be accessed electronically from any location without it being printed, shipped and then later archived or discarded.

Here is how you can calculate how much of environmental impact you have contributed and thereby saving how many trees?
By using SharePoint Content management solution, the savings realized by the company can be translated into positive effects on the environment.

How do you calculate?
1 tree makes 16.67 reams of copy paper or 8,333.3 sheets
1 ream (500 sheets) uses 6% of a tree

http://www.conservatree.com/learn/EnviroIssues/TreeStats.shtml

For the a Company which uses 2,000,000 pages, the number of trees saved are calculated as below:
Calculating Paper Saving’s
Total Pages 2,000,000
Reams of Paper (500 sheets/ream) 4,000
Number of Trees Saved (17 reams/tree) 235

Other benefits Using SharePoint

Real Estate
Not storing paper has two benefits regarding real estate – paper storage space and office space. This is space that would require energy consumption for heating, lighting, and humidity control. Beyond that there is also the impact on the environment of using the physical space as a warehouse as opposed to, say, a reserve forest or wetland.

Another example of the real estate impact of storing physical documents is the fact that a paper document is only available at a single location. By storing documents electronically, they can be access in multiple locations, even simultaneously.

Lifestyle Benefits
Putting documents online reduces the number of employees who are commuting to an office. This has tremendous impact on the environment, but also on employee lifestyle. Some organizations are beginning to assign lifestyle scores to projects. While analyzing return on investment and other facets of a project, organizations can assess the impact on employee lifestyle. Raising lifestyle benefits makes a company a more attractive employer and helps organizations with recruiting.

Technology Benefits
Organizations which use SharePoint solutions are also well-positioned to meet their business challenges as they now have a scalable and manageable technology platform which is hot-pluggable and that it can be integrated with other standards-based applications and tools. Since .Net Framework is compatible with SharePoint, SharePoint also gives you an opportunity to customize application which will help the user community to accept the cultural change.

Knowledge Management – Going green
“Going green” has become a topic of increased attention, but it’s nothing new to knowledge management. By its nature, knowledge management promotes efficiency and optimal use of resources, which often reduces the amount of energy required to achieve a given goal.

Knowledge Management (KM) awareness is creating new interest in KM solutions that can improve business performance while reducing environmental effects. Knowledge management using SharePoint plays an important role improving their energy management to optimize the use of office equipment and energy in buildings. SharePoint knowledge management solutions, including records management (RM) and enterprise content management (ECM), reduce the use of paper. In addition, online collaboration and online meeting solutions can greatly cut down on the need for travel to meetings.

In the past, larger companies were well positioned to make use of knowledge management solutions that transformed paper-based information into digital information because they could justify and afford the investment. Now, the small and medium-sized business (SMB) market has more choices, with the lower entry costs for software as a service (SaaS) products. SharePoint provides an option for SharePoint online hosting KM solutions.

Go Green – Green Benefits of Content Management
SharePoint offers so many opportunities to go Green, Top six ways to go Green with SharePoint:
1. Save money on paper – and reduce your environmental footprint at the same time.

2. Increase the effectiveness of core processes.
Think about the benefits of SharePoint technologies in just a single core process – finance. Driving paper from financial processes allows an accounts payable group to pay invoices faster, taking advantage of discounts for early payment. It allows an accounts receivable group to improve cash flows and reduce the number of days that sales are outstanding. The cost of processing an invoice can typically be cut by a factor of 10, creating savings that drop directly to the bottom line. These kinds of savings can usually be replicated in other paper intensive processes, yielding BOTH bottom line AND Green benefits.

3. Truly integrate your field operations.
The application of distributed capture technologies – using a scanner in a field office to process locally created paper and electronically store it in a central location within SharePoint. These scanned documents can be accessed from any location over the internet for immediate review. Distributed capture solutions often pay for themselves just through savings in courier and shipping costs. But taking courier and overnight services off the road also translates into significant direct environmental benefits.

4. By using SharePoint we can reduce real estate costs. Less paper means fewer filing cabinets means less real estate – which reduces cost, but also significantly reduces your environmental footprint.

5. SharePoint helps in improving employee productivity.
As a content management tool, SharePoint proves to be the best in the industry for the following:

Collaboration
Portal
Enterprise Search
Enterprise Content Management
Forms Driven Business Process
Business Intelligence

6. Reduce off-site storage costs. Off-site storage of paper is expensive, often requiring rental and maintenance fees as well as significant transportation costs to the facility. SharePoint provides a SaaS option for hosting the portlet.

In this article, I’m am going to introduce you to some of the features of Nintex Workflow 2007 (NW), and show you why I think this is a really cool product. I’ll also tell you about some of the annoyances I found.

Full Disclosure: Now, I’m trying to be as unbiased as I can and give you my honest opinion, but you should know that I was paid by Nintex for creating the USP Journal issue. No, they didn’t get any editorial control, but I was still paid. As such, feel free to hold a salt shaker ready and take what I say with an appropriate grain of salt.

Nintex Workflow in a Nutshell

Basically, Nintex is an easy to use workflow add-on to SharePoint. If you have worked with workflow in SharePoint before, chances are you have either worked with SharePoint Designer or Visual Studio. Both of these options are well suited for their intended use, but there is a big gap between SPD and VS that NW fills really well.

On one side, SharePoint Designer offers an incredibly easy and free way of adding simple workflows to a SharePoint site. Using a bit of creativity you can even create fairly complex solutions, using only the built-in actions and features. However, SharePoint Designer lacks scalability and flexibility, and re-use is at best very cumbersome.

On the other side is Visual Studio, which is like having your own thermo nuclear device. It’s incredibly powerful and you can more or less control at least parts of the world, but you had better know exactly what you are doing, or you risk your solution blowing up in your face. Where Visual Studio offers immense power, its learning curve is so steep, it can scare the most die-hard mountaineer.

Nintex Workflow bridges the gap between these two solutions, by giving end users some of the power of a Visual Studio solution while maintaining the ease of use and gentle learning curve of SharePoint Designer. In addition, NW includes some truly unique features, such as the ability to combine sequential and state-machine workflows and user interaction with tasks through email in a feature that deserves mention for its name alone: LazyApproval.

Authoring Workflows in Nintex

What initially sparked my interest for NW was the interface for designing workflows. The interface resembles the workflow designer in Visual Studio in that you get a visual overview of the ‘flow’ part of your workflow. Branching, loops, and state machines are presented in what I think is a really intuitive interface that makes it easy for end users to understand what is going on.

What makes this workflow designer especially friendly to end users is that it resides inside SharePoint itself. Using scripting and more fancy scripting than I’d dare to undertake, you are actually designing your entire workflow right inside SharePoint with no client software to install or learn at all. You simply drag-and-drop actions from the action menu onto the designer surface and configure each action using dialog boxes.

True, the interface of the Visual Studio workflow designer offers more options and allows for a greater degree of flexibility, but Visual Studio is still an all-or-nothing package; if you want the added flexibility, you also need to deal with the added complexity. That complexity is probably far more than any end users are prepared to handle.

Templates and Snippets

Another nice feature is the ability to easily create templates of existing workflows. You can create the generic templates for common tasks such as approval or customer follow-up and then re-use the templates when creating new workflows. This saves a lot of time if you are creating similar workflows or have common tasks used by several units in an organization.

Another option for workflow re-use is snippets. A snippet is basically a set of workflow actions stored as a single action. You create these snippets in the workflow designer, and they become part of your available actions for use in any workflow. For example, you might create a snippet to notify an item or document owner about changes to that item or document. Whenever you want to include that functionality in your workflow, you simply drag the entire snippet onto the workflow designer, and you get that functionality added without having to re-create all the individual actions.

Go with the Flow

If there is one thing I really miss, especially in SharePoint Designer workflows, it is better debugging and tracking of what is going on. A common approach is to add a lot of history logging to track what the workflow is doing. In Visual Studio, you can attach the debugger and step through the entire workflow, which is really nice and gives developers extreme control.

While NW lacks the stepping option, it does offer a very nice workflow information page far superior to the default workflow status page of SharePoint. On that workflow information page, you get a visual representation of your workflow, including which actions and branches are currently executing.

This workflow information page can also give you a detailed view where you can get a whole boatload of more information about the workflow execution, including how long each action takes, the outcome of conditions, who approves or disapproves which actions, and a range of other information.

The workflow information provided by NW goes a long way towards providing the debugging information you need to figure out workflow bottlenecks, logical errors, and other problems you may encounter.

State of the Machine

The final thing I want to point out as truly unique in NW is the support for state machines. You may wonder what is so special about supporting state machines, after all, most workflow products support state machines in some fashion.

What is really nice in NW, though, is that a state machine is simply an action, just like any other multi-branch action. This means you can combine state machines with sequential workflows inside the same workflow. For example, you may have a long running customer follow-up process, in which one part of the workflow consists of contract negotiations. That contract negotiation may move back and forth between different states, but is still only part of a longer workflow in which the ultimate goal is to make the customer happy.

In NW, you can simply add a state machine action and configure that action as you would if you had developed a stand-alone state machine workflow. Then, after that part of the workflow completes, you can continue in a sequential workflow, or even transition into a new state machine inside the same workflow.

OK, So What’s the Catch?

Alright, I’ve said enough about the cool things, so it makes sense to point out some of the weaknesses as well. Note that most of these issues are annoyances at worst.

First, the interface for controlling configuration scopes leave a lot to be desired. Basically, you can configure settings for sites and site collections, and the scopes control inheritance and all that, but the way that Nintex has solved the interface is not good. You need to pay attention to small pieces of texts on the page to know whether you are configuring for a site or for the entire site collection.

Second, NW supports setting up holidays to avoid workflow activities while no one is available to respond to tasks or interact with the workflow. However, the way the holidays are configured could have been done so much better. You can only add one day at a time, so if you are closing the office for two weeks during summer you need to add each day of those weeks individually. Really sad for schools with months of vacation at a time.

Third, the workflow designer can become cluttered when you are creating complex workflows, especially when using multiple branches. The branches keep expanding horizontally and will eventually fill any screen size if you have enough branches. And frankly, ‘enough’ branches is too low a number for example in state machines with many states. The same applies to the workflow information; to get an overview, you need to do a lot of scrolling. A “zoom out” function would be useful.

None of these issues are deal-breakers, though. It feels to me like they have gone 95% of the way towards making a perfect workflow solution, but with a product like this, the last 5% can be annoying.

And still, their 95% are still light-years ahead of anything else I have seen in this niche.

Want to Learn More?

The state machine image above is an example from the USP Journal I mentioned in the beginning of this article. In that issue, you’ll learn how to develop workflows in Nintex Workflow. The image shows part of a “get well card” that you’ll develop during the exercises in the issue. I’ll show you how to install and configure NW, familiarize you with the Workflow Designer, teach you at least some of the actions available, as well as explain the logic of how various tasks are done, such as the above example of inline state machines.

You can get the 128-page issue from the issue download page, and as I said, it’s free, as in beer.

.b

Welcome to edition 7 of this seemingly never-ending tribute to the humble annual leave (vacation) form. This is getting to be like the “Friday the 13th” series of movies – they never stop!

First up, I want to categorically state that, as a heterosexual Australian male, I have a few stereotypical personality traits . I enjoy beer, kung-fu movies, Burger Rings, Vegemite and Tim-Tams, love the cricket (especially playing India) and most importantly of all, I do not read instructions. Period. I think that ignoring the RTFM rule is a characteristic of all of humanity but Australians in particular seem to celebrate this trait as something endearing.

Therefore, it pains me greatly to have to inform you that this seventh edition of the series is one of those posts where you have to put on the brakes and explain some really boring conceptual stuff to proceed with the rest of the series. Yeah, I know – theory is boring and sucky and you just wanna get into the nuts and bolts of it all. But, as Homer demonstrates below, sometimes we have to defy our genetic programming and actually read the instructions. The alternative is a SharePoint solution equivalent to that of Homers BBQ.

This post will deal with some of the mechanics of form submission and form publishing.

What has gone before…

The first few posts in this series are starting to get hazy – it seems so long ago now. To sum it all up in a nutshell, we introduced the leave form as a means to introduce a lot of key SharePoint features in an easy to understand and relevant way. We set several requirements that we had to achieve.

When I started this series of articles, I knew it would be quite a few parts and ambitious in its way. But after reading some of the other great articles on SharePoint Magazine, such as Bjørn Furuknap’s first article on customising the user experience, I’m now feeling like I picked the easiest topic of all!

Seriously, Bjørn, part 1 of your series is the closest experience I can imagine to any man giving birth! I bet you feel relieved getting that one out of your system!

So, do I feel guilty that my subject matter is easier? Am I suffering nerdiness envy?

Hell, no! I’ll stick to my fantasy world of user acceptance testing with Homer Simpson any day!

Previously…

Given that there are big time gaps in getting these articles out, I’d just like to reiterate that this series is pitched at a very wide audience, so hard-core nerds will probably find it waffly and frustrating. But then again, most regular people find hard core nerds waffly and frustrating .

I have been writing this series from the point of view of a frustrated implementation developer/engineer who has to deal with a clueless business development manager and a difficult customer. This, of course, is completely unfamiliar territory for all implementation developer/engineers because none of you reading this would have ever experienced such a situation, right? … hehe

Part one of this series introduced some background and provided the requirements for the leave application/approval process for the Springfield nuclear power plant. Those requirements were:

Parts two to four were really the “slick presales demo” parts of this series where the world is promised to the client and, hence, expectations were completely off the planet. Thus, we started out nice and easy in part two and three, where we introduced InfoPath 2007 and went through the exercise of importing the existing Springfield MSWord based form. We then added some data entry controls and tidied up the formatting. In part four, we published this form to SharePoint itself.

All in all, the first four articles covered some pretty straightforward stuff. Now, however, the salesman has moved on and our intrepid engineer is starting to get into the pointy end of things. In part five we delved into the scary world of web services and InfoPath data connections so satisfy the requirement of automatic identification of the requestor. That was a bit of a jump, wasn’t it?

This time around, let’s take care of the “reduce data entry” requirement, and leverage some of InfoPath’s useful features to make our form smarter. For those who found article 5 a bit heavy, this one is actually quite a bit easier (but it’s just a brief lull before we get to coding!). At the end of part 5 I said I’d deal with how to automagically handle the employee number – but I have decided to take care of that a little later.

Preventing a rift in the space-time continuum

Yeah, I know I was using the Simpsons theme for this series, but today I am dropping in a dash of Heroes.

First up, we need to add some logic to the form so that it doesn’t submit crap (that’s the technical term for “invalid”) information. For example, we want to make sure that you cannot return to work on a date *before* you leave – unless you’re Hiro Nakamura, of course.

Generally, for the rest of us who cannot bend time, you do actually come back to work at some point *after* you leave, so let’s make the necessary changes to ensure that our form does not destroy the world in some space-time vortex.

Today we are interested in the three date/time fields as shown below.

If you recall in part three where we created the form controls, we gave them the meaningful names of CommenceDate, CompletionDate, ReturnDate.

For reference, at any time, you can review your field names easily by clicking the “Data Source” link in the InfoPath design pane as shown below.

So, we have these three date fields and the rules are:

• The completion date cannot be *before* the commencement date.
• The return to work date cannot be *before* the completion date.

When you think about what we are doing here, we are validating data to make sure that it matches our business rules. Fortunately for us, InfoPath has some nice capabilities here to assist. Even better, they called it “Data Validation”. So, let’s take a closer look…

• Select the “Completion Date” control, right click and choose “Data Validation”

You are presented with a fairly unexciting text box asking you to add a condition that determines whether the value entered is valid. Clicking the “Add…” button displays the dialog box to add a condition. It is quite common to have multiple conditions that need to be satisfied in order for the data entered to be considered valid.

In our case, we wish to ensure that the CompletionDate field cannot contain a value that is less than the CommenceDate field. Create this condition by specifying “less than” from the middle drop down box, and then picking the “CommenceDate” field for the third dropdown box.

Clicking OK and we have our completed validation condition!

One final OK and we are back at our form and ready to test this. Rather than publish the form to SharePoint now, we can make use of InfoPath’s “Preview” button on the toolbar and test it out. Below I have an example preview where Homer has been identified as per the previous post. Additionally, I have used the date picker to specify the commencement date (October 25 2008) of leave.

What do you now see on the Completion Date field? What’s with that red asterix? Maybe I should hover my mouse over it and take a look, eh?

Aww… How sweet! A tooltip that matches the description I gave for this data validation condition. Well, what do you know? I spelt data instead of date (don’t worry I’ll fix it up later).

So, let’s try and defy time, then. I will enter October 24th as my return date. Doesn’t seem vary happy does it?

But if I change the date to the 25th of October (therefore validating the rule we set up), InfoPath happily accepts the value.

That it? That was easy!

Yeah, it was very easy so what are you complaining about? Easy is good and there should be more of it!

We now need to do the same thing for the “Return to Work” form field. Essentially, we perform the very same steps and thankfully for the both of us, I am not going to smother you with screenshots. This is where you try it yourself and instead I will simply list the steps and one screenshot.

1. Right click the ReturnDate field and choose Data Validation
2. Add a new validation condition where the ReturnDate is less than the CompletionDate
3. Add a tooltip text “Return date cannot be before the completion date”
4. Click OK twice and test using the preview button

The published experience

Now that we have successfully tested the validation rules for the date fields, let’s publish the form to SharePoint and see what it all looks like. I followed the exact publishing steps that I outlined in part 4, so please refer to that article if you need a recap.

I navigated to the forms library as described in part 4 and created a new form.

I then deliberately entered bad data into the form and sure enough, the data validation rules picked up on the issue. Excellent – Waylon Smithers is very pleased!

Reviewing our progress…

So, since we are about to see off part 6, our Project Manager wants to get a status update on how the Springfield leave form project is progressing. So, after 6 articles, what have we achieved? To remind you, the requirements were:

Identification of Homer is now sorted, and we have taken steps both in the areas of reducing data entry and validating the dates (excluding days absent). So, we are tracking nicely and haven’t fallen behind schedule just yet .

Before we continue with addressing all of these requirements, we will have to take a bit of a detour as I explain below.

Too good to be true?

Here’s a little experiment for you to try. On the above form, published in its current form with deliberately invalid dates (highlighted in red), you will see a toolbar that has a “Save”, “Save As”, “Close” and “Print View” on it. I clicked the Save As button and was dutifully prompted for a filename. I called the form “Homer’s Test Form” as shown below and clicked Save

I then closed the form and checked out the form library on the http://radioactivenet site. What the…! It saved it! What’s the point of data validation if you can just save the form anyway?

The answer to that question, my friends, is there is a difference between saving a form and submitting a form. But you will have to wait for part 7 of this series for that riveting discussion!

Thanks for reading

Paul Culmsee

www.cleverworkarounds.com

www.sevensigma.com.au

Wondering what the hell I am talking about? Perhaps you’d better read part 4.

This post represents a change of tack. the first four articles were written from the point of view of demonstrating InfoPath in a pre-sales capacity. Your “business development managers”, which is a politically correct term for “steak-knife salesmen”, have promised the clients that InfoPath is so good that it can also make your coffee too. Essentially, anything to make the sale and earn their commission. Of course, they don’t have to stick around to actually implement it. They have moved off onto their next victim, and you are left to satisfy the lofty expectations.

Now, we switch into “implementation engineer” mode where a proof of concept trial has been agreed to. At this point we are dealing with three client stakeholders. Monty Burns (project sponsor), Waylon Smithers (process owner) and Homer Simpson (user reference group).

To remind you about parts one to four, we introduced the leave form requirements, and demonstrated how quick and easy it is to create a web based InfoPath form and publish it into SharePoint with no programming whatsoever. Was it a realistic demo? Of course not! But we have sold the client the dream and now we have to turn that dream into reality!

Here are the original requirements.

Crap, there is probably going to be a dozen or so articles and I’m running out of jokes already?

But then I suddenly remembered that in this certification obsessed IT world we live in, I could make up my very own certification! I mean how hard can it be? Just add the word “institute” to your name and your legitimate right?

Therefore I am pleased to unveil the first of a series of certifications to be offered by the CleverWorkarounds Institute and its associated body of knowledge (CIBOK). The CCLFD or CleverWorkarounds Certified Leave Form Developer certification, which allows certified practitioners the opportunity to feel vastly superior to the mere mortals they work with. Additionally, it has waaaay more bragging rights than one of those weenie certifications like MSCE or CISSP. Of course, like all acronyms to add to your business card, you are certainly guaranteed a big, fat pay rise.

So what someone wants to validate your credentials, you just flash the badge below and they will all be like…”wow, this dude is a business process god!”

SharePoint Pre-Requisites

Right enough banter and back to business! Now remember, we are in “Business Development Manager” mode in this post and therefore we are trying to impress here. Selling the client the message that the you will solve all organisational process issues (and find the answer to world peace) in InfoPath and Forms Services. So far, we have fairly quickly produced a usable InfoPath form. All in all it has taken maybe 10-15 minutes of demo time. So in the interests of “impress the client at all costs”, we have done enough to publish it straight into SharePoint, so that it is usable via a web browser.

That CCLFD certification is looking good yes?

So first up, we need a SharePoint site to publish the site to. But not just *any* SharePoint server. It needs to be running the enterprise licence if you wish to use InfoPath Forms Services.  So sorry stingy people, WSS and Office SharePoint Server 2007 Standard Edition will not suffice.

Now if this were a demo, I would have already had this set-up in advance to make the client “ohhh”, “aaah”, “wooow” louder. But I think it is worth examining the prerequisites in more detail.

Assuming that the SharePoint farm been built and a web application has been created (called http://radioactivenet), it is time to create a brand new site collection to host this form. The SharePoint farm administrator performs this task in Central Administration -> Application Management. In this example, we are creating a completely blank SharePoint site.

Have we done enough to publish our form to SharePoint? Unfortunately, not quite. In fact if we tried to publish our leave form into the site as it is now, we would have a little warning message that easy to overlook and then cause you no end of wasted time.

But I am getting ahead of myself. Having created this new site collection above, we now need to enable the enterprise feature-set that includes the forms services component that we need. For the purposes of this post, I will not be explaining the SharePoint feature framework, but for the uninitiated, SharePoint is like a fisher-price toy with lots of buttons that have different effects when pushed. (We haven’t yet pushed the right button). Think about SharePoint site templates (e.g Document Workspace, Wiki Site) as automatically pressing the buttons for you.

To activate the enterprise featureset, we log into http://radioactivenet as an administrator or site collection administrator. Choose the “Site Actions” drop down menu below the search box. Choose “Site Settings” and you will be taken to the administrative back-end of a SharePoint site collection. I have highlighted the option to control site collection features. (Click to zoom)

This screen shows you all of the nice buttons to push. The one that we need for this demonstration is the “Office SharePoint Server Enterprise Site Collection Features”. Simply the click “Activate” and you are done!

Finally, let’s publish it already!

To remind you all of where we got to at part 3, we have a functional form looking like this. (Click to expand)

Publishing an InfoPath form into SharePoint is based on a Wizard. We want to impress here, so we will do a straightforward form publication. Start the wizard by choosing “Publish” from the “File menu”. The first wizard screen will ask you *where* you wish to publish to. Obviously we go with the default answer of SharePoint

Next we are asked to specify which SharePoint site we would like to deploy this new form to. We are using our newly created http://radioactivenet site.

Now we hit the first important step in the whole process. This is the step where InfoPath publishing wizard asks you to how to publish this form. While I am not going to explain each option in detail at this stage, I will warn you now that we are going to come back to this screen in subsequent posts.

Notice how “Enable this form to be filled out by using a browser” is checked? This is because this InfoPath form that we created has been set to be “browser compatible” way back in part 2 when we first created the form template.

The first and default choice is to create the form in a SharePoint Document Library. Thus in the SharePoint world, InfoPath forms are just another type of library storage. therefore you can can use version history, recycle bin and all of the other goodies that come with SharePoint document libraries. Now I should make it clear though, that SharePoint creates a special type of library called a “Form Library”, designed specifically for InfoPath forms. So we leave “Document Library” chosen as the default and click continue on.

Having chosen to use a document library we are now asked to create a new one or choose an existing library. In our case, we have not yet created the library to hold the leave form, so we choose to “Create a new document library” and then enter it’s name and description into the follow-up dialog box. This will create a form library called “Leave Forms” for us as part of the publishing process.

The next step is another important one. But in the interests of our “impress the client at all costs” focus, we are going to leave it until the next post. So we click Next to continue.

That’s it for the publishing process! Clicking the Publish button will commence the process. InfoPath will create the form library and when it finished provide us with a summary of what has been performed as shown below. You can see the name of the library where the form was published (“Leave Forms”), the URL of the SharePoint site (http://radioactivenet/leave forms) and the fast that Infopath Forms services is running on the server.

The new form library

So, are we ready to “wow” the client yet? Almost!

Looking at the http://radioactivenet site, we can now see that we have a new content item in the navigation. Well what do you know? It’s a leave form library!!

If you navigate to this document library, you will see that it pretty much looks like any other SharePoint document library. Clicking the New drop down in the document library though shows that something is subtly different with this library. The document type to create has the InfoPath symbol on it. This library knows that it is here to store InfoPath forms.

But there is one minor catch. By default, SharePoint assumes that if you have InfoPath installed on your PC, then you will always prefer to use InfoPath in preference to a more limited, somewhat “clunkier” web based version. In our case, we want the form to show up in a browser, irrespective or whether InfoPath is installed on you PC. So let’s do that now.

In the new Leave Forms library, we choose “Form Library Settings” from the “Settings” drop down menu as shown below.

Now remember how I said that a forms library is a document library geared especially to host InfoPath forms? Well, now you get to see why. One of the configuration options unique to a forms library is whether to display a form in a browser or using InfoPath. The option controlling this can be found in “Advanced Settings” as highlighted below. The third option under advanced settings controls the behaviour for “browser enabled” documents. Note that the default option is to “Open in the client application”.

So let’s change this to “Display as a web page” and click OK. Also note the second option, “Document Template”. We will be talking about this a subsequent post as well.

The big test!

So, all is now in place and it is time to demonstrate the functionality to your eager and excited clients. Go back to the home page of http://radioactivenet and choose “Leave Forms” from the navigation bar. In the document library view, choose “New Document” from the “New” drop down.

Wohoo! The form renders in the browser! (and the crowd goes wild! )

Conclusion

So there you go, in something like 20-25 minutes, you have created and published a web based form that started life as a MSWord template. Highlighting how long this world have taken to be custom developed, your client is already writing a cheque and wants you to do this with all of their internal forms right???

Whatsmore, we haven’t even gotten to the unbridled joy that is a workflow yet! Oh man if the client likes forms services, they ain’t seen nothin’ yet right???

Well, to be honest, this form really isn’t that smart yet is it? Before we even get to workflow considerations, the form still isn’t *that* friendly and we haven’t yet satisfied several of the requirements outlined in part 1. Remember that we had to provide:

It never fails to happen.  Your company invests in SharePoint, takes time to define business processes and automate them using workflow (with a dash of InfoPath, perhaps), tests the solution to within an inch of its life and finally launches in production.  Two days later, it comes to a screeching halt because the user community isn’t completing system-assigned tasks.  Business processes don’t run to completion, KPIs are flashing amber and red.  Someone has just got around to blaming the problem on global warming …

Of course, failing to complete tasks won’t normally cause that much trouble.  It’s just plain inefficient, even in a simple scenario where a department manager manually creates tasks in a WSS task list.  The manager shouldn’t have to remember to look at an “incomplete tasks view” to find out which department members have overdue tasks.

Users always have plenty of excuses:

• “I can’t find the task.”
• “I didn’t know I was assigned a task.”
• “The dog ate my task.”

This a common business problem and we can solve it.

Companies often turn to some kind of automated reminder system to prod End Users into marking their tasks complete, thereby allowing those beautifuly orchestrated business processes to proceed as designed.  This article describes how “Power” End Users and Developers alike can use SharePoint Designer to create an automated task reminder system based on SharePoint’s core workflow capability.  This solution applies equally well to Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server (MOSS).  The article starts off with a little theory and then moves into a painstakingly detailed and lovingly created walk-through describing exactly how to create this workflow solution.   After the walk-through, it describes some important limitations, some technical implications and finally, suggests some useful extensions.

First, the business requirement:

• A task has been assigned to a user.
• The system should send an email to the user every 24 hours until the user has completed the task.

It doesn’t get much more straight-forward than that.

We will use SharePoint Designer to create a workflow solution that meets that requirement.  The solution leverages several SharePoint features:

• Windows Workflow Foundation.
• SharePoint Designer (of course).
• SharePoint workflow’s remorseless nature.

“Remorseless nature” means that a functioning SharePoint environment continues running a given workflow forever unless one of two things happens:

1. The task is deleted.
2. The workflow decides on its own to quit.

Before we fire up SharePoint Designer, we need to consider the workflow’s design:

This looping workflow has one choice to make among three options each time iterates:

1. Is the task complete? If yes, quit. Yeah, we’re done!
2. Is this the first time I’m sending a reminder? If yes, send a reminder and pause one day. Set a flag to indicate that the first reminder has been sent.
3. Is the second or more time I’m sending a reminder? If yes, send it and pause one day. Increment a counter to indicate how many reminders have been sent.

(Developer readers here may be thinking to themselves that these seem a lot like states and/or state transitions.  You’d be correct to think that.)

Pre-Configuration

To support a design like this, we need to add two columns to our task:

1. FirstEmailReminderSent
2. EmailReminderCount

The workflow uses these fields to maintain some information about the task (e.g. was an email reminder sent) as well as to trigger the workflow to run again for subsequent reminders.

These two columns, added via the task list’s settings, look like this:

It’s important to set the default value of FirstEmailReminderSent to “No”.

EmailReminderCount is simply an number with default value of zero.

Walk-through

With this configuration work complete, let’s see all of this in action by creating a workflow.  Firing up SharePoint Designer, we create the workflow in the normal way (i.e. open up the site with the task list, create new SharePoint content, create a workflow).  It looks like this:

The workflow has been named “Daily Reminder,” it’s associated with a list called “Tasks” (i.e. the task list) and here is the key: It’s set to run both when the task is created and when it’s changed.  The “whenever an item is changed” bit is very important, as we’ll see later.  This setting enable us to leverage SharePoint’s remorseless nature to our benefit.

The first step of the workflow is easy: Stop running if the task has been completed:

The second step is more interesting.  This step, labeled “Send Initial Email,” obviously sends the first email.  However, it also sets up the subsequent reminder.  Let’s see how that works:

Note that this task only runs if our task column, “FirstEmailReminderSent” is equal to No.  Since we were careful to specify “no” as this column’s default value, we know this step will run (provided that we got past the first step above).

First, we send the reminder email.

Then, we set FirstEmailReminderSent to Yes.  This ensures that this particular step never runs again.

Next, we pause for one day.

Once our pause completes, we want to start looping.  We do this by “poking” the task by changing any field of the current item.  When we do this, from SharePoint workflow’s  perspective, the item has been changed.  Since we checked “Automatically start this workflow when an item is changed,” it starts the workflow all over again.   We could pick any field but since we need to “poke” the current item, we may as well derive some business value at the same time.  We’ll use the EmailReminderCount field.  This way, we can poke it and know how many times the reminder has been sent, killing two birds with one stone.  The next series of screen shots show how to increment that counter.

First, we create a workflow variable as shown:

Copy the current value of EmailReminderCount to our TemporaryCounter variable using the “Set Workflow Variable” action:

Use the “Do Calculation” action to increment this by one.

Finally, update the Task’s EmailReminderCount using the “Update Field in Current Item” action.

The third and final step looks very similar to the previous:

This step only runs if the task was not marked as completed and if the first email reminder has already been sent.

Workflow pauses for a day and then increments the EmailReminderCount by one.  Performing this update causes the workflow to start over again.  Assuming the user never marked the task as complete, SharePoint workflow skips the first steps (since task is not completed) and the second step (since FirstEmailReminderSent is still Yes), landing back here on the third step.  It sends the email and pauses 24 hours, pokes itself and keeps looping like this, forever, until the task is completed or it’s deleted.

The following series of screenshots capture a test environment where the pause has been set to a short time interval:

In the above screen shot, the system has sent three reminders and is still waiting for the workflow to be completed.

Here is the initial workflow history:

Here is how the task is marked complete:

Here is the final workflow history:

Limitations

SharePoint Designer workflow is … limited.  There are several important limitations, but one of the most important for most users to understand is that these workflow solutions cannot be easily ported from one environment to another.  In fact, they cannot be easily ported anywhere, period.  There are clever workarounds to this problem, but that’s for a future article. (Hint -edit the XOML file directly, replacing task, list and other GUIDs manually).

Second, the workflow history is a bit garbled.  Conceptually, this is just one happy workflow.  However, at a machine/SharePoint level, we really have multiple instances of the same workflow.  This isn’t a problem for SharePoint, but it does sew confusion in a reporting sense.  As the final workflow history screen shows, even though we humans think just one workflow actually ran for this task (the Daily Reminder workflow), SharePoint shows five separate histories.  In our reminder scenario, this really isn’t a problem.  Each workflow history represents one email reminder.  However, if we had extensive logging and other complicated activities taking place, it would be hard to decipher the history and required a lot of clicking.  There is a clever solution to this problem as well, again for a future article.  (Hint – create entries in a custom list using a common key field to group them together).

Finally, it is important to realize that WSS and MOSS service pack 1 introduced a security feature that prevents a system administration account from starting any workflow automatically (though this was recently amended with the 07/15/08 infrastructure update).  If you’re testing this out in your environment and nothing seems to be happening, log in to the system as a non-admin account:

State Machines in SharePoint Designer?  Looping?  Preposterous!

As hinted at early on, this solution actually defines a state machine.  It uses the task itself as a persistent store for state data.  This workflow defines the following states:

• Starting state: Sending a first reminder.
• Reminder state: Sending a subsequent reminder.
• End state: Marking the task as complete.

It’s not hard to imagine creating other kinds of state machines using this approach.

There is a real risk of pushing beyond reasonable business scenarios for which SharePoint Designer was designed (and some might argue that we already have).  Keep that in mind.  A complicated state machine workflow should be developed using visual studio with its close-to-the-metal workflow building tool set.

Extending the Solution

Several common sense extensions come to mind:

• Weekends: Incorporate some logic to determine whether the current date is a non-business day. If it is, simply pause for 24 hours before running again.
• KPIs: Integrate this solution with a KPI. If the user requires many reminders, turn amber and eventually red to indicate a seriously overdue task.
• Escalation: if a given task requires too many reminders, fire off an email to a manager.
• Due Date Aware: Don’t send an email reminder for task unless it has passed its due date.

Conclusion

This article describes a fully functional email reminder system.  The solution leverages core WSS workflow technology and uses a relatively friendly tool, SharePoint Designer, to do it.  This means it does not require MOSS but works in MOSS (since MOSS extends WSS).

Although the business example focuses on tasks, it should be clear that the pattern described here can fit into many different business scenarios that require repetitive (looping) actions over a period of time.  Simply define how the loop should end, what it should do in the first iteration and what it should do for subsequent iterations.

Too often, we hear that SharePoint Designer workflow can’t loop, can’t create state machines, is terribly limited and crippled, etc.  With a little imagination, we can prove the critics wrong and build simple yet powerful workflow solutions using this tool.

• IT Manager attends an “information session” from a Microsoft Gold Partner, has one two many chardonnays and is convinced that SharePoint is the *answer*, but isn’t sure of the question just yet…
• IT Manager calls aforementioned Microsoft Gold Partner and I am sent out to dazzle them with my wit, charm and technical brilliance
• IT Manager agrees with me that SharePoint has to be sold to (and owned by) “the business”, so chooses the first candidate business process that pops into his head
• All hail the mighty “leave form“

Me sarcastic? never!

Note: I was recently certified as a Microsoft Certified Trainer for SharePoint, and I am using this series as practice for my training material! Thus this entire series of articles is pitched at a very high (end user) level. Readers with some exposure to SharePoint may find this article from the series is particularly easy-going, but rest assured, by the time I am done, I will be delving into web services, code and all sorts of goodies. Writing that stuff for the non developer will be a challenge – so stay with me, I will slowly ramp up the concepts as we go on.

So to recap the introductory article, we have documented the leave application and approval process for the Springfield nuclear power plant, and they have kindly supplied us with their existing leave form that their employees print out and fill in by hand. So our very first job is to see how InfoPath handles importing this MSWord based form to InfoPath.

InfoPath 101

Even though InfoPath is part of MSOffice, many people do not know about it, let alone used it. If you have never seen InfoPath before now, then I suggest you do some reading about it and maybe even download the evaluation.  My one sentence explanation is that it allows you to create electronic forms for data entry or data collection. Among its features is that it can import Word or Excel documents to speed up the form creation process. So let’s do that first up.

Upon starting up InfoPath 2007 we are presented with a “Getting Started” wizard. Our job is to design a new form, so the option to choose is to Design a Form Template as marked in the screen-grab below.

The next screen is to choose various options in relation to designing a form. We are starting from a completely blank form (which is the default option anyway), but this form is going to web browser based, so that people filling it in do not need InfoPath installed on their PC’s. SharePoint enterprise edition provides support for browser based forms via the “Forms Services” feature. InfoPath 2007 has built-in support for forms services, but the form must be marked as “browser compatible”.

This is not a default setting, so be sure to check the “Enable browser-compatible features only” box before clicking the OK button.

Now we are at the main form designer screen within InfoPath. Being part of the MSOffice suite, it has a set of toolbars that looks very much like the other applications in the MSOffice suite. To the right of the InfoPath screen is the “design tasks” tool pane. I’ve shown it below.

You will come to know the “design tasks” pane very well soon enough. From here we can perform all sorts of actions to construct a new electronic form such as create textboxes, buttons, drop down lists and the like. Not only that, but we can instruct InfoPath to connect to “data sources” to populate the values in say, a drop down list box. Imagine for example that all of your clients are listed in your CRM system. InfoPath has the capability to access those client details and display them on the form. Think of the data entry duplication that this will save,  not to mention the  maintenance of data accuracy, eh?

But hey, we are here to impress the clients with our technical wizardry and to show how InfoPath allows non-developers to create sophisticated electronic forms. So what we will do first-up is import the existing MSWord based leave document and see what we get out of the box.

Importing the old form

So, you should be at the main InfoPath screen to perform this action. From the “File” menu, choose “Import Form”. On the next screen, choose “InfoPath importer for Word documents” and click “next”

You will be prompted to browse to a file to import. In this example, I have chosen the “springfieldleaveform.doc”. The “options” button allows you to control the specifics of the import process. In this example, I will simply import the form with all of the default import settings.

Click “Finish” and InfoPath will do its thing – viola! We have the beginnings of a leave form!

Graphics?

Ah, but wait, what happened to the graphics? The original MSWord form had two pictures in the header of the document – a 3-eyed fish and a picture of the towers. It turns out it seems, that graphics in the header or footer of an MSWord document do not get imported into InfoPath. Bummer – I really liked that 3-eyed fish!

But fear not, importing graphics is as easy as a cut and paste. If I open my original word version of the form, I can double click near the top of the document, and the header/footer will now be available to edit as shown below.

Now you can click to highlight both images and they will paste into InfoPath. Not exactly earth shattering, is it?

It’s still not right…

Okay, so it wasn’t a perfect import. In fact I’d give it about a 6 out of 10. But the point is we have our images and our text inside InfoPath. Also to be fair, MSWord files were not designed for the web either, so it is unsurprising that it wasn’t flawless.

So, now we can use the native features of Infopath to tidy up this form. First, we will tidy up the arrangement of the two images, and then we will add some graphical elements like textboxes and option buttons to allow the form to be electronically filled in. We will create a table on the form that looks like this

In the right-hand “design task” bar, we select “Layout” and then choose to create a “custom table”. Choose a 2*2 table and you should see the table as shown in the third image below (look above the fish graphic).

The next step is to format the table correctly. Highlight the two rightmost cells, right click on them and choose “merge cells”. The result should be a table looking like the rightmost image below.

Now drag and drop the three-eye fish to the leftmost cell and the plant picture to the rightmost cell of the top row of the table. Your result should look something like this.

Now highlight the remaining title text, and then cut and paste it into the empty bottom left cell . Aha! We are starting to look better! A bit of resizing of the table cells width and it is looking more like the original.

Are we impressed yet?

Okay, sorry that is very much a rhetorical question, I know. I haven’t exactly written the most technically complex article ever.

But at least we have gotten the InfoPath version of the form to look much more like the MSWord version. If I had been running that as a client demonstration, it all in all would be around 2-3 minutes work. Is the client blown away in amazement and opening the chequebook yet?

Not exactly, but we haven’t gotten to the good stuff yet. In part 3, we will add some textboxes and other graphical elements (called “controls”) to the form, and then we will do some smart things to reduce manual data entry, as well as ensure that the data that we have collected is accurate.

Bye for now

Paul Culmsee

www.cleverworkarounds.com