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 a number of 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, in addition to the “Modify All Data” permission required by Metadata API. Using retrieve() without the “Manage Territories” permission will return only entities that belong to a Territory2Model in Active state. We recommend against retrieving without the “Manage Territories” permission because the call will retrieve 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 will 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, you might 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 will fail 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 will attempt to create new models, but that operation will fail because of the developer name conflict. For example, you might 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 will fail 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 will change the model’s state to Deleting and cascade delete all territories, rules, and user associations in the model. Deleting may take some time depending on the number of territries in the model.
• Whenever a model is created, its initial state is Planning. If a model with the same developer name already exists, it will already have 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.