I tried to use Invoke Process in UiPath 2024.10.8. I want to invoke by Package Name, but the list of entry point is empty. If I write it manually, I can use the entry point, but I hope that I could select the entry point. Do anyone know about this issue?
hello @Yudha_Cahya ,
That’s expected behavior rather than a bug in 2024.10.8.
The Entry point dropdown gets its list from the process definition in Orchestrator, not from the package itself. With Invoke by = Process name, Studio can query the release in the connected folder and read the entry points that process exposes, so the list fills up. With Invoke by = Package name there is no process/release to query — the package is only resolved by the robot at runtime — so Studio has nothing to enumerate and the list stays empty. Typing it manually is the expected path there, and it writes exactly the same value the dropdown would: the workflow path relative to the package root, e.g. Process.xaml or Workflows\SendReport.xaml.
Two things worth knowing:
- Invoking by package name is still supported but deprecated per the docs. If nothing forces you to use it, switch to Invoke by = Process name and point it at the process in Orchestrator. You get the dropdown, the Refresh arguments option works properly, and if you leave Entry point empty it falls back to the entry point configured on the process in Orchestrator.
- When you flip the toggle, Studio does not update the name for you. Package name and process name are often different, so re-check that field after switching.
Quick way to confirm what you are hitting: open the process in Orchestrator → Edit → look at the Entry point dropdown there. If your entry points are listed in Orchestrator but not in Studio while in package mode, it is the package-vs-process behavior above, not a package that was published without entry points.
One more thing to rule out: Studio has to be connected to the same Orchestrator folder where the process lives, otherwise even Process name mode comes back empty. If the process sits elsewhere, set Orchestrator folder path on the activity (for example Finance/Accounts Payable).
Docs reference: Activities - Invoke Process
This could be related to the package not being properly published or the entry point configuration.
Please check:
-
The target process/package is published successfully in Orchestrator.
-
The package version selected in Invoke Process is the correct one.
-
The workflow you want to invoke is configured as an Entry Point.
-
Try refreshing/reloading the package in the Invoke Process activity.
If the entry point is still not listed, you can also try removing and re-adding the Invoke Process activity or updating the UiPath.System.Activities package to the latest compatible version.
Since manually entering the entry point works, it may also be a UI/package metadata refresh issue.
I see, thank you for your answer. Then, I want to confirm your last paragraph. So, if I create the reusable process in folder IT, can I use it in a project that placed in folder Finance?
Yes, that works. That’s exactly what Orchestrator folder path on the activity is for.
Set it to the folder where the reusable process lives, relative to the tenant root, with / as the separator — so IT, or Shared/IT if it’s nested. If you leave that field empty, the robot only looks in the folder the parent job is running from, which is why a Finance job wouldn’t find it by default.
Two conditions to be aware of:
- Modern folders. Cross-folder invoking works with modern folders. Classic folders don’t support it.
- Permissions. The robot account running the Finance process needs access to the IT folder too, with rights to view the processes and packages there. If it doesn’t have that, the run fails with a “child process not found” error — and that error actually logs the path the robot searched, which makes it easy to confirm whether it’s a folder-path problem or a permissions one.
One Studio-side thing that trips people up here: the Process name dropdown only lists processes from the folder Studio is currently connected to. So while Studio sits on Finance, the IT process won’t show up in that list. Either type the process name in manually and set the folder path alongside it, or temporarily switch Studio to the IT folder, pick it from the dropdown, then set the folder path back. The stored value is identical either way.
A design note you can take or leave: if the thing in IT is genuinely shared logic rather than a process that also runs on its own, publishing it as a Library and adding it as a dependency is usually cleaner than invoking across folders. You get per-consumer version control, no runtime coupling to folder permissions, and no cross-folder package lookup at execution time. Invoke Process is the better fit when the child really is its own process — has its own schedule, its own queue, its own owner in IT — and Finance just needs to trigger it.
I don’t think I will create it as a library cause my main idea is to try using part of the existing projects rather than create a new library. But, if it should be done with new library, I will try to look for it. Could you give your opinion about this problem?
Then, due to your respond, if I get it correctly, if my users just have the access of folder Finance, their robot can’t run the process in IT folder, right? Do you have an activity suggestion if I want to recall a function from any folder with limited access permission?
Yes, you read it right. Folder access is enforced at runtime, and there’s no activity that gets around it — Invoke Process, Start Job, Get Asset, they all resolve against the folder the account can actually see. If the Finance account has no role on IT, the call fails no matter which activity you use. That’s by design, not a limitation to work around.
So you have three options, and which one fits depends on what “reusable” really means here.
1. Grant minimal access (if the process in IT is genuinely its own process)
Add the Finance executing account to the IT folder with a small folder-level role — View on Processes and Packages, plus Create on Jobs. Nothing else. They won’t see IT’s assets, queues, or anything unrelated. Then Orchestrator folder path = IT works. This is the normal answer when IT owns the automation and Finance just triggers it.
2. Deploy the same package as a process in Finance too
The package sits in the tenant feed, so you can create a second process from it inside the Finance folder. Same automation, no cross-folder call, no extra permissions. Downside is two process entries to keep in sync when the package version changes.
3. Library — and I think this is actually your case
You said you want to recall a function from an existing project. That’s the tell. Invoke Process runs a whole separate process as a child job — it’s not a function call. A library is a function call: you publish the reusable workflows, add the library as a dependency, and the activities show up in your Studio panel like any other. It gets packaged into the Finance project, so at runtime there is no IT folder, no cross-folder lookup, and no permission question at all.
You mentioned wanting to reuse parts of existing projects rather than build something new — that’s exactly what a library is for, and you don’t start from scratch. Open the existing project, create a library project, and move the workflows you want to share into it. The arguments you already have on those .xaml files become the activity’s input/output properties. Usually it’s an afternoon of work, not a rewrite.
Short version: if IT should run it, go with option 1. If Finance should use it, go with the library.
Ahh okay, I got it. Thank you very much for your responses