Verizon Punts Email to AOL. What Do You Do Now?

AOL mail gives Verizon a shove

Does Verizon's recent move to end email services and move millions of email boxes to AOL have you thinking about alternatives? We can help. Here's some useful information and recommendations to keep in mind while you consider your options.

Tip #1: Doing Nothing Isn't An Option

When you receive the email from Verizon notifying you that the mail service is being ended, you'll have about 30 days to act. If you do nothing, your email box will be deleted and you will lose access to all your past mail.

Fortunately, Verizon is providing an option that will buy you some time. You can choose to let them move your mailbox to AOL, and it will keep your address, at least for now. No word currently on how long Verizon will let these addresses stick around. AOL is owned by Verizon, but like any company it could be sold at some future point.

Our recommendation is to let Verizon convert your mailbox to AOL. There are other options. For example you could switch to or Gmail, but these require more work and you'd lose your address. That could make it very difficult for you if you need to recover passwords from online account where you provided that address.

Fortunately, it looks like AOL's service will have better capabilities than the Verizon email service did, so you'll have more options available if and when you decide to permanently change your email address. Remember that even if you take them up on the offer to move to AOL, you aren’t locked in; you can always move to a new account later.

Tip #2: Inventory Your Online Accounts and Passwords

Because Verizon's email service is going away, you can end up in a bind if you were using a account to login to other web sites or cloud services. Now would be a good time to do a crawl of your old email and inventory any sites and services you've previously registered - old ones as well as those you currently still use.

Once you know which accounts are important to you, services like LastPass or RoboForm can be used to store your login information. This will reduce the chances that you'll need to fall back on password reminders that rely on your email address. Then, you can go into each service and update your profile to reflect your new address. Or, delete the account if you no longer need it, which will help protect you from username/password leaks that have become far too commonplace in recent years.

If all this sounds like a lot of work, consider what could happen if you find that you need to recover an account, but you can't because the email account no longer exists. So, for a quick fix, go back to Top #1 and let them more your address to AOL *before* you move to a new service provider.

Tip #3: Consider Replacement Email Services

Once you switch your Verizon email to AOL, you may still want to consider other options. Why? One reason would be because AOL is a consumer service, and perhaps you've been using your Verizon account for business. Or, maybe you aren't fond of AOL's user interface, tools, or customer support and would prefer to work with a different company. Yet another reason would be if you want to protect yourself in case AOL and Verizon parts ways at some future point - or if maybe they decide to merge AOL and Yahoo! Services together.

Whatever your motivation, you may decide that you want to make a permanent switch. Here are some options you can consider.

If you're a consumer using the Verizon account for personal reasons, the good news is that you have many other great options. You can create a free account at, Microsoft's successor to Hotmail and MSN. (Use this link provided here, then click "Get a new email address".) Or, you can do the same at Gmail, Yahoo, or any number of other great providers. In case it affects your decision, keep in mind that Yahoo is also being bought by Verizon and that it and AOL will be merged into something currently being called "Oath", whatever that means.

If you've been running a small or home based business using your Verizon email address, it might be time to think about upgrading to a business class service like Office 365.

