12-29-2010 06:48 AM
Was there a compelling reason for Sage to remove the ability of selecting Administrator as the Accountmanagerid? Since it is a required field, this was the best way for us to flag an Account as unassigned. It's not like it isn't a typical real world scenario where some Accounts aren't assigned to someone. Enhancements (?) that limit existing functionality should be made only after very careful consideration which doesn't appear to be the case here!
12-29-2010 06:57 AM
I feel your pain on this one as we went through the same issue when we upgraded way back when.
We ended up designating all unassigned accounts as belonging to our VP of Sales. At least this way we were able to show our Account Managers which accounts were up for grabs since our VP does not chase individual accounts.
I agree though, designating unallocated accounts to "admin" would be a better solution.
12-29-2010 02:08 PM
12-29-2010 05:37 PM
I'm not exactly sure what you're saying. It sounds something like, it's not considerate to assign an Account to Admin because it's an ID that has too much power so Sage did the correct thing in disabling that functionality. (Surely, I've missed the point!)
A painfully typical scenario at my company is that thousands of records are imported into CRM and assigned to a handful of individuals because they want the full domain of prospects for their territory. Within a year, if not months, they have returned to their more manageable subset of Outlook Contacts abandoning CRM altogether.
The problem is that one user can only effectively manage so many records and so much data! Their working subset in CRM should be no more and no less. So what do we do with the excess records that have overwhelmed them to date? Delete them? I'd love to, but that wouldn't make the manager who purchased the data very happy. So I do the next best thing, assign the excess to Administrator (a user that rarely logs in at our company and surely not to work with data) leaving a very manageable group of key accounts in the users' My Groups. This worked great in 5x and 6x. Why all of a sudden doesn't it work in 7x. Because someone doesn't think that it's CONSIDERATE to assign Accounts to Administrator?
Look, I've been down the tomayto/tomahto road far too many times. I know this isn't a fight that can be won or loss. You see it your way and I see it mine. That's the nature of the user. So why try to dictate how the user should use the CRM. Why not simply setup the core structures and provide some simple scripting/workflow technology that allows each user to promote their own business rules. If you want to promote the CONSIDERATE alternative of not assigning Accounts to Admin then set up a selectable option allowing the user to choose (or not) for themselves.
My workaround: Exec SQL assignment of Admin to Accountids, related Contactids and Opportunityids - Ugh! Thank you Sage, not!
12-29-2010 06:04 PM
Necessity is the mother of invention. I just found a more suitable workaround: I simply flag the Accounts with a special code word in one of the userfields. And then I create a Group based on that userfield code word which I then use in a territory re-alignment. Oddly enough, Administrator is an option! Beats Exec SQL!
01-27-2011 11:14 AM
Now you've done it Larry! Cat's out of the bag.... Look for a new "enhancement" to remove admin from re-assignment as well. :-)