We've been compiling a list of features that would be great to have in Workflow, and I finally have enough free time to write everything up. They aren't in any specific order.

1. Creating Global Tokens

We have many workflows where the first activity is Assign Token Values that creates things like folder paths etc. that are re-used across the workflow inside Move/Route activities. However, most of the time these stay the same. So it would be nice to be able to create them at the global level, maybe inside the Workflow Admin Console. We could then access them inside each workflow under the Global list.

2. Archiving Workflows

We would like the ability to "archive" workflows and remove them from various lists like Rule Manager. Disabling their starting rules only makes them unavailable to users, but from an administrative perspective, keeping the lists (Rule Manager, Download Workflow, etc.) clean while at the same time keeping the workflow definitions in the database (only in an Archival status) where they can continue to be backed up would be great.

3. Renaming Workflows

The only way to rename a workflow seems to be to download it to the Designer, change the name, publish it, recreate its starting rules, and delete the old one. That's five steps for a simple task. I feel like it should be possible to right-click a workflow in the Rule Manager or in the Admin Console and selecting 'rename' or something.

4. Key-Value Pair Generation

Being able to create arbitrary multi-value tokens is great, but not enough. Often times (especially when using Workflow for reporting), we need to be able to compile large amounts of data and organize them in a clean way. So if we have "project name" and "project manager", storing them inside two separate multi-value tokens doesn't make sense, because the only way to find a project manager that is assigned to a given project in that case is to use the index counters, and those aren't guaranteed to be synchronized (some projects don't have project managers for example).

So we would like the ability to create two-dimensional, dictionary-type data structures inside workflow, and then refer to a key to get its value and vice versa. Being able to easily convert these pairs to JSON or XML would be extra-nice, since a lot of our custom front-ends use those. For instance, sending a project name/project manager pair like this:

{"Front Office Renovation": "Bobby Smith"}

to a web service would allow that service to consume it easily.

5. Object Generation

This is similar to the key-value pairs, but more complex. It would be nice to have a "Create Object" activity where you can define an object and its various properties, and then refer to it using its unique ID further down in the workflow. Basically, like creating a C# class with a set of properties on the fly, and then creating instances of that class, populating its properties and adding it to collections inside loops (e.g. multi-value token).

Example use case: Let's say you're using workflow to compile project-related data from various sources, such as the LF repository and third-party tables. You want this data to be organized under a Project object. Each project has a name, id, project manager (optional), and budget. In C# this may look something like this:

public class Project {

    public int id                   { get; set; }
    public string name              { get; set; }
    public string projectManager    { get; set; }
    public int budget               { get; set; }

}

A workflow activity can allow you to specify the name of this class and its properties, and then allow you to create new instances of it (and assign data to its properties) inside the workflow.

6. Starting Workflows via Email

I've brought this up to the development team before, but I wanted to revisit it. Being able to start workflows by simply emailing an account e.g. workflow@ourdomain.com would be incredibly powerful. You could then have various starting rules in the rule manager to specify conditions like "if from" or "if subject contains word", and have the email fields (to, from, body, etc.) available inside the workflow as tokens.

7. Starting Workflows via Web Request

Currently, whenever we need the ability to start a workflow via a web request, we have to write a custom web service that's a wrapper around the Workflow SDK, and then deploy that service on IIS. This can be a ton of work. It would be great to have something that's more tightly integrated into Workflow itself. An administrator should be able to define starting rules that are web requests. For example, it would be great if we could create starting rules like:

    Request Type: POST

    Request URL: /workflow/myWF

    Request Body contains keyword

    Request Body Format is JSON

Workflow would then listen for POST requests to that URI, filter incoming requests based on the conditions (as well as things like the existence of a valid API key that was created in the Admin Console), and then process the data inside the workflow.

8. Inline Conditionals Inside Token Editor

It would be great if the token editor had inline conditionals. For instance, imagine an email activity where the To field contains the following tokens:

%(Project_Manager), %(Customer)

If we want to make it so that the customer token is included only if certain conditions are met, we need to place the email activity inside a Conditional Decision. The problem is that this can make workflows very crowded, because every minor change in the condition warrants an entirely new branch, and the the rest of the email fields remain exactly the same.

But if we could do something like this:

%(Project_Manager), %(Customer#if_%Project_Type_equals_"public"#)

Then we could have one email activity to cover both cases.