BIM 360 Admin Hierarchy

[bshevelev]

Current BIM 360 Admin Hierarchy is deficient, poorly structured, and counterproductive.

With the current system, Account Admin invites another Account Admin, - who decides? Account Admin creates projects, - we have thousands. Account Admin adds other team members, - hundreds of them.  Project Admin can’t create a project, - their direct responsibility. Project Admin can’t add members to Member directory, and can’t add Companies, - they should collect that data (a huge load of data) and communicate it to Account Admin, - waste of time and resources. Project Admin from other Team has access to all other trades folders, - makes no sense, both technically and legally.

To make the system efficient, the following Admin Hierarchy changes should be implemented ASAP.

Admin Role	Responsibilities
Hub Admin	Invites Account Admins
Account Admin	Invites Project Admins
	Sets Roles
Project Admin	Creates a Project
	Activates the Services
	Invites members to the Member Directory
	Invites Companies to the Company Directory
	Invites Members to the Project
	Creates Teams
	Sets Design Collaboration Permissions
	Sets Folder Permissions
	Invites Team Admin to the Project
Team Admin	Invites Team members to the Member Directory
	Invites Team Members to the Project
	Sets Design Collaboration Permissions for Team Members
	Sets Folder Permissions for Team Members

[fhohnen]

Completely agree. The whole security / admin paradigm is too complex, laborious and prone to error.

Thinking about this in terms of more fundamental change,  I wonder if a scenario along the following lines might be possible:

• each company is responsible for provisioning / creating / removing their own users, and the details of their own company.  Why not have a single directory of companies and users, rather than forcing multiple hub owners to do this for other parties?
• each company controls its own data, and who it gives access to. Let contractual mechanisms (not technology) drive who they give access to, and not lump this responsibility on a hub owner, who participants may or may not trust. Delegated control of certain sections of the information hierarchy.
• The concept of 'project ownership' should not equate to 'access to everything' (see point above). Make the platform as level a playing field as possible (should not advantage a hub owner for example).
• the party that starts a project can invite other users to that project (eg. someone from company A invites someone from company B). Once a single individual from company B has been invited, they can in turn invite others from company B. The result is less work lumped on the hub owner, and fewer delays.
• if a company removes a user, they lose access to ALL projects, regardless of hub ownership. Contractually they are usually only granted access on behalf of a company, and any access they may retain on other hubs not controlled by their company is a contractual and security risk.

[juan_guardia]

Project managers can add members to the team from the general list, and these members automatically add their company to the project. It should be possible for the project manager to add companies to the project.