What's in a Salesforce Namespace?
If you ever want to move code between production environments then Packages are the way to go (keep an eye for a questions like this in App Builder and the Administrator exams).
There are quite a few considerations when it comes to creating your package.
In this blog post, I'm going to focus on the differences between Managed and Unmanaged packages and registering a Namespace on your ORG.
In this blog post, I'm going to focus on the differences between Managed and Unmanaged packages and registering a Namespace on your ORG.
Why create a Package?
Change Sets are perfect for creating something in your development environment and eventually promoting it through to Production. However, there is a strict relationship between those two environments.
Each Sandbox has to be specifically linked to the Production environment it will promote changes to. You can't deploy a change set unless you have specifically authorised that Sandbox for incoming packages.
This restriction means that if you ever want to move some code or configuration from one production environment to another production environment then you will need to create a Package.
There's also a great overview on the Salesforce Developer's Blog here. https://developer.salesforce.com/page/Packaging
Once you've had a quick look at the background to Packaging read on for more detailed information of the 2 different types of package you can create.
Each Sandbox has to be specifically linked to the Production environment it will promote changes to. You can't deploy a change set unless you have specifically authorised that Sandbox for incoming packages.
What is a Salesforce package?
If you've never come across Packages before, check out Salesforce.com's overview page of them here. https://help.salesforce.com/apex/HTViewHelpDoc?id=sharing_apps.htmThere's also a great overview on the Salesforce Developer's Blog here. https://developer.salesforce.com/page/Packaging
Once you've had a quick look at the background to Packaging read on for more detailed information of the 2 different types of package you can create.
Unmanaged
What are Unmanaged Packages best for?
In my opinion, Unmanaged Packages really come into their own if you need to install a fully editable TEMPLATE in another Production environments. (I've made the word template bold as that's the term that helped me best understand this concept).
If you create an Unmanaged Package containing your new reports/dashboards, cool Workflow, or any other Salesforce item and give it to another Salesforce Administrator they will be able to edit ALL of it. You will have no control over that package's future use.
Now, that might be fine for your current purpose but it's one thing definitely to bear in mind. Overview of Packages from Salesforce Developer Blog
Now, that might be fine for your current purpose but it's one thing definitely to bear in mind. Overview of Packages from Salesforce Developer Blog
Managed
What are Managed Packages best for?
A Managed Package would be best if you would like to maintain control over the content. If your package contained custom code you had written, or a new application you had spent hours developing, you might want to ensure that the code couldn't be copied, or edited without your permission.
There are several steps to creating a managed package and for detailed guidance I'd really recommend this resource. https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/packaging_about_packages.htm
First Steps to Managed Packages
 |
| Before you can create a Managed Package you will need to create a Namespace for your ORG |
Registering your Namespace
If you need to have more control over the contents of your package you will need to create a Managed Package. However, before you can do that you will need to change fairly innocent looking settings in Developer Settings.
When you first try to create a Managed Package in your ORG you may not have the option to select Managed. If your environment is showing "Unmanaged Only" then you need to activate a custom namespace in your ORG first.
 |
| Once your Namespace is registered you can either create Managed or Unmanaged packages |
What's a namespace?
Have a quick read through this great namespace overview if you want more information on Namespaces, but essentially the Namespace is a unique identifier for your ORG and prevents 2 different packages have a field/report etc with exactly the same name.
Packaging your content allows you to export it to different Salesforce environments.
 |
| The configuration screens give a good reminder of the differences |
- Imagine that your package contained a field with an API name of Field1__c.
- When you import that package into another org there is a risk of Field1__c already being taken.
- So, namespace prevents this by labelling your field with the namespace as prefix you'd actually be importing yournamespace.Field1__c.
 |
| Your Namespace has to be unique across Salesforce |
Conclusion/Why does this matter?
Imagine that you had just complicated lots of custom code and you're all ready to package it up and sell it for $$$$ on the AppExchange.
Read this bit below if nothing else :)
If you have written all of your code before you activate your namespace then you will have to go back through all of it and add in the namespace prefix to keep it working once you have activated your namespace.
So, my advice would be to decide whether you are going to activate your namespace and/or create a managed package before writing that first line of code.
Good luck!
Gear Icon from IconFinder, artist Edoardo Coccia
Comments
Post a Comment