Our platform is UiPath Cloud Orchestrator with DEV/Test/Prod tenants. The Robots are hosted on Azure Windows instances for DEV / Test / Prod.
I created an UiPath App to upload an Excel file, store it in a storage bucket, then start a unattended process to read the excel file.
The UiPath app points and binds to the storage bucket and process in the DEV tenant.
I would like to deploy and migrate the UiPath app to point to the Test Tenant. It seems like that to point to Test, I have to change the app in the app studio to switch the pointers/bindings for the process and storage bucket and replace them and change or confirm the UI elements are correct.
Does anyone know if there is a better way to do migrate the app to another tenant for the UiPath apps?
It does not seem right to have to change the pointers this way. It only just allows us to point to one tenant at a time so hard to really have DEV/Test/Prod instances of the Uipath app without having copies of the app for each tenant.
I can export the app (.uiapp file) and import the file across Cloud platforms but not across the tenants without changing the name of the app. The .uiapp file seems to be a json format with the bindings in the file with specific ids etc. Changing the pointers and bindings here would be error prone as well.
I have looked through the documentation, the uipath academy training and the forums which do not provide an answer.
This is great feedback! So long as you’re using the same artifacts across tenants you shouldn’t have any issues replacing the dependencies in your app with the ones from another tenant before you publish - but we agree that this doesn’t quite work the way that users need it to.
We are doing two things to improve this experience:
In the short term, we’re improving the bulk dependency management experience to make it easy to change which tenant you’re using
Later this year we’re improving the way apps are published to make Apps work better with Orchestrator and Folders
The team is actively working on this It will be possible to use Orchestrator Folders to deploy (and manage access to) Apps before this summer, possibly sooner.
I am having this same problem if I create an App that app is available on the spot across all tenants making it very cumbersome and error prone to promote from Dev To Prod, have you found a work around? Currently I have an entity connected and a process, my app points to the Dev versions of these items, to promote to the next level I have to make changes that threaten the integrity of the app. I would love to know your approach as I am struggling to find one that would be secure.
I can understand your pain and frustration but right now there is no way to manage it you can only make duplicate copy of your apps for Dev/Uat/Prod and then move apps. Follow below approach.
Create Apps using some name like {AppName}_Dev
Test it successfully.
Export Apps - Import Apps as {AppName}_UAT or Prod
Test it
This way you an make app identical now question will be what if there is a CR to deploy then again follow below approach,
This part of folders will be very interesting because we can manage access based on folder access. So if you have an app that is conected to a process that is linked to a folder you can keep everything connected