Creating Your First Package in Salesforce

I have solidly relied on gooogling every problem and question I’ve had since the start of my Salesforce journey 3 years ago. However when it comes to packaging the usefulness of search results quickly decreased, if you know of good resources, please share a link in the comments below.

1. Considering the Behaviour of each Type of Package

Few options available to you:

Unmanaged Package(published publicly, or privately)

• No Name Spacing required (but you should still use naming conventions for the longevity of your product, think about it as preparing your child for life once they grow up)
• Updates are trickier, it is great to one time insert into an org. To update it may be necessary to uninstall and reinstall the package, if this is used to store significant data in a package that will require updates, this may mean this option is unworkable for you.
• Transparency, you insert your work into an org, and they can keep working it. Think about it as a 1980s car, pop the hood you can change the oil, do what you like with the car in your ownership.

Managed Package

• Name Spacing is required (you need to register and ideally consider this prior to creating all your fields)
• Updates are automatically pushed to recipient orgs.
• No transparency, it all works but your work is hidden from the recipient org. You can think of it as a brand new car where once you pop the hood, you only see a cover and only an authorised mechanic can peer inside and see what’s there. It protects your IP.

Unlocked Package

• Harder to compile as there is no UI, has to go via GitHub.
• It keeps transparency of Unmanaged Package while enabling updating similar to a Managed Package.
• Updates need to be manually distributed and triggered via link but apart from this, the update process is similar to that of Managed.

In the end we went with Unlocked.

2. Consider Whether You Really Need Record Types in Your Package

Packaging Record Types for sObjects: coming soon

Packaging Record Types for cObjects: coming soon

3. Consider Update Behaviour in Relation to Fields

So there is insert, update and from this post I learnt you could have ‘destructive changes’, I will update this part with your comments and as I learn more.

Scenario one: The package field name is a perfect match with an existing field it will overwrite the existing. If the data type matches the data held is unchanged. If the field type is different it overwrites data it holds on records. (eg. A field that is changed from picklist to a checkbox type, all records will be set to ‘False’ regardless of prior value)

Standard Objects (sObjects)

Standard Field: Pick List value deactivated in recipient org via package update:

Standard Field: Pick List value created in recipient org via package update:

Standard Field: Pick List value created in recipient org via package install:

Custom Fields created as part of initial package install:

Custom Fields edited in subsequent update:

Custom Pick List values created in subsequent update:

Custom Pick List values edited in subsequent update:

Custom Pick List value deactivated in subsequent update:

Custom Objects (cObjects)

Custom Fields created as part of initial package install:

Custom Fields edited in subsequent update:

Custom Pick List Values created in subsequent update:

Custom Pick List Values edited in subsequent update:

Custom Pick List Values deactivated in subsequent update:

Hope you find something helpful here. Would love to hear your experiences, tips and any corrections in the comments.

More Tips

Include an App as part of your package, but don’t assume that everything you assign to it will become a dependency, here is where prefixes come in handy.

Chose a prefix to add in front of all your custom fields on standard objects. It may seem tedious but it is worth your time to go back to change this. This is not necessary on cObjects you create, just sObjects. Don’t forget; page layouts, lighting page layouts, compact layouts, field sets, permission sets (if included) — basically everything your package relies on :). If you end up moving components in using change sets this REALLY helps.

If you are working in non-profit space, and using only Custom Objects (fewer than 10) as well as Account and Contact, then consider Lightning Platform Starter licenses which will cost as little as £50 p/a per user. (These licenses do not see objects reliant Sales (Leads) or Service (Cases) Clouds, although have a look here to see if you can grant access to case.)