One of the really nice things about StackExchange is their willingness to develop communities based around nearly any topic. There's a process of following, definition, and commitment required to get any new community up and running to ensure it isn't just another dead site. This is all done on Area51 the StackExchange staging zone.

One of the new proposals I am pretty excited about is the App Stores site. It aims to fill in the gap with questions related to App Store deployment (Apple, Android, WP7, etc.) that aren't directly related to programming (StackOverflow) or design (User Experience).  From the proposal:

Proposed Q&A site for developers who have questions about the technical and business aspects of submitting apps to App Stores and Markets. (Typically for mobile, but not exclusively limited to.)

There are a lot of things to learn when it comes to app development - regardless of platform. Once you've designed, created, and tested your app it can seem like you should basically be done. Unfortunately, the last few steps of actually distributing your app(s) can be quite challenging - especially the first time.

There can be huge delays as you try and sort through the layers of policies and requirements. Trying to use outdated advice from Google is extremely frustrating and it can be pretty stressful trying to figure out the dynamics of an App Store when all you want to do is get your app out there.

I wish this site had been around the first times we submitted to the Apple App Store, Android Marketplace, Amazon Appstore and the WP7 Marketplace. Each had it's quirks and surprises. If you've had experience submitting to or working with any app store, consider following and then committing to this proposal. Let's take the lessons we've learned and share them. It's a great idea and will be a fantastic resource - so check it out!

One of the interesting things about the above Dilbert comic is that it contradicts the marketing campaigns of Apple, Google and Microsoft that imply anyone with a free weekend, some mild development talent, and a magical idea is practically guaranteed a million dollars. Can you make money developing apps? Absolutely. However, many starting developers and their mothers may be surprised to learn that there is a lot more to it than just making something that works.

I couldn't tell you the number of times people have found out that I am part of an app development company with multiple apps on multiple platforms and been amazed that I'm not making millions of dollars every month with all that sweet app money. After that there's usually a moment of awkwardness where they are trying to figure out how I screwed up something so obviously "easy".

It just isn't that simple. There's a lot that goes into a "successful" app that has nothing to do with traditional development. One of those things, is your app's price. You need great screenshots, marketing, luck, well written descriptions, reviews, more luck, etc., but if a customer isn't willing to pay whatever you're asking then, too bad. It's not my goal to discourage new developers/companies or to provide exact guidance on how to price your individual app. There are plenty of articles out there all about the "right formula" but I've not found them too helpful. What has been helpful are the few articles that give insight into specific experiences. I won't be giving out exact numbers due to licensing restrictions, but I still wanted to talk a little about our experiences with one of our apps, THE DOG.

THE DOG is a breed guide app featuring Artlist's beautiful and unique photographs of dogs and made in conjunction with 4Kids Entertainment. It is currently available for iOS and WP7 and the Android version will be available in the next couple of weeks.

We did some experimentation on the App Store (Apple) by setting our apps at a series of price points and comparing the number of downloads. Our guess was that at the higher prices we would have fewer downloads but higher overall profit. However, we found that the number of downloads was so much higher at $.99 that the profit was greater for that price point than any other.

We feel THE DOG is a quality app and well worth at least $4.99 considering that's a one time fee that includes lifetime updates, no ads, hundreds of photos, tons of information and more. We had some customers that agreed with us and purchased at that price and at the various prices between that and $.99 (Thank you!). However, even at $1.99 the number of downloads was less than half of what they were when we switched to $.99. Then considering that higher numbers of downloads leads to higher rankings within the store and therefore higher numbers of downloads and higher rankings... and so on, and it was a pretty easy choice for us to change the pricing.

I recently read this article, Microsoft Wants Expensive Apps on Windows Phone, and was a little conflicted. As a consumer of apps myself, I really enjoy the amazing low prices of some really cool software. But as a developer, I understand that the push from consumers for higher quality apps with more and more features, lifetime updates, beautiful graphics, and full social media integration all for $.99 or in many cases free - seems unsustainable (or at least unprofitable) using traditional development methodologies.