Office 365 has plans that include the latest version of Office (including Outlook), email service with perks like shared calendars, spam protection, and your own domain name (e.g. It even has voice telephone services for businesses. These services aren't outrageously expensive, will make your small business look extremely professional, and can really level the playing field against larger competitors. All these services and more are available for less than $50 a person per month.

If you decide that you'd like to explore Office 365 as an option for your business, please feel free to give us a call. If you have a few minutes, you can fill our free Microsoft Cloud Services Assessment form and/or free Office 365 Migration Assessment form, and we'll follow up with you to schedule a free consultation. We're very attentive to our customers, will take the time to understand your business and go over all the options, and we offer lot of valuable but affordable services to go along with Microsoft plans that can take your business to the next level.

Tip #4: Collect Addresses of Your Contacts and Send a Notice

If you plan to permanently move your email address, you may want to let friends, family, customers, and business colleagues know. While you certainly can't force anyone to update their contact information for you, doing all that you can is certainly advisable. This is also possibly a good opportunity to rekindle communication with old contacts that you may not have heard from in a while - and you never know what opportunities could come from that.

Of course, to tell everyone about your move, you'll need their contact information. If you've been disciplined about keeping Contacts up to date, you might already have this, but many times we may have exchanged email with folks who never made it to our contacts folder. Fortunately, there are still ways to get this data so that you can make good use of it.

While you may be using different email software, here's how you'd do this in Outlook:

  1. In Outlook click on File, then Open & Export tab, then Import and Export button. This will open the wizard.
  2. Select the option to "Export to a File" and click on Next.
  3. Select "Comma Separated Values" and click Next. You can open this later in Excel.
  4. Select the folder you want to collect from and click on Next. We want "Sent Items" in this case. You could also do this for "Inbox".
  5. Enter a file location or click "Browse" to pick a folder and type the file name, then click Next.
  6. Click on "Map Custom Fields" button. This will bring up a list of all the available fields that are available in that folder.
  7. Since we only want the email address and name, click on "Clear Map".
  8. From the Left side click-and-hold on "To: (address)", "To (name)", "CC (address)", and "CC (name)"; drag each to the Right list. For Inbox you would do this for "From: (address)" and "From (name)" instead.
    • Pro Tip: If you also include the date/time of the email, you can use it to break your list out into years and track when you last contacted people.
  9. You can optionally click Next a few times to preview the results.
  10. When you're ready, click on OK then Finish.
  11. Now, you can open the results in Excel and do any de-duplication or other data clean-up you need to do.
  12. Once you have your list of addresses, you can use a service like MailChimp or Constant Contact to send an announcement to those you need to keep in touch with.

Please be polite and remember that it is considered very bad form to send e-mails out to a large audience using the CC or BCC features, since these may allow your contacts to see each other's address and even reply to each other. I can't tell you how many times I've seen someone do that only to watch my inbox blow up with a dozen replies of "please take me off your list." Keep you communications 1 on 1, use a bulk mail service, or see Tip #5.

Outlook users may also want to go spelunking for the Suggested Contacts folder to capture those addresses as well. To find this, go to Folders, then Contacts and scroll down until you see "Suggested Contacts" which should be just between "Sent" and "Sync Issues". You can copy these into your new account, export then to PST for later use, or export them to CSV as described above.

Tip #5: Set-up An Auto-Responder

After you switch your account to AOL, which we recommend that you do, you can set up an auto-reply rule to let people know that you're going to move permanently. This is something that Outlook does very well, and we've helped many customers to set this up before. If you don't have Outlook, or prefer an option that works when your computer isn't online, you can set up an away message in AOL Mail using their website.

Smooth Sailing or Rough Waters Ahead?

With these tips in mind, your Verizon email transition should be a pretty smooth one. Did you have a different experience or something that you'd like to share? Let us know in the comments.

Microsoft Hates Folders (Part 2 of 3)

So last time we established that for some mysterious reason Microsoft hates folders. Microsoft does not want you to upload your folders to SharePoint. Microsoft is very, very convinced that uploading your folders to SharePoint is a terrible, horrible, no-good, very-bad idea, and is absolutely certain that what is best for you, your company, and the entire world would be if you never ever ever uploaded a folder to SharePoint ever again, and in fact never even used a folder in SharePoint.

Right. You’re going to keep using folders in SharePoint because that’s how all your stuff is organized, and re-organizing all of it right now to take advantage of SharePoint’s other methods of categorization, regardless of how much better they might or might not be, is time you simply don’t have.

So, how do you get your 300 gigs of data in folders into SharePoint Online?

Method 1: Use OneDrive for Business.

This is the method Microsoft would prefer you use. With OneDrive for Business, you synchronize your SharePoint MySite to your hard drive, and also any other SharePoint site you use that you might want to synchronize. This creates a great deal of confusion.


Notice that there are two different folders labeled OneDrive? One of them is labeled OneDrive – Personal and the other is OneDrive – LiquidMercurySolutions. Then there’s also the folder labeled SharePoint.

Sometimes I think Microsoft needs to adopt a strategy from the Evil Overlord list, but slightly modified. They should run their marketing plans past a 50 year old office administrator who does not work for Microsoft. If she is confused by the plan, maybe they should adopt a different strategy. Sure, once you know what’s going on, you know why there’s such a plethora of folders and why the ones that are OneDrive for Business have different names that aren’t OneDrive for Business and what the difference is between that and regular OneDrive. But when you don’t know, it’s hopelessly confusing, and even when you do know, it’s easy to click on the wrong thing.

So, to clarify, since Microsoft’s as clear as mud here:

  • OneDrive (no Business here) comes with Windows 10, and you can download it for earlier versions. It is Microsoft’s generic, consumer-oriented, cloud file share, similar to Dropbox. At one point it was named SkyDrive, but Microsoft got sued and had to change the name. This is for your personal stuff. Windows 10 tries to persuade you to save everything to your OneDrive, when you first install it or configure it for yourself after buying the PC. So this is where your family photos and your kids’ artwork and that screenplay you’re writing in your spare time go.
  • OneDrive for Business is used to synchronize SharePoint. One of the sites you have access to in SharePoint is called your MySite. For most folks, it’s going to look something like this:



You get to it by going to {yourdomain}, where your company’s regular SharePoint Online site is {yourdomain} Click “Sync”, and this site will synchronize to your PC in a folder called “OneDrive – {Your Business Name}” (so in the example up above, mine is “OneDrive – Liquid Mercury Solutions”). This is for your personal work documents, which is less oxymoronic than it sounds. Drafts, notes, things you want to share only with a small working group such as the one or two people helping you revise it, that letter you’re writing to OSHA about your horrible working conditions… the MySite/OneDrive for Business site is by default accessible only to you, except for the things you put in the Shared With Everyone folder.

  • SharePoint – the folder labeled SharePoint on your PC is where synchronized SharePoint libraries live. These are the folders on the main company site (or any other site – in the example above, I have a personal site collection for my development work, where I also keep a collection of cookbooks so I have documents to test various forms of metadata operations on, and that’s the one I keep synchronized.)

So, logically speaking, all you have to do to get your folders into SharePoint is synchronize a library and copy your folders into the sync folder that appears on your PC, right?

Oh, but the devil is in the details.

First of all. SharePoint libraries have a maximum of 5,000 items. Folders are items. Everything in the folder is also an item. So if you have 50 folders, and each one has 10 folders under that, and each of those folders has 10 items in it… boom, 5000 items. So you’re going to want to watch to see how many items you actually have. If the folder you want to copy has more than 5000 items in it – which is very easy to achieve in some businesses, for example, a legal office where every client has its own folder and every case also has its own folder – you’re going to want to think about how to break it up. Alphabetical ranges are popular (ie, library for A-M and library for N-Z). Or if your business has a regional structure, perhaps separate different libraries by region.

Secondly. There are characters that your PC’s file system will tolerate, but SharePoint Online will not, because they are special characters reserved for URL functions. They include &, % and #. So if you like to name your files “75% Growth Plan” or “#1234 Union Ave” or “Meeting with Bob & Jane”… you’re going to have to rename them. Those files will not sync.

Third, make sure you’ve got enough space. Today, Microsoft is giving every SharePoint Online customer a terabyte of space. But that’s a recent development. The limits on the size of your site collection might have been set before that was true, so maybe your entire site collection has only 20 gigs and you want to upload 21 gigs of data to it. That… won’t work out so well for you. Have your administrator check to see if there’s space.

Fourth, by default, the folders on the PC will be named “Your Site Name” – “Your Library Name”, but with only a certain number of characters allotted to either one. So if your firm is named “Dewey, Cheatum and Howe” and your main site is called “Dewey, Cheatum and Howe Team Site”… that’s going to download as “Dewey, Cheatum and Howe” because at best you get 24 characters. (It might even be less.) And worse, if your library is called “Legal Pleadings From April 2016” you’re going to end up with “Legal Pleadings From Ap”. If you broke up your libraries on A-M and N-Z and stuck the letters at the end of the library name, there’s a good chance they won’t even be there on the synced folder on your hard drive, because you’ll be out of characters. You can change them… sometimes… but it’s buggy. Some clients of mine have had no trouble; others, we change the name of the folder 5 times and it keeps resetting.

And fifth… prepare to wait, and to get very little useful information about what the sync is doing while you’re waiting. Sync is a very slow operation. It’s not intended to transfer gigs and gigs of data; it’s intended to keep changes made to the files or folders on the PC synced to the library and files in the cloud, and vice versa. You can hover your mouse over the little OneDrive icon in the systray to see if the sync is done or how it’s progressing. But if you’re synching multiple libraries,  your results will be misleading because it’s usually telling you how much is left to go on the one library it’s working on now.

For migrating a lot of data… there are better ways. For moderate values of “better”.

Method 2: Use File Explorer.

Use this one weird trick that Microsoft hates! …No, that’s not clickbait. It really is a weird trick and they really do hate it.

A long time ago, Microsoft made SharePoint compatible with File Explorer via a technology called WebDAV. So you could connect to a library directly via File Explorer, and copy files to and from SharePoint. This is dangerous. You can see the hidden folders and files that SharePoint hides from you, so you could theoretically cause a great deal of problems to your SharePoint site, to the point where you could potentially corrupt it into being unusable. Also, see, File Explorer is an icon of a folder, and Microsoft hates folders.

For a while they did their best to block this feature, but nowadays it actually works, most of the time, if you make the appropriate goat sacrifices on the full of the moon at the dark of night in a properly cleared stone circle. Or, at least, if you are using Internet Explorer as your browser. Internet Explorer is deprecated; even Microsoft doesn’t want to support it anymore, so Windows 10 machines ship with their default being a new browser, Edge, as in it’s on the very edge of being a usable browser but not quite there yet. (Don’t get me started talking about Edge.) But Edge doesn’t support this trick with SharePoint, and none of the non-Microsoft browsers do either. It only works in Internet Explorer.

You go to the library you want to open, in Internet Explorer. On the “Library” tab click “Open in Explorer”. (This is available from the new Document Library style that is missing the ribbon and its tabs; in this format you get to it from a drop-down menu at the far right.) You may have to do it more than once to get it to respond. Once you do, it will open File Explorer, connected directly to the library.



Note that if you have synced this library with OneDrive for Business, this trick will not work.  It can only be used if you don’t have a sync folder for this library; otherwise it will try to force you to use the sync folder instead.

Using File Explorer, you can bulk copy a lot of files and folders, a lot faster than you could have using OneDrive sync. But it’s buggy. Sometimes it will spontaneously lose its connection and have to be re-opened for no real reason. Sometimes you won’t be able to get it to open at all. And if the library in question has any required metadata, then every single file you upload will be checked out to you, as a draft, and invisible to anyone else because that’s how required metadata and drafts work in SharePoint.

Method 3: Purchase migration software.

This one’s always an option. For a small company, however, it’s not usually an affordable one. Most migration software prices come in at a minimum of 4 digits, or heavily restrict how many gigs of data you can transfer, or both.

(Shameless plug time: we have migration software that sells in the triple digits. The catch is that there’s no attractive UI; it’s all scripting, so it’s mainly for use by consultants like us and IT departments.)

No matter how you go, it’s gonna be slow

Transfers to Microsoft’s data centers are throttled so no one customer can consume enough bandwidth to negatively affect other customers. So expect your data migration to take a while. Sync is easily the slowest method, and File Explorer probably the fastest. All methods will run into the same issues with bad characters, although most migration software will take this into account and either allow you to change the names, or will change them for you. All methods will be affected by space and by the number of items per library, as well.

What if I’ve decided I hate folders too?

There are actually some good reasons for moving away from the folder model entirely when you migrate to SharePoint (or at least mostly.) In the third part of this blog, I’ll discuss those reasons, and how you would go about migrating data without migrating folders or losing metadata.

Microsoft Hates Folders (Part 1 of 3)

It’s not clear what brought this on. For many years, Microsoft – inventor of Windows, which did not create the folder metaphor for directories (I believe that was Mac, or maybe Xerox PARC), but certainly used them happily for decades – and folders got along just fine. Then suddenly one day users of SharePoint Online couldn’t work with folders anymore, except in very limited ways.

I’ve encountered this many, many times in the course of helping clients migrate into Office 365. They want to move off OneDrive into SharePoint, or off of networked file shares. Great! We create a site for them, and appropriate libraries. And then it turns out that we can’t upload their stuff the way that anyone would normally upload things into SharePoint, because SharePoint no longer allows you to upload folders.

Did… it never occur to Microsoft that people who are migrating into SharePoint Online would probably have a lot of folders? That they might like to upload?

I know what the technical logic is behind deprecating folders, of course. At practically every SharePoint Saturday I’ve been to, someone has been teaching a class on why you don’t want to, or need to, use folders in SharePoint libraries.

A folder structure, when it comes right down to it, is metadata. You could have piled all your finance documents in the root of your C drive, but instead you put them in a directory labeled C:\My Documents\Finance to organize them better, because a Windows directory doesn’t allow you to apply metadata directly to files, so in order to mark them as Finance files you put them in a directory labeled Finance. And then you probably have directories like Taxes\Federal\2007, or Reports\P&L\2013, or Register\MyBank\Checking\2001, or stuff like that. All of this is metadata. Tax files, specifically federal tax files, specifically the ones from 2007. Reports, specifically P&L reports, specifically the ones from 2013. And so forth.

It’s a method of organization that comes from mentally projecting filing cabinets, where there can be only one physical sort method of physical objects, into the world of computers, where there could theoretically be as many sort methods as you have different data to sort by. So Microsoft has been pushing hard for SharePoint users to get out of the habit of folders, and use metadata instead with views that group, sort, and filter the data in different ways.  That way, should you have a need to pull together all financial reports for 2013, you aren’t hampered by the fact that the reports have been set into different directories by the type of report and then within those directories divided by year; you can simply pull all of one year together.

Well, ok, Microsoft, that’s great, but do you have time to go through half a terabyte of data going back 10 years to add metadata to it so that you can safely mark it in SharePoint without having to upload the folders? “Yes,” Microsoft says, “we do! We’re one of the biggest corporations on the planet and we are crawling with low-paid interns who can do that sort of work for us!” OK, but have you thought about the fact that your customers don’t all have those resources? In particular, your customers of SharePoint Online, which is most economic for small and micro businesses?

No. Of course they haven’t.

All is not lost, of course. There are two ways to get your folders into SharePoint anyway. There’s the method recommended by Microsoft, which is full of bugs, and then there’s the old, deprecated and nowadays mostly undocumented method, which is full of different bugs. The third option is to hire us to do it for you, since we’ve written our own tools to solve this problem, and if you’re planning to do that, you can call us at 410 633 5959 or email me at . Operators are standing by!

Yeah, I kind of assumed that if you were reading a blog about how to do this, you wanted to do this yourself. But I had to try.

So. In the next part of this blog, I’m going to talk about how to get your folders onto SharePoint anyway. Then in the third and final part, I’ll demonstrate the advantages to using metadata rather than folders and show why you actually might want to try to move away from folders as a method for organizing your data on SharePoint, going forward.

An Army of One Asks "SharePoint, What Is It Good For?" - Using SharePoint in One Person Companies

It's dangerous to go alone. Take SharePoint. Recently, we've been getting a lot of new customers who are the sole proprietor of their businesses. This isn't too unusual; many businesses are one-person shops who don't have any employees. For example, while it isn't unusual to eventually take on assistants, many tax preparation specialists, accountants, architects, lawyers, IT folks, marketing gurus, or business consultants start out as just an individual person going into business for themselves. I personally went this route; rather than take on a full-time job, I operated as an independent contractor for nearly 15 years.

Liquid Mercury has always been a company based on helping our customers get the best value out of SharePoint. This used to mean mostly Fortune 500 companies and government agencies. Then, Office 365 came along and has greatly increased the audience for whom SharePoint is accessible. Now, even a single person business can buy an Office 365 Business Premium plan for $12.50 a month and get access to SharePoint.

There's a lot of interest in the platform, and one question that people in business for themselves ask us more than any other is "What's the point to SharePoint when you haven't got anybody to share with?"

At first, the answer wasn't entirely obvious, even to me, so I thought it might be worth sharing a few tips on how sole proprietors can get the most out of the SharePoint component of their Office 365 service.

Author's Note: This article got to be much more involved than I expected. So I've decided to break it up into two parts. In this, part 1, I'll go over the first three tips, which are primarily about benefits you can achieve for yourself. In the next part, I'll go into depth about ideas that can help you when working with your customers.

Tip #1: Develop a Filing System

When I think about how to use SharePoint in a one-person office, the first thing that comes to mind for me is to simply get better organized with all the documents needed to operate the business every day.

Any business will have these. There will be invoices and communications from vendors that need to be scanned, filed, and paid out. Possibly, there will be invoices sent to customers. You may have to write your own contracts and then keep track of variations as you negotiate with your customers. Perhaps you'll need to write quotes or formal proposals in order to win the business. There might be status reports and time sheets.

You can certainly organize all these documents into folders. That's how people have been doing it for years. I will give you one good example why this might not be the best option in the long run.

Suppose you decide that your filing system will be organized by customer. One folder per customer, no problem. To keep clutter from piling up, under each customer folder you create a folder for time sheets, work logs, and invoices; a folder for documents the customer shares with you (so you can honor that NDA you signed); and one for the original proposal and agreement (so you can remember what you promised to do for them). You did remember to scan the signed copy of your contract and put it there, right?

Anyway, suppose you hire some help for a large customer. You need to share documents for that customer with your hired help. But there are certain details you'd prefer to keep in house, such as how much the customer is paying you, those confidential/proprietary documents, etc.

Now you also want to hire a bookkeeper to help you convert work activity into invoices. This person needs access to all the customer's documents, but only needs the financial stuff not the contracts or project documents.

You start to think that maybe it would've been better to organize the top level folders first by the type of document, and then have sub-folders for each customer. Over time you change the way your organizing your files, coming up with newer/better categorizations - but you don't really have time to go back and change the historical documents. What you need now is called a "matrix". What you actually have is probably better classified as a "mess".

But what does SharePoint do to resolve this problem?

SharePoint lets you attach any number of properties to a document. These are called Fields and they work exactly like you'd expect fields in a database or columns in a spreadsheet to work. You can have a Field for which customer a document relates to, and a different field for the purpose of the document. Say that later you decide to add a follow-up date to keep track of work on certain documents. With SharePoint, you can add that easily at point down the road.

Of course, we wouldn't just enter extra data about files for the fun of it. Learning to file things in a way that is completely different than what we've been taught to do for the past 25 years takes a certain amount of discipline. New skills will have to be learned and new work habits developed. For this effort, there must be a proportionate reward.

As it turns out there is such a benefit. Fields are useful because you can then create something called a View. Views let you show only the documents that meet certain criteria. For example, "Show me only the proposals that I won the business." or "Show me only the invoices where the customer hasn't paid me yet." Things can also be set up so that your bookkeeper wouldn't need to be confused by all those non-invoice documents that you have to track, because from their point of view (no pun intended) these can be completely hidden. So, you can start to see how Views would be very useful indeed and worth the effort of putting data into Fields on almost all your documents.

Tip #2: Find Things Faster, Easier

One thing that SharePoint has always done pretty well is search. (Hey, you SharePoint experts, don't laugh; I am serious.) Since the first version back in 2001, I have been very impressed that SharePoint was able to crawl all the documents on my entire network, including file shares, and bring back results that often times I'd completely forgotten even existed.

This was no small accomplishment, and SharePoint's ability to uncover hidden gems has only gotten better with time.

Quick Benefits Right Out of the Box

Today, in Office 365 we have something called Delve, which will show you not only what documents you've been working on, but timeline of your work with thumbnail representations of what these documents actually look like. Most one person shops are not running an traditional server with an enterprise version of SharePoint, so I feel pretty safe saying that for the purpose of this article, most interested readers will have access to Delve.

Here's a screen from Delve showing my recent documents.

Also, many people do not realize that OneDrive for Business is essentially SharePoint with another face. Yes, OneDrive lets you sync files to your local hard drive. However, when you browse the web site to look at the copies of your documents that are stored in the cloud, that web site is a SharePoint web site and those documents are stored in SharePoint Libraries. As a result, they are also searchable in SharePoint and will show up in Delve.

So, you can get a tremendous benefit without any extra effort at all on your part simply by choosing to save your documents into SharePoint or OneDrive for Business.

Taking Search to the Next Level

Combined with the proper use of the Fields we talked about in Develop a Filing System, SharePoint search can be used to not only search for documents based on their content, but also on how they were categorized using the data in those Fields. For example, just like you can create a View to show you certain types of documents within a Library, you can also use Search to surface documents stored on any SharePoint site.

This feature has many practical applications, especially for larger businesses, but the most compelling for a sole proprietor will likely be digging through lots of documents to find the one you need - as quickly as possible. Imagine for example that search results can be filtered by a specific customer, by a set of products that they relate to, or let's say... maybe by whether you remembered to scan and upload the final signed version.

Tip #3: Create Standard Operating Procedures

Almost every one person shop starts out with the idea that if you build a better mouse trap, people will beat a path to your door. Yet, in the course of business, we often fall into a trap ourselves. We discover that we're spending more time being a bookkeeper, bill collector, contract writer, office clerk, tech support, etc. rather than the thing we went into business to do.

Eventually, if you are going to stay focused on your mission, your one person business is going to take on hired help. That could mean employees or it could mean contracting with other specialty firms.

Either way, how you go about getting your work done is something that will need to be documented and shared. Without proper documentation of your processes, it becomes much more difficult to identify those parts of your work that can be effectively retooled, delegated, or outsourced to make your operation as efficient and competitive as it can be.

If you get to the point where you're successful enough that you are forced to grow, then you'll have no choice but to try and explain to other people what you want them to do and how you want it done.

Take it from me, it will be better for you if you start writing these things down before that day comes.

I learned the hard way that rapid business growth can be every bit as dangerous as a period of decline. In fact growth can trigger missteps, leading to long term problems and the ultimate downfall of a small business. Growth can turn many strategies that help the tiny business survive into bad habits that hold it back. Growth puts such a strain on the leadership of a business, that it might make one reconsider why they went into business for themselves in the first place.

By documenting your business processes before you're busting at the seams, you can go a long way towards making sure that once you're simply too busy to train new employees, there'll be a guidebook they can follow to help you get the most out of hiring them.

So enough about why you need to be writing SOPs before you actually think you need to have them. How does exactly SharePoint fit in with helping you define your business process?

Unstructured Notes

The first step is having a ready-to-share platform for writing things down as you think of them. At this stage, your ideas may not even be fully formed, so getting things on record quickly without interrupting your other work is essential.

For the unstructured piles of stuff I tend to generate at this stage, I use OneNote. OneNote is great because I never have to remember to hit Save, and it makes it relatively easy to record the web site where I found whatever helpful bit of information I might be working with. It has lots of features in that are helpful in taking down information quickly.

Okay, but you don't actually need SharePoint to use OneNote. It's part of Office and you could simply save your Notebook files to your laptop, or if you're really cloud savvy you can put them into OneDrive.

SharePoint sites include something called a Site Notebook. Site Notebooks are simply OneNote Notebooks that are already saved to a SharePoint library, set up for sharing with team members, and web accessible. If you start with a Site Notebook rather than creating a new Notebook some other way, then no extra steps are needed to start sharing the notes you take there.

Say that all you do when you start your business is create one SharePoint Team Site for each hat you have to wear - accounting, marketing, sales, management, and operations. Then, open the Site Notebook for each site in OneNote so you have a central place to start taking notes. When the time comes that you're ready to bring on some outside help, just share access to the appropriate Team Site, and they'll have your notes too.

By the way, there's a nice thing about sharing Notebooks this way. Two people can edit the notes at the same time and see one another's changes in real time.

Structured Documentation

Suppose you get to the point where you want to formalize your notes a bit further into something your assistant can use to help you perform some business tasks that come up fairly often. There are a couple things you can do in SharePoint that might be a better choice than using OneNote.

The first option is to create a Wiki Library. Wikis are web sites where you can quickly post and edit information directly on the web page. For example, this can be useful for creating and updating a company FAQ, employee policy handbook, etc. It's a bit easier to lock down a Wiki so that only certain people can make changes but everyone can read it. Wikis have the advantage that you have more control over how you structure the pages and navigation between them, and that users will not need any special knowledge beyond how to get to the web page using a browser. Wiki pages also show up as individual entries in search results (see Finding Things Faster) rather then one search result for an entire Notebook.

The other option for structured information is to copy your notes into Word documents. For example, if you wanted to create an Employee Handbook this might be the way to go. Personally, I find that if a process has a lot of diagrams, pictures, or screen shots, then creating the Word document is a lot easier than the work involved with uploading all those images to a Picture Library in SharePoint so they can be used on a Wiki. It's also easier to create a PDF from a Word document than a Wiki or Notebook, so if your process is something you'll have to share with people who don't have either Office or access to your SharePoint site, you might want that option. Word documents also show up in search as one result per document.

Defining a Process

When I talk about defining a business process, a lot of people will immediately jump to thinking about workflows. Workflows in SharePoint provide a way to marshal a process through several steps, with notifications for people when their step comes up.

Let me just get this out front; developing a workflow is not necessarily a great idea. There are several reasons. Firstly, workflows add overhead to a process. In addition to completing the task, you often have to report to the workflow that the task has been completed. Second, workflows define a process rather rigidly. This becomes a problem if your process changes fairly often - or worse yet maybe you don't even have the process fully defined. These issues are most obvious when you're a single person operation and need to track your own work.

SharePoint does provide some ways to improve your processes without forcing yourself into taking on a cumbersome system to track every step of what you do.

For example, Task Lists are a great way to plan a project and keep tabs on the steps involved so that you don't lose track of your progress. Over the years we've built a number of SharePoint add-ons to Tasks that let you do things like copy a set of template tasks to a new Task List, manage multiple projects within a single Task List, and more.

Microsoft recently released a tool called Planner that comes with some Office 365 subscriptions. We really like Planner! It shows a lot of potential, and in many ways it is easier to use than the SharePoint Task List. We wonder what Microsoft's plan for SharePoint Tasks will be in the long term, now that there are two different ways to accomplish essentially the same thing. Even so, Planner is a new product with several caveats and limitations that make it less amazing than we'd like it to be. For the moment, there are still times when choosing SharePoint Tasks instead is a valid option.

Screenshot of Microsoft Planner in Office 365

Beyond Task Lists, there are other ways to use SharePoint to structure your processes. Many people do not know that you can create a custom List in SharePoint very easily. These Lists can hold any kind of information you can imagine. For example, you could record a list of product prices, or a series of trade show events that are important to your business. You can even build a customer relationship management database using SharePoint.

Next Time in Part II

I'll post again soon about the next three tips, which are primarily about how you present your tiny rowboat of a company when you're working with all the tugs, oil tankers, and cruise liners of the world.

  • Tip #4: Look Bigger Than You Are
  • Tip #5: Share Documents, Securely
  • Tip #6: Structure Customer Service and Interactions

I hope you'll join us. Please consider subscribing to the blog to get notification for the next part and other content that might be of interest to you.

As always, if you use SharePoint or you're considering Office 365 for your one-person operation or army of employees, please don't hesitate to contact me, or visit us at to learn more about what we offer and how we can help you.

Anouncing CloudPrep 2014 Migration Toolkit for SharePoint Online

We do a lot of Office 365 migrations. Most of these are for businesses with fewer than 50 employees. This should surprise nobody except maybe Microsoft, who seemed to be slow to realize that their cloud platform would have the most appeal to companies with limited budgets – or that most jobs in the US are provided by small businesses. Go figure.

Over the years, I’ve written several times about the challenges of moving from a conventional file store to Office 365. Fact is, it’s just not simple to do. It really makes sense to have an experienced IT professional help you make the move. I like helping customers make the switch, but doing so has presented interesting challenges for my business that I’m sure other SharePoint consultants share too.

Firstly, there are great third party tools out there for migrating files. We often use ShareGate and Content Matrix from MetaLogix. MetaVis is another great company that has great tools with lots of features. Fact is that even though these tools are great, they are also quite expensive. They’re feature rich, so really knowing the tool is a skillset of its own – and it makes good IT people hard to find when I need them to do a job. We also run up against serious limitations when trying to use these tools; sometimes we cannot find a way to use the tools to migrate the files in exactly the way we want to.

Second, some of my client already have a part-time IT person or managed services company that helps them service their PCs and on premises servers. Traditionally, we’re a SharePoint consultancy and we never set out to try and replace other IT folks; they need work too. They have the relationship with my customer, and the local presence needed for that on-site work. Over the years, I’ve seen that customers prefer to have their own local IT provider for most small requests. We needed to find a way to coexist with these other businesses in a way that would benefit us both.

Back in 2012, at the behest of a marketing consultant (who gave me lots of advice that was either bad or I couldn’t follow it at the time) I created a small tool called CloudPrep. This tool wasn’t much; I never had much confidence in it and so I never really promoted it. But, it did the work of renaming files that SharePoint didn’t like, and combined with WebDAV it was enough to make getting 20 to 50 GB of customer files into the cloud in a few days’ time. I released it into the wild, and CloudPrep has been getting downloaded a few times a week – mostly by other Office 365 consultants to my chagrin. Lesson learned and another checkmark for finding a way to compete with other IT providers; there are more of you than there are of me!

One problem I’ve noticed is that Office 365 migration budgets are small – I mean really tiny! That’s weird when you consider that for a 25 person company the ROI could be hundreds of thousands of bucks. But, we have been in an economic slump for something like 5 years now. I guess that takes its toll; even if you knew it would make you a thousand dollars next month, you can’t spend $100 today unless you have it to spare. Some companies are reluctant to spend even a few thousand to plan and execute.

There are a few tools that are in the “beer money” range. I tried FilesToGo once – and only once. It lacked some features that seems obvious to me, but made my client extremely angry. It didn’t have a lot of options either, one size fits all. I won’t discourage anyone from using it if it meets your needs, but I’m not going to risk my relationship with my clients on it. I am honestly surprised that after all this time, there’s nothing else in its price range.

I guess you could say that I’ve gotten fed up with this situation. Yet another migration we had to do where the current tools on the market couldn’t meet our needs for the client’s budget. That story gets old.

So, the boys in the lab and I finally built our own!

Announcing CloudPrep 2014! Forget everything you ever knew about that crappy tool we made back in 2012, because this is completely something at a whole new level.

CloudPrep 2014 is not one of those big expensive tools with a fancy GUI. It’s a set of PowerShell command-lets that work with SharePoint Online and your local file system. These commands and the sample scripts provided with them are designed to empower IT people and make migrating files to and from SharePoint Online a piece of cake.

These tools don’t replace an IT person or their experience. You’ll still need an experienced consultant to tell you how to organize your files, use metadata, overcome or avoid SharePoint Online limitations, and of course actually use the tools. You needed all that before anyway. The difference is that now much of this can be provided by your own experienced IT staff; or if you’re an IT consultant yourself, you can use our tool and make your small-business and small-budget migrations a breeze instead of a quagmire.

Our commands fall into basic categories: planning, preparation, file migration, and SharePoint management. We’re still putting the finishing touches on the product now. We’re hoping to have the Lite and Standard editions released to market sometime in February, with the Premium and Professional versions available as soon as March or April.

In the meantime, please take a look at our feature matrix and proposed pricing structure. There’s still time to collect some feedback. So, if you have a feature you’d like to see that isn’t here, then leave us a comment and let us know. Even if you don’t add a feature by the launch date, we’re planning to add even more features later. We’ll entertain any reasonable suggestion – except charging more for the product.

Like what you see and can’t wait to try it out? Contact us and I’ll give you a 15% discount if you purchase during the early access period.

Edition->Feature        Lite   standard Premium Professional
Release Date   Feb  Feb  March  April
Proposed Price Free $285 $576


+$300 Per Tenant>2

Number of Office 365 Tenants Unlimited Unlimited unlimited Unlimited
Numbre of Site collections Unlimited Unlimited Unlimited Unlimited
Requires powershell 2.0 or higher Yes Yes Yes Yes
Requires Sharepoint client connectivity Yes Yes Yes


1 year support and Updates

(renewable Annually)

  Yes Yes Yes
Supported OS: Windows server 2008 or 2008 R2 N/A Yes Yes


Supported OS: Windows XP N/A   ?? ??
Supported OS: Windows Server 2003 N/A   ?? ??
Planning and Reporting        
Sizes and Numbers of items by folder, extention, ect. Yes Yes Yes



Check for Potentially Illegal file types   Yes Yes


Folder and File Path Length Checking   Yes Yes


Permissions Checking for Local Files     Yes


Target URL Length Check Report     Yes


Upload Time Estimates      


File Preparation        
File Renaming for Illegal charaters Yes Yes Yes Yes

File Renaming for Illegal Paths


Yes Yes Yes


Preserve Author and Editor for uploaded Files

  Yes Yes


Check for and Automatically ZIP files with illegal extentions (EXEs, Ect.)



Check for and Automatically ZIP "_files" Folders

  Yes Yes


Migrate and Manage Files


Supports Network Mapped Drives

yes yes yes yes

Supports Network UNC Paths

yes yes yes



Upload Entire Folder to Document Library

Yes Yes Yes


Upload Specific File to Document library

  yes Yes


Download Document Library to Folder

  Yes Yes


Download Specific File

  Yes Yes


Warns if Source Exceeds 5,000 items

  yes Yes


Warns if Target URL length Too Long

  yes Yes


Specify Content Type for Uploaded Documents

  Yes Yes


Specify Content Type for Top Level Folder



Specify Content Type for Sub-Folders



Support for Documents Sets



Flatten Folder Structure with duplicate filename handing



Flatten Folder Structure at 1 or more levels deep



Convert Folder Names to Metadata Fields



Create Source URL Field for Uploaded Files



Create MD5 Hash Field for Uploaded Files



Export Metadata to CSV File when Downloading Files



Synchronize of Local and Cloud files using File Modified Time



Synchronize of Local and Cloud Files using File Modified Time+ MD5 Hash



Automation Features


Powershell command-lets

Yes Yes Yes Yes

Unattended Execution

  Yes Yes Yes

Sharepoint Management &


Create and Edit SharePoint Users

  Yes Yes Yes

Set Common Properties for Lists and Document Librarys

  Yes Yes Yes

Create and Edit Columns in Lists and Document Libraries

  Yes Yes Yes

Create and Edit Views Lists and Document Libraries

    Yes Yes

Copy a view to same or Different Document Library or list and site

    Yes Yes

Import and Export Site Columns

    Yes Yes

Import and Export Content Types

    Yes Yes

Import and export views

    Yes Yes

Add, Remove users and Groups, Permission Sets

    Yes Yes


CloudPrep Lite
This edition is a good fit for small file migration needs and try-before-you-buy. You can use it to do basic reporting on the structure of your files, rename files that are known to cause problems during migration, and upload folder structures to your SharePoint Online document libraries. In most cases it has a 99.7% or better success rate, and it produces a handy report so that your remaining files can be uploaded manually.

CloudPrep Standard
This edition includes a standard set of features designed to help you move files into Office 365 with a minimum amount of difficulty. You can upload and download large file collections without having to stand by the computer, perform multiple upload/download passes, and specify a default content type for files. Run it from anywhere, including various versions of Windows Server. We also include some additional pre-migration reporting tools that help to identify problems before you migrate your files.

CloudPrep Premium
For the seasoned SharePoint admin or IT professional, this edition includes features that will help you get the most out of Office 365 in the cloud. We include even more reports to give you a 360 degree view into any potential file migration issues. The file upload tool includes a variety of features for setting metadata and flattening folder structures.

CloudPrep Professional
This edition enables the true Office 365 IT professional to handle migrations for multiple clients. All the features of the Premium Edition plus advanced content type features including support for Document Sets. It also includes the ability to create MD5 Hash file uploaded files, which helps in detecting duplicate files and in determining that if two files are not the same even when their date stamps match.

Who Really Has the Best SharePoint Workflow Product?

I came across this blog article today, asking the question "Who has the best SharePoint Workflow Product?" This seems to have gotten a lot of attention, and so far I see that over 4,500 people have voted. That's some serious interest!

I sometimes get this question from our customers, and this is particularly challenging for me because often the correct answer is "it depends". Sure it sounds like a copout, but it's really not a very simple question.

It gets even a bit more complex for us, because we partnered with Nintex and AgilePoint, and needless to say Thanksgiving dinner can get a little bit awkward if I were to try and declare a unilateral favorite. But, read on and you'll see there's a reason that things played out that way.

I'm going to do my best to approach this question as impartially as I can. I will be very candid. From my point of view, the three workflow products mentioned in the article, AgilePoint, Nintex, and K2 are certainly the best of breed for all SharePoint workflow products. There's also Bamboo, Datapolis Workbox, HarePoint, MetaStorm, and Global360 to name just a few; but I really feel like most of these have missed their chance to take a leadership position in this space, in one way or another.

So here it goes: the good the bad, and the ugly of SharePoint workflow and third-party products.

Why Not OOTB SharePoint Workflow?

You can't have a serious discussion of third-party workflow products in SharePoint without asking the obvious question, "Why not use SharePoint workflow in the first place?" Personally, I am not a fan of SharePoint so-called out-of-the-box workflow for a lot of reasons.

OK - deep breath, inhale…

The first thing that jumps out at me is the way that Microsoft has absolutely bungled SharePoint workflow when you look at what they've done over the past ten years. In SharePoint 2001, they had workflow, but in SharePoint Portal Server 2003 they took it away completely. In 2007 they brought workflow back, using something like Outlook rules to help end users develop simple workflows, or Workflow Foundation in Visual Studio for the really complex stuff. These had serious limitations and neither could be effectively created by analysts alone, so in SharePoint 2010 they introduced some Visio capabilities - but then totally dropped the ball by taking away any ability to do simple workflows with loops or anything like "go back to step 2". I was sure they'd get it right in SharePoint 2013, so I was horrified to learn that they have completely revamped the workflow system so that now 2010 workflows and 2013 workflows are completely different and incompatible - and that in the 2013 version there are a significant number of actions you can no longer do that worked in the 2010 version. To me, this is not a stable and mature part of the platform; to leverage it will be like building on shifting sand and you should be prepared to rebuild everything in a couple of years if you go this way.

More so, SharePoint's native workflow cannot handle complex, recursive, or long-running flow patterns. Some processes are just too complex, long-running, or rapidly changing to be supported by SharePoint's native workflows without either a great deal of custom code - unless you use a third-party workflow product or in some cases a full-blown Business Process Management (BPM) suite.

As for Visual Studio workflow, custom code is expensive and time-consuming both to create and to maintain on an ongoing basis, so the best practice in almost any situation where the problem can be solved by either custom code or an existing product on the market is to use the existing product.

Finally, even in SharePoint designer there's a valid point that if you have developers available to do SharePoint workflow in Visual Studio or SharePoint designer, there is a very, very, very good chance that there's something (anything!) else that they could be doing instead which would give you a better return on their development time. Thus, we strongly recommend that you pick at least one third-party workflow product.

That being said, let's move on and take a look at some products!

Nintex Workflow

Nintex is an excellent choice if you have workflows that are more complex than can be easily done out-of-the-box with SharePoint. It's comparatively easy to set it up and use it when you contrast it with anything K2 has to offer. As a result, Nintex is commonly used to supplement SharePoint Workflow within the vast majority of SharePoint farms.


I haven't recently looked for any market data, but I'm pretty sure that Nintex is by far the most successful SharePoint product in terms of pure sales, and as a partner we love the Nintex web site for their ability to give us the resources we need to market and demonstrate their product. You will have no absolutely difficulty finding a reseller in your area to help you with professional services - although I hope that you'll just call on us instead. We'd be happy to give you a demo. Personally. ;-)

Nintex has pretty good integration with systems outside of SharePoint. Off the top of my head I know that we can use it to do most basic tasks within SharePoint, plus we can call web services from outside systems or manipulate databases. These features are pretty easy to use, but I would not say that your average SharePoint user or site owner will necessarily know how to leverage them. That said, most business users will be able to get by doing things purely inside of SharePoint.

Nintex has EXCELLENT support for the cloud. They have a version of their product that runs on Amazon Web Services and integrates with Office 365 SharePoint Online. At this writing, I'm not aware of any other workflow product for SharePoint that can claim this.

As far as downsides go, I'd say that Nintex architecture suffers from the same issues that SharePoint workflow does, so on SP 2010 or older your workflows are going to run on the web front end and will consume resources there. As a result, you may need to add more WFE to your farm the more you use it. This is mighty convenient for Nintex, since they license the product per WFE in your farm.

One other thing to note is that Nintex can't really handle the high complexity in some of the processes that we develop for our clients. We're talking about long-running processes that could take months or over a year to complete, and they have hundreds of steps. You see things like this in government agencies a lot. I've done really mind bogglingly complex ones for NIH, FAA, and most recently USDA. Personally, I wouldn't want to try to use Nintex to solve these sorts of problems.

AgilePoint (particularly Genesis Edition)

Considering all the workflow products for SharePoint, probably the main thing to point out about AgilePoint is that it is so much more than just a workflow engine. There just aren't that many players out there in SharePoint workflow who can honestly claim they are a fully functional business process management system, or BPMS.


As a result, AgilePoint workflows can be changed while running. A long-running flow will not be "orphaned" by changes to the process that occur while it is in progress. This is perhaps the very best feature. As a rule, if you process has 25 or more steps and is completed over the span of a month or more, you should strongly consider AgilePoint.

And yet, in contrast to many other BPMS systems, AgilePoint is designed exclusively for the Microsoft .NET framework, and relies heavily on the MS product suite for its creation and implementation, rather than using a proprietary tools. AgilePoint uses Microsoft Visio to design workflows and InfoPath to create forms, so any office with full Microsoft Office licensing already has all the tools AgilePoint requires. It integrates natively into SharePoint workflow; AgilePoint workflows can be deployed to SharePoint at least as easily as SharePoint's own native workflows can be deployed from SharePoint Designer.

AgilePoint Genesis installs natively alongside (and co-exists with) other SharePoint workflows. It supports every known pattern of dynamic and ad-hoc workflow identified by the BPM industry and provides 36 different functions for interacting with SharePoint. More are available with the Enterprise edition, and the possibilities with custom AgileParts are virtually limitless. This functionality leads us to conclude that AgilePoint sports A+ level “tight integration” with SharePoint. Users will never know their process has left the SharePoint server, yet AgilePoint will not negatively impact SharePoint performance in any way.

As a company, AgilePoint's primary focus is in workflow, and it’s designed to make creation and modification of workflows easily accessible to business users, rather than requiring high levels of programming skill. A business analyst with strong knowledge of Visio can be trained to create a fairly complex workflow within half a day. Workflow activities can be based on InfoPath forms created by anyone with technical savvy to create forms in Microsoft Access. Most process revision consists of moving objects on a diagram and doesn’t require a developer at all.

Call me a total geek, but one cannot discuss the strengths of AgilePoint without at least mentioning some of the obscure but important technical aspects that make it a truly impressive product. For one, AgilePoint’s model is declarative, meaning that there's almost entirely no code generated to drive the workflow process, only XML; this is in sharp contrast to many BPMS as ell as the MS Workflow Foundation Engine (SharePoint, K2, Nintex) which all use a high amount of dynamically generated source code to drive the workflow logic. In fact, AgilePoint actually uses the Visio document format itself to drive its workflow engine, so the process is literally running the exact same flow-charts drawn by the business analysts and developers! Another advantage is that AgilePoint is one of only a very few pure-play .NET BPMS out there in the market. Also, the product is built entirely on .NET; there is no part of the product which inherits from COM as many older and more well-established players in the market still do (over 10 years after .NET’s debut).

That’s not to say you can’t program against it if you want to; developers can write full featured extension in .NET, and they often know tricks to make InfoPath and SharePoint do things that go well beyond out-of-the-box capabilities. We've found that many additional things can be done if you're willing to add custom web services to the mix (also true for Nintex, to be completely fair). For example, we built a set of web services for one of our clients that allows them to move and copy Documents Sets around in SharePoint using AgilePoint, and it also implements structured creation of new team sites which is an important aspect to SharePoint governance.

Finally, the very low cost of AgilePoint's Genesis product is a significant advantage, putting it within reach of smaller companies and even single-project level budgets. AgilePoint's Enterprise Edition is traditionally a product costing five-figures; however they recently reduced their pricing quite substantially to be competitive in the SharePoint market. For 100 users, a typical annual fee for Genesis with AgileReports and InfoPath support would be less than $5k, and governments and non-profits get even better pricing. They've also proven to be flexible about selling additional components a-la-carte from the higher edition of the product if you only need a few. It's worth pointing out that even at the Enterprise price, it holds its own nicely against many six and even seven figure alternatives.

For up to date AgilePoint pricing or other product information, please fill out our short request form. You'll be taken to their product information and download page afterwards If you decide to download the free version, please let them know we sent you.
By now you probably realize that I truly love working with this product. So, I will mention a couple of disadvantages, just to prove I am being completely honest.

Firstly, I have to say that while AgilePoint comes closer to the promise of developer free workflow than just about anyone else does, their system is still quite complex and you will need the help of an experienced consultant to really make it sing. (I swear I am not saying that just so that you'll hire us.) For simple workflows, you will be fine following the basic patterns for which there are many demos, and I think most business users could probably make minor adjustments to processes. This is where a ley AgilePoint strength can become a bit of a weakness, because it really lets you build these amazingly complicated workflows. Once something gets that complex, of course it is going to require a specialist.

Also, AgilePoint does have a runs-in-the-cloud option, but it lags behind Nintex in terms of support for Office 365. Last we heard, you can't initiate a workflow instance from inside a SharePoint Online list or document library. However, their support for Office 365 sites as part of a workflow that starts in some other way is pretty good. If you're running a hybrid farm scenario with one foot on-premises and one foot in the cloud, you might be able to work around this. Also, their technical team is pretty savvy, and I live in hope that they might catch up pretty soon.

Another drawback is that AgilePoint Genesis is reliant on InfoPath. That could be a strength, depending on how you look at it. Microsoft has promised that InfoPath will be a part of SharePoint until at least 2020, but they've pretty effectively bumbled the message to customers and partners alike about what we should use instead of InfoPath. AgilePoint does have their own forms engine that is part of their enterprise product, and we're hoping to see some flavor of that included into Genesis edition so we can offer an option for folks trying to actively avoid InfoPath in their solutions.

One final note is that we've learned that very, very large forms could cripple the ability to do parallel process. This is because each step in the AgilePoint process is a view in the same InfoPath document; two people can't edit the document at the same time. However, it's possible to work around this issue, by designing you processes with this limitation in mind.

All in all, we find that AgilePoint pros far outweigh the cons. If you want a six-figure BPMS at a four-figure price and would like to avoid spending millions of dollars to support a system that might see fewer actual workflows implemented on it than I have fingers on one hand, skip the big boys and build it in AgilePoint.


K2 BlackPearl and BlackPoint, its lightweight SharePoint version, are great products built on .NET technology and well suited to strong integration with SharePoint. K2 has been around a long time, and as a result their product has a great feature set. They were the dominant player in SharePoint workflow until Nintex came along and ate their lunch as people made the switch from 2007 to 2010.

K2 has good integration with products that are not SharePoint. In fact, I'd describe their flagship product is a standalone workflow product that just happens to play really well with SharePoint. As such you won't have any serious issues using it to connect to Oracle or other non-Microsoft systems - though it is built on Microsoft so it's going to be stronger in that scenario.

In some ways, I feel a little bit guilty - as if my review of K2 should be a little bit longer. However, simply put, they're far too expensive for my taste. It costs a lot to buy, there aren't that many people who know if really well, and development isn't lightweight enough to give to the business users, so there will always be a development cost for using it.

My recommendation is that if you already leverage K2 in your enterprise, then using it in SharePoint is a no brainer; if you haven't already got it In house, you should weigh it against the other options available.

(More of my thoughts on this are now in the comments; thanks to the community for challenging my thinking on this.)


As a BPMS platform, MetaStorm has considerable strengths. Its primary focuses are on forms creation and business process modeling (i.e., analyzing and optimizing a flow that is not well understood in order to improve it). Its proprietary forms creation mechanisms are fairly robust, and they are fully integrated with its process flows. In addition, it can be integrated with Microsoft Office - a toolbar at the top allows work in MS Office applications to be integrated into MetaStorm processes, once the MetaStorm client has been installed. MetaStorm's design philosophy was to create a "One-stop shop" where flows, forms, reports and dashboards can all be created and managed within the same interface. For those who are adept with that interface, this can be an enormous advantage.

However, MetaStorm's weaknesses make it less than ideal for managing the workflow within SharePoint.

To begin with, while both products make the claim that they are integrated with SharePoint, it is very important to point out that MetaStorm is only “loosely” integrated with SharePoint. It offers web parts that are "windows" into the MetaStorm engine, allowing access to forms and dashboards, but these web parts can't be used to create MetaStorm elements, they merely interact with them. The actual forms and processes are housed entirely within the MetaStorm server, and users of the web parts are frequently directed to external web pages within that server. Sometimes web users are forced to accept functionality that is much more limited than that provided by the MS Office add-on.

The connections to SharePoint processes are not native and need considerable configuration and technical expertise. While MetaStorm processes and forms used solely within that product can indeed be developed by mid-level Information Workers, the ability to wire MetaStorm flows to SharePoint at various connection points requires strong developer-level skills; it is our opinion that it's a tool best suited for large organizations where an entire IT department exists to create and modify workflow, where that department can be trained on the use of a specialized, proprietary tool. There would be a substantial technical cost for most organizations to acquire these additional skills on top of skills in SharePoint development.

On a recently completed project, we had approached the company to show us how we might do manipulation of SharePoint sites, documents, and other assets from within MetaStorm. What we found was that this always came down to custom code. OpenText does have some impressive libraries of scripts that can be used for this purpose and they seem willing enough to share; but I keep coming back to this - it is more code and it will need to be maintained.

Finally, we could find no example of anyone leveraging InfoPath as the form repository with MetaStorm as the BPMS nor could OpenText point us to one, although this issue may pale compared to the complete confusion regarding Microsoft's plan vis-a-vis the future of InfoPath.

MetaStorm has been around for a while under different names and companies. It has both a Java version and a .NET version. Parts of the .NET version of their process engine pre-date .NET and require higher-level developer knowledge to program or troubleshoot. What will happen to MetaStorm in the future is really unclear to us, since OpenText also owns a couple other workflow products including the formerly known Global360.

For these reasons, we don't generally recommend trying to implement SharePoint workflow in MetaStorm. It's not necessarily a bad product, but it just doesn't seem like the right product for the job 99% of the time.

Other BPMS Products

The vast majority of BPMS products come from the IBM technology space, are written in Java, and they typically do not integrate with SharePoint at all. This makes the set of developer skills required to build and maintain flows in those products far different from the set needed for managing SharePoint. Many are also cost prohibitive. In an environment where SharePoint already exists this would certainly drive up costs beyond what is reasonable. In general, I don't think it's such a great idea to use these systems combined with SharePoint - YMMV.

SharePoint Workflow? Why Not Zoidberg?

If I had to pick a favorite from the list above, I would have a very hard time choosing between AgilePoint and Nintex. So, here's where I have to ask the question that I do not hear people asking very often. If these different products have such different strengths and weaknesses, why not simple use more than one?

I happen to think that's a great idea. Use Nintex for your quick-and-dirty, self service, six-guns blazing, SharePoint workflows that will work really well with the lazier faire approach to SharePoint collaboration - particularly in Office 365. Use AgilePoint to develop complex or long-running processes that will improve the maturity level of your organization and require continual adaptation and improvement. Especially when you look at prices for both AgilePoint Genesis and Nintex for Office 365, you'll see that you can probably fit both of them into your budget easily.

Did you like this article or find it helpful in making a decision? Do you work for one of these companies and feel like I didn't give your product a fair shake or left something out? Perhaps you've used one of these products in your organization and have an experience or opinion you'd like to share. Leave me something in the comments, subscribe to my blog (see upper right of this page), tell your friends about us, or give us a 5.0 on PinPoint - it's cheaper than buying me a beer and won't get lost in the mail.

----------------Comments from the old blog---------------------

12/12/2013, 7:17:50 AM
Great write up and very useful for anyone wanting to make a decision on choosing the right workflow/BPM tool for their SharePoint. 
Thanks and keep them coming!

12/12/2013, 11:25:46 AM
K2 is a fantastic product. It provides simple and easy approach to bringing data, forms and workflow capabilities together into applications that are configured. Reuse is at the core and configuration is everywhere. This is where I see the product lending itself for people to learn it quickly and leverage it massively.

12/12/2013, 11:46:04 AM
Your experience with K2 must be very outdated, as web based designers allow everyone to build processes. K2 also integerates with any .Net service application such CMS, SalesForce, SAS, etc., so there really are no limits.  
As to the price, well it is true that you get what you pay for. 
Too many of the SharePoint integrated BPMS products, especially those built on SharePoint Declarative Workflows (ah... extensions of SharePoint Designer), are too dependent on Microsoft not making any changes, and tend to break when SP Service Packs are rolled out.

Thomas Carpe
12/12/2013, 12:01:30 PM
Dayv and Jay, 
I agree with you that K2 is an excellent product. They've been around for several versions of SharePoint and so their feature set it robust and mature. 
I do not agree that it is a problem of you get what you pay for, as all these products are excellent for what they were designed to do. From my point of view, the main challenge with getting customers to adopt K2 has always been price, and that goes for any large scale product (take AvePoint's DocAve as one example). Especially since 2009, there's been a lot of downward pressure in the marketplace and with the appetization of the SharePoint market it is a challenge to get any but the largest enterprise to adopt a five or six figure solution no matter what bells, whistles, and unicorns are included in the box.  
Workflow (and the need for BPM) often starts at the project level and not in the enterprise - at least that's my experience where I have seen it succeed, and therefore the means are going to be on a much smaller scale in general. In particular, Office 365 customers have especially small budgets. 
I wouldn't say that my experience with K2 is limited, but I do admit that it is a bit out of date. The last time I used the product in a solution was on the SP2007 platform and at that time the engine was reliant on Workflow Foundation and thus had all the same fundamental flaws that Dayv describes regarding patching regimens and such. 
One thing I do feel like I need to rebut about your comments on declarative workflows: what you say about anything relying on SPD workflow, XOML, etc. is absolutely correct. One might say that same is true with WFE as a service packs and Microsoft product upgrades will almost certainly break workflow - just look at what happened with SP2010 vs. 2013 and workflow. However, AgilePoint's declarative model is their own XML schema and not based on XOML at all; therefore it has none of those drawbacks. In my view it has proven to be very reliable. 
It seems not we've heard a bit from some folks from K2, and I do appreciate that since my review of that product is a bit sparse and I think people need to hear about what it can do well in addition to where it falls short. I may take another look at the product if the opportunity presents itself.

Renier Britz
12/12/2013, 2:49:50 PM
Hi Thomas, 
Thank you for taking the time to put this post together.  
To be completely transparent, I work for K2.  
The first thing, you are correct by saying that K2 relies on Workflow Foundation our runtime execution engine is built on workflow foundation, to date we have never been disrupted by any updates on Windows Workflow Foundation. SharePoint ships with a workflow runtime that is also build on top of windows workflow foundation. You called out SP 2010 vs SP 2013 workflows, it’s not because of changes to Windows Workflow Foundation it is because of changes to the implementation of workflow runtime on top of workflow foundation. K2 is unaffected by changes made on the SharePoint workflow runtime as we don’t rely on the SharePoint workflow runtime and therefore don’t inherent the same set of limitations. 
The second point I would like to address: Pricing – as you mentioned “Workflow (and the need for BPM) often starts at the project level and not in the enterprise” I agree 100%. K2 pricing is competitive and allows organizations to start small, in many cases started on department level. We have more options in the works, lookout for major announcements in March ’14 at the K2 User Conference. 
Now back to what this is all about, workflow tools for SharePoint – With SharePoint 2013 Microsoft made a ton of existing enhancements, the app model being one of the most interesting changes. We had a choice, take what we have and make it work on SharePoint 2013 OR take full advantage of the changes and build something that will truly change the way people create forms and workflow-driven apps on the SharePoint platform (emphasis on create, this should not be a developer only play). The easiest way to get familiar with what K2 has to offer, go and have a look at the following recorded webcast: 
If you have any questions let me know. 

Thomas Carpe
12/12/2013, 3:15:45 PM
Thanks for sharing. I really do appreciate getting an outside perspective on K2. Our goal is always to make sure our customers get the right solution that works for them, which as I said before is one of the reasons that I may seem a bit ambivalent when it comes SharePoint workflow and third-party products. 
Going to what you said about WFE, you are correct and I am sorry if I was less than clear on this. WFE is a sub-structure which is different from SharePoint workflow in the same way that is a sub-structure and not the same thing as the SharePoint API. What I was referring to in the comment about the move from 2010 to 2013 SP workflow is that there was a lot of shifting around in the way Microsoft implemented workflow between the two versions. 
Some of that may be like you said, part of a fundamental shift in the way Microsoft wants developers to deliver on the platform. Back in July, I heard Ira Fuchs present on the differences between SP workflow in 2010 and 2013 and I have to say that I was not impressed at the loss of capabilities on the new model and that MS has basically said that if you don't like the takeaways well then you can still build SPD 2010 workflows instead. 
Maybe they will provide it later - maybe not. Either way, if you can't manipulate SharePoint with it, what was the point in Microsoft making the update in the first place? For now, all the third-party workflow products are safe until MS figures out how to do it right, but after 5+ versions I'm not holding my breath. 
At any rate, it's all part of a big shift to client side code, and like many people in the SharePoint development world I have mixed feelings about that too - and I am not fully sure that I can say I trust MS to deliver a framework that will be a place where we can exceed our client's expectations - at least in the near term future, since they usually take their time and a few tries before they do anything right. ;-) 
I do look forward to seeing what you guys are cooking for next year. Perhaps I will revisit this topic then, or take a more detailed look into K2 at that point. 
By the way, I maintained your product link in the comment. Make sure to hit your bosses up for a Christmas bonus and have a great holiday. ;-)

Steven Bretti
12/12/2013, 8:58:04 PM
K2 is a serious BPM product that allows for a number of capabilities that cover business needs very well. Forms, Data, Workflow and Reporting. It empowers the business users with simple user interfaces and no-code solutions. 
I think this is its biggest advantage, the ability to provide no-code solutions not just for the workflow, but also for capturing data through K2 smartforms, and any CRUD based requirements through K2 smartobjects without having to write code. Purely point and click through the UI. 
Yet it still has the capability to scale this out at a later stage to do more advanced business automation. 
This is important. You want to buy one product to cover the enterprise needs, rather than have multiple tools that you're paying multiple licences for. 
K2 can live within your SharePoint solution as a seamless application, or it can live on its own. It is not limited by SharePoint. It also provides integration options to common enterprise systems such as CRM, Salesforce and other LoB systems. 
Definitely a product worth considering in any BPM based solution, whether you are looking at it for a SharePoint based solution, or for your enterprise needs. I think it covers both very well, and priced accordingly.

Thomas Carpe
12/13/2013, 5:52:12 PM
Thank you steven for your insights. 
I do think that what you're saying about is probably true for any enterprise class BPMS product include AgilePoint Enterprise Edition. K2 also has a light-weight version that runs in SharePoint alone as I understand it, so to be fair I think I'd compare *that* version to Genesis and Nintex. It just seems a bit unfair to me to judge different weapons manufacturers by comparing a tank to a rifle. ;-) 
I have to say, I've noticed that this blog has gotten a lot of attention from the folks at K2. Their marketing department must be really good about getting the word out. I certainly don't mind since it's great exposure and a love a vigorous debate. It would also be cool to see hear some more from some of those people from in the original survey who voted for Nintex and AgilePoint. ^_^

