Let me start off by saying that I applaud the fact that the Axure team has added organizations with a user roles system to Axure cloud. This is a HUGE step toward adding more value to the service so that Axure can increase adoption to the platform, encourage more teams to want to use it to manage their projects, and convince teams to eventually integrate it in to their overall design process. I was in the process of setting a new org today and was very excited to see that the new roles system was available. I began configuring my org but had to stop what I was doing when I got to the invitation process to avoid having to answer a flood of Team’s messages on Monday from confused team members (I already sent out 14 and may need to take a “sick day” tomorrow).
Here is the problem …
The roles that are available are fine in theory, but the way that the privileges are set up essentially render them useless. The entire point of having a user roles system is to make it easy to invite/manage users to the org so that you can speed up the time that it takes for team members to begin collaborating on projects. By adding users to the org, you should no longer need to create user invitations for each new workspace/project that gets created, saving you valuable time, and making the process more streamlined for everyone involved. Sadly, the current state of the feature creates more problems than it solves.
The admin role is fine. It allows you to give a user the ability to basically manage all of the users and workspaces. Echoe for the super admin.
The “guest” role doesn’t really provide much value outside of creating a list of users so that you can modify their roles later, and also keep track of who belongs to the org. It also helps to make team members aware of the service and get their Axure cloud accounts created. The issue with this role is that a “guest” is unable to view org workspaces and has to be invited to each workspace individually. You can’t even select “guests” from the org user list to quickly add them to a workspace which means that you have to add them the old fashion way. You could argue that this is the purpose of a “guest”, and that statement would be fine IF the “member” role could bridge the gap. Spoiler alert: it can’t.
The “member” role is where everything falls apart. This was clearly supposed to be the time saving role, but the role comes with too much power! Any user with the “member” role can view all of the available workspaces and choose which ones to join, BUT, they can also create workspaces AND MANAGE all of the org’s members. Between the “guest” role and the “member” role, you either get to create a group of guests that can’t do anything and require an invitation to each workspace, or a group of members that can create workspaces, access all workspaces, and add/remove/modify all org members.
As we can see from the breakdown above explaining the current implementation of the user roles system, it is impossible to add users to an org that have the ability to view the org’s workspaces/projects WITHOUT also being able to manage the entire org’s user list. Until the privileges for the current roles get adjusted, or the ability to create custom roles is added, using the new org tools is going to be a painful process.
If you are facing similar issues and have found a workaround, or if I have missed something so obvious that I have seemingly hallucinated this entire problem like any LLM, please reply to this rant ASAP to save me from the inevitable flood of unread Team’s messages that await the start of the work week.