Can we use Salesforce Territory in our Managed Package which builded on force.com?

We have two Supervisors A & B in the same territory, both A & B have two Sales Reps, Supervisor A has A-Rep1, A-Rep2, Supervisor B has B-Rep1, B-Rep2 How to set the Territory and Role and let each Supervisor and only see their rep's and their own data?

  • Your requirements could also be implemented without TM by a simple role hierarchy and sharing configuration. Also for RH, TM and ETM there is already UI to configure that. Is your Package trying to replicate it? Are you trageting TM or ETM? Best you update your question and not answer with an comment. – Uwe Heim Mar 22 '15 at 10:46

If you use Territory Management data structures or functions, your package might become dependent on this feature to be active in the Orgs where users are going to install it. This might reduce the acceptance of your package for those who can't activate it or don't like it.

The supervisor/rep scenario sounds pretty easy and should be no problem. TM also introduces a second hierarchy parallel to your current Role Hierarchy, so you cand model the assignments independently.

Mind that there are two different versions of Territory Management which are coupled to a corresponding version of Forecasting.

  • Territory Management 1.0 and Customizable Forecast (older)

  • Territory Management 2.0 (or Enterprise Territory Management) and Collaborative Forecast (newer)

It doesn't mean you need to activate Forecasting but your Forecasting will be limited to the respective version. This means the other way round that Organizations with Customizable Forecast and currently no TM can't simply turn on ETM 2.0 but only TM 1.0

Using dynamic APEX and SOQL you might also be able to avoid a system-enforced dependency and write code which works dynamically with both versions of TM or even with a custom TM-substitute or completely without. This will result in more effort for development but will bring the most flexible solution. If possible I would try this approach.

  • So, the best way is building a custom TM-substitute in our Managed Package? But if TM already used in customer org, how do I match their TM? – BruceYue Mar 22 '15 at 5:43
  • I never said that the best way is a custom substitute. I said I would go for a loose coupled non-system-enforced dependency. The rest is additional flexibility as a result of a dynamic design. If you address only THAT single customer with a certain TM: go for it. If you are targeting more: consider that TM is one of the rare used features coming in two different incompatible versions. – Uwe Heim Mar 22 '15 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.