Thomas Carpe
12/13/2013, 6:06:16 PM
Decided to check in on the original survey and see if things were still holding neck and neck or if there might be some trends. I was surprised to see today that AO is pulling ahead at almost 40% and Nintex is not too far behind. 
You folks who love K2 may have a point, but the survey seems to be saying something slightly different. Well, it's a web-poll so I guess you can't take these things too seriously, right? ^_^
12/16/2013, 11:36:50 AM
Hi Thomas, 
Thanks for a very interesting article. I do not have any experience with Nintex or Agilepoint but your comparisons and descriptions of them has been interesting. I do however have more than 10 years’ experience with K2 and I’d like to add to your review of K2 – and in fact compare it more closely to what you have written about Nintex and Agilepoint, especially since as you said you did not have a lot to write about K2, maybe this will be helpful.  
K2 vs Nintex 
Building simple SharePoint only workflows in either tool I guess is going to be a matter of preference. However the fact that the Nintex workflows run on the WFE vs K2 having its own dedicated execution engine is quite a big drawback. I guess that could even out if K2 is installed on a very small single server footprint, but I really like the fact that K2 can easily scale and a process that starts out simple now can grow as your organization’s needs grows. I believe that Nintex workflow reporting data is only stored for something like 90 days - In K2 this is not an issue at all as all data is stored in K2’s own databases and can be stored indefinitely or archived after a period of time. The other drawback for Nintex is complicated workflows as you mention – should not be a problem with K2.  
K2 vs AP 
You mention long running processes as a major feature and benefit, something that K2 is also good at, as mentioned above. K2 processes are versioned so by default process instances remain on the process version it started on (which is a good thing imo). Tools exist to manage cross process version migrations if that is really necessary. The ability to create K2 workflows inside Visio has existed since the late 2000’s but I guess it never really caught on with customers, since the K2 UI is already so user friendly and easy to use that the Visio UI components disappeared from the scene and frankly I do not miss them – so me personally… not to excited about building processes inside Visio in AgilePoint. It sounds almost like building forms inside MS Word.. the tool does not fit the job. I have not seen AP’s implementation of this, but that is just my opinion of it. Ease of use, non-developers making changes while still having flexibility to create amazing add-on components can all be done in K2, just like in AP. Your point about needing a consultant to “really make it sing”… I like the way you put it, and that’s also true for K2, but again it’s probably fair enough because in any such a complicated platform you will need a specialist to really bring it to its full potential.  
So from the information on your blog it seems to me that K2 is really not that different than Nintex or AgilePoint - and I guess you are right in that you will have to know your requirements for a workflow product very well and only with that in mind can you really decide amongst these contenders. Personally my vote will go for K2 because I am confident that I can really build any solution on it and scale it well into the future.  

