Does anyone here from a large enterprise with hundreds/thousands of Salesforce.com users? How is your team currently structured? Do you leverage onshore/offshore model? What type of breakdown do you have in terms of administrators, analysts, architects, developers etc?

Since Salesforce.com is a SaaS solution and since it also empowers business users to act in administrator capacity with point-and-click tools, I am just wondering what is the right team size from the IT perspective?

UPDATE: Some clarifications - (A) lots of customizations (B) lots of integrations (C) lots of Apex/VF coding is part of requirement.

5 Answers 5


I don't have thousands. I do have over 200 spread between three divisions (and cities).

It's important to consider what you want to use your instance for. Do you need to have an onsite administrator? Will you be doing ongoing customization or apex?

Do you just need some import support? You might be able to get away with using Salesforce Success Plans + and take advantage of their Admin functions.

Or you may want a full team. The recommendation is 1 full time admin for every 100/150 users. If you're doing lots of customization consider having someone with some apex development skills.

For any organization that will be doing major customization of their instance I recommend two items. First, a Business Analyst. Someone who can take a research and figure out your requirements and needs. This is important because they can provide the details of your projects to any internal staff or your any consultant/outsource company you choose.

The second is someone who can do project management to plan and prioritize what is really important for your organization


I second the Wizardly One on making sure that you have a good BA. That being said, I know that Salesforce markets the heck out of not being software, but it sounds like you are going to be doing a lot of software development. If you already know that you are definitely doing that then make sure that you have a solid team of professional software developers. Don't go cheap. The last thing you want is for someone with no DB design experience to end up designing the entire enterprise DB (i.e., the Salesforce Object model) for your large scale systems.

I'd hire someone who has experience running designing, developing, and deploying SF projects, someone who understands team development concepts, someone with enterprise application development experience. You don't want someone who only has SF experience. They are going to need to be sharp in DB design, HTML/CSS/JavaScript, other languages and technologies (Java, Oracle, etc) for the integration. If you can get at least one really solid SF developer you can have that person help you more with hiring and training others who are less experienced.

Lastly, to echo one of Leon's points, if you are doing large scale team development it is very important to have controls in place. It is very easy and tempting to make changes willy nilly in production, but that doesn't always scale well when there are multiple large scale projects going on and/or multiple large scale custom enterprise apps in use. Here are some good references that someone leading your team development should be able to analyze (pros and cons of each) and implement:

  1. Team Development: Possible, Probable, and Painless: http://www.youtube.com/watch?v=EfXMY-ZFXXY&t=5m34s

  2. Development Lifecycle Guide: http://www.salesforce.com/us/developer/docs/dev_lifecycle/


On the topic of governance for large orgs, here's a recorded Dreamforce session with VMWare, Genentech, and USG describing their change management/release management processes:



A lot comes down to the governance you want to put in place to support your Salesforce implementation, which is in turn driven a lot by the size and complexity.

When there is a single population (even if widely spread) often a small team of SFDC admins who live in the business (rather than IT) can do the bulk of the work - changing picklist values, adding new fields, even creating new objects / business processes. Where things are more complex - eg you have an opportunity record which is used very differently by different parts of the business, you need to put in place more strict controls and processes. Say a new field of "Market Sector" is added to an object by your Singapore operation - is there a similar field in use in AMER Mid-market? By your project services sales team? Some central management of what goes in where, who owns it etc becomes necessary...

Totally agree with Salesforce Wizard though - start with a BA and as far as possible drive any development to declarative, point and click rather than Apex / VF.


We are running a mid-size org with about 600 active users spread out over at least 5 departments, with Customer Portal access for external employees as well. We are a 3 man team, with 1 Business Analyst, 1 Admin and 1 Developer. Internally we're not part of the IT team but belong to the business tools development unit. I have no idea what onshore/offshore eans, but I guess we're not using it.

As to the size of the team, it has worked well for the last 6 years we've been using Salesforce. A biggger team would perhaps scale better in terms of getting the solutions out faster than we do now, along with more and better governance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .