Auto-Transition Error Checking
Integrators can try two types of auto-transitions. The first is an auto-transition that occurs because of a user action. The second is an auto-transition that occurs by unattended automation, such as a nightly build.
User action auto-transitions For this kind of auto-transition, a user is present to react to any rule-related issues that appear. Also, make sure that you support the situation that occurs when the author of a work item type adds a required field that the integration does not recognize. To support this situation, perform the auto-transition and then inspect the work item type for rule violations. If you find any, display the form for the user to resolve.
Unattended automation auto-transitions You must assume that no user is present to resolve these issues. In this case, the integration should fail gracefully and write a message in an error log that the auto-transition was tried and give a reason for failure.
When defining either type of auto-transition, define the transition so that each work item reaches a valid state at the end of the transition without requiring user intervention. In other words, all the rules that are defined for the state being transitioned to are met by providing defaults or copied values for all fields. If any field becomes invalid after the transition, the state transition will fail.
In order to keep fields from becoming invalid, do the following:
Define a DEFAULTREASON for the state transition.
For fields that would become required after the state transition, define DEFAULT or COPY rules.
For example, you have created the transition action Check-In that transitions the state of a work item from "Working" to "Ready to Build." The work item's rules for "Ready to Build" require that the "Resolved By" field be set. You would then define a DEFAULT or COPY rule for “ResolvedBy” in the TRANSITION section. Additionally, define a DEFAULTREASON to make sure that the required field can be set without user intervention.