By using this website, you agree to our Terms of Use (click here)
I am setting up a new Tenant and want the customisation project that was created for our main Tenant to be applied to this new Tenant. Our partner did the original publish for our main Tenant. I'd rather do it myself this time then engage them to do something that should be trivial. Is it a matter of using the Publish to Multiple Companies function and selecting the new Tenant from the list? As it is already published to our main Tenant, is it fine to not select both Tenants in the list?
Should i select Database Only (I'm thinking yes) or Publish with Cleanup (I'm thinking no).
The thing is, when i look in the new Tenant, i already see most of the cusomisations already there. I believe database changes are applied to all Tenants anyway, and same applies to site files (reports, pages etc.)
The only thing that appears to be missing are the site map changes (2 reports added), which i could just do manually without publishing. The customisation project consists of: Screens, Reports, Site Map and DB Script. By my understanding, Reports and DB Scripts are site level, Site Map is Tenant level. Therefore publishing would only accomplish the Site Map changes as the other changes have already been applied at the Site level when the project was originally published.
Yes, use PUBLISH -> Publish to Multiple Tenants on the Customization Projects (SM204505) screen:
Don't use Database Only unless you only want the backend stuff to happen (not the front-end) which usually you don't want.
Publish with Cleanup is ok to check. Acumatica tries to be smart so it doesn't have to republish stuff that is already published. But sometimes it's too smart. So check Publish with Cleanup if you want it to be sure to republish everything (it will just take longer).
As for Customization Projects in multiple Tenants, it's super confusing. You can have Customization Projects in multiple Tenants, but when they publish, they affect the Database structure for all Tenants (since there is only one database) and the Web Pages for all Tenants (since they share the web pages). Only any actual Database data (like menu entries) won't be published unless you are publishing to multiple Tenants (I think Data Access Classes might behave the same way). Bottom line, you get this weird combination of some Tenant-specific stuff and some multiple Tenant stuff even when you only publish to one Tenant.
In practice, you will give yourself a big headache if you load Customization Projects into multiple Tenants. Best practice (in my opinion) is to pick one Tenant to store all Customization Projects, then publish to all of the Tenants from there so you ensure that of your customizations are consistently applied across all Tenants.
In the end i didn't bother doing it. The only customisation that wasn't in the new Tenant were 2 site map entries which I added manually. Database Changes, Screens and Reports were already there. Thanks for the explanation Tim. 🙂
So I tried the Publish to Multiple - from our test tenant to our new tenant. In the process I managed to unpublish our main customisation project from our main live tenant and almost had a heart attack. I had to republish our main customisation project to our main tenant and thankfully everything was restored and no data loss (main project includes database changes).
I guess this I why our partner advised us that its better to have one rolled up project and only have that one published, which kinda makes the publish to Mutiple Tenants to copy changes to new Tenants, not really possible. What am I missing here?
Pretty stupid that Publish to Multiple also unpublishes any other projects in Tenants that weren't selected.
The unpublishing projects issue is only partially related to publishing to multiple tenants. The important rule to remember is that when publishing customizations, the system always unpublishes ALL customizations before publishing those you have selected. The only way around this that I am aware is to go into the one customization you want published and publish it from there. For one reason or another, this method by-passes the unpublish step.
I finally found this documented in the most current S100 Sys Admin training guide on page 75 under step 5.2. (I have been burned by this more than once!)
Thanks for the reply @shawn-slavin. I found the section in S100 you mentioned:
So this basically means it's not possible to use Publish to Multiple Tenants as a means of just cloning some database objects (GI's, Site Map, Security etc) from one Tenant to another without impacting your source Tenant? This has really turned me off using Publish as a means for copying custom objects to new Tenants.
Royce,
I'm not sure. This isn't my strong suit. I'm not a developer.
If you have multiple tenants with different customization package bundles, I'm not sure how you will manage them as a single group. If you have groups of tenants with identical customization package bundles, you should be able to publish and update as a group. If each tenant has a unique set of customizations, I don't see any way to manage their packages any way other than as individual datasets.
I think Shawn hit the core problem here: Customization Projects stored in more than one Tenant.
There is some gray area, but in my opinion, for all practical purposes, Customization Projects really are at the Instance (or URL) level, not at the Tenant level. If you assume that every Tenant on the same Instance has the same set of Customization Projects, then it keeps things really clean.
Then you just have to pick one Tenant and one Tenant only to store the Customization Projects in. Otherwise it gets confusing because you don't know which ones are actually deployed.
I have no issues with selecting one Tenant as the "main" tenant for customisation projects management. The issue I have here is that I want to copy a bunch of database objects to a new Tenant. These objects were created directly in the main tenant. This means creating and publishing to multiple a new "copy to new tenant" project.
What caught me out was that when i did a test run of this from a test tenant, it unpublished our main customisation project in our main tenant!! I also don't like that my "copy to new tenant" project would need to remain as published in our main tenant.
Because of all this, I decided not to go the publish method and i am migrating everything manually (for the 2nd time) to our new tenant. Publish is broken in Acumatica. It needs an overhaul!
In hindsight, this is probably what i should have done:
I would imagine that when followed this way, the copy project would only appear as published in the new Tenant and not the one it was exported from. This is a much cleaner way to bundle DB objects for cloning to a new Tenant vs "Publish to Multiple" from an existing one. I would also imagine there is no risk of unpublishing anything from your main tenant because the Publish is done in the new Tenant.
I spoke too soon - I simulated the above procedure in an Acumatica training database. I published a small "customisation" project with a couple of trivial code extensions in Tenant1 and then created a simple Dashboard in Tenant1. I created another project in Tenant1 for the Dashboard and Exported it. Then in Tenant2 I imported the project and published. Tenant2 now had the Dashboard. Then back to Tenant1, my "customisation" project was shown as Unpublished and the copy project was Published.
So basically this procedure doesn't work if you have customisation projects already published in your source Tenant.
Edit: but did find that you can switch back to Tenant1 and republish the customisation project to restore your customisations. This will also unpublish the copy project, which has nil impact anyway as the project is database objects only. The copy project can then be deleted from Tenant1 as it doesn't need to permanently remain once the objects have been copied over.
I am working up the courage to try this in our live system 🙂
Right. Pick one Tenant and put all Customization Projects there. That's what I'd recommend at least. You might do some temporary stuff on a per Tenant basis, but when you're done, keeping all Customization Projects in one Tenant is the cleanest. Otherwise it can get very confusing.