VSTS Process Customization futures (June 2016)
The first wave of work for process customization is complete: allowing you to modify fields, layout and states of existing work item types. While it’s taken longer than we had anticipated, we’ve received a ton of great feedback and our plan is to continue to work through the backlog. With the summer season beginning, I wanted to update our rough timeline of when we expect to deliver the next set of process customization 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.
With states and fields available, the next step is allowing users to create their own custom work items. When you create a new work item, 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; adding a custom work item to the backlog will be as simple as checking a checkbox.
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 it will display with the avatar image, display name and contact card on the work item form.
Define simple business logic and rules
In TFS, process administrators can use rules on fields to model custom business logic. While this is a powerful customization, maintaining the rules in XML is quite difficult . 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.
Once we have work item types, all the key process assets will be in place and we can release public REST APIs for customization. Our plan is to provide two sets of APIs: a read only resource that shows the full, composed process as well as a separate set of resources for doing create, update, and delete operations at the inherited process level. Some advanced functionality will exist in the APIs that we don’t have UI for yet.
Improvements to custom states & picklists
Derrick listed a couple items we choose to scope out of our initial delivery of states. In addition, we’ve gotten feedback that customers need the ability to rename picklist values as well as reorder them (and have that order represented on the work item form). I’m sure we’ll get more feedback on the features above and we’re allocating time at the end of the year to address some of this.