Thomas Carpe
12/16/2013, 12:29:47 PM
All your points are well taken. This was the best read on K2 that I have seen yet, and yes I think you really are helping to create a complete picture which is great. I've gotten a lot of good information about a product I admittedly knew less about. 
I'd like to throw in a few Segway comments if I might, that were just sort of inspired by your remarks. 
The first is about Visio and its relationship to workflow. If I were diagramming a workflow or business process without any sort of BPA behind it, obviously I would diagram that in Visio using a flow chart. That's a no brainer. 
Over the years, I've used a variety of tools including BizTalk and yes sometimes even SharePoint Designer, and I've always been disappointed in their sad attempts to integrate with Visio. I never used the tools for Visio and K2 either, so I can't comment if they're better than the ones I've used. 
AgilePoint was the first product that I saw where I could basically map out my entire flow as a drawing and then publish it and refine the properties etc. In that aspect my biggest frustration is often that I get a flow chart in Visio from a business analyst and I have to re-draw the entire thing using AP shapes. The thing that I really like about it is that when it shows the status of my workflow in SharePoint it uses my actual Visio drawing to display it, including any custom shapes and comments I might add to it. There's an image up on this blog post as an example. Somehow people just really like seeing where their process it; and having the flexibility to display it in ways other than a cascading downward waterfall is great for me. If some other products can do that for me, yes I would really like to see that. So, maybe you don't go squeeeeee over Visio, and that's OK, but I see real value in using it. 
The other thing I thought of here is that it does generally depend on the developer's confidence in a product. And, confidence is generally a function of experience. We need those past products to help us understand the capabilities and also the limits of the products we are working with. This is true of SharePoint, and also I think that's true of any product including the workflow products we've been discussing here. In the end I think we will support those products where we have the most positive experiences and tend to drift away from products where we have negative experiences - or insufficient ones. And with that in mind, it's more than just a technical question but also a question of the marketplace. Though I worked with it before, my small firm couldn't find and win K2 projects at the time when we really started doing business, which was 2010. Thus, we never really developed that affection for the product. We got some lucky breaks working with AP and found that we were able to do some really impressive things with it, and at the same time there were a lot of clients asking for Nintex because their needs were less complex and they liked what the product could do. 
For this reason, I think you can't necessarily read what I've had to say all along as a recommendation per-se; rather it's a comparison based on my personal experience. If someone is looking for impartial analysis to choose a product, there's Forrester and Gartner etc. My hope is that we can help people to understand what we're able to work with as consultants and developers, and sort of which types of projects we've found that these products do a good job at meeting the requirements. To that end, I think there's no right or wrong answer to the question at the top of this article. 
That being said, if we can all manage to argue about it for just a little bit longer, I think everyone will benefit from the free publicity. ;-)

