Territory2Model

File Suffix and Directory Location

Territory2Model components have the suffix territory2Model and are stored in the territory2Models folder.

Version

Territory2Model components are available in API version 32.0 and later.

Special Access Rules

The Territory2Model object has a State field in the SOAP API. States include Planning, Active, Archived, and several other states, such as Cloning, that indicate that a process is underway. Users who do not have the Manage Territories permission can access only models in Active state. The Manage Territories permission is required for deploy() calls for all territory management entities. Using retrieve() without the Manage Territories permission returns only entities that belong to a Territory2Model in Active state. We recommend against retrieving without the Manage Territories permission because the call retrieves only partial data.

Fields

Declarative Metadata Sample Definition

The following example shows the definition of a Territory2Model component.

1<?xml version="1.0" encoding="UTF-8"?>
2    <Territory2Model xmlns="http://soap.sforce.com/2006/04/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3    <name>FY13</name>
4    <description>Geographic allocation</description>
5    <customFields>
6        <name>Activation_DateTime__c</name>
7        <value xsi:type="xsd:dateTime">2014-07-16T05:05:00.000Z</value>
8    </customFields>
9    <customFields>
10        <name>AutoNumber__c</name>
11        <value xsi:type="xsd:string">M# 000001</value>
12    </customFields>
13    <customFields>
14        <name>DeactivationDate__c</name>
15        <value xsi:type="xsd:date">2016-07-12</value>
16    </customFields>
17    <customFields>
18        <name>External_Id__c</name>
19        <value xsi:nil="true"/>
20    </customFields>
21</Territory2Model>

Usage

• The retrieve() call does not return models in these four states: Cloning, Cloning Failed, Deleting, and Deletion Failed.
• Whenever a model is created, its initial state is Planning. You can only do a deploy() operation for models in Planning or Active state. The same requirement applies to territories and rules associated with those models. For example, sometimes you can have a model in Planning state on a sandbox org, and a model with the same developer name in Archived state on your production org. The deploy() operation on production fails because that model’s state is Archived and that state prevents changes to the model.
• Because of the state restrictions, if you have territory models in different orgs with identical developer names and you attempt a deploy() operation, Metadata API attempts to create new models. However, that operation fails because of the developer name conflict. For example, sometimes you can have a model in Planning state on a sandbox org, and a model with the same developer name in Archived state on your production org. The deploy() operation on production fails because that model’s state is Archived and that state prevents changes to the model.
• If you try to delete a model that has territories, then the delete() call changes the model’s state to Deleting and cascade deletes all territories, rules, and user associations in the model. Deleting can take some time depending on the number of territories in the model.
• Whenever a model is created, its initial state is Planning. If a model with the same developer name already exists, it already has a state, so we do not include the State field in Territory2.
• Territory Management 2.0 components don’t support packaging or change sets and aren’t supported in CRUD calls.
• Namespaces aren’t supported for unlocked packages.

Wildcard Support in the Manifest File

This metadata type supports the wildcard character * (asterisk) in the package.xml manifest file. For information about using the manifest file, see Deploying and Retrieving Metadata with the Zip File.