Team Services (Inheritance)
This topic applies to team project and process customization for the Inheritance process model. For the Hosted XML process model, you customize your team project by importing a custom process template; and for the On-premises XML process model, you customize by importing modified XML definition files.
For an overview of process models, see Customize your work tracking experience.
In Team Services, you customize your work tracking experience through a process. A process defines the building blocks of the work item tracking system as well as other sub-systems you access through Team Services. Whenever you create a team project, you select the process which contains the building blocks you want for your project.
Team Services supports two process types. The first, the core system processes—Scrum, Agile, and CMMI system processes—are locked. You can't customize these processes. The second type, inherited processes, you create from a core system process. These processes you can customize.
In addition, all processes are shared. That is, one or more team projects can reference a single process. Instead of customizing a single team project, you customize a process. Changes made to the process automatically update all team projects that reference that process.
Once you've created an inherited process, you can customize it, create team projects based on it, and migrate existing team projects to reference it. For example, updates made to the MyAgile inherited process will update the Agile and Fabrikam Agile team projects. The Git team project can't be customized until its migrated to an inherited process.
To perform any of the following actions, you must be a member of the Project Collection Administrators group or be granted explicit permissions to edit or create a specific process.
- Create an inherited process
- Customize a process
- Migrate a team project to an inherited process or to a core system process
- Add a new team project based on a core system or inherited process
- Enable or disable a process for use when creating a team project
- Set a process as the default when creating a team project
Open Process in the admin context
To open the admin context from the user context, click the gear Settings icon and choose Account settings.
If you don't see the Account settings option, then you are working from an on-premises TFS. The Process page isn't supported. You must use the features supported for the On-premises XMl process model as described in Customize your work tracking experience.
Create an inherited process
From the Process page, open the context menu of the process you'll use to create an inherited process. Here, we create an inherited process from the Agile system process.
If you don't have access to the options, ask your project collection admin to grant you permissions.
Enter a name for your process and optionally a description.
Change the process referenced by a team project
You can change the process a team project references to an inherited process or a system core process. However, you can only change team projects to another process that is derivative of the same core system process. That is, you can change an Agile-based team project to any process you created from the Agile system process as well as to the Agile core process. Whereas, you can't change a Scrum-based team project to an Agile-derived inherited process.
To migrate a single team project to an inherited process
Choose the Migrate projects option from the context menu of the core system process for the team project. Here we choose to migrate a team project based on the Agile process.
Next, move the team project(s) to the migrate column.
The system lists only those team projects that are valid for the current process.
When you migrate a team project to an inherited process, any customizations that you've made will appear in the work item form. If you've added required fields, work items that don't meet the requirements will appear in an invalid state. You'll need to enter values for the required field prior to saving these work items.
To migrate a single team project to a core process
You can migrate a single project or several projects to a core system process.
To migrate a single project, choose the option from the team project from the Overview tab.
Click OK to confirm the change to the core system process.
To change several team projects to an inherited process
Choose the Change team projects to use… option from the context menu of the inherited process.
Choose the team project(s) that you want to migrate and click the icon to move them.
If you migrate a team project to a core system process or other inherited process that doesn't contain the same custom fields, data is still maintained. However, the custom fields that aren't represented in the current process won't appear on the work item form. You can still access the field data through a query or REST APIs. These fields are essentially locked from changes and appear as read-only values.
Create a team project from a process
Choose the new project option from the process context menu to add a team project based on the selected process.
See Create your first team project , to learn more.
Now that you know how to create inherited processes and migrate projects - you can now start customizing a process. As you do so, keep in mind that all team projects that reference the inherited process that you customize will automatically update to contain the changes and modifications that you make.
Grant or restrict permissions to create and modify inherited processes
By default, only Project Collection Administrators can create and manage processes. However, these admins can grant permissions to other team members to Create, Delete, or Edit specific processes.
To customize a process, you need to grant Edit process permissions to a user account for the specific process.
Open the Permissions dialog from an inherited process context menu.
Or, open Security from the inherited process you've selected.
Add the account name of the person you want to grant permissions to and set their permissions.
For more information about setting permissions, see Restrict access.
Each process is a securable unit and has individual access control lists (ACLs) that govern creating, editing, and deleting inherited processes. At the collection level, team project collection administrators can choose which processes can be inherited from and by whom. When you create a new inherited process, the process creator as well as team project collection administrators have full control of the process and can also set individual ACLs for other users and groups to edit and delete the process.
Enable/disable a process
You disable a process to prevent other team members from creating team projects based on that process. You might choose this option when you want to apply several customizations and don't want the process used until they are complete. Or, you might want to retire use of a process in favor of migrating to a new process.
All core system processes and newly created inherited processes are enabled by default.
From the Process overview page, click the process that you want to enable or disable.
To enable or disable the process, select or unselect the checkbox.
Set the default process
Set a process as the default to have it pre-selected for any additional team projects you plan to create.
Account owners/Project Collection Administrators can add team projects from the account home page, which will automatically reference the default selection.
Process naming restrictions
Process names must be unique and 128 Unicode characters or less. Also, names can't contain the following characters:
Feedback and support
We welcome your feedback.
Or, see our comprehensive feedback and support page.
Need additional help?
Email VS Team Services Customization Help and we'll be happy to help you out!