Using Custom Check-In Policy

Review Assistant tool includes the custom check-in policy for TFS. Check-in policies enforce constraints every time when files are checked into source control. Team Foundation Server provides a number of out-of-box check-in policies, including policies that check that static code analysis has been performed, and policies that check that work items are associated with check ins.

This topic explains how a custom check-in policy works. As an example of a custom check-in policy, this topic uses Pre-Commit Code Review Policy, that requires that files pass code review before check-in. To learn more on implementing custom check-in policies, see Adding Code Review Policy to TFS Project.

Pre-Commit Code Review Policy Algorithm

The policy works in accordance with the following algorithm.

  1. Once a user invokes the Check In Pending Changes command or just opens the Pending Changes view in Team Explorer, the policy is evaluated.

  2. The policy loads the Review Assistant package and attempts to connect to a review server using previously stored credentials.

  3. Policy searches for the open reviews and for the pending changes. There are three possible outcomes:

    a. No review is found – the policy is not satisfied.

    check-in policy warning

    b. An open review is found – the policy is still not satisfied.

    check-in policy warning 2

    c. A closed review is found – the policy is satisfied (no warning).

  4. A user activates the policy (when it’s not satisfied). Here we have two scenarios:

    a. There are files that require the code review.

    i. A shelveset with pending changes is created.

    ii. Code Review Board is opened and the new review for the above shelveset is created.

    iii. The user specifies a reviewer and publishes the review.

    b. Files in the pending check-in are under review.

    i. Code Review Board is opened and the review, which causes the policy to fail, is displayed.

    ii. The user can check the status of the review and push the things forward, if necessary.


When the policy fails to evaluate correctly, it returns no failure. In other words, if it fails to connect to a review server the policy is still satisfied.


The following restrictions apply to the Pre-Commit Code Review policy.

  • Policy does not filter the files during the evaluation. It will fail even, if you change supplementary files that don’t need a review. In this case you should override the policy warning.
  • If you add files to your check-in after the review is created the policy will fail. In this case you should remove additional files from the check-in to satisfy the policy.
  • Reviews created by the policy are cached for a limited time. But it will not be an issue, unless you delay the check-in for a month.