Please help me find a solution to this. We currently have an organization that doesn’t respond to user requirements
we have multiple citizen users and runners who each have a personal outlook connection
they use common attended processes that are published on shared folders
they do not have service accounts
I understand the only solution is to create their connections on the said folder however they do not want other users to be able to see them
What alternative is there? is the only solution to run each automation on their personal workspace? so in the case the process will have to be published again?
@adext01 Hi,
You don’t necessarily need to publish a separate copy of the automation into every user’s Personal Workspace.
For this scenario, you can keep the attended process in the shared folder, while each user keeps their personal Outlook connection in their own Personal Workspace. This way, their personal connections are not exposed to other users. UiPath actually recommends Personal Workspaces for connections authenticated with personal user accounts.
You can also restrict users from creating connections in the shared folder by assigning the Automation User role (or a custom role without Connections.Create). They can still run the shared attended process while maintaining their private connections separately.
So I would avoid duplicating/publishing the same process into every Personal Workspace unless there is another requirement that specifically needs that setup.
Hi @adext01 ,
As there are no service accounts and users do not want others to see their Outlook connections, running the automation from each user’s Personal Workspace is the most suitable solution. The process may need to be published/shared to those workspaces so each user can use their own private connection.
There is an alternative, but the important point is that personal connections created in a user’s Personal Workspace are not automatically available in other folders.
If the process needs to be executed from another folder or by a robot, I would avoid depending on the developer’s Personal Workspace connection.
A better approach is to create the Integration Service connection in a shared folder and give the required users/robots access to that folder. Then the connection can be used by the processes deployed there.
For example:
DEV
Developer can use their own connection for development/debugging.
If other developers or unattended robots need to use it, create a shared DEV connection in a dedicated folder.
Give access through folder roles rather than sharing personal credentials.
TEST/UAT
Create the connection using the TEST service/robot account.
Store/use it from the TEST shared folder.
Developers get only the permissions required to deploy and test.
PROD
Use dedicated service/robot accounts.
Keep the connection in the PROD folder with restricted access.
So, instead of trying to make a Personal Workspace connection visible to other folders, I would recommend folder-level shared connections + RBAC.
This also makes the deployment from DEV → TEST → PROD much cleaner because you don’t have to change the process logic just because the connection belongs to a particular developer.