Sharing custom objects with other licenses - Answers - Salesforce Trailblazer Community
Trailblazer Community
Ask Search:
Elizabeth MillhollenElizabeth Millhollen 

Sharing custom objects with other licenses

I am system administrator. I have created custom objects that my sister company could benefit from simply cloning those custom objects on their license. Is this possible? I have enterprise edition. Thanks
Steve MolisSteve Molis
Are you talking about copying them to another SFDC Org that your sister-company has?
Elizabeth MillhollenElizabeth Millhollen
Yes Exactly SteveMo. I was not sure if that was a possibility. It would
save them time building those custom objects themselves, and ours need to
be exactly the same.
Steve MolisSteve Molis
Okay, you might want to look into using Packages for this.

Overview of Packages

Available in: Group, Professional, Enterprise, Unlimited, and Developer Editions

User Permissions Needed
To create packages: “Create AppExchange Packages”
To upload packages to the AppExchange: “Upload AppExchange Packages”

A package is a container for something as small as an individual component or as large as a set of related apps. After creating a package, you can distribute it to other Salesforce users and organizations, including those outside your company.

Packages come in two forms—unmanaged and managed:
Unmanaged packages
Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the components can be edited in the organization they are installed in. The developer who created and uploaded the unmanaged package has no control over the installed components, and can't change or upgrade them. Unmanaged packages should not be used to migrate components from a sandbox to production organization. Instead, see Change Sets.
Managed packages
Managed packages are typically used by partners to distribute and sell applications to customers. These packages must be created from a Developer Edition organization. Using the AppExchange and the License Management Application (LMA), developers can sell and manage user-based licenses to the app. Managed packages are also fully upgradeable. To ensure seamless upgrades, certain destructive changes, like removing objects or fields, can not be performed.
Managed packages also offer the following benefits:
  • Intellectual property protection for Apex
  • Built-in versioning support for API accessible components
  • Remote access support (OAuth)
  • The ability to branch and patch a previous version
  • The ability to seamlessly push patch updates to subscribers
  • Unique naming of all components to ensure conflict-free installs
The following definitions illustrate these concepts:
Unmanaged and Managed Packages
Managed and Unmanaged Packages
A component is one constituent part of a package. It defines an item, such as a custom object or a custom field. You can combine components in a package to produce powerful features or applications. In an unmanaged package, components are not upgradeable. In a managed package, some components can be upgraded while others cannot.
An attribute is a field on a component, such as the name of an email template or the Allow Reports checkbox on a custom object. On a non-upgradeable component in either an unmanaged or managed package, attributes are editable by both the developer (the one who created the package) and the subscriber (the one who installed the package). On an upgradeable component in a managed package, some attributes can be edited by the developer, some can be edited by the subscriber, and some are locked, meaning they cannot be edited by either the developer or subscriber.

For information on which components can be included in a package and which attributes are editable for each component, see the Quick Reference for Developing Packages.

Packages consist of one or more Salesforce components, which, in turn, consist of one or more attributes. Components and their attributes behave differently in managed and unmanaged packages.

If you plan to distribute an app, it is important to consider packaging throughout the development process. For example:
  • While creating your app, consider how components and their attributes behave in different packages and Salesforce editions.
  • While preparing your app for distribution, consider how you want to release it to your customers.
  • While installing a package, consider your organization's security and license agreements.
It is also helpful to familiarize yourself with general packaging information, such as:

Steve MolisSteve Molis

Preparing Your Apps for Distribution

Available in: Group, Professional, Enterprise, Unlimited, and Developer Editions

User Permissions Needed
To create packages: “Create AppExchange Packages”
To upload packages: “Upload AppExchange Packages”

