Need help in understanding the deployment folder setup for RPA processes in Meastro BPMN.
I have the following process "New invoice creation"created in a folder named “Default/InvoiceProcessFolder”
And while creating the task in Meastro BPMN, I have selected the same process and have deployed the meastro to the main folder
And post deployment, I see that the run package requirement the process is referring the package from the solution (subfolder) path (“Default/Invoice reation/New invoice creation”) which deployment has created, rather from the path that I have used in the automation selection
From what I understand, this is expected when the Maestro BPMN is deployed as part of a Solution. The deployment creates/uses the resources under the Solution folder, so the Package Requirements may point to the process created there rather than the original process folder.
If you want the child RPA process to run from Default/InvoiceProcessFolder, you may need to deploy the child process/dependency to that folder and configure the Package Requirements accordingly. UiPath also recommends deploying Maestro dependencies to the same folder where the Maestro process is deployed.
So I don’t think the original folder selected during automation configuration is automatically preserved after Solution deployment. It would be good to confirm whether there is a supported way to link the Package Requirement to an existing process instead of the Solution-created process.
Hi @AutomationUser_SMB
This is expected Maestro behavior. When a Maestro solution is deployed, it creates its own solution-specific subfolder and automatically maps package requirements to resources within that solution context. Therefore, the Run Process activity references the process from:
Default/InvoiceProcessFolder/InvoiceCreation/...
instead of directly using the process from:
Default/InvoiceProcessFolder
This design helps keep solution dependencies isolated and portable.
What you can do
After deployment, manually update the Package Requirement mapping to point to the process in the desired folder, if Maestro allows editing.
Ensure the target process is published and accessible in the folder where the Maestro solution is deployed.
If you want to reuse a centrally managed process, consider referencing it as a shared resource rather than relying on the auto-created solution copy.
By the looks of it, I understand the same, by give the setup of the processes the info like queue and assets were already created in the main folder, and
If the meastro is creating the seperate in the solution folder, it should also share or copy all the other information related to the process.
And update the package requirement for each deployment is not a reliable way of working on this approach.
Please suggest if there is a way to preserve the main folder path, package, assets, queue and other info associated with the process when deployed,
By the looks of it, I understand the same, by give the setup of the processes the info like queue and assets were already created in the main folder, and
If the meastro is creating the seperate in the solution folder, it should also share or copy all the other information related to the process.
And update the package requirement for each deployment is not a reliable way of working on this approach.
Please suggest if there is a way to preserve the main folder path, package, assets, queue and other info associated with the process when deployed,
I agree with your point. If the queues, assets, and other resources are already configured in the main folder, manually updating the Package Requirement after every deployment would not be a practical approach.
I think the key point to confirm is whether Maestro/Solutions supports preserving the existing Orchestrator folder/resource references during deployment, instead of creating new resources under the Solution folder.
If there is no such mapping option, then this looks more like a limitation/design consideration of the current deployment approach. I would suggest raising it with UiPath Support to confirm the recommended deployment architecture for this scenario.
