You can tie operational behavior and permissions to iterations and iteration types, in which case the tool could e.g. Limit who can deliver or change work item states and the like based on the current iteration. It would then change as soon as you select a new current iteration.

Most user actions in CLM are controlled by permissions and allow preconditions and follow up actions. For instance, who can change a state on a Work Item is controlled by permissions, and there can be a precondition on Work Item Save that in certain states, certain fields must be set.

The current iteration is used to determine what set of permissions, preconditions and follow up actions are used. As Ralph stated, it is possible to configure certain iterations and iteration types to have customized permission and behavior checks. For instance, as the release for a product nears, the final iterations may enforce multiple code reviews before delivery of a change set. In this case, setting the current iteration on the timeline causes the stricter preconditions to be used.

A team area can follow the project timeline, or a differnt timeline. If the team area follows the project timeline, when the current iteration is changed in the project area, the permissions and operation behavior defined in the team area will be checked according to the current iteration in the project area's default timeline.

Hope that helps!

Ruby
Martha (Ruby) Andrews
Jazz Foundation L3 Development Team Lead