We are new to Salesforce and only recently we started actually discussing using Salesforce to support some of our more complex business operations.

The use of Salesforce to support these business operations will require several new custom objects in additional to custom visualforce pages, triggers, API, etc.

So far, we have only created simple customizations to our Salesforce organization such as visualforce pages to meet simple objectives, triggers, new custom objects, etc. When we got these quick and small customizations done, we either used our Developer Sandbox or a Developer Organization.

In case of the Sandbox use, depending on the complexity of the customization, we either created a changeset to deploy to production or manually created the customization in our production organization. Now, when we used a developer organization, we pushed the customizations to the Sandbox either via a unmanaged package or by manually creating them again in the Sandbox; and once installed and tested in the Sandbox, we followed the Sandbox approach mentioned above to push them to production.

So, now that we are discussing creating complex customizations to support our business operations, which will involve creating a lot more custom objects, relationships, triggers, API calls, etc, we are curious to know what most Salesforce developers in similar situation as ours are doing.

What approach would you use?

  • Develop the app in the Sandbox and push to production via changesets.

  • Develop the app in a developer org and push to Sandbox and production via a UNMANAGED package. (I think this approach does not allow for future upgrades)

  • Develop the app in a developer or and install into Sandbox and Production via a MANAGED package (We had a hard time with this approach in the past as we were not able to easily troubleshoot errors due to the managed package's debug logs not being visible to Admins).

Any feedback is greatly appreciated.



  • 3
    Suspect you will get a variety of answers. I would add another approach of keeping your work in a version control system and pushing to sandboxes and production through the Ant tooling. On the managed package approach, you can get the detailed logs enabled so that shouldn't be decider there.
    – Keith C
    Sep 1, 2015 at 23:02
  • 2
    The longer you go without it, the more you'll realize you need a code versioning system. I've learned this the hard way.
    – sfdcfox
    Sep 1, 2015 at 23:27

2 Answers 2


Keith C has mentioned ANT, but I might iterate up to a full-weight dev process like that over time.

I'd start with dropping managed packages internally unless you have a compelling reason (Use cases laid out here: https://help.salesforce.com/HTViewHelpDoc?id=managing_packages.htm&language=en_US). You're developing and customizing for your org only, I don't see why you would need to use these.

Changesets or similar should be good enough. I personally deploy code and some customization straight out of MavensMate (open-source IDE), manually reproduce some objects and fields directly into PROD (I like the granular control over permissions this way), and use changesets sparingly (I find them slow to build).

Dev org vs. Sandbox comes down to your appitite for dev process complexity, team size (is it greater than 1? {simplification}), and potential integration targets (eg. SAP). In my experience, the thing that prevented me from really using Developer Orgs to correctly tier my dev work was that I only had 2 versions of integration-target systems to connect (Dev and Prod), so could only wire up SFDC Stage and Prod with a full set of behaviour. Depending on what you mean by 'API's, this could influence you.

Overall, regardless of deployment flow, I would strongly encourage you to get a few of the building blocks right:

  1. Factories to support unit tests (test coverage required at 75% level, but these tests often become inflexible without well-thought-out factory classes to provide inputs).
  2. Trigger framework like EVA (http://www.slideshare.net/developerforce/an-extensible-design-for-apex-df-template), etc (https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices)
  3. Source Control: this can be a bit unintuitive because the final source is stored in the cloud, but simply use your chosen IDE to pull the source directory to your local box, then GIT (or equiv) normally.

*edited as per Keith C.

  • I'm not making a recommendation; I'm adding another option to the list for Sam to consider.
    – Keith C
    Sep 2, 2015 at 7:36
  • Fair point, Keith.
    – DavidWaugh
    Sep 2, 2015 at 17:08

There is a sort of middle ground between unmanaged and managed packages for this. You can use what I refer to as Local Unmanaged Packages which are unmanaged packages used only as a container for metadata in the org but not for distribution of metadata between orgs. The advantage is that the Local Unmanaged Package's metadata can be retrieved from a source org and deployed to a target org easily via the Metadata API.

You should be able to quickly try out this approach with the following steps:

  • In your DE org, go to Setup -> Create -> Packages and create a new unmanaged package.
  • Use the Add button to add all the components you want to be a part of your package
  • git clone https://github.com/SalesforceFoundation/CumulusCI (these are our build scripts that make it easy to work with your metadata)
  • Set the environment variable CUMULUSCI_PATH to the location where you checked out CumulusCI
  • Create a new folder and change into it
  • Edit cumulusci.properties and set cumulusci.package.name to the name of your unmanaged package
  • Create a subfolder, src, which will hold your metadata source
  • Create a build.properties file with sf.username, sf.password, and sf.serverurl lines (more info at https://developer.salesforce.com/docs/atlas.en-us.daas.meta/daas/forcemigrationtool_connect.htm)
  • Run ant retrievePackagedToSrc

When the retrieve completes, you'll have a local copy of all the metadata from the unmanaged package being developed in your DE org. If you then edit the build.properties file to provide the credentials to the org you want to deploy to, you can run the deploy command:

ant deploy

This will deploy the retrieved metadata from the src directory into the new target org. When deployed, you'll notice the new target org has the same package with the same contents under Setup -> Create -> Packages. Even better, you can continue to use this same retrieve/deploy process to push updates to the unmanaged package from source to target org. Note that you never actually upload or install an unmanaged package. It's just used as a local container in the org.

Once you have everything running through files in a local directory, it becomes much easier to version control. You can create a new Github repository from the local directory and start using Github to track changes to your code. Next up would be setting up automation to automatically test your commits to version control and report any deployment or test issues to you.

You must log in to answer this question.

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