What belongs in a Project?

S1mon

I'm just setting up a new Enterprise system as Admin. What belongs in a "Project" in Enterprise, besides documents which are obviously part of a project? Do common parts libraries go in projects? How do other Enterprise admins like to set this up?

So far I've turned off the ability for any users to create documents at the top level to avoid it becoming a mess, and I created a top level "user" folder which is shared with the team so that they can have individual folders for tutorials and other scratchpad stuff.

adrian_vlzkz

We have a root level folder called "Library" in there a Sub-Folder for "Purchased Components" where all Non-Rev-Managed items go and other folders for components and designs that used across multiple projects

EvanReese

I'm not 100% sure our way is optimal, but I think of a project folder as a unit of analytics, mostly. If I understand the projects correctly, it's pretty much just a folder of things that you'd like to track together as a bundle. For that reason, if we were building out a library of common parts or something, I'd think it's nice to have them in their own a project folder so you have easy visibility on how much effort or activity goes on there.

The team can also use cad.onshape.com instead of your enterprise domain for things like tutorials that your enterprise really doesn't probably need to own (unless you want to see how much time people are spending on learning things). It can help keep clutter down. 

romeograham

@Evan_Reese that's the way we set ours up: mostly as a way to keep track of work done. We use them for "projects" (like, for us: a particular package for a particular customer), as well as other type of collections of effort: automation, common (shared) components, different kinds of tooling, etc. There are several overlaps that sometimes make this setup a little messy, but it seems to be working so far.

You can also use them as a unit of sharing, too.

adrian_vlzkz

Evan_Reese said:

I'm not 100% sure our way is optimal, but I think of a project folder as a unit of analytics, mostly. If I understand the projects correctly, it's pretty much just a folder of things that you'd like to track together as a bundle. For that reason, if we were building out a library of common parts or something, I'd think it's nice to have them in their own a project folder so you have easy visibility on how much effort or activity goes on there.

The team can also use cad.onshape.com instead of your enterprise domain for things like tutorials that your enterprise really doesn't probably need to own (unless you want to see how much time people are spending on learning things). It can help keep clutter down. 

Projects are also used for permissions. In our case we use Project Roles to have dynamic approvers for Release Management depending on the project. Regular folders don't have Permissions Schema associated to them.

KatieHuffman

We released a new class  Administering Onshape Enterprise  recently that explains all the Enterprise settings and features. The lesson on Sharing Data in Onshape Enterprise goes in depth on setting up Projects, Roles, and Permission schemes. This course is available to both Enterprise and Pro users.

EvanReese

Ah yeah, good point about the permissions side of things. It didn't occur to me since we're not a big team and everyone has access to everything.

BLeeVN

KatieHuffman said:

We released a new class  Administering Onshape Enterprise  recently that explains all the Enterprise settings and features. The lesson on Sharing Data in Onshape Enterprise goes in depth on setting up Projects, Roles, and Permission schemes. This course is available to both Enterprise and Pro users.

This Slide helps... but I feel like Projects is really limiting to Companies that make Product from variations of the same Parts @KatieHuffman.  Because Documents cannot be in multiple Projects duplicate Documents will need to be created which would be crazy.  In the Training Link in the Quoted Message it specifically mentions Common Library Documents to be managed by Direct Share and not Role Based Control.  In my case everything is "Common"... I can see Role Base Control being good if you work on multiple Customer Projects which each have their own distinct Part Designs.

I don't see using Projects at all... or if I do, it will be only one Project for every Document created in our Company.  In fact I feel creating a Project is added effort if our Company is going to have many Common Libraries (Folders).  It would be simpler to just allow everyone to create content in My Onshape (free for all), with Release Management Control, what does it mater if this fills with garbage, you can ignore unreleased content.  Also, Onshape is a searchable database unlike file servers making it fairly easy to find something.

I wonder if I am missing out by not using Projects?

adrian_vlzkz

BLeeVN said:

KatieHuffman said:

We released a new class  Administering Onshape Enterprise  recently that explains all the Enterprise settings and features. The lesson on Sharing Data in Onshape Enterprise goes in depth on setting up Projects, Roles, and Permission schemes. This course is available to both Enterprise and Pro users.

