You could look at creating different companies based on a logical division within the parent company such as a region or high level org structure and go mult-tenant.
This would effectively give you one more layer of grouping and also allow you to refine permissions to the region etc. We did this but then kept the support organizations named similarly so that each "company" had a desktop tech support org and a telecom support org etc Because we based this on a high level org structure we were also able to represent one more level of the organization in the company org dept structure. Thanks Cade On May 8, 2012, at 9:32 AM, Frank Caruso <[email protected]> wrote: > One of the requirements is to have the application auto assign tickets to a > support person based on the location of the incident. If the incident is at > Site A in Kansas then the system needs to able to auto route to the Site A > Support Group as wells auto assign a technician assigned to Site A. There can > be many Sites in Kansas and each could have a unique support personnel, but > there are also could be many sites that share the same support personnel - > would be dependent on the proximity to each location. > > Are there actually 1200+ support organizations and groups, no, but the > requirement is still there and I see no other way to minimize the number of > support groups and provide the requested functionality. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