Mike Fitzmaurice
12/20/2013, 11:22:35 AM
Full disclosure: I am an employee of Nintex. 
I love blog posts that spark discussion — especially when Nintex is part of that discussion. Looking amid the fray, what’s quite apparent is that the wonderful world of SharePoint workflow solutions is alive, well, and worthy of plenty of enthusiasm. And that’s a Good Thing.

Thomas Carpe
12/20/2013, 12:10:45 PM
Good to hear from you. I completely agree! More information is always a good thing, and I enjoyed hearing from everyone on this. 
As a Nintex person, I do have a question for you. Did the changes to SharePoint workflow architecture in SP2013 cause any significant changes in the way that Nintex Workflow runs or is licensed on SP2013 as opposed to 2010? For example, I understand that now in 2013 all the workflow is supposed to run on its own service and not on the WFE anymore, so do you guys still sell it by the number of servers in the farm and did you find that this change has improved performance or scalability over the older version of SharePoint?

2/12/2014, 1:03:16 PM
Biggest downsides of Nintex: 
1. Workflow data and history are stored in mulitple locations. If you run into any issues with a workflow or the databases, it's extremely difficult to manage and control the workflow data. Their best practices are extremely cumbersome and not database friendly. 
2. Rollbacks are next to impossible. If you need to roll back a deployment, you will be SOL. You will need to copy the entire web app and nintex DB onto another environment. 
3. Documentation seems to have been written by a crossword puzzle designer. Info and steps are broken up between God knows how many docs. Best of luck.
3/25/2014, 6:56:56 PM
I think you need to investigate more of Sharepoint 2013 workflow manager and service bus as this is a highly scalable product, even more than Nintex, NIntex runs on wfe servers, but with workflow manager you can have a separate farm for workflows, which makes it an amazing product. 
This comparisson without comparing the ootb product makes no sense to me.

