Managed Project Support

Enabling Single Sign-On

Configuring Azure Maps or Bing Maps


Configure Client-Side Layers

Configure Server-Side Layers


Advanced Settings

Features by Layer Type

Setup Documentation

EZT Managed Project Support – version 3.12.02+

EasyTerritory now makes it easy for regional administrators to delegate realignment work to their territory or sales managers without having to approve every movement of postal codes between territories. This takes the workload off of the administrator while ensuring the overall result at the regional level is sound. One of the major risks in delegating realignments is in the cross-contamination of regions when a territory manager inadvertently moves postal codes from an adjoining area that is not in their purview. Managed projects prevents this. Work gets done more efficiently and territory managers get a more direct-feel for the edits they make.

A regional administrator creates a managing project to define each region a given territory manager has access to. This project is only accessible to the administrator. The administrator also creates a managed project and links it to the managing project. The managed project is accessible by all of the managers under the regional administrator. When a territory manager opens the managed project, they only see their region and can only edit postal codes (or counties, states, etc.) as defined by their regional administrator. It only takes a few minutes to set this up — here’s how:

To set up managed-project support, follow these simple steps: 

  • As a regional administrator, create a project for your territory manager regions.
    • Start a new project in EasyTerritory.
    • Add from the Rolodex the layer you want your managers to build their territories from (postal code polygons are a common layer to use, though counties, states, etc. also work).
    • Create regional territories using the make-territory feature.
    • Save your project.
  • As a regional administrator, edit the same project in the administrative portal in EasyTerritory.
    • Give the label a name to indicate this project defines the regions your managers can access.
    • Set the Project Type to managing.
    • Set unlisted to checked so it will not show up in your manager’s Rolodex.
    • Set private to unchecked.
    • Save your changes.
  • As a regional administrator, re-open your managing project in EasyTerritory by refreshing your browser to start over so that we pick up the administrative changes above.
    • For each region, open the markup properties.
    • Choose the manager from the drop-down (these are EasyTerritory users)
    • Save your changes for each region.
    • Save your project.
  • As a regional administrator, create another blank project in EasyTerritory and save it.
    • Then edit this project in the administrative portal.
    • Give this project a name your managers will recognize.
    • Set the Project Type to managed.
    • Link to the previously created managing project from the drop-down.
    • Set unlisted to unchecked so that it will be available in your manager’s Rolodex.
    • Set private to unchecked so that managers can access it.
    • Save your changes.
  • When managers log into the managed project, they are taken to their work area highlighted in yellow.
    • Managers are then able to create and edit territories within their work area.
    • Managers can only select/query parts from their region. If their region in the managing project was built with postal codes, then the constraint in the managed project applies to postal codes.
    • Managers can only realign territories in their area.
    • When a manager saves the project, all other territories outside their region are left unaffected on the server.
    • When a manager creates a territory, it is automatically grouped by their full name.

Starting in EasyTerritory version 3.39.xx managers can now create derivative projects through a project save-as and then merge their derivatives back into the master managed-project using a markup workflow. The advantage to using this approach is that it allows managers to try several variations in different derivative projects. The merge process only moves the manager’s markup into the master leaving all other project settings and map layer configurations untouched.

For questions about this feature contact