Overall, I like Microsoft's idea of increasing app prices (along with quality, integration, etc.) and am excited about the new opportunities with the upcoming Mango release, but the App Store has already set the trend that only truly exceptional or niche apps should be priced higher than $.99 if you are to have any sales.  Perhaps while the Marketplace is still relatively small (currently 20,000 apps), higher price points will be possible.  But with an influx of apps (competition) those price points are bound to drop.

Part of the problem for us developers is that none of the app platform companies are totally partnering with us.  They are providing amazing platforms, great tools (for free in nearly every case), ongoing support, community interaction and more. But they are also taking 30% of all sales and $99 a year from developers, effectively making us their customers/employees.

This means they have to balance enabling our success (after all they make the most money when we do) with keeping up an image of huge opportunity for little investment to keep us all coding. This sometimes leads to misleading or generic statistics that can often lead to disappointment for the vast number of developers (even some really good ones). It's hard to know what to include, when to release, and how much to invest - let alone how much to charge.

Going back to THE DOG, we decided to port the app to WP7 to try and get in early while the competition was still low. Android and iOS have many dog apps, and while we are confident that our app is as good and in most cases better than those apps, it can be easy to get lost in a sea of apps that all make similar claims. In addition, C# and the development environment (Visual Studio) for Windows Phone was already very familiar to us and made getting started very quick and easy. Porting the app required a complete rewrite from the iOS version but was still considerably easier than starting from scratch. This made the required investment relatively small and a worthwhile experiment.

We assumed that since the competition was so low, app sales would be as good or better than the iOS version. The iOS version is doing very well, unfortunately, as of right now the WP7 version is not(?). Actually, it's hard to tell if our app is doing well (at least relatively) without base line numbers to compare it to. But from our perspective of the amount of sales needed to justify the costs (let alone show a profit), it isn't cutting it.

I would suspect this has less to do with our app, and more to do with the size of the market. For now, the number of potential customers is just so much smaller for Windows Phone.

There are other things we can do and may try in the next couple of weeks (Trial mode, offer a free version, extensive marketing, etc.), but we are seeing similar results for another ported product - Panda! (iOS, WP7). Panda! is one of our only completely free apps (No charge and no ads) and is released mostly to make me laugh. Although, Panda! is also one of our only apps to not actually serve any useful purpose, people still like to download it. Even though it's free, we are seeing the same reduction in overall downloads as with THE DOG (WP7 downloads are at roughly 5-10% of iOS downloads for the same periods).

This means that there is an even more fundamental question you have to answer besides your price point. Is developing the app even worth it?

We will probably continue to develop some WP7 apps (We love the OS and Mango is too good to ignore), but in some ways it's an act of faith. Faith that the platform will get better (and more popular) eventually leading to more profit and faith that our customers (end users and those contracting us to make the apps) want our products on multiple platforms.

All indications are that our faith is not misplaced. The app market (all platforms) is estimated to grow tremendously leading to more opportunity and (hopefully) more profit. WP7 is predicted to gain more market-share, and our customers have indicated they want us to support multiple platforms. We also love what we do and that certainly doesn't hurt!

But wait - weren't we talking about setting your app's price? Mobile development is a complex business and there is a lot to consider. Setting your app's price is just one part of that complexity and can be a bit (lot) like guesswork. Bottom line is that if you develop a good app and market it well, the price can be fiddled with until you hit the spot that's most profitable. You'll still probably have to adjust it from time to time, but your time is probably better spent trying to guess your way through everything else involved in becoming an overnight millionaire.

The InputScope shown to the left is "Chat", with the smilies selected.

As Shawn Wildermuth points out in his Ten Pet Peeves of WP7 Applications:

"... the default input scope on TextBox's do not offer AutoCorrect. So at a minimum changing the InputScope to Text will give the user auto-correct options. Using the case-specific InputScopes like EmailSmtpAddress, Chat, Number and FullName can help the user input data."

Setting the Input Scope is as easy as changing this XAML:

<TextBox x:Name="txtMyText" />

To This:

<TextBox x:Name="txtMyText" InputScope="Text" />

Wowee, AutoCorrect and Word Suggestions magically start working! This is an area that new developers seem to miss and can find difficult to implement (Intellisense only shows you the possible values if you use the long notation). You can find an example of the long notation and a list of InputScopes here.