This Slide helps... but I feel like Projects is really limiting to Companies that make Product from variations of the same Parts @KatieHuffman.  Because Documents cannot be in multiple Projects duplicate Documents will need to be created which would be crazy.  In the Training Link in the Quoted Message it specifically mentions Common Library Documents to be managed by Direct Share and not Role Based Control.  In my case everything is "Common"... I can see Role Base Control being good if you work on multiple Customer Projects which each have their own distinct Part Designs.

I don't see using Projects at all... or if I do, it will be only one Project for every Document created in our Company.  In fact I feel creating a Project is added effort if our Company is going to have many Common Libraries (Folders).  It would be simpler to just allow everyone to create content in My Onshape (free for all), with Release Management Control, what does it mater if this fills with garbage, you can ignore unreleased content.  Also, Onshape is a searchable database unlike file servers making it fairly easy to find something.

I wonder if I am missing out by not using Projects?

In our environment anything that is used across various projects is labeled a "Product", so ultimately at a root level we have:

-Projects
-Products
-Purchased Components

Many of the items that are originated in Projects eventually become Products

romeograham

We use projects partly for managing "products" (access etc) but we also use Projects to provide access to Common stuff: libraries, Part Studio templates, Hardware etc.

If "Purchased Components" were in a Project - we'd use the project to share them out to users that need them - and also to see how much time was spent messing around with Purchased Components - since projects are a nice Unit of analysis in the Analysis tab (in Enterprise).

billy2

This seems to be an old issue. Do we want folders or not? Do you have to have a library folder?

I've never wanted to manage a library folder so I've never created one. After I build something and use it in a project I just promote it to a library component by clicking on a system variable. My library is all over the place. I don't have to manage anything and they all become available when I'm inserting an assembly and I look for the property "lib" in other documents. I tend to promote library stuff towards the end of a project so document versioning isn't much of an issue. I could move them to their own document, but I usually don't because I don't want to manage that. 

It's a lazy person's data management and it seems to be working for me. I'd rather spend time making working assemblies from mcmaster and misumi rather than managing a folder. OS is a database yet we still treat it like it's a hard drive's tree structure. I'm not sure this is a good thing.

At a top level, that's what I'd put in the enterprise project folder. Who wants to look through a million documents to find the top document for all your company's projects? Or, you could just set a property in the "top" document and search on those. I don't run analytics and it's not important to me. I know Adrian does and is really good at organizing this type of stuff. He's been working on it for a while and probably has it figured out.

Those who have set up an enterprise, does your structure look like an inverted tree?

KatieHuffman

@BLeeVN
Onshape provides different tools to be flexible and allow you to fit your business needs. Projects are one of those mechanisms, that allow your company to set up role-based access control, so instead of sharing by selecting permissions for the individual or team, the user that is sharing just has to select the role and the permissions are already defined for that role. It is a way for admins to be more prescriptive in how users can share within the enterprise. Using projects can also limit who can share the project, as you must have permissions to that project, and even a global permission to create a project and select the permission scheme associated with it. The video in the training uses one example where you might decide to use a mixed method, to share different types of data in different ways.

You may find using the regular sharing method works better for your enterprise, or you might like the extra control of role-based access and projects. Either way it is so great to see all the different ways you guys are utilizing these tools in this thread!

BLeeVN

This Slide helps... but I feel like Projects is really limiting to Companies that make Product from variations of the same Parts @KatieHuffman.  Because Documents cannot be in multiple Projects duplicate Documents will need to be created which would be crazy.  In the Training Link in the Quoted Message it specifically mentions Common Library Documents to be managed by Direct Share and not Role Based Control.  In my case everything is "Common"... I can see Role Base Control being good if you work on multiple Customer Projects which each have their own distinct Part Designs.

Thanks all for contributing to my Posted Comment... after thinking more about this I don't feel Multiple Projects is ideal for our Product which is "Library" like in structure.  In our case in order for Onshape Users to have the most flexible least frustrating workflow having a single Project for everything would work best, this will give them unimpeded access to making content.
I also see that Folders within the Project will hinder us in the future as more and more sub-levels of Product are attempted to be grouped but trying to manage common Parts in a Common Part Folder will become make-work.  I hope that Onshape Developers work on creating Company Labels... see Company wide labels — Onshape