What IT Is

As an IT consultant, I frequently change technologies and project roles. The frequent shift of focus is great for staying interested, engaged, and marketable. The downside is that many mental-muscle-memory tasks fade or never take root with long gaps between repetitions. One example is XSLT, which I have had to re-learn three times because it is not difficult to learn but only find I need it every five to seven years. Another example is various Linux commands, which I will post on my blog so that I can find them quickly when needed.

An additional technique I use, when available, is little cheats where the broad strokes are easy to remember and help prompt my memory for the details. The example of this I want to share today is creating Salesforce Unlocked Packages.

Before I start, it is important to understand that for a true package-management and -deployment strategy there is a lot more involved than just the ability to create a package. A package strategy requires thinking about how the org is used, who the stakeholders are, how many teams contribute to code and metadata within the org and how different their focuses are, and clear roadmap for an enterprise architecture with agreements on the direction and commitment to sustainable governance model. This post is just about being able to take something built in one org and being able to deploy it into another org as either a consulting starter, a demo set, or a shared feature.

In this example, I built a useful little Flow demo that guides CSRs in first searching for a contact before creating them to reduce duplication while following standard procedures for customer contact.

It is a good component to keep handy as a starting point for clients that need a similar feature, so I want to be able to easily manage it in source control and distribute it to other orgs. Or I may want to share it with other developers for enhancements. In either case, I don’t work hands-on with packages to easily remember how to construct them. No fear! I do remember how to create unmanaged packages, which is a good start. However, it has been a while since I built this component, so looking at the list of flows does not make it clear to me what is what:

I could guess, based on the names, but it is safer to be sure, so I go to the flow itself and look at the Properties to find the API Name:

Components can have dependencies. Sometimes it is necessary to track them down and can require some test deployments to be sure all have been captured. In this case, the implementation is straight-forward, and Salesforce still finds a component that I had forgotten was involved:

Now that there is a package definition in the Salesforce org, I want to be able to move it to Github where I can work with it. The next step is to go to https://workbench.developerforce.com and navigate to Migration\Retrieve and select to extract the package by name:

This will produce a zip file of the package components. To make these useful, set up a Visual Studio Code project for Salesforce (see if How to set up a Salesforce development environment you need help with this part). Now unzip the package into a folder name “unpackaged” at the same level as [PROJEC_PATH] and run the following command:

sf project convert mdapi --root-dir ../unpackaged --output-dir force-app

If the above paths were laid out correctly, you will see an output showing the components added to your project. Otherwise, check your folder layout and naming conventions and try again. At this point, it is useful to replace the default /manifest/package.xml with the one in the root of the unzipped package from Workbench (the following step assumes this). Finally, test that you can push the package contents to another org with:

sf project deploy start --target-org [USERNAME] --manifest ../[PROJECT_PATH]/manifest/package.xml --test-level RunLocalTests --wait 100

Once all components are deployed, you should see them in your org (they may not be enabled):

In this case, the flows require activation before they can be used. Post deployment steps will depend on your components.

Finally, add your project to source control. The project used in this article can be found at https://github.com/ssnsolutionist/Call-in-Contact-Flow-main.

Some of the steps above included commands from a cheat-sheet I maintain at https://github.com/ssnsolutionist/trailhead1/blob/master/sfdx-cli-common-commands.md

09-08-24 Revision Notes:

1. The cheat sheet linked above is out of date. I’m working on it, mostly by having Perplexity.ai re-write them for me as I need them.
2. Originally published as a Logic20/20 Insight article, the editors there later stripped out the screen shots, so publishing the full version here.

© Scott S. Nelson