Reading the Imaginative Universe blog linked above and using some of the code demonstrated, I wrote an app to help me see and use the various InputScopes. I will provide a link to the full project below.

The app binds a ListBox to the full list of InputScopes (and so will automatically include any additional InputScopes added in future releases). Select an InputScope from the list and then tap the TextBox to see it in action.  Pretty simple, but useful for exploring the various InputScopes.

The code is the property of WireBear, but you can feel free to use sections of it and to distribute this app (for free) with the WireBear name and link intact. Hopefully this helps you make more intuitive apps so that if nothing else, our experiences as users get improved!

Resources:

• WireBearScoper (WP7 C# Project)
• Ten Pet Peeves of WP7 Applications (See # 1)
• WP7 InputScope (Scope list and examples)

UPDATE ListTable
    SET FieldName = FieldValue
    WHERE QueryFieldName = QueryFieldValue

In the generic T-SQL above, any row where the QueryFieldName column had a value equal to the QueryFieldValue would have it's FieldName Column set to FieldValue. Pretty straightforward for anyone with a database background.

With the SharePoint Web Services, however, there isn't a simple UPDATE command like this. Instead of the one simple command above, we have to make 2 calls to the Web Service and provide some complicated XML parameters. This can be a big hassle the first time you do this, so to hopefully save you some headaches, I'll provide most of the code required below...

I won't be showing you how to setup whatever project you are using or how to connect to the web service. The code is in C# and I will assume your service reference (Lists) is called myService.  So let's get started!

Helper Functions:

I will be using a few helper functions to make generating the XML parameters easier, I'll go ahead and list these here:

private void AddAttribute(XmlDocument x, ref XmlNode node,
          string attributename, string attributevalue,
          string AttributeNameSpace = "")
{
    XmlNode attnode =
              x.CreateNode(XmlNodeType.Attribute, attributename,
              AttributeNameSpace);
    attnode.Value = attributevalue;
    node.Attributes.Append(attnode);
}
 
private XmlNode CreateUpdateNode(XmlDocument x, int ID, string RowID)
{
    XmlNode node = x.CreateNode(XmlNodeType.Element, "Method", null);
    AddAttribute(x, node, "ID", ID);
    AddAttribute(x, node, "Cmd", "Update");
    node.AppendChild(CreateFieldNode(x, "ID", RowID));
    return node;
}
 
private XmlNode CreateFieldNode(XmlDocument x, string Name, string Value)
{
    XmlNode node = x.CreateNode(XmlNodeType.Element, "Field", null);
    AddAttribute(x, node, "Name", Name);
    node.InnerText = Value;
    return node;
}

Retrieve the Items to be Updated:

This is equivalent to the WHERE clause of the example SQL query. You will need to use the GetListItems method of the Lists service.

This method uses the List GUID to reference the target list, I'll leave it to you to retrieve it and will assume it in the variable ListGUID. You will also need to replace the QueryFieldName, QueryFieldType, and QueryFieldValue variables with appropriate values.

XmlDocument doc = new XmlDocument();
XmlNode queryNode = doc.CreateNode(XmlNodeType.Element, "Query", null);
queryNode.InnerXml =
          string.Format("<Where><Eq><FieldRef Name='{0}' />
                         <Value Type='{1}'>{2}</Value></Eq></Where>",
          QueryFieldName, QueryFieldType, QueryFieldValue);
 
XmlNode viewNode = doc.CreateNode(XmlNodeType.Element, "ViewFields", null);
viewNode.InnerXml = "<FieldRef Name='ID'/>";
 
XmlNode resultsNode = myService.GetListItems(ListGUID, null, queryNode,
          viewNode, null,
          doc.CreateNode(XmlNodeType.Element, "QueryOptions", null), null);

Parse the IDs from the Results:

XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
nsmgr.AddNamespace("z", "#RowsetSchema");
XmlNodeList rowNodes = resultsNode.SelectNodes(".//z:row", nsmgr);
List<int> IDs = new List<int>();
foreach (XmlNode rowNode in rowNodes) {
    XmlAttribute result = rowNode.Attributes("ows_ID");
    IDs.Add(int.Parse(result.Value));
}

Perform the Update:

This is equivalent to the SET portion of the example SQL query. You will need to use the UpdateListItems method of the Lists service.

Again, this method uses the List GUID to reference the target list, I'll leave it to you to retrieve it and will assume it in the variable ListGUID. You will also need to replace the FieldName and FieldValue variables with appropriate values.

XmlDocument doc2 = new XmlDocument();
XmlNode node = doc2.CreateNode(XmlNodeType.Element, "Batch", null);
AddAttribute(doc2, node, "OnError", "Continue");
 
int itemCount = 1;
foreach (int i in IDs) {
    XmlNode updateNode = CreateUpdateNode(doc2, itemCount, i);
    updateNode.AppendChild(CreateFieldNode(doc2, FieldName, FieldValue));
    //Append More children here to update multiple fields
    node.AppendChild(updateNode);
    itemCount += 1;
}
 
myService.UpdateListItems(ListGUID, node);

That's it. To review, we created a CAML query and retrieved the IDs of the matching rows using the GetListItems method. We parsed the XML result and put all of those IDs in a List<int>. We then added each row ID to a batch update XML parameter which we used in the UpdateListItems method.

As you can see, this is way more complicated and not nearly as obvious as a SQL UPDATE command, but you can take the above code and create a pretty generic wrapper to make your web service updates nearly as easy. Let me know how it works out for you or if you have any questions!

The following is not recommended for use in this field: Fox. Your app may be rejected if you use this term.

Our app has a list of nearly 100 dog breeds with one of them being the Wire Fox Terrier. I guess we don't understand when Fox became a word that was off limits.

Does anybody have any ideas why using the term Fox is not recommended in your app's App Store description?

We have found this to be especially helpful for web service tasks. Calls to web services can fail if the server has gone offline for a minute, but could recover if tried in 10 minutes or so. So we have added an exception loop to each of our web service tasks that retries indefinitely.

Here is the process:

On this process you can see we have a Form task and then a script task called FailTask. The FailTask is pretty simple, it just throws an exception. Here is the code inside the FailTask:

void enteredActive(State state) {
  Log log = LogFactory.getLog();
  log.info("FAIL");
  thisProcess.setFieldValue("FakeField","panda");
}

So we write a message to the log then try to set the value on a field that doesn't exist. FAIL! The next task, Other Stuff, will never be reached in this particular example, but is representative of the rest of your process.

The other four tasks are the interesting ones. First is an Exception task. An exception task is just a task that becomes active when the task it is connected to (with a red line) throws an exception - pretty straightforward. After the exception task we have placed a Delay task. This is the task that determines how long the process should wait before retrying.

The most important task is the Reset State script task. Here is the code inside:

void enteredActive(State state) {
  thisProcess.getTaskByName("FailTask").forceToState(State.READY);
}

(This Code can also be placed in the Delay task on the enteringDone event, we have separated it into a separate Script task just to make it easy to understand)

This code retrieves the failed task (whatever task you are attaching the exception loop too) and sets its' state to READY. This command will fail if the task is not currently at state ABORT, so just make sure to only put this code inside your exception loop.

The last member of this loop is the strangest, the Loop task. The loop task is between the Delay task and the Exception task and does NOT link back to the main process (Fail Task). Resetting the state of the Failed task immediately activates it (which is why we reset AFTER the delay task). The loop is only there to reactivate the exception task so that if the Failed task fails again, the exception loop starts over.

In our example above the process will retry forever until it succeeds. You could easily add conditions to the loop task to determine how often it should run and this will be the equivalent of a retry count (since the exception task will never be reactivated).

Adding these types of loops to your processes can help them to be more robust and keep you from having to intervene on recoverable tasks.

On Vista, this option was removed completely. On Windows 7 you have to hold Shift while right-clicking to get it to show up. This is not obvious and can be irritating.

I recently came across a tool by Sysinternals (now Microsoft) called ShellRunas.  Go get it. To restore your context menu do this:

1. Extract the ShellRunas.exe to your C:\Windows\System32 directory
2. Open a command prompt (as Administrator), type:
   ShellRunas.exe /reg

Your context menu has been restored!  That's pretty awesome by itself, but something I like to do is use it to create shortcuts.

A common occurrence for me is the need to run Microsoft SQL Management Studio as a different user to login to a server that only accepts Windows Authentication. This is a classic Run as different user scenario, but I can't tell you how many times I have opened it up and tried to connect only to remember I have to restart the whole program with the Run as different user option.  So I created a shortcut by doing this:

1. Copied my current shortcut to Management Studio and pasted it to create a new one
2. Right-Clicked on the shortcut and selected Properties
3. Changed the target to:
   C:\Windows\System32\ShellRunas.exe "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"
   (your path may be different)

Now when I run that shortcut I am automatically prompted for my credentials!  But there is another feature of ShellRunas that can make your shortcut even better.  If I change the target setting from above to this:
C:\Windows\System32\ShellRunas.exe /netonly "C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"

That /netonly section uses the alternate credentials only on remote calls.  This means that in Management Studio (or whatever program) I can access all my documents (as long as they aren't mapped to a network share) and still be using the correct credentials when accessing the remote server!

Just a simple but effective tool that makes my job easier.

Download the original samples from Microsoft

While I see a lot of value in having sample code for theme deployment, most SharePoint admins don't have all the tools required to compile these into a usable format. That means the above download is basically unusable for anyone who doesn't have these tools.

A guy named Daniel Brown made the WSP packages available, but all the links are now dead (it has been a while).  I have the tools, but even I was annoyed that I had to open each project, compile/package them, and then deploy.  So... I have decided to release the packages myself!  I've looked through the EULA included with the original download and I don't think I'm in violation, but I'm sure I'll soon find out if I am!

I have not modified a single image or line of code from the samples.  All I did was package them up to provide to you along with the instructions to make these a part of your server. Having said that, WireBear claims no ownership or credit for these themes nor do we provide any guarantee of success, warranty, support, etc.  But they are free...

The Themes

There are 10 Themes available.  I have provided a separate download for each one, but at the end of the article you can find a link to download them together.  Once again, please note the Screenshots are from Microsoft and we claim no ownership!

Team Theme

StartUp Theme

Sporting Theme

Publishing

Procurement Theme

OARP Theme

Events Theme

Corporate Theme

Contoso Theme

Construction Theme

Installation

To install these, you can either use the stsadm tool and add, deploy and activate them like any other feature  or you can run the included setup.bat to have the theme installed for you (may have to play with the options depending on your setup).  Please note that activating these themes will set it as the current theme for the target site.

Download All Theme Packages

So what are our options?  We posed that question to Autonomy technical support and they came back with a couple of methods to get to these buttons in javascript and to set their color there.  We needed this behavior on multiple tables on the same form and on multiple forms so we put together a method using their help to come up with a pretty simple solution...

The heart of it is the following code:

//Sets the colors of the + and - buttons for dynamic tables
function ColorizeButtons(tableName){
  var tbl = CSForm.getTable(tableName);
  var addColor = "699A41";
  var remColor = "BF3834";
  if (tbl != null && tbl.isDynamic()) {
    if (tbl.isRowAdditionAllowed()) {
      var addButton = CSForm.getField("DFS__" + tableName + "_addRow");
      if (addButton != null) {
        addButton.setFillColor(addColor);
        addButton.setTextColor("FFFFFF");
      }
    }
    if (tbl.isRowRemovalAllowed()) {
      for(var i=0;i<=(tbl.getNumberOfRows()-1);i++) {
        var remButton = CSForm.getField("DFS__"+tableName+"_removeRow_"+ i);
        if (remButton != null) {
          remButton.setFillColor(remColor);
          remButton.setTextColor("FFFFFF");
        }
      }
    }
  }
}

To use this, open up the script editor in the Form Designer (Tools > Script Editor).  Expand your form and click on the <Client> node and paste the above code.  Then expand the <Client> node and then expand the CSForm node and double click the OnLoad() event to add the function.  In this event add a call to the above function for EACH dynamic table on your form where you want the buttons colored using the name of the table as the parameter (Our sample table is named GreatStuff).  For the test form we're using our OnLoad event looks like this:

function CSForm_OnLoad()
{
  ColorizeButtons("GreatStuff");
}

Then for EACH dynamic table on your form find the table's main node in the <Client> node on the right and expand it and double click the OnRowAdded() event and set the code like this:

function GreatStuff_OnRowAdded()
{
  ColorizeButtons("GreatStuff");
}

Your Script Editor should look similar to this:

Press F5 to save and compile.  That's it.  Just test the form (File > Preview > As HTML) .  With most recent versions of Internet Explorer you will be prompted during the preview with a yellow message bar at the top of the page saying that it has restricted content from the page. This will only happen on your local machine and is a good, but annoying, security feature. Just click on the message and choose Allow Blocked Content... and all your scripts will run just fine.

Now your plus (+) buttons should be green and your minus (-) buttons should be red:

That's all there is to it.  The buttons aren't beautiful, but now they're easier to see and the colors you choose can help indicate their function or match your logo.  To customize the colors used, just edit the ColorizeButtons function listed above with the hexadecimal color values in a string (without the #).  This is a pretty standard format found in HTML and you can easily find sites out there to help you with these.  A good and easy one is ColorPicker.com.  You can just adjust your colors right on the site and it gives you the hex value right at the top.  Just copy it and remove the #.

  var addColor = "699A41";
  var remColor = "BF3834";

To change the text color just edit the setTextColor("") calls using the same types of values (the code above uses white "FFFFFF").

Let us know if you find this useful or if there are other tricks you use to help customize your forms.

This isn't LiquidOffice's fault, it's doing what it's supposed to, but depending on your environment this can be a big problem and a huge irritation.  Fortunately, we can use LiquidOffice to solve this problem quickly and simply with just a few additions to your process...

The most common cause of zombie processes is having a "choose your own adventure" type process with multiple forms.  Consider the following process:

In the above generic process we have two forms and two script tasks.  The script tasks are just there to serve as placeholders for whatever tasks you might be doing between and after forms.  Often in a more complex process you would have some sort of branch task that changed what the second form was or altered some fields depending on the result of the first form.  But to keep things simple this is our sample process.

Note - We have checked the "Automatically Display Next Form on Submit" property in the Form section of the first form task's properties.  At this point our process also does not take advantage of the Initial Form property (we will cover that further down).

In our common BeanShell script area we have the following generic function:

//Writes a message to the Log
void writeToLog(String Message) {
  Log log = LogFactory.getLog();
  log.info(Message);
}

This is a simple helper function we use to save time when we write to the log.  Using this in the More Stuff task (final script task) we have:

void enteredActive(State state) {
  writeToLog("All forms processed!");
}

So if everything goes well, the final thing our process does is to write to the event log to let us know it's all done.  But what happens if when a user gets to the second process they realize they messed up the first form so they close the window and start over?  A good solution is to provide a back button (See our Multiple Submit Buttons in LiquidOffice article).  However, not everyone will use a back button no matter how convenient and it still doesn't account for people who either accidentally or purposely closed the window for whatever reason.

When this happens as far as the user is concerned the process is gone, but LiquidOffice holds onto the instance, all of it's data, the versions of the form(s) and the process that were used, and the current state of the process.  All of this will need to be cleaned out manually using Management Console and in some versions of LiquidOffice the process isn't fully cleaned up on manual deletion.

Fixed Lifespan

The Fixed Lifespan solution is very easy to implement.  Here is our example from above with a Fixed Lifespan:

Only two controls were added to the process.  An Or block and a Delay task with no parent tasks (no preceding connections).  The Delay time you set is equal to the lifespan of the entire process.  The Or block needs to be the last item in your process and allows us to say, "however you get here, end". If the tasks all complete before the delay expires then the process performs as expected and the delay task is ignored.  However, if the delay expires, the Or block at the end cancels out the rest of the process tree and the process gracefully dies.

This works because both Form 1 and the Delay task are started at the same time (process instantiation).  So it's a race.

This makes for a very simple solution but should be used with extreme caution.  This is especially true for large processes which require approval, manual operations, or special routing.  You will need to take into account all reasonable time frames for each task to complete and make sure your Delay task is set much higher.

Estimating an appropriate lifespan and maintaining adjustments to that lifespan as the process changes can be difficult and error prone.  Many times you only want specific tasks to timeout and you'd like that timeout to be relative to each task.  For example, once a user has submitted the form(s) you probably don't want an automatic timeout.  So what do you do when you only want to target certain tasks and you'd like those timeouts to be relative to the task they are timing out?

A Better Solution:

With the help of Autonomy tech support (Thanks Simon!) we have come up with a solution that fits that criteria and that we add to nearly every process we publish.  We call it a suicide loop because that sounds cool (right??), but that might lead you to believe that we are just forcing a delete on the process from within the process.  In actuality, we are still gracefully completing the process allowing for standard cleanup and for statistics to maintain their integrity.  In addition, you can add whatever code you want when this happens (send an email, write to the log, etc.).

The solution involves adding an Escalate task, some other task(s), and an Or block:

The escalation task needs to be attached to the form causing the problem (Form 2 above). Ensure your Delay until escalation property is set to a relatively high number to allow the user the chance to fill it out.  For testing we set ours to 1 minute (0:01:00.000), but a value of 24-72 hours is generally more appropriate.  To be clear, this is the amount of time the form (NOT the entire process) can be left open (zombie or not) before the process is sent to heaven - so you will need to pick it carefully.

If the form is submitted before the escalation delay then the process continues on as expected and the escalation task is cancelled.  However, if the escalate occurs, the Or block at the end cancels out the rest of the process tree and the process gracefully dies.

Wait a second, what about that extra script task between the escalate task and the Or block? This is REQUIRED.  This can be a blank script task (does nothing) or something else like an email task (or whatever other business logic you want to insert), but you must have something here.  This is because although the escalate task is cancelled, it "shows" as completed which signals the Or block to be followed - cancelling the process immediately.  Placing something here changes that.  In our process above, when the escalate task is cancelled the Script task is set to Passive which prevents it from executing and therefore stops the path.

Our script task does this:

void enteredActive(State state) {
  writeToLog("Goodbye Cruel World!");
}

If you run this process, close the window on (don't submit) the second form and you'll see the "Goodbye Cruel World!" message in the System:EventLog within the Management Console (after the escalation delay).  You'll also find the instance is marked as complete.  The process can also be completed normally (all forms submitted) and the suicide loop will never be entered.

Congratulations, it was really that simple!  Unless of course, it wasn't...

Multiple Suicide Loops:

In most cases the above solution should have taken care of your problem.  But if any of the following are true, you will need to add additional loops:

• Multiple forms where a user could stall out
• Using the process Initial Form setting set to Instantiate Process Before Display Form

Using our same process from above we have now set the process Initial Form property to Use Initial Form and set it to Instantiate Process Before Displaying Form:

This effectively means our process has multiple forms where a user could stall out.  So this means we need a way to kill the process on either form 1 or form 2 being abandoned.  This really just means we have to add another suicide loop (one for each stall point).  This isn't that complicated but it's a little annoying.

LiquidOffice doesn't allow the escalate task to be attached to more than one task (the pink line).  This means you need a separate escalate task for each stall point.  This creates a new path for each stall point that can be joined back together for one final suicide task(s) as needed, but ultimately every path in your process needs to end in that final Or block.

Unfortunately, you can't just have each escalate task point to the same inbetween task (the "Goodbye Cruel World" script in our example).  Because then the process will stall out at this task since it will be waiting for the other escalate task(s) to also reach that point before continuing.  You also can't simply add an Or block before the imbetween task or you will have the same problem as before with the Or block being activated when the escalate task is cancelled.

So you need to add the "full" suicide loop for each stall point like this:

This is a pretty simple implementation.  But what if you wanted to send an email (or some other logic) every time a process stalled out?  You could just cut and paste and replace the imbetween script tasks with these tasks, but maintenance would be a nightmare and your process tree could quickly get huge.  So do something like this:

As you can see we still have a generic script task after our escalate tasks, but these do nothing.  We have moved our Finally logic between the Or blocks.

Although the suicide loop is more complex than the fixed lifespan, the benefits are worth it. Regardless of exact implementation, the prevention of zombie processes is an important part of your design for EACH process.  These are our methods, what do you guys do?  Any other process maintenance tips? Let us know in the comments!

Zombie Image from http://gear.ign.com/articles/949/949442p1.html