Skip to main content
Pricing
Sign InBook a Demo

Workplace vs Project

UI: seletores Workplace / Project na navegação e respectivos Settings Audiência: todos os usuários

O que são Workplace e Project

O BIMWorkplace organiza as informações em dois âmbitos hierárquicos:

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

Um Workplace é o espaço de nível superior onde se gerencia a organização do trabalho, os usuários e os recursos compartilhados. Um Workplace pode conter vários Projects.

Um Project é o espaço operacional de um projeto de construção. Pertence sempre a um único Workplace e contém os membros, configurações e dados específicos desse projeto.

Regra simples: se algo deve ser gerenciado ou reutilizado entre vários projetos, tende a pertencer ao Workplace. Se pertence apenas a um projeto, tende a pertencer ao Project.

Diferença essencial

WorkplaceProject
Função principalGovernança, administração e recursos comunsTrabalho e informação de um projeto específico
HierarquiaNível superiorExiste dentro de um Workplace
UsuáriosMembros do WorkplaceMembros atribuídos ao Project
RolesWorkplace rolesProject roles, atribuídas separadamente em cada Project
Exemplos de configuraçãoSubscription, Billing, Companies, Workplace Users, Attributes, Permissions, templates e créditosProject Info, Teams, Project Users, Naming Standards, Approval Flows, CDE Configuration e Meetings Policy
Exemplos de dadosDados administrativos e recursos compartilhadosModels, Views, Topics, documentos e pastas CDE, reviews e restante informação operacional

Workplace não significa necessariamente “empresa” ou “contrato”

Um Workplace pode ser usado para representar uma organização, unidade de negócio, cliente, programa, contrato ou outro contexto de Collaboration, conforme a forma como a organização pretende estruturar o BIMWorkplace.

Por isso, não deve assumir-se que Workplace = empresa ou Workplace = contrato.

Project não significa necessariamente “fase”

Um Project representa o contexto operacional de um projeto. Uma organização pode decidir criar Projects separados para fases, edifícios, lotes ou contratos distintos, mas isso é uma decisão de organização da informação e não uma regra da plataforma.

Relação entre usuários do Workplace e do Project

O acesso é feito em duas camadas:

  1. o usuário pertence ao Workplace, onde tem uma Workplace role e os módulos/licenças que lhe forem aplicáveis;
  2. para trabalhar em um determinado Project, tem também de estar associado a esse projeto, com uma Project role própria.

Consequentemente:

  • estar em um Workplace não significa ter acesso automático a todos os seus Projects;
  • o mesmo usuário pode ter roles diferentes em Projects diferentes;
  • um usuário pode conseguir ver o Workplace e não ver determinado Project;
  • dentro do Project, o acesso final pode ainda depender da licença do módulo, da Project role e de permissões específicas de objetos, como pastas CDE, Topics ou Views.

Ver Roles and permissions para o modelo de autorização completo.

Como o contexto funciona na interface

A navegação mantém separadamente o Workplace atual e o Project atual.

  1. Seleciona-se primeiro o Workplace.
  2. A lista de Projects passa a mostrar os Projects disponíveis nesse Workplace.
  3. Seleciona-se o Project.
  4. Os módulos passam a trabalhar no contexto desse Project.

Ao mudar de Workplace, o contexto do Project anterior é removido antes de serem carregados os Projects do novo Workplace. Isso evita apresentar dados de um projeto pertencente a outro Workplace.

Na navegação, existem também acessos separados a:

  • Workplace Settings — configurações do Workplace;
  • Project Settings — configurações do Project atual.

Onde configurar cada coisa

Workplace Settings

Exemplos de seções atualmente gerenciadas no nível do 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 em Workplace Settings porque aí são definidas as Project roles disponíveis no Workplace. A atribuição dessas roles aos usuários é depois feita no contexto de cada Project.

Project Settings

Exemplos de seções atualmente gerenciadas no nível do Project:

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

Exemplo prático

Imagine um Workplace chamado Hospital Central com três Projects:

  • Edifício Principal;
  • Estacionamento;
  • Infraestruturas Exteriores.

No Workplace são gerenciados, por exemplo, os usuários, empresas, subscrição, roles e recursos comuns.

Ao entrar no Project Edifício Principal, os Models, Topics, documentos CDE, Teams e configurações visualizados são os desse Project. Mudar para Estacionamento muda o contexto operacional, embora ambos continuem dentro do mesmo Workplace.

Como decidir o âmbito correto

Pergunte: “Isso deve aplicar-se a vários Projects ou apenas ao Project onde estou?”

  • Vários Projects / administração comum → Workplace.
  • Um Project específico → Project.
  • Preferência exclusivamente pessoal → User Settings.

Erros comuns

“Vejo o Workplace mas não vejo o Project”

Ter acesso ao Workplace não é suficiente. Confirme se o usuário está associado ao Project e se essa associação está ativa.

“Mudei de Workplace e deixei de ver o CDE/Design do projeto anterior”

É o comportamento esperado. Os módulos trabalham no contexto do Project pertencente ao Workplace atualmente selecionado.

“Tenho acesso ao Project mas não consigo usar um módulo”

O acesso ao Project não concede automaticamente todas as funcionalidades. Devem ser verificados a licença/módulo disponível para o usuário, a Project role, as permissões da funcionalidade e, quando aplicável, permissões específicas do objeto.

“Devo alterar Workplace Settings ou Project Settings?”

Use Workplace Settings para administração e definições comuns. Use Project Settings para equipe, normas, workflows e configuração operacional de um Project específico.

Ligações

Was this article helpful?

Back to Concepts