Boomi Global Variables replace the old “configure every connection per environment” habit with one account-wide place to manage environment-specific values. That is a real improvement, but it also moves risk: one value change can now affect many deployed packages at once. This guide explains what Global Variables are, how they relate to environment extensions and process properties, and the change-control and lifecycle model I recommend before you let a team loose on them in production.

What Boomi Global Variables are

Global Variables are a centralized, account-wide mechanism for configuration overrides. Instead of setting a connection URL, user name or password as an extension on every process deployment, you define the value once and reference it from the components that need it. Boomi introduced the feature in Early Access with support for Connection, Trading Partner and Operation settings, and made it generally available in the March 2026 release, rolled out to accounts in staged waves through the following months.

The capabilities that matter for an architect:

• Reuse across components – one variable can be referenced by multiple Connections and Trading Partner settings, including encrypted fields such as passwords.
• Where Deployed – a view that shows every package that references a variable, so you can see the blast radius before you change anything.
• History – an audit log of value changes per variable.
• Test values – values you can use in Test Mode without touching what production uses.
• Archive and unarchive – added in July 2026 in both the UI and the Platform API, so retired variables can be frozen instead of deleted.

Global Variables vs. environment extensions vs. process properties

Teams often ask which mechanism to use. They solve different problems, and mixing them without a rule is how configuration drift starts.

My rule of thumb: if two or more processes need the same environment-specific value, it belongs in a Global Variable. If only one process uses it and it may legitimately differ per deployment, keep it as an extension. If the value is produced or changed during a run, it is a process property. For a deeper comparison of runtime scope, see Boomi process properties vs. global variables: a practical scope model.

Why Global Variables need change control

With extensions, a wrong value usually breaks one process. With Global Variables, a wrong value can break a whole integration domain in one save. That is not a reason to avoid the feature – it is a reason to treat a variable change as a production change, with the same discipline you apply to a deployment.

Three properties of the feature make that discipline practical:

1. The impact is visible up front. Where Deployed tells you which packages reference the variable. Paste that list into the change request instead of guessing.
2. The change is auditable afterwards. History shows who changed what and when, which shortens incident analysis considerably.
3. You can test without touching production values. Test values let a developer validate a new endpoint or credential in Test Mode first.

A naming and ownership model that scales

Global Variables become hard to govern once there are a few hundred of them and nobody knows who owns which one. Decide on a convention before the first variable is created:

• Prefix by domain and system, for example FIN_SAP_BaseUrl, HR_Workday_TenantId, B2B_PartnerX_AS2Url. The prefix makes ownership obvious in lists and in Where Deployed.
• Name the meaning, not the environment. The environment is already the dimension the value varies on; SAP_BaseUrl_PROD defeats the purpose.
• One owner per prefix. Record the owning team in your CMDB or wiki and require that team’s approval for value changes.
• Separate secrets from plain configuration in naming, so reviewers can see at a glance when a change touches a credential.

The lifecycle: active, archived, and why not delete

Since the July 2026 release, a variable has a status of active or archived. In the Global Variables Management page an “Archived” status column and an information-panel banner make retired variables visible and prevent accidental edits. The Platform API follows the same model: the former archive parameter was renamed to status, archived variables cannot receive new or updated values, and the only change still allowed on an archived variable is its status. Invalid Global Variable references are also no longer included in the GlobalVariableReferences section of the Component API response.

That gives you a clean retirement path:

1. Check Where Deployed. A variable that is still referenced by a deployed package is not ready to retire.
2. Remove the reference from the components, package and deploy them.
3. Archive the variable. Its last value stays visible for audit, but nobody can change it by accident.
4. Unarchive only through the normal change process if a rollback needs it.

Archiving instead of deleting keeps the History intact, which matters when an auditor asks what a connection pointed to six months ago.

A production change procedure for variable values

1. Request – the change describes the variable, the new value (or the secret reference), the reason and the planned window.
2. Impact – attach the Where Deployed list and identify the business processes behind those packages.
3. Test – validate with a test value in Test Mode against the target system.
4. Approve – the owning team approves; for credential changes, a second person reviews.
5. Change – update the value in the agreed window.
6. Verify – confirm the History entry and check the first executions of the affected processes in Process Reporting.

Watch your runtime patch level

New platform features interact with runtime versions. Boomi’s July 2026 runtime patch 26.07.1 fixed an issue where enabling Global Variables and creating a global variable caused X12 Trading Partner listeners to fail at the Start step (INT-18435). The lesson is broader than that one defect: when you switch on a platform-wide configuration feature, include runtime patch levels and B2B listeners in your test scope, and roll out in non-production first.

Migrating from environment extensions

Do not migrate everything in one go. A phased approach keeps risk small:

1. Inventory extensions that hold the same value across many processes – shared endpoints and service accounts are the best candidates.
2. Create the Global Variables with the naming convention above and fill them per environment.
3. Switch one integration domain at a time to reference the variables, then package and deploy.
4. Remove the now-redundant extension values so there is only one source of truth.
5. Archive any variable that turns out to be unused after the migration.

Frequently asked questions

Can Global Variables hold passwords?

Yes. Global Variables can be referenced from encrypted connection fields. Treat changes to those variables as credential changes and apply four-eyes review.

Are Global Variables available in every account?

Boomi rolled the feature out in waves after the March 2026 general availability. If you do not see Global Variables in your environment configuration yet, check with your account team.

Should I delete Global Variables I no longer need?

Archive them. Archived variables keep their history, are clearly marked, and cannot receive new values, which is exactly what you want for retired configuration.

Sources

• Boomi Integration and Automation Platform Release – March 2026
• Boomi Integration and Automation Platform Release – July 2026
• Boomi Integration Release Notes, July 2026
• Boomi Enterprise Platform May 2026 Release Notes