Designating a Primary Territory

To determine incentive compensation credit for territory assignments in downstream systems, establish clear territory responsibilities, and resolve integration conflicts that may occur when a user is assigned to multiple territories, Align admins can designate a territory as being a roster member’s primary territory. Primary territories are prioritized when Align configures a user in CRM using setup data inherited from their functional profiles, but the user is assigned to multiple territories with different functional profiles.

For example, a roster member assigned to a territory goes on a leave of absence. Their territory is temporarily assigned to another roster member as a non-primary territory, while the employee on leave retains primary ownership of the territory.

Configuring

To configure this feature:

  1. Grant the Align Integration User the following permissions:

    Object

    Object Permissions

    Fields

    Field Permissions

    align_settings__aln

    CRED

    primary_assignment_handling__aln

    Edit

    roster_member_territory__aln

    CRED

    primary__aln

    Edit

    roster_member_territory_model__aln

    		 CRED

    primary__aln

    Edit

    roster_member_territory__aln

    		 CRED

    override_primary_validation__aln

    Edit

    roster_member_territory_model__aln

    		 CRED

    override_primary_validation__aln

    Edit

  2. Grant Align end users the following permissions:

    Object

    Object Permission

    Fields

    Field Permissions

    align_settings__aln

    R

    primary_assignment_handling__aln

    Edit

    roster_member_territory__aln

    RE

    primary__aln

    Edit

    roster_member_territory_model__aln

    RE

    primary__aln

    Edit

  3. Add the primary__aln field to the following object page layouts:

    • roster_member__territory__aln
    • model_roster_member_territory__aln

  4. Add the primary__aln field to the Roster Member Territory related list on the following object page layouts:

    • roster_member__aln
    • territory__aln
    • model_territory__aln
  5. Add the primary_assignment_handling__aln field to the align_setting__aln object page layout.

  6. Select one or both of the following values for the primary_assignment_handling__aln Align Global Setting:

    • validate_roster_members__aln – Prevents users from assigning more than one primary territory to a roster member
    • validate_territories__aln – Prevents users from assigning more than one primary roster members to the same territory

    Existing roster member assignments are not retroactively validated when enabling this setting. This setting can only be used in the Global Settings record and cannot be used in field-force specific settings, since end users can be assigned to multiple territories in different Field Forces.

Designating a Primary Territory for a Roster Member

To designate a territory as being the primary territory of a roster member, select Yes for the primary__aln field for the appropriate roster_member_territory__aln or model_roster_member_territory__aln records.

When the user attempts to create or save a roster_member__territory__aln or model_roster_member_territory__aln record designated as a primary territory, the following validation occurs based on the selected values for the primary_assignment_handling__aln Align Global Setting:

  • If validate_roster_members__aln is selected, all other roster_member_territory__aln or model_roster_member_territory__aln records associated with the roster member are checked. If any other record is already designated as being a primary territory within the same date range, the user is prevented from saving the record.

  • If validate_territories__aln is selected, all other roster_member_territory__aln or model_roster_member_territory__aln records associated with the territory are checked. If any other record is already designated as another roster member’s primary territory, the user is prevented from saving the record.

  • If both validate_roster_members__aln and validate_territories__aln are selected, both steps of validation occur

Validation in model records does not apply across models, only within the same model. For example, a roster member can be primarily assigned two different territories for the same date range in different projects.

Admins can override the validation specified in the primary_assignment_handling__aln Align Global Setting by selecting Yes for the override_primary_validation__aln field on the appropriate roster_member_territory__aln or model_roster_member_territory__aln records. This field can only be populated via data loading and automatically resets to No as part of the dataload process to prevent future changes that override validation from occuring in the user interface.

Resolving Multiple Profiles with Primary Territories

If a user is assigned to multiple territories, with one territory designated as a primary territory, an integration conflict may occur if the different territories attempt to assign different types of the following records to the user:

  • Security Profiles
  • Application Profiles
  • Layout Profiles
  • Security Policies

This is because users can only be assigned one of each type of these records. If this occurs, a message displays in the header of the corresponding roster_member__aln record informing the admin that the user’s primary assignment is being used to resolve the conflict when setting these values in CRM.

See Roster Members with Multiple Inherited Functional Profiles for more information about users with multiple functional profiles.

Primary Territories and Roster Member Transfers

When territories are transferred between roster members, the end_date__aln field of the old roster_member_territory__aln record automatically populates with one second prior to the selected transfer date. This ensures roster_member_territory__aln representing primary territory assignments do not overlap after a transfer. Additionally, the new assignment is also designated as the primary territory.

For example, if the Align admin selected April 1st as the transfer date of a territory, the end_date__aln field of the corresponding roster_member_territory__aln record populates as March 31st at 11:59:59 PM.