Last Updated on April 3, 2022 by Rakesh Gupta
Big Idea or Enduring Question:
How do you deploy Flows or Processes using the Packages?
After reading this blog post, the reader will be able to:
- Understand how to use packages to deploy flows
- Understand how to use packages to deploy processes
- Deploy components to any org using packages
Business Use Case
Pamela Kline is working as a System administrator in Universal Container (UC). She has developed Out of Office notification for Chatter post automation in the Developer edition org and done with testing. She wants to deploy this flow to another Developer Edition Org.
Automation Champion Approach (I-do):
Once you are done, with Flow or Process development, the next step is to deploy it. There are many ways, through which, you can deploy or distribute, Flow(s) or Process(s), from one org to another:
- Change Sets
- Visual Studio Code
- Force.com Migration Tool
This blog is a sequel to my previous blog – Deploy Flow(s) or Process(es) Using Change Sets. In this article, I’m going to discuss how to distribute a Process or Flow using Packages.
When both the Salesforce organizations are not connected, for example, Developer Edition org and Production Org, then its best practice using Packages to deploy/distribute the components. There are few possible solutions for the above business scenario, but we’ll use Packages to deploy the flow from one Developer Edition org to another Developer Edition Org. Before proceeding ahead, you have to understand Managed and Undamaged packages in Salesforce.
- Managed Packages: – Managed packages are typically used by Salesforce 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.
- 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.
You can learn more about packages in Trailhead.
Guided Practice (We-do):
There are 4 steps to solve Pamela’s business requirement using unmanaged packages. We must:
- Create an unmanaged package
- Add components to your package
- Upload an unmanaged package
- Install a package
Step 1: Create an Unmanaged Package
- Click Setup.
- In the Quick Find box, type Package Manager.
- Select Package Manager, then click New.
- Name the unmanaged package.
- As a best practice, always input a description.
- Click Save.
Step 2: Add Components to Your Package
The next step is to add components to the package.
- In the Packages list, click the name Out of Office of a package.
- Adding components to package
- Click Add to add components.
- Choose the type of component, in this scenario, choose the Flow Definitions.
- Select the components
- In the end, click Add to Package.
- Optionally, click View/Add Dependencies to add dependent components.
Step 3: Upload an Unmanaged Package
The next step is to upload the managed package.
- In the Package detail page, click the name Upload button to upload the Out of Office package.
- Enter the Version Name and Version Number.
- Optionally, you can select Package Requirements and Object Requirements.
- Click Upload.
After the successful upload, you will get an email from Salesforce with a link to install the package into any organization, as shown in the following screenshot:
Step 4: Install a Package
The final step is to install the package in your developer edition or sandbox org.
If you are planning to install this Package in a Developer Edition org, use the below link
To install this app replace Login with your Salesforce instance name, In my case, it will look like the following URL
- In a browser, type in the installation URL you received when you uploaded the Package.
- Enter your username and password for the Salesforce organization in which you want to install the package, and then click the login button.
- Click Install. You’ll see a message that describes the progress and a confirmation message after the installation is complete.
- Process or Flow which is deployed using the Packages is always in an Active state.
Points to remember
- You can include only one version of a flow in a package.
- You can’t include flows in package patches.
- An active flow in a package is deployed to its destination as inactive. Activate the flow manually after deployment.
- If the flow has no active version when you upload the package, the latest inactive version is used.
- In a development organization, you can’t delete a flow or flow version after you upload it to a released or beta managed package.
- If any of the following elements are referenced in a flow, packageable components that they reference aren’t included in the package automatically. To deploy the package successfully, manually add those referenced components to the package.
- Post to Chatter
- Send Email
- Submit for Approval
I want to hear from you!
What is one thing you learned from this post? How do you envision applying this new knowledge in the real world?
Let me know by Tweeting me at @automationchamp, or find me on LinkedIn.
7 thoughts on “Distribute Flow(s) or Process(es) Using Packages”
How would you include a field as Package Key in order to be able to install the package? I just saw that on a package I installed today
Very helpful! I moved a flow from Trailhead Playground to my dev. org. with your instructions, since there is no change set function in the Playground.
What about adding a flow into a managed package and facing the limits of the customer org? I.E Professional edition only allows 5 flows.
If a managed package is certified by Salesforce, it will not count against the limit.
Good blog post.
Thank you 🙂