VSTS Process Customization futures (January 2016)

Last month, we released our first major milestone for process customization - the ability to add a field and modify layout, checkout my blog post on the topic if you haven't seen it yet.  As I shared in July, this was just the first scenario of our overall plan:

1. Add custom fields & modify layout for existing work item types - Completed!
2. Add picklist and identity fields to existing work item types
3. Modify the state workflow on existing work item types
4. Creation of custom work item types
5. Define business logic and rules for custom fields
6. Import/Export of custom processes

With the new year upon us, we wanted to lay out a rough timeline of when we expect to deliver the rest of these scenarios. 

NOTE: The timeline is subject to change and all the designs below are early mocks to land concepts - we have lots more UX and design work to do before completing these items.

Add more field types: HTML, multi-line string, and boolean

With the add a field experience shipped, many customers have been asking us for additional field types. The most popular are HTML fields for storing rich text data about a work item and a long-time ask on User Voice, checkboxes. We'll be adding these additional field types and they'll show up in the add a field experience no differently from any other field type. We do have additional field types on our list but those will be longer term investments.

Figure 1. A new HTML field called "Design" was added to the first column and a boolean field "Ready to deploy" was added to the status section.

Add picklist fields to existing work item types

The biggest ask since releasing add a field is how can a user add a dropdown field to the form. We call those picklists. In TFS, we have AllowedValues/SuggestedValue/ProhibitedValue rules as well as global lists that help provide this functionality but they’re not easy to use. Instead of thinking about picklists as a set of rules, we’re going to make lists a first class citizen in the system. You'll be able to define items in a list and back a picklist field with a list. Longer term we'll add the ability to order items in the list and rename them.

Figure 2. I'm adding a new field called "TShirt size" to my feature work item to track estimates. The field is a picklist and will appear as a dropdown on the form with the values specified in the list.

Modify the state workflow on existing work item types

Moving beyond fields, the next customization we want to add to work items is the ability to control the workflow or state model that work items go through. Like fields before it, states are getting a makeover and we’re going to simplify the state model so that the most common scenarios are easy to accomplish while at the same time supporting the advanced scenarios enterprises have come to rely on. Like with fields, states will be stored at the process and individual work items will choose which of these available states they want to use. Adding a state will be very similar to adding a field. By default, each state will also include a pair of fields tracking when the work item was moved into that state and by whom - this is something most process administrators add so we're going to do the heavy lifting for you. Another change is that we're switching the model so that by default, a work item can transition between any two states freely; we'll also allow users to restrict individual transitions if your business processes require it but that will be optional. Looking at how states appear on the work item form, each state will have a color associated with it and the list of states will be ordered based on your chosen workflow as opposed to being alphabetized, another small rock but something customers have been requesting for a long time.

Figure 3. The feature work item type has five states: the four that were defined in the Agile system process and the "Groomed" state which is custom to the "My Agile" process.

Figure 4. Looking at the state control on the work item form, the order and colors match exactly to what was defined in the process in figure 3.

Add Identity fields to existing work item types

Custom identity fields to track ownership, assignment, etc. are another scenario we want to enable. Like with picklists, we want to make this significantly simpler than exists today on TFS. Identity will be another field type available from the add field dialog and you'll be able to scope the field to an existing group of users.

Figure 5. Adding a "PM Owner" identity field to the feature work item to track who's responsible for the designing the feature. I can scope the field to members of the existing "PM Team" AAD group.

Creation of custom work item types

With states and fields available, we can finally allow users to create their own custom work item types.  When you create a new work item type, it will have the initial set of system fields along with a "new" and "closed" state.  Of course, you will have full control of these work item types and can add as many additional fields and states as you want.  You'll also have full control of the layout.  Adding custom work item types is great, but what most customers really want to do is add those new work item types to the backlog.  We'll be introducing a new concept called behaviors which is essentially a contract between experiences and process.  Adding a custom work item type to the backlog will be as simple as checking a checkbox.  We'll definitely talk a lot more about behaviors later...

Figure 6. Adding a new "Live site incident" work item type is as easy as giving it a name, description and color.

Define business logic and rules for custom fields

In TFS, process administrators can use field rules to model custom business logic.  While this is a powerful customization, maintaining the rules in XML is quite difficult and takes a TFS PHD to configure.  This is another area we want to significantly simplify through a fit for purpose UI.  We are looking at modeling rules through triggers and actions, similar to how service hooks work on the service today.  In addition to wrapping this experience with a UI, we're looking to add new triggers and actions to filter the new picklist and identity fields.

Figure 7. In these mockups, you can see that the user has configured a new rule by choosing a trigger and action: when the state changes to resolved, set the value of the 'Assigned To" field to the value of the "Created by" field.

REST API support for customization

As I mentioned in the previous blog entries about process customization, we will be delivering granular REST APIs allowing 3rd party tools to modify process.  Create, update, and delete operations will all be exposed as well as some advanced functionality that we don’t have UI for yet.

Import/Export of custom processes

Once we have all the above pieces in place, we'll bring both APIs and UI experience to allow the creation, import and export of full custom processes.  This will allow customers with multiple accounts to copy a process from one account to another.  This can also be used to try out process changes in a staging account before you commit them to your production account.  We're also looking to provide an experience to import an existing process template from TFS and have it converted on the fly to the new process model.  Finally, we'll bring inheritance to custom processes so organizations can align around a common core process but leave room for autonomy as well.