Workplace Vs Project Pt BR | Help

UI: selectores Workplace / Project en la navegación y respectivos Settings Audiencia: todos los usuarios

Qué son Workplace y Project

BIMWorkplace organiza la información en dos ámbitos jerárquicos:

Workplace
└── Project
    ├── CDE
    ├── Explorer
    ├── Design
    ├── Build
    ├── Management
    └── Insights

Un Workplace es el espacio de nivel superior donde se gestiona la organización del trabajo, los usuarios y los recursos compartidos. Un Workplace puede contener varios Projects.

Un Project es el espacio operativo de un proyecto de construcción. Siempre pertenece a un único Workplace y contiene los miembros, configuraciones y datos específicos de ese proyecto.

Regla simple: si algo debe gestionarse o reutilizarse entre varios proyectos, tiende a pertenecer al Workplace. Si pertenece solo a un proyecto, tiende a pertenecer al Project.

Diferencia esencial

	Workplace	Project
Función principal	Gobernanza, administración y recursos comunes	Trabajo e información de un proyecto específico
Jerarquía	Nivel superior	Existe dentro de un Workplace
Usuarios	Miembros del Workplace	Miembros asignados al Project
Roles	Workplace roles	Project roles, asignadas separadamente en cada Project
Ejemplos de configuración	Subscription, Billing, Companies, Workplace Users, Attributes, Permissions, templates y créditos	Project Info, Teams, Project Users, Naming Standards, Approval Flows, CDE Configuration y Meetings Policy
Ejemplos de datos	Datos administrativos y recursos compartidos	Models, Views, Topics, documentos y carpetas CDE, reviews y el resto de información operativa

Workplace no significa necesariamente “empresa” o “contrato”

Un Workplace puede usarse para representar una organización, unidad de negocio, cliente, programa, contrato u otro contexto de colaboración, según cómo la organización desee estructurar BIMWorkplace.

Por lo tanto, no debe asumirse que Workplace = empresa o Workplace = contrato.

Project no significa necesariamente “fase”

Un Project representa el contexto operativo de un proyecto. Una organización puede decidir crear Projects separados para fases, edificios, lotes o contratos distintos, pero esto es una decisión de organización de la información y no una regla de la plataforma.

Relación entre usuarios de Workplace y Project

El acceso se realiza en dos capas:

el usuario pertenece al Workplace, donde tiene una Workplace role y los módulos/licencias que le sean aplicables;
para trabajar en un Project determinado, también debe estar asociado a ese proyecto, con una Project role propia.

En consecuencia:

estar en un Workplace no significa tener acceso automático a todos sus Projects;
el mismo usuario puede tener roles diferentes en Projects diferentes;
un usuario puede ver el Workplace y no ver un Project determinado;
dentro del Project, el acceso final puede depender aún de la licencia del módulo, de la Project role y de permisos específicos de objetos, como carpetas CDE, Topics o Views.

Ver Roles and permissions para el modelo de autorización completo.

Cómo funciona el contexto en la interfaz

La navegación mantiene separadamente el Workplace actual y el Project actual.

Primero se selecciona el Workplace.
La lista de Projects muestra los Projects disponibles en ese Workplace.
Se selecciona el Project.
Los módulos empiezan a trabajar en el contexto de ese Project.

Al cambiar de Workplace, el contexto del Project anterior se elimina antes de cargar los Projects del nuevo Workplace. Esto evita presentar datos de un proyecto perteneciente a otro Workplace.

En la navegación, también existen accesos separados a:

Workplace Settings — configuraciones del Workplace;
Project Settings — configuraciones del Project actual.

Dónde configurar cada cosa

Workplace Settings

Ejemplos de secciones actualmente gestionadas a nivel de Workplace:

Workplace Information;
Projects;
Companies;
Workplace Users;
Workplace Attributes;
Workplace Permissions;
Project Permissions;
Configurations Template;
Usage & Credits;
Enterprise API;
Billing Information;
Subscription.

Project Permissions aparece en Workplace Settings porque ahí se definen las Project roles disponibles en el Workplace. La asignación de esas roles a los usuarios se realiza luego en el contexto de cada Project.

Project Settings

Ejemplos de secciones actualmente gestionadas a nivel de Project:

Project Info;
Teams;
Project Users;
Attributes Library;
Naming Standards;
Approval Flows;
Document Operational Statuses;
CDE Configuration;
Model Reference Remaps;
Configurations;
Meetings Policy.

Ejemplo práctico

Imagine un Workplace llamado Hospital Central con tres Projects:

Edificio Principal;
Parque de Estacionamiento;
Infraestructuras Exteriores.

En el Workplace se gestionan, por ejemplo, los usuarios, empresas, suscripción, roles y recursos comunes.

Al entrar en el Project Edificio Principal, los Models, Topics, documentos CDE, Teams y configuraciones visualizados son los de ese Project. Cambiar a Parque de Estacionamiento cambia el contexto operacional, aunque ambos continúan dentro del mismo Workplace.

Cómo decidir el ámbito correcto

Pregunte: “¿Esto debe aplicarse a varios Projects o solo al Project donde estoy?”

Varios Projects / administración común → Workplace.
Un Project específico → Project.
Preferencia exclusivamente personal → User Settings.

Errores comunes

“Veo el Workplace pero no veo el Project”

Tener acceso al Workplace no es suficiente. Confirme si el usuario está asociado al Project y si esa asociación está activa.

“Cambié de Workplace y dejé de ver el CDE/Design del proyecto anterior”

Es el comportamiento esperado. Los módulos trabajan en el contexto del Project perteneciente al Workplace actualmente seleccionado.

“Tengo acceso al Project pero no puedo usar un módulo”

El acceso al Project no concede automáticamente todas las funcionalidades. Deben verificarse la licencia/módulo disponible para el usuario, la Project role, los permisos de la funcionalidad y, cuando sea aplicable, permisos específicos del objeto.

“¿Debo modificar Workplace Settings o Project Settings?”

Use Workplace Settings para administración y definiciones comunes. Use Project Settings para equipo, normas, workflows y configuración operacional de un Project específico.

Workplace vs Project