Skip to main content
Answer

Is It Possible to Restrict a Customization to a Specific Company in a Single-Tenant Multi-Company Setup?

  • June 9, 2025
  • 6 replies
  • 140 views
M
Semi-Pro III
Forum|alt.badge.img+1

Hi all,

I'm trying to understand how Acumatica handles customizations in a single-tenant, multi-company environment.

Let’s say, for example, we have a single tenant with three companies under it (not separate tenants). Suppose we develop a customization for the Sales Order screen (SO301000) — such as adding custom buttons and logic — but we only want that customization to be active and visible for Company 1, and not for the other companies.

Here’s what I’d like to know:

  1. Is it possible to restrict a customization (or parts of it) to apply only when a specific company is selected in the Company/Branch selector?

  2. Are there any best practices, performance concerns, or potential pitfalls when implementing company-specific logic like this in a shared customization project?

I understand that in a single tenant, we can't publish separate customization projects per company, but I’d like to know the recommended way to handle company-specific behavior in this kind of setup.

The goal is that if a user switches between companies (e.g., using the company selector), the customization should only appear or behave differently when Company 1 is active.

Any guidance, recommendations, or code snippets would be greatly appreciated!

Best answer by DrewNisley

It depends on what kind of logic you are wanting to implement. If you are using the customization project editor to do things, then the answer is no, but if you are doing code, the answer is it depends. You can include logic into your code to utilize the AccessInfo class that will allow you to access the current branch the user is signed into. You can then incorporate that into visibility restrictions and logic, but it might have to be a little extensive depending on how many changes you are making. If you want to publish this to multiple instances, I would suggest creating a Setup screen that you can add a field to select a branch to reference in your logic instead of hard-coding the BranchID into your code. If you don’t, you are going to have to change your code between different instances.

Hope this helps!

6 replies

DrewNisley
Pro I
Forum|alt.badge.img+3
  • DrewNisley
  • Pro I
  • Answer
  • June 9, 2025

It depends on what kind of logic you are wanting to implement. If you are using the customization project editor to do things, then the answer is no, but if you are doing code, the answer is it depends. You can include logic into your code to utilize the AccessInfo class that will allow you to access the current branch the user is signed into. You can then incorporate that into visibility restrictions and logic, but it might have to be a little extensive depending on how many changes you are making. If you want to publish this to multiple instances, I would suggest creating a Setup screen that you can add a field to select a branch to reference in your logic instead of hard-coding the BranchID into your code. If you don’t, you are going to have to change your code between different instances.

Hope this helps!

Drew Nisley
darylbowman
Chris Hackett
M
A
Jr Varsity I
Forum|alt.badge.img+5

Hi ​@malinthawarnakulasooriya08 ,

I believe we can handle this within our code by checking the specific company and ensuring our customization runs only under that condition.

 

string companyName = PX.Data.PXAccess.GetCompanyName();
int? branch = PX.Data.PXAccess.GetBranchID();


Based on the requirement, we can add conditions using the companyName and branch variables to control the execution of our customization.

Chris Hackett
M
D
Captain II
Forum|alt.badge.img+7
  • Django
  • Captain II
  • June 9, 2025

Often I’ll add a checkbox to the related Setup DAC where I can toggle the functionality on and off. Then I never have to worry about someone else publishing nor do I have to worry about snapshots.

Chris Hackett
M
DrewNisley
M
Semi-Pro III
Forum|alt.badge.img+1

Thank you so much ​@DrewNisley , ​@Ankita Tayana & ​@Django for your valuable answers. Dear ​@Django Could you please explain a little bit more of your answer? 

Chris Hackett
D
Captain II
Forum|alt.badge.img+7
  • Django
  • Captain II
  • June 11, 2025

So, for example, I’ve added a field to SOSetup that is a boolean field:

 

In my code, I just check to see if the box is checked or unchecked before running my new functionality. This way I can publish the same codebase to production AND to my testing environment without worry. In production that check box is unchecked until all of the testing has been completed.

Chris Hackett
M
DrewNisley
nhatnghetinh
Captain II
Forum|alt.badge.img+11
  • nhatnghetinh
  • Captain II
  • June 12, 2025

Hi ​@malinthawarnakulasooriya08 

We use "Access Rights" to assign permissions to groups of users in which companies are allowed to see new fields, new features that are customized.

 

Best Regards,

NNT

I have devoted my time and deep passion to Acumatica! 🌐 https://www.linkedin.com/in/phambaotruong
Chris Hackett
M
Terms & ConditionsCookie settingsAccessibility statement
About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved