By using this website, you agree to our Terms of Use (click here)
We have a site with 3 companies. Each time a customization is added to one of the companies, it uninstalls the customization's installed in the other companies. Not all of the customization's are applicable to the other companies. How are other's managing this issue?
For the automatically unpublishing issue when publishing, you must publish inside the customization window. Then the other customization will remain published.
Great question and one that can be VERY confusing.
An Acumatica Instance is just a website or a URL.
A Customization Project can affect two things:
1. Front-End: The Acumatica front-end is essentially just .aspx web pages. Each screen that you visit in Acumatica is just an .aspx web page. There can only be one web page for the screen in each Acumatica Instance. Multiple companies running under the same Acumatica Instance all share the same front-end code.
2. Back-End: The Acumatica back-end is the database. Since an Acumatica Instance can only be connected to one database, the companies running on that Acumatica Instance are all stored in the same database. If you add a field to a table, it is adding that field for all companies. Multiple companies running under the same Acumatica database all share the same back-end code.
Note: One Acumatica Instance can only be tied to one Database, but one Database could have multiple Acumatica Instances pointed to it. And each Acumatica Instance could have different front-end customization in place (if you want to give yourself a real headache).
Now, there are some nuances to this. For example, a Customization Project could contain Site Map menu entries. Since those are just database records stored per company, you could say that customization is company-specific. But, for all practical purposes, a Customization Project affects all companies on an instance. That's the way that I recommend thinking about it at least.
If you publish a Customization Project in multiple companies on the same instance, then things get very confusing as you are experiencing. Especially when you have a Customization Project with the same name stored in multiple companies. Then it's pretty much impossible to know which one is actually published.
There is a difference between "stored" Customization Projects and "published" Customization Projects. You can store a Customization Project in each company. But a "published" Customization Project is the only thing that really matters as far as what functionality you experience. Once you publish a Customization Project, it affects all Companies (now called Tenants in Acumatica 2018 R1) on an Acumatica Instance because that is when it modifies the .aspx pages.
So what is the best practice? Personally, I recommend picking one Company/Tenant to store your Customization Projects in. Delete the ones in all of the other Companies/Tenants. Then, publish to all companies when you publish the Customization Projects.
Hi Everyone.
I am having the same issue.
We have 2 separate companies but they both need different customizations applied. I am having a hard time trying to figure out where to publish them from. We had an incident recently where somebody published the customizations in Company 2 and it removed all of the customizations from Company 1.
I don't want the customizations for Company 1 in Company 2 and vice versa. I need to keep them isolated. Is there a way to do this?
Thanks.
I also think it is important to be sure we are all using the same terminology. What version are you running @Mindover? If you are using 2017 R2 or earlier, then you should be able to publish Front-end customization by company as Tim lays out in his earlier comment.
If you are using 2018 R1 or later, you should be able to publish front-end customizations by tenant.
Starting in 2018 R1, what was called company was renamed to tenant and a new middle layer of organizational structure called 'Company' was introduced. This uses the Branches table to manage this new construct.
All this to say, I am not aware of a way to have different customs by company in 2018 R1 and later within the same tenant.
@shawn-slavin - This was for version 6.1. We have since migrated them to 2018R1. The problem still exists, if they are a tenant in the installation and you customize the screens, then it applies to all tenants. It makes sense it would because they all share the same site. Customizing the database though will make it specific to the tenant.
Tim, I think you might have missed the issue asked here about customisations applying to one Tenant but not the others. If these customisations are Front-End, then my understanding is that it's not possible. Once you publish Front-End (eg. Page) customisations to ANY Tenant, they will apply to ALL Tenants because Tenants are a database level concept whereas Pages are an Instance level concept.
If you ask me, Publish is broken and needs an overhaul. I've been caught out by its traps before.
We are running 2017 R2. I did verify with support that it is not possible to Publish separately from inside Acumatica.
I think the customization really apply to all tenants, even you have created customization in Tenant 1, once you published it will be automatically applied to all remaining tenants.
I think the customization really apply to all tenants, even you have created customization in Tenant 1, once you published it will be automatically applied to all remaining tenants.
That's only true for Site level customisations - database level changes (eg. Site Map) will not be published to all Tenants through a single publish (to one Tenant).
Royce, I agree with your database level changes comment, but some database changes (like adding a field to a table) affect all Tenants. In general I've experienced that front-end changes affect all Tenants, but I've seen some specific front-end customizations that can vary by Tenant. It's so confusing though that I personally prefer to have one set of Customizations and apply them to all Tenants. That's definitely the safest thing to do. And I totally agree with you, PUBLISH is broken and needs an overhaul. Acumatica isn't TRUELY multi-tenant in my opinion. If it was, then Tenants wouldn't be able to impact other Tenants (like publishing in one Tenant removing customizations in another Tenant).
Sorry for the confusion between Tenants/Companies. I was following the lead in the first post to use the "2017 R2 and prior" terminology. I modified my post above to hopefully be more clear. I also added a new post with a graphic explaining the difference between Instance/Tenant/Company/Branch in 2017 R2 and prior vs. 2018 R1 and later:
https://www.augforums.com/augforums/everything-else/instance-vs-tenant-vs-company-vs-branch/
Tim, just to clarify, when i was referring to database changes it was DML changes and not DDL changes. In other words, records in a table and not table structural changes.
I agree that Acumatica isn't true Multi-Tenant.
I still remember when I tried to copy some GIs to a new Tenant and in the process managed to remove all of our Partner made customisations from our main Tenant. That's why i don't use publish any more and manage it all manually.