Thomas Carpe
3/27/2014, 1:18:53 PM
Hi Luis, 
While we haven't done a great number of solutions based on SPD workflow lately, I can say that I've done a lot of these over the years. I understand there were a lot of improvements in the architecture of workflow on SP2013. However, my issues with it are more a question of what features existed in 2010 workflows that were not carried over to the new version. You should check out Ira Fuchs' presentations on SharePoint workflow; I agree with a lot of his points. Beyond that, it is just a matter of the fact that we're now several major versions into SharePoint and yet the workflow portion of the product has had major shifts with each one. From a business perspective it is a real challenge to get someone to invest in technology that will have a shelf life of just a few years. 
That being said, I do have some customers who are asking what they can do with OoTB workflow and if something comes along that changes my opinion I will be sure to share it on the blog.

3/28/2014, 4:55:43 AM
Nintex is good, but only for simple workflows. Also it's forms application is terrible from what I've heard. 
K2 - much better when it comes to more complex workflows. Altough with high barrier to entry. Additionaly my customers say forms application has lots of bugs and performance issues. 
AgilePoint is the closer to BPM than simple workflow here. Although visio and their graphic designer have their limitations. 
You may want to check out WEBCON BPS. Forms and workflows (and business processes) in one application. Graphical designer, changes in processes can be done on the fly (no need to publish new version) and you also get plenty of DMS capabilities along with OCR, barcodes etc. On the downsize: it doesn't support cloud.

3/30/2014, 11:06:56 AM
Great review !!! 
nowadays I actually need to decide between nintex and agile point for our company . 
I still a bit confused regarding the strength of nintex compared to agile point . since agile point uses an external and separate server ,hence processing resources ,from share point itself (it's agnostic to SharePoint) and it cost about the same as nintex what's the question here ? would you say that nintex is not up to complexed and long processes managing ? 
from the review it seems like agile point is perfect if you have the time and human resources to invest in learning it's foundations and from the moment you get it it's one league above nintex for the same $ so what's the dilemma? or am I missing something here..... 

Thomas Carpe
3/31/2014, 10:13:57 AM
First I want to thank everyone who has made this a very active thread since it was posted back in December. You guys rock. 
Alex, to answer your question, there are differences between the two products that might affect your choice. 
AgilePoint has a forms engine also, but until recently they were using InfoPath as their main forms engine for Genesis. The Nintex forms engine has been a part of the product for a long time. If you are looking for an escape from InfoPath, this might be your option although AgilePoint is catching up fast. 
Nintex has been ahead on Office 365 development for quite a while. We are still waiting eagerly for an offering from AgilePoint but unfortunately it is still vaporware at this point. 
Nintex has pretty good support but they are a huge company. If your needs are complex they will probably connect you with a random partner. AgilePoint is a smaller shop and you would get to know the development team personally. 
AgilePoint server is a separate install. It can be configured to run on one of the SharePoint servers if necessary. There are different options if you are running SP2010 or SP2013 because of the .NET framework 3.5/4.0 difference. IMHO, the 4.0 version is much better. The installer varies a bit among the different builds and sometimes there are issues setting up advanced features such as data export. Nintex installer is pretty tight, but the options are fairly standard - NW 2010 or NW 2013. 
There are designer differences. Nintex designer is a web based tool built into SharePoint. If you have Visio aleady, then using it for AgilePoint will not bother you. If you don't have it, then the extra licensing cost for it will be another obstacle. Nintex charges by the number of WFE in your farm, and to the best of my knowledge there's no extra cost per user. 
Because as you mentioned, it is more system agnostic, AgilePoint will integrate well with more third-party systems. Both will do just about anything you want via calls to web services if you have that option. 
And off the top of my head that's about all I could think of today, but I hope it will help you.

pravesh kumar sharma
4/15/2014, 2:40:37 AM
i agree with most of the point which you have mentioned in blog .. i have worked on SharePoint and Skelta BPM tool for 8 years.. Technical and functional point of view.. 
i would like to add some points.. 
1. most of the enterprise tools having workflow capabilities (ERP,CRM, CCM, SCM etc. even MOSS) but that is very limited to its own suit. 
2. SP workflow does not have capability of process life cycle(designing, deploying, monitoring etc.) 
3. BPM engagement starts from Business point of view keeping in mind many factors (SOA, agility etc..), but workflow initiatives most of the time comes from IT initiatives and just customization of some small process 
4. workflow required customization most of the time whereas BPM suits having its own OTB modal like designing process, reports, UI and readymade LOBs connectors. 
5. SP workflow is very limited to SharePoint artifacts like DL, List, InfoPath, outlook etc.. whereas BPM starts from automating process via connecting machines to machine(SAP, oracle, SQL etc.) and people to people(Fin to HR to Procurement to Admin etc.) 
6. BPM provides BAM components and monitoring tool for KPI, MIS, graphical reports for Process and data in order to Optimize the process 
7. in last but not the least.. BPM is superset of workflow  

Thomas Carpe
4/15/2014, 8:25:39 AM
Thank you Pravesh for your comments. I agree with basically everything you have said here. If there were a line representing a maturity model, SP workflow would be on the lower-left end of that line, and BPM would be at the upper-right. Products like Nintex sit somewhere in the middle. It is important to understand that BPM goes well beyond what SharePoint does - or tries to do - and that these different tools serve different needs.

4/17/2014, 1:44:43 PM
Excellent overview and comments. We are using SP2010 OOB and a big issue we have is that it's so hard to troubleshoot a misbehaving WF. I'd be interested in hearing from Nintex and K2 "light" users on how well or poorly those products might address this.

Ahmed Mostafa
5/14/2014, 3:30:27 AM
I like this article. I have used K2 on a number of engagements for my clients. What I really want to investigate is ECM dimension. I believe the way SP stores fields and attachments together in SQL is a big drawback that affects the total performance. Have any of these vendors addressed this issue? how do they store their attachments and meta data?

Michael Mangan
11/10/2014, 9:24:11 AM
One of our specific requirements is to embed the workflow approval as a digital stamp on the document, do any of the solutions support this?  
I really appreciate this blog. Thanks

2/20/2015, 2:56:44 PM
Excellent article, Thanks all, hang around everyone will learn from each
3/6/2015, 4:53:31 AM
flowchart likes diagrams can be drawn from many visio alternatives as well. Its ok to use a visio alternative if it is online as platform indepedent

Cierra Luke
4/24/2015, 2:51:32 AM
Hi Thomas, 
Thanks for this helpful post. I a professional software solution provider in a web designing and development company. We have been using MetaStrom from last 3 years, but now our CEO wants a new BPM software to manage our workflow and processes. Can you suggest any good one? 
Thanks in advance

Thomas Carpe
4/24/2015, 10:57:26 AM
Thanks to everyone for the comments and questions. Haven't gotten the chance to come back here and reply very often, which I regret. Business has been getting quite active - perhaps the economy has finally really turned a corner? Will post some replies now to try and catch up. 
In the question of lite versions of Nintex and K2, I can't really make the comparison since I have seen the Workgroup and cloud versions of Nintex but have not played around much with K2. An old friend of mine, Mark McGovern recently went over to a new job at K2, and perhaps he can connect somebody with a person there who can speak to their product line. 
From what I know of the products we work with often, I would say that the workflow engine that drives the process will be the same in the lite version as in the enterprise edition. That's just good software development, because who wants to maintain two build sets. right? That being said where I think you'll see differences is in things like number of allowed users, what activities/actions you can perform in a workflow, etc. 
Moving on the SharePoint Foundation 2013 and the workflow product that Microsoft has produced. We've done some projects lately where this was required, because the customer did not have a budget to purchase another product. If you must go this way, I think you'll survive. But, I still feel like the MS workflow manager is not as robust as any of the products I talked about in this blog, and probably even Bamboo and Datapolis have something to offer that it does not. The new version has the disadvantage of needing to be installed on a seperate server from the SharePoint farm. Otherwise, you're stuck with SP 2010 workflows. Yes, I realize maybe I am talking out of both sides of my mouth here, because I will say the same thing is a feature of products such as AgilePoint which can be installed on their own server - however, it is possible to install AgilePoint on the SharePoint server if necessary and they cohabit quite nicely. I've never had anyone recommend to me that this is possible with MSWM. So there's the distinction in my mind. I also know that many of the activities that were possible in SP2010 workflow are no longer available in WM/2013. Haven't looked into it lately, so maybe that's changed. However the laundry list of takebacks was quite lengthy last I heard and MS would have serious catching up to do to make it comparable to what it was in the previous version. Anyone who wants to know the current status should seek out Ira Fuchs, as he's the guy that I have learned so much from in the past and can tell you what Microsoft is doing now at a level of detail that would just go beyond my own knowledge. 
If you find yourself in the unenviable position of working with SharePoint OOTB workflow, I believe you will find that it gets the job done well enough for simple processes. We use it all the time in Office 365 where it is a built in part of the feature set and I don't have to worry over things like who installed the extra server on the farm. I like it quite a lot when I need a short workflow to produce the same kind of behavior on SharePoint Online that in past years I might have been able to do with a List Item Event Receiver or Timer Job instead. But, like anything you get what you pay for, and I think with SP workflow what you gain by not buying a product is offset because it is back to IT people having to implement the workflow and there's a lot that business users will not be able to figure out for themselves. Since all the big players now have cloud capable versions of their workflow products, there's no reason to be stuck in this situation. 
Speaking of the lightweight and OOTB workflow in SharePoint, one product that came up on my radar recently was KissFlow. This product uses Zapier to integrate with other cloud products and says it has a connector connector to Office 365. While they don't offer one yet for SharePoint, look for them to become a major force in the market if that ever changes. The current lack of a proper connection to SharePoint is a major shortcoming IMHO and an opportunity for somebody. 
On the question of whether it is OK to develop workflow using online tools instead of Visio, I think this is just a question of personal preference. To be honest with you, I have tried many cloud platforms over the years - not just workflow - and for something really complex, I want to have the file on my desktop and not have to rely on a web browser to properly render it. I find cloud based development to be well over that magic 400ms threshold where my mind will wander and eventually I find myself checking email and standing up to get a cup of coffee. That being said, this is my criteria and for you the pros and cons may be different. Web based platforms have the advantage of being workable from anywhere regardless of what software you have. One thing I really like about AgilePoint by the way is that you can now choose either method to develop a workflow, so if you like Visio use Visio and if you like the browser use the browser. :-) 
On the most recent question about Metastorm. That's a tough one. I did a thorough analysis of Metastorm for a client a couple years ago, and I have to say that while it was a powerful product, it was definitely showing its age and there were lots of things that made it a poor fit for our project. 
That being said, without detailed criteria, it is impossible to say which product you should switch to if you're moving away from Metastorm. For example, you need to consider what processes you already have in that platform and whether you are using it like a BPMS or are the workflows you already have actually quite simple. Obviously, if you have a lot built on the Metastorm platform, you are going to need something equally robust which is going to take you toward the K2 and AgilePoint end of the spectrum. If your lack of satisfaction comes from feeling that you never fully utilized the product feature set, then maybe going with a simpler solution like Nintex or SP workflow would be the way to go. 
Hopefully this helps you realize that the problem is a really complex one and can't be easily solved with a one size fits all answer. "It depends." Classic consultant response, am I right? :-) So, go back and start asking the detailed questions and I think the answer will present itself. Best of luck!

Thomas Carpe
4/24/2015, 11:02:09 AM
I was reading my own old posts and wanted to chime in to remind everyone that you can now subscribe to MS Visio in Office 365, so that's another barrier to entry that's come down. If you need a quote for anything Office 365 related, follow the links to contact us and we'll do that for you. :-)

Brian Garnica
4/27/2015, 1:49:46 PM
It was really good to read this article!! Excellent job about comparing different products. We had been making some research to offer the right option to our customer. 
Thomas Carpe
4/27/2015, 3:36:33 PM
Brain, thanks for the whuffie. Feedback about the blog posts is always appreciated, as they're a labor of love. Hope your customer makes a good choice; it is always a complex decision figuring out which horse to hitch your wagon to. ;-)
7/8/2015, 3:16:23 AM
just to make it clear i dont work for any of these companies but I am a sharepoint developer from 2003 to 2013 so far. I have used k2 2003, black pearl and now nintex. nintex by far is seriously bad for complex worflows and time consuming. K2 is far better in complex workflows that span over time. plus i dont care what people think of what they like but care more about what business use.... in my experience in the uk the majority of banks and consultant companies use K2. the place i work for at the moment are using nintex and they already regret it.
Thomas Carpe
7/8/2015, 12:08:11 PM
Good to hear from you. 
I am so surprised this post still attracts comments so long after I wrote it! It seems everyone has strong feelings about this stuff. 
I was more familliar with Black Pearl and Black Point back in the 2003-2007 days and really started drifting away from it in 2010. With AppIt from K2 released now as well as AgilePoint NX One cloud offering and new pricing models for Nintex on Office 365 too, I feel like maybe this topic is due for a revisit. There are so many more exciting possibilities to choose from this year than there've ever been before, especially if you don't have the luxury of managing your own SharePoint farm. 
I imagine that market share for the big workflow software products varies by country and type of company. It's my understanding that Nintex has the most market share overall when it comes to SharePoint - I wouldn't be shocked if Microsoft buys them outright - but there will be local differences in different places around the world and various sizes and types of companies. That being said, my feeling is that who's on top shouldn't be the way that companies decide what product to choose. You have to go with your experiences and those of others in the community, and I am grateful for everyone who shared here because it gives me a good sense of what people are seeing outside of my own little world. 
You're definitely not the first person I've heard express some negatives about a particular product. I think that each case is different and you have to consider the pluses and minuses individually, and that the market and the best choice is a moving target. I still have to say that whatever the down sides may be, almost any product would be better than the OOTB experience in SharePoint. 

