Overview #
In Acumatica-based systems, it is easy to assume that separate tenants are fully isolated from each other. From a business-data perspective, that assumption is often mostly true: tenants are designed to keep company data separate.
Customization publishing is different.
A customization project may be visible or managed from a specific tenant, but the publishing process can affect shared instance-level artifacts such as database structure, web pages, DLLs, and screen files. This means publishing or unpublishing a customization from one tenant can affect other tenants in the same Acumatica instance. Acumatica’s documentation describes customization publishing in a multitenant site as publishing customization projects across tenants, and Acumatica community discussions confirm that some customization impacts are instance-level rather than purely tenant-level. (help.acumatica.com)
The Problem #
A common scenario looks like this:
- A new sandbox or test tenant is created.
- The tenant has not yet been fully mirrored, initialized, or aligned with Production.
- A customization project is published from the new tenant.
- Production unexpectedly appears to lose customization behavior, screens, reports, or related custom artifacts.
At first glance, this seems impossible. The customization was published from a separate tenant, so why would Production be affected?
The reason is that the tenant is not always the true boundary for customization deployment. In practical terms, the safer boundary is often the Acumatica instance, not the individual tenant.
Root Cause #
The root cause is usually a mismatch between tenant-level data isolation and instance-level customization artifacts.
In a multi-tenant Acumatica environment, each tenant may have its own company data. However, customization publishing may touch shared components in the same instance. Community guidance from experienced Acumatica users notes that database structure and web pages can affect all tenants because the tenants share the database and web application layer, while only some data-driven items remain tenant-specific. (AugForums.com)
This creates a mixed deployment model:
| Area | Typical behavior |
|---|---|
| Business records | Tenant-specific |
| Customization project records | Often managed from a tenant |
| Database schema changes | Shared across the instance |
| Web pages / ASPX screen changes | Shared across the instance |
| DLLs / customization files | Shared across the instance |
| Some site map, GI, and configuration records | May be tenant-specific or require multi-tenant publishing |
Because of this, a customization publish from a test tenant can affect Production if both tenants exist inside the same Acumatica instance.
Why New or Unmirrored Tenants Are Especially Risky #
A newly created tenant may not contain the same customization project set as Production. If a publish operation is performed from that incomplete tenant, the system may treat the customization projects selected or available in that tenant as the active publish set.
That is dangerous because Acumatica publishing behavior can unpublish projects that are not included in the selected publish set. Tim Rodman’s Acumatica publishing guide specifically warns that Acumatica publishes checked customization projects and can unpublish unchecked projects. (AugForums.com)
So the risk is not simply:
“The sandbox was new.”
The deeper risk is:
“The sandbox was new, incomplete, and inside the same instance as Production. Publishing from it changed the shared customization state that Production also depended on.”
Example Scenario #
Suppose Production has these customization projects published:
- Project A: Custom sales order logic
- Project B: Custom reports
- Project C: Custom screen changes
A new sandbox tenant is created, but it only contains Project A. Someone publishes from that tenant.
Depending on the publish method and selected projects, Acumatica may rebuild the active customization state using only the projects selected or available from that context. Projects B and C may no longer be applied to shared instance-level files, even though Production still depends on them.
The result may look like Production was “unpublished” or partially reverted.
Warning Signs #
Use extra caution when any of the following are true:
- The tenant was recently created.
- The tenant was created separately rather than restored from a verified Production snapshot.
- The Customization Projects screen does not show the same project set as Production.
- The tenant is in the same URL or instance as Production.
- You are using Publish to Multiple Tenants.
- You are unpublishing a customization from a test tenant.
- Production and sandbox tenants share the same database or web application instance.
- A customization contains database scripts, screen changes, DLLs, or custom pages.
An Acumatica Community answer to a similar multitenant question states that unpublishing a customization in one tenant can affect another tenant, depending on the customization, and recommends testing customizations in a sandbox instance instead. (Acumatica Community)
Best Practice #
The safest practice is:
Test and publish customizations in a separate sandbox instance, not merely a separate tenant inside the same instance.
When that is not possible, use one authoritative tenant to manage customization projects. Do not casually import, publish, or unpublish customization projects from multiple tenants. Experienced Acumatica community guidance recommends choosing one tenant to store and manage customization projects, then publishing consistently from that tenant to avoid confusion and inconsistent deployment state. (AugForums.com)
Recommended Publishing Procedure #
Before publishing customizations in a multi-tenant environment:
- Confirm whether the tenant is in the same Acumatica instance as Production.
- Confirm whether the tenant has been fully restored or mirrored from Production.
- Compare the Customization Projects screen against Production.
- Verify all currently published Production projects are present.
- Verify all projects that should remain published are selected.
- Avoid publishing from a newly created or partially initialized tenant.
- Perform the publish after hours if Production could be affected.
- Export current customization packages before making changes.
- Take a snapshot or backup when appropriate.
- Document which tenant was used as the authoritative publishing source.
Recovery Steps if Production Is Affected #
If Production appears to lose customization behavior after a publish from another tenant:
- Do not continue publishing from the incomplete tenant.
- Go to the authoritative Production customization project set.
- Confirm the correct projects are present.
- Re-select all projects that should be published.
- Republish the full intended customization set.
- Validate affected screens, reports, Generic Inquiries, and business processes.
- Document the incident and update the publishing procedure.
In many cases, no business data has been lost. The issue is often that the active customization layer was changed or rebuilt incorrectly. However, validation is still required because schema, screen, report, and logic changes can affect operational behavior.
Key Takeaway #
A separate tenant is not always a safe customization deployment boundary in Acumatica.
For business data, tenants may be isolated. For customization publishing, the instance matters. Some artifacts are shared across tenants, and publishing from an incomplete tenant can alter the customization state used by Production.
The operational rule should be:
Never publish or unpublish customizations from a newly created or incomplete tenant in the same Acumatica instance as Production unless the full customization project set has been verified and the Production impact is understood.
For high-risk customization testing, use a separate sandbox instance. For multi-tenant environments inside the same instance, maintain one authoritative customization source tenant and publish from that source consistently.
