Segment developers between apps - Enterprise Org Structure

Question

We have a large enterprise with a number of different unrelated business units. We are looking to do a smaller Salesforce implementation with some of the smaller business units but would like to keep the enterprise in mind. Everyone is coming from the same domain and will likely use Single Sign On federated through active directory.

Is it possible to delegate admins and developers for apps only? I may have business unit A that has a development staff of 4 and 25 users but what happens when I want to bring on business unit B that has 8 developers and 2000 users?

Do developers have access to all Apex classes in the Org or is there a way those can be partitioned off between business units. I don't want developer in unit A to be able to mess with Developer B's apex class. Nor do I want developer in Unit A to query Unit B's data.

How can an enterprise limit their developer and admin permissions to the app level and have everyone under the same Org? Or is that completely impractical.

Answer 1

TL;DR. It's impractical.

Anyone that can deploy code to an org must be an administrator. The "Author Apex" permission requires View Setup and Configuration and Modify All Data-- in other words, they are full administrators. They can see all code, all fields, and all records in the org.

There are ways to limit this effect, such as creating a sandbox and only granting access to the sandbox as administrators. Since there'd be nothing in there but sample data (unless it were a full sandbox), this would limit data exposure. They'd still be able to see all code and all fields, however. Plus, there'd have to be a master administrator in the production org to import code/accept incoming change sets/etc. Obviously, this person should be trusted.

Alternatively, one could try to set each business unit up with a developer edition, and configure each org with a managed package. This would avoid conflicts and allow seamless upgrades, but this solution is fraught with pitfalls. You can't generally delete items from managed packages. You can't access related data for fields that share the same name across namespaces. You'd use more queries than necessary, etc.

Overall, I'd recommend that you simply trust your developers. Make them sign an NDA if you need to in order to protect yourself and your business units, and make sure you are hiring competent developers. Any trustworthy, competent developer won't be stealing data or code, so finding people that are in for the long haul would be preferable to hiring temp or contracted developers.

Answer 2

Unfortunately, you cannot segment Class/Page security the way you specify. If you have access to develop classes/pages, you have access to all classes/pages.

There are a few things you can do to mitigate this, but likely none of those will be a silver bullet.

1) You can create separate orgs for each business unit and integrate the common data among all of them. This will give you the security you need but will have a big overhead around the integration.

2) You can prefix your classes/objects/pages with a division-specific or project-specific string (eg: DIV1_MyClass.cls, PRJ1_MyPage.page). This provides some separation but no real security. If, as I strongly recommend, you leverage git (or any other source control) then you can add a layer of audit to anything that is checked in.

As I said, there are no silver bullets.... I've worked with a lot of big companies in the past, so feel free to reach out if you have more questions