I am working on a Tulip instance with 3 different workspaces. Unless I’m misreading, the Tulip docs (Workspace Configurations and Settings) seem to indicate that I should be able to add non-“Account Owner” users to multiple workspaces with different levels of access, but my attempts to do so have been unsuccessful.
When I open the user’s profile, I only see the option to select a single workspace. When I look at the “Roles” tab and go to “Assign” for a given role, I see checkboxes that make me believe I should be able to select multiple workspaces for the user but that doesn’t seem to work either. If I do attempt to grant the user another role in a different workspace from the “Roles” tab, it appears to give them that role and remove roles in other workspaces which is not what I’m trying to do. It occurred to me to go to the Workspace Settings to attempt to add the user, but all I see is a message that the “user is not part of this workspace” with no option to add them.
Am I doing something incorrectly, is there a known bug, or is this not a feature that is available on the platform yet?
Hi @cpuzzo, sorry you’re having trouble with this.
I’ve checked with our support team and this looks to be a bug. It’s a problem we’re aware of and there’s a fix being planned now. We can circle back when this is resolve. Thanks for flagging with us!
Looks like we’re hoping to release a point release in the next few days, as soon as tonight. I’ll check back with the support team and let you know when it’s implemented.
@John@cpuzzo Was this issue resolved?
I’m trying to assign non Account Owners to multiple workspaces and the User setting page only has a drop down list to select one Workspace.
Hi @kefl and @cpuzzo - wanted to follow up here, are you still having an issue with this?
There appears to be a potential feature limitation here, where you can’t have a non-Account Owner User in more than one Workspace when SAML is in use and ‘IdP Control Mode’ (not ‘Tulip Control Mode’).
Can you confirm if you are using the IdP Control Mode? If so, I can turn this into a Product Suggestion!
We are starting our journey with Tulip and I would suggest we will need this in the very near future to have multiple workspaces (and potentially multiple roles).
We will be looking into using Tulip in IdP control mode as part of our user provisioning as we are using SAML (GxP environment) for the signatures.
Currently we are only configured to use SAML so far.
Hey Nathan, I am a product manager that works on governance features at Tulip. Can you share your use case for multiple workspaces in one instance? Is it related to organizing multiple plants on one instance? Or is it more about managing the lifecycle of apps- dev/test/prod? Or something else?
So currently we have no business case at the moment as we are still rolling out to one plant.
Our workspaces are organised as our manufacturing sites within our instances. So I can envisage when we start rolling out to other plants we would need potentially certain users to support the other plants.
If we use Tulip Control mode we cant do that currently.
Appreciate it. And to help me understand a potential solution, do you have your IdP organized in such a way that it would make it easy to determine which users should be in which workspaces? Is it one field or multiple fields? IE is there a list of sites that they are a part of (possibly multiple fields), or is it that users with a certain level of seniority should have access to multiple workspaces (single field)?
Hello Beth,
Sorry for the very late answer.
We are not even using SAML at the moment and the issue remains.
If I understand my situation correctly, A user (not account owner) must choose ONE workspace, then you can assign a role or group to this user. Group and Roles are currently not workspace related.
A new product suggestion would be to modify the current structure to:
A user does not need to choose a workspace
A role is workspace dependent (Supervisor in Workspace A and Supervisor in Workspace B are two different roles)
A user can have roles from different workspaces (Supervisor in Workspace A and Application viewer in Workspace B)
Why?
Because some user may have roles across workspaces and don’t need to be Account owners. Because a user may have different roles depending on workspaces.
Because roles could different from one workspace to another (maybe supervisor in Workspace A has more rights than supervisor in Workspace B).