How to Generate Proposals 376% Faster Using SharePoint

In a previous case study and white paper, I described how to make proposal generation a snap using SharePoint's Document Set feature for quick proposals, and site templates for more complicated RFP responses.

We used this method in house for a long time. One thing that struck me about this approach was that it still took a long time to get the proposals together. Also, even though we has a few good templates, it was often better to copy a winning proposal than it was to go back to our building blocks and start fresh. I wondered what we could do to make this process easier and get more mileage out of our existing library of written materials.

Thankfully, the technology to solve this problem has been around for quite a while - it just isn't part of SharePoint's out-of-the-box feature set. Today, I'm going to describe our solution to this challenge.

Document Automation and the Proposal Process
Did you ever wonder why Microsoft changed all of the extensions for Office documents, for example from .DOC to .DOCX? Well, it isn’t just because Microsoft has a long standing love-affair with the letter X - though they certainly do. It's actually because they made a switch to a new document format called OpenXML. Open XML is basically just a giant ZIP file (actually CAB, but whatever) full of XML files that describe Office documents.

What makes OpenXML significant is that it is the standard that lets us manipulate those documents. Aha! Now we've come back to my problem with proposals. (I bet you wondered where I was going with that tangent?) Previously, we've been able to manage our documents, but all the work we do with them has been manual. But, what if we can further automate the process?

In many ways, our proposals are not very different from those of other companies. A lot of this is dictated by the best practices of purchasing departments or government agencies.

Here's the basic structure of a typical proposal.

  1. Title Page
  2. Executive Summary
  3. About Us: History, Services We Provide, Locations, Etc.
  4. Capabilities:
    1. Certifications, Etc.
    2. Several Short Resumes for Staff*
    3. Products / Line Card*
  5. Past Performance:
    1. Customer Satisfaction
    2. Several Project References*
  6. Technical Approach
    1. Describe the Problem
    2. Methodology*
    3. Proposed Scope of Work
  7. Pricing, Terms, Etc.
  8. Appendix - pretty much anything that does not fit elsewhere

Essentially, this structure is pretty formulaic. We can trim this up, or expand it to hundreds of pages. Sometimes the customer will have RFP requirements that will force us to rearrange or rename the sections, but the same things appear over and over again.

Salespeople complain that these proposals take too much effort for too little reward. Often, the large ones end up being written by entire teams of people over several weeks. There's a lot of hand wringing about getting the tone to be consistent throughout the document - and there are often more opinions than there are people doing the work. For all the effort, often the chances of winning are very small.

However, our best and most successful proposals did not take very long to write. The reason for this is that most of the material above is repetitive - meaning it will appear in any proposal. The exceptions to this are the Executive Summary, The Technical Approach, and the Price. The less time we take to craft the rest of the document, the more likely we will have the time needed to craft a good proposal in the places that actually matter.

Rather than letting people have their way and just never write proposals, why not find a way to make them easier to do? There's something to be said for the fact that if you don't bid on an RFP your chances of winning are zero.

Document Automation by Brute Force
Notice that in the above list, I have marked some of the items with blue asterisk (*)?

The way we used to handle these sections was to have one big document called, for example, "Past Performance". It would have all our past projects and references that we might be inclined to use. Because there are lots of different kinds of SharePoint projects (and even more kinds of customers) this document would get pretty big. Same goes for staff biographies or the products that we sell. When a proposal would get created, we would paste the contents of only those items that we wanted to include for a particular proposal.

The other way to do it would be, for example, to have one document for each methodology section. These tend to be pretty large; they talk about for example how you would do an Intranet project differently from an Extranet project. We'd just paste the entire document directly into the target proposal.

For the asterisked items, this is how we would handle things. Sounds easy enough right? It has a couple of drawbacks though.

Firstly, it is pretty manually labor intensive. And, you need a person knowledgeable with Word to do it, or the formatting will get all screwed up. There's a large potential to make a mistake and forget to put in a particular reference. Believe it or not, this is the less serious of the two problems with this approach.

The other issue is that changes do not make it back into the master documents. For example, somebody who is doing a red-team review of a draft proposal might notice that there is some language in a paragraph that's confusing and so they revise it. If that paragraph came from our templates, then we'll make the same mistake on the next proposal; we might repeat the same work fixing it - or we might not catch it the next time through.

You can imagine this is a serious enough problem if you're just trying to write more professional looking documents, but consider this. It is not just your past experience or the qualifications of your staff that are different over time - the marketplace is always changing too. Because of these problems, our best work was often not giving us the repeat value that would have helped us win more business.

The Concept of Document Assembly
What you want instead is to reach that sweet spot, where you can reproduce success at a minimal cost. Each time you get a little bit better, and all the while you can adjust your tactics to deal with new information or moves from the competition. We found a way to do exactly that with OpenXML using a technique called document assembly.

The concept behind document assembly is really simple. It is basically a streamlined version of what Office already lets you do with copy-and-paste. The way it works is that you have many smaller documents - sometimes they may even be only a paragraph or two. For each one, you focus continual effort on making those two paragraphs the best that they can be. This is something you should be doing even when you don't have an RFP to work on, but it's especially important when there is a proposal due.

The key is to always make the changes to the master documents - unless they're a one-time thing for a particular proposal. Near the end of the proposal process, you use document assembly to piece together all the parts of the proposal. Make a couple of formatting changes and then send the document to the printer.

There are several benefits to doing things this way:

  • You can add metadata to each document "part" so that you know its status, where it belongs in the overall proposal, how recently it was updated, and what types of clients or jobs it's relevant to.
  • You can assign rights so that, for example, the resumes are always updated by HR staff and the past project summaries are always added by whoever led the project.
  • You can leave the really strong branding stuff out of your proposals until the very last minute. Often, really fancy branding stuff looks great but slows Word down a lot.
    You can have different document styles, such as a version for professional two-sided printing, a version for economy print or PDF, and a version for those pesky government bids that don't want color images or any fancy font-work.
  • If you don't like the results you get, you can easily rebuild from the template and source document parts.
  • If you liked the document format that you got, you can copy the template for next time. That's way better than just copying the finished product and then doing find-and-replace on the customer's name.

What Document Assembly Looks Like in SharePoint
But you don’t want to hear me going on and on about this stuff, right? Let's take a look at how we do this in SharePoint and you'll see how much easier it is.

We start in the Quick Proposals document library. This library has been set up with some SharePoint document sets (whose content type is called Proposal Set). That helps us keep track of data about separate proposals that might include one or more related documents. By the way, if you want more information on how we set up Proposal Sets and our Quick Proposals library, you can reach out to me for details.


From here, you can see our default view is Active Proposals. In our case an active proposal is one that is either "In Progress" or "Submitted". Today we don't actually have very many of those, because two of our most recent proposals were accepted - yay! So, there's not much in the queue today.

Let's make a new proposal for a client who called us this week. We switch to the Document tab on the ribbon and under the chevron for New Document we'll find Proposal Set. (You could also hit the big icon for New Document, since Proposal Set is the default - and only - option.)


In some cases, we might also include options here for Proposal Document and Proposal Document Link. These can be added when folks have a bad habit of dropping documents directly into the root of the Quick Proposals library before they've created a Proposal Set. Usually it's better to leave them out, so people have to create the Proposal Set first, but that's really a business decision.

From here, we need to enter some basic details about the proposal. Not all of these fields have to be filled out right away, but we do need to give the proposal set a name.


Personally, I find it really helpful to fill out all these fields from day 1. It helps with managing the proposal creation as a project, and I can use some views in SharePoint to generate reports for my business partners, Alara and Justin.

When you're done filling out the data you want, you hit OK and SharePoint will create the new Proposal Set.


Above, you can see the Proposal Set has been configured to show me all of the information I entered on the welcome page. This is useful for sharing the key data with my teammates who will help me generate the proposal documents.

We can customize the welcome page to include a variety of different things. For example, we can combine the Proposal Set with our Document Rules Engine to show KPIs for completed or missing documents or metadata. We can change the columns shown for individual documents, and even add custom web parts to this page.

Let's start creating some documents; there are two ways to do this. The first method is to configure SharePoint to create new documents each time a new Proposal Set is created, which is what we've done here. But, if the type of documents you'll create is going to vary a lot from proposal to proposal, you'll want to create them by hand.

You'll notice that we already have 2 documents in our Proposal Set. This was done to make the whole process fast and easy. We could have easily created these from the New Document menu in the ribbon.

The XLSX document is a worksheet that we can use to create estimates. The Word document is our DocxFusion Proposal Template. This document is customized for each company and specific print formats. Here's what ours looks like.


As you can see, this template contains all the styling for the proposal as well as placeholders for content that's going to come later from other canned documents we've already created. We also have some review comments to give guidance on how this proposal should be crafted.

Here's a close-up view of a content control that's being used as a placeholder, with reminders about the recommended length of each section.


You can customize the template now, by changing some of the copy or entering the name of the person it is intended for. Sometimes it is better to customize the output document, and sometimes it is better to customize the template.

We're going to go ahead now and build our final proposal from the template. To do this, click the chevron (or ellipses in SP 2013) and then click Build Document.


This will pull up the Build Document screen, where we can choose content to put into our proposal.


The left hand panel shows documents from a Templates library. This is where I've saved all my reusable proposal materials, including canned marketing copy, case studies, and short pieces describing the technical approach for different types of projects. Don't worry if you don't have all these things yet, because you can build your collection up as you go.

Above the left hand panel, you can see there's a dropdown to choose the view for the Templates library; I'm only looking at approved content right now. You could organize this in a variety of different ways.

By checking the documents on the left hand side and clicking the > and < buttons, I can copy them into different parts of my template document. I can also change the order using the Move Up and Move Down buttons, so things will appear in the order that I want them to later on.

Here's the list I decided to go with for the Black Mesa proposal. Specifically, since Black Mesa is in the defense industry, I only picked case studies for government agencies. Also, I only chose the Team Bios for people who will be working on the project as Key Staff, as well as recommendations and methodologies that apply to this opportunity.


When finished, I click Build to start the process of document assembly.

We're given a quick chance to add some metadata to the document, some of which will actually appear in the text of the document itself.


And now, voilà! Here's our new proposal.


Here's what our finished proposal looks like by the way. Very professional!

... and, well, you get the idea. Here's the back cover.


Where to from Here?
Of course, if that were all there was to do, then there wouldn't be any work left for the sales team! We can open the document and put in our finishing touches, additional content, etc. If you need to rebuild the proposal from the template, you can do so as many times as you'd like.

It's also possible to add content from image files, Excel workbooks, and PowerPoint slides using this approach. For example, I could complete my WBS worksheet and then include it under Schedule or Pricing sections.

Best of all, you can make updates to any of the template documents that will be included in any subsequent builds (for this or other proposals). You can re-use effective content from winning proposals quite easily.

Suddenly, bidding on those last minute proposals and adapting to the changing marketplace is no longer the bridge-too-far that it used to be. We liked this solution a lot; and other people have started asking about it. So, we've made it into a software product named Chimera. If you'd like to put this kind of solution to work at your business, you can contact me about it and we'll be happy to build you a proposal for it. ;-)