When you are ready to distribute your package, determine if you want to release a managed or unmanaged package. For more information about the different types of releases, see Developing Packages for Distribution.

  1. Create a package:
    1. Click Your Name | Setup | Create | Packages.
    2. Click New.
    3. Enter a name for your package. This does not have to be the same name that appears on AppExchange.
    4. From the drop-down menu, select the default language of all component labels in the package.
    5. Optionally, choose a custom link from the Configure Custom Link field to display configuration information to installers of your app. You can select a predefined custom link to a URL or s-control that you have created for your home page layouts; see the Configure Option. The custom link displays as a Configure link within Salesforce on the AppExchange Downloads page and app detail page of the installer's organization.
    6. Optionally in the Notify on Apex Error field, enter the username of the person who should receive an email notification if an exception occurs in an Apex script that is not caught by the script. If you do not specify a username, all uncaught exceptions generate an email notification that is sent to This is only available for managed packages. For more information, see Handling Apex Exceptions in Managed Packages.
      Apex can only be packaged from Developer, Enterprise, and Unlimited Edition organizations.
    7. Optionally, enter a description that describes the package. You will have a chance to change this description before you upload it to AppExchange.
    8. Click Save.
  2. Salesforce sets your package API access privileges to Unrestricted. You can change this setting to further restrict API access of Salesforce components in the package. For more information, see Managing API and Dynamic Apex Access in Packages.
  3. Add the necessary components for your app.
    1. Click Add.
    2. From the drop-down list, choose the type of component you want to add to your package.
      • At the top of the list, click a letter to display the contents of the sorted column that begin with that character.
      • If available, click the Next Page (or Previous Page) link to go to the next or previous set of components.
      • If available, click fewer or more at the bottom of the list to view a shorter or longer display list.
    3. Select the components you want to add.
      Some components cannot be added to Managed - Released Managed - Released packages. For a list of these components, see Developing Packages for Distribution.

      S-controls cannot be added to packages with restricted API access.

    4. Click Add To Package.
    Repeat these steps until you have added all the components you want in your package.
    • Some related components are automatically included in the package even though they may not display in the Package Components list. For example, when you add a custom object to a package, its custom fields, page layouts, and relationships with standard objects are automatically included. For a complete list of components Salesforce automatically includes, see Developing Packages for Distribution.
    • When you package a joined report, each block is included in the package. Although the blocks appear in the package as reports, when you click on a block, you see an error message that you have “insufficient privileges” to view the report. This is expected behavior. Instead, click on the name of the joined report to run it.

  4. Optionally, click View Dependencies and review a list of components that rely on other components, permissions, or preferences within the package. An entity may include such things as an s-control, a standard or custom field, or an organization-wide setting like multicurrency. Your package cannot be installed unless the installer has the listed components enabled or installed. For more information on dependencies, see Understanding Dependencies. Click Done to return to the Package detail page.
    You cannot upload packages that contain any of the following:
    • References to person accounts, such as an s-control or custom field referencing person accounts.
    • Workflow rules or workflow actions (such as field updates or outbound messages) that reference record types.
    • Reports that reference record types on standard objects.
  5. Click Upload.
    If you are creating a managed package to publish on AppExchange, you must certify your application before you package it. For more information, seeSecurity and Trust on AppExchange.

    On the Upload Package page, do the following:

    1. Enter a Version Name. As a best practice, it's useful to have a short description and the date.
    2. Enter a Version Number for the upload, such as 1.0. The format is majorNumber.minorNumber.

      If you are uploading a new patch version, you can't change the patch number.

      The version number represents a release of a package. This field is required for managed and unmanaged packages. For a managed package, the version number corresponds to a Managed - Released upload. All beta uploads use the same version number until you upload a Managed - Released package version with a new version number. For example, the following is a sequence of version numbers for a series of uploads.
      Upload Sequence Type Version Number Notes
      First upload Managed - Beta 1.0 The first Managed - Beta upload.
      Second upload Managed - Released 1.0 A Managed - Released upload. Note that the version number does not change.
      Third upload Managed - Released 1.1 Note the change of minor release number for this Managed - Released upload.
      Fourth upload Managed - Beta 2.0 The first Managed - Beta upload for version number 2.0. Note the major version number update.
      Fifth upload Managed - Released 2.0 A Managed - Released upload. Note that the version number does not change.
    3. For managed packages, select a Release Type:
      • Choose Managed - Released to upload an upgradeable version. After upload, some attributes of Salesforce components are locked. For a list of locked attributes, see Developing Packages for Distribution.
      • Choose Managed - Beta if you want to upload a version of your package to a small sampling of your audience for testing purposes. You'll still be able to change the components and upload additional beta versions. For information on beta versions, see Developing Packages for Distribution.
        Beta packages can only be installed in Developer Edition or sandbox organizations, and thus can't be pushed to customer organizations.
    4. Change the Description, if necessary.
    5. Optionally, enter and confirm a password to share the package privately with anyone who has the password. Don't enter a password if you want to make the package available to anyone on AppExchange and share your package publicly.
    6. Salesforce automatically selects the requirements it finds. In addition, select any other required components from the Package Requirements and Object Requirements sections to notify installers of any requirements for this package.
    7. Click Upload.
  6. Once your upload is complete you can do any of the following.
    • Click Change Password link to change the password option.
    • Click Deprecate to prevent new installations of this package while allowing existing installations to continue operating.
      You cannot deprecate the most recent version of a managed package.

      When you deprecate a package, remember to remove it from AppExchange as well. See “Removing Apps from AppExchange” in the AppExchange online help.

    • Click Undeprecate to make a deprecated version available for installation again.
You will receive an email that includes an installation link when your package has been uploaded successfully.
If you uploaded from your Salesforce production organization, notify installers who want to install it in a sandbox organization to replace the “” portion of the installation link with “”

Steve MolisSteve Molis
Here's a great "How to?" guide for creating an distributing Packages ->
Steve MolisSteve Molis
Are you all set now or do you still need help with this?
Elizabeth MillhollenElizabeth Millhollen
Hey SteveMo!

Some more Questions for you: We have had success installing the package to
my sister company in Philadelphia. However, the custom objects that we were
trying to import with the package still aren't showing up on the
administrator's SF.

When I was creating these custom objects (in Baltimore) I had the hardest
time figuring out how my Users could see them. It turned out that on the
Enterprise Edition I had to clone standard user and create a custom user
profile that allowed them to see the custom objects. That solved that
initial problem. I am not sure if the enterprise edition has anything to do
with this new problem we are experiencing, but it is something to

So, I've created a custom user profile here in Philadelphia and that user
can not see the objects.

Where the Heck are these objects hiding??!?!? Thanks for your help. (I'd
say we owe you some serious Outward Bound Schwag at this point! - what's
your mailing address!)

Thanks again,