Packaging and deploying Boomi processes across environments

The order sync between the e-shop and the ERP works in test. Now it has to reach production, and next month a change will follow, and the month after another. This article explains how to make each of those steps a versioned, repeatable release with a way back, and how to do it in Boomi, first by hand and then from a CI pipeline.

The problem with “just deploy the latest”

Without a release discipline, deployments drift:

Nobody knows what runs in production. “The latest version” means different things to different people.
Untested changes slip in. Someone saved a half-finished change to a shared map, and it travels with the next deployment.
Rollback is guesswork. When the new version creates duplicate invoices, which version was the good one?
Releases have no story. Six months later, nobody remembers why the VAT mapping changed.

The pattern: immutable, versioned packages

The pattern used across software delivery works for integrations too:

Freeze the integration and everything it depends on into a package with a version number and notes.
Promote the same package through environments: test, then production. Never rebuild for production.
Change only configuration between environments, never the package.
Roll back by deploying the previous package again.

Build ──► Package v1.4.0 ──► Test ──(approval)──► Production
                                                   ▲
                       Package v1.3.2 ─── rollback ┘

Step 1: Create a packaged component

In Boomi, a packaged component is a frozen, versioned snapshot of a process (or other deployable component, such as an API Service) together with all the components it references: connections, operations, maps, profiles.

Open the process, for example Orders | E-shop to ERP, and make sure all changes are saved.
Use Create Packaged Component (from the process or from the Deploy area).
Confirm the component and its dependent components are included.
Enter a version, for example 1.4.0, and notes. Boomi can suggest a version, but a convention you choose is easier to communicate.
Create the package. It can no longer change; a later fix becomes version 1.4.1.

A useful convention: major version for changes to the contract with other systems, minor for new features, patch for fixes. Whatever you choose, use it consistently.

Write release notes that help at 2 a.m.

Notes are the cheapest documentation you will ever write. Keep them short and specific:

1.4.0 - 2026-10-20 - Maria P.
- Orders with shipping method "store pickup" now map to ERP warehouse W02 (ticket INT-231)
- Customer VAT number trimmed before lookup; fixes C-1042 duplicate customers
- No configuration changes required

The last line matters: say whether environment extensions must be updated before deploying.

Step 2: Deploy to test

Go to Deploy → Packaged Components (exact labels vary slightly between releases), find the package and choose to deploy it.
Select the test environment and add deployment notes if useful.
Check that the environment extensions for any new connection or property are set before the first run.
Run your tests. See testing Boomi processes for what to cover.

Step 3: Promote to production

When test passes and the change is approved, deploy the same package version to the production environment. Do not create a new package from the current state of the process; it may already contain someone else’s unfinished work.

Use Boomi’s role-based access so that only release managers or administrators can deploy to production, and record the approval (ticket number, approver) in the deployment notes.

Step 4: Roll back by redeploying the previous version

If version 1.4.0 misbehaves in production:

Open the deployment history for the process in the production environment.
Find the previous package, 1.3.2, and deploy it again to production.
Confirm the runtime now shows 1.3.2 as the deployed version, and check the next executions.

Rollback restores the logic, not the data. If 1.4.0 already created wrong records in the ERP, you still need to fix them. That is one reason to keep releases small.

Also note that environment extensions are not part of the package. If 1.4.0 required a new extension value, rolling back does not remove it, which is usually harmless but worth knowing.

Step 5: Automate with the Boomi Platform API

Once manual releases work, a CI pipeline (GitHub Actions, Azure DevOps, Jenkins) can do the same steps through the Boomi Platform API (historically called the AtomSphere API). The relevant objects include PackagedComponent (create a package) and DeployedPackage (deploy a package to an environment, and query what is deployed). Check the current API reference for exact field names and authentication; the examples below show the shape of the calls.

Create an API token for a dedicated service user, store it as a pipeline secret, and authenticate with it:

BASE="https://api.boomi.com/api/rest/v1/${BOOMI_ACCOUNT_ID}"
AUTH="BOOMI_TOKEN.${BOOMI_USER}:${BOOMI_API_TOKEN}"

# 1. Create a packaged component for the process
curl -s -u "$AUTH" -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "$BASE/PackagedComponent" \
  -d '{ "componentId": "'"$PROCESS_ID"'", "packageVersion": "1.4.0", "notes": "INT-231 store pickup mapping" }'

# 2. Deploy the package (packageId from step 1) to the test environment
curl -s -u "$AUTH" -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "$BASE/DeployedPackage" \
  -d '{ "environmentId": "'"$TEST_ENV_ID"'", "packageId": "'"$PACKAGE_ID"'", "notes": "CI build 512" }'

A typical pipeline:

# Sketch of a GitHub Actions workflow
jobs:
  package-and-deploy-test:
    steps:
      - run: ./scripts/boomi-create-package.sh "$VERSION"
      - run: ./scripts/boomi-deploy.sh "$PACKAGE_ID" "$TEST_ENV_ID"
      - run: ./scripts/run-regression-tests.sh
  deploy-production:
    needs: package-and-deploy-test
    environment: production   # requires approval in GitHub
    steps:
      - run: ./scripts/boomi-deploy.sh "$PACKAGE_ID" "$PROD_ENV_ID"

The production job deploys the package ID created earlier, never a new one. The pipeline’s approval step becomes your change control record. Pair this with automated tests as described in regression testing for Boomi integrations.

Before you go live

Agree a versioning convention and a release notes template.
Restrict production deployment to a small group or to the pipeline’s service user.
Check extensions in the target environment before each release that adds connections or properties.
Practise a rollback in test, so you know how long it takes.
Keep the API token safe: a dedicated user, stored as a pipeline secret, rotated like any other credential.
Watch the first executions after each deployment; see Monitoring Boomi integrations.

Summary

Treat every change as a frozen, versioned package that is promoted unchanged from test to production, with notes that explain it and the previous version ready to redeploy. Boomi’s packaged components give you that out of the box, and the Platform API lets your CI tool drive it. For the wider picture, see our guide DevOps for integrations.