Teamwork Makes the Dream Work—Fusion 360 for Design Teams

KEVIN SCHNEIDER: So welcome. Last day of AU. Hopefully you had a good time last night. Looks like a lot of people didn't as we were joking by attendance. We got 90 minutes today, we're going to talk about how to use Fusion and all of its various different clients to set up four design teams. In particular, teams-- multiple designers working in parallel.

There is a presentation that goes with this that you can pull down, it's already up there, and there's a document I'll be posting up as well. It wasn't up there? OK, good. I can double-check with the AU folks to make sure that gets done. And there's a PDF document that goes along with this that goes into a ton of detail on the first half of what I'll talk through this morning, that gets into data and the hubs and the way data is organized. And we won't be able to cover all of that this morning because we want to cover a bunch of different facets about getting teams set up together.

So first thing we're going to talk about is just how to set up the environment. There are some particulars here that we need to get into that cover how to get your team set up with data and organized. We'll talk about managing assemblies and making them easier to work on as a team. Some best practices in doing that, how to make it easier to collaborate with other people's designers and non-designers in your organization, and finally, how to share assets amongst a bunch of your team members. Bear with me for one second. OK, thank you.

OK, so from the very beginning, when you get Fusion, your default account is what we would call a personal hub. And the difference here is as individual users, as individual designers, you want a very fast way to get started, start creating data, store that really easily, invite a friend to take a look at it, and not have to deal with any administrative hassles in setting up PDM systems or data management systems for engineering organizations.

If you're actually going to work with a team, there is a variation of your personal hub-- we will call it a team hub that is specifically designed for teams to work together, and it adds extra support for you to manage your team, your data, and provides admin capabilities that really is important for successfully setting up a team.

So I'm just very quickly, as I said, the document will go into it a bunch more, but if we look at a personal hub, think of this as if it's your data storage, which means you own it and only you are a member of that hub. You see all the data inside of it, you own all of that data, and you can individually invite people to see slivers of that data, but only you own all that data.

So there is one hub member, that's you. There's one hub admin, that's you. There's no extra complexity in admin tools. If you share projects amongst others, those all get aggregated-- we'll look at that in a minute. All your projects are what we'll call secret projects, which means everybody has to be explicitly invited to be able to see them.

You can't set up any kind of domain names, like email addresses if you're in a company to let you in, but you can make unlimited projects, you have unlimited members. Anyone can be invited, even if they don't own [INAUDIBLE] Fusion, they can just sign up for a free account. And there is a data cap on how much data you can store.

Team heads-- team hub starts to show some specific differences. One that's really important is there are many hub members. And your whole company can be hub members or your whole design team can be hub members. So that means they all get to see all the data inside of that cone or that collection of data.

Every Fusion user gets a subscription to the team site, so you don't have to pay anything extra to get this. Every Fusion user can get it. If you want to invite or add extra members in your company, there is a charge for extra people. It's $15 a month per person for non-designers to become members.

Also really important is there are multiple admins. So you can have safety in that there are more admins in case somebody leaves. An admin leaves, you don't lose access to your data, it's really important to have multiple admins. There are admin tools. When you look at the data-- and I'm going to show this to you live-- you only see your company's data. You don't see any other company or any other people's data aggregated alongside your company data, so there's a very specific wall between your company's IP and any outside projects you might work on.

There are three different types of projects. We'll talk about those in a minute. You can configure a domain in the email, so anyone with Autodesk.com can automatically get in, you don't have to approve every person who gets invited. It can be set up at ease administration. Unlimited projects, unlimited members.

Again, you can invite contributors to a project even with a free account. But one nice thing is you can turn that off. You can say, I do not want to allow any outsiders to be invited without admin approval first. This means you have very strict controls on who has access to your data, and as an administrator, you can have confidence about who can get access to it. And it has the same data caps.

So obviously from some of these, like admin tools, domain-based administration, and when we talk about the projects, these add some extra important tools for setting up a design team. Excuse me. On the topic of project types, as I mentioned very quickly, in your personal hub, you have what's called a secret project, which basically means the only people who can ever see that project are people who are members of that project.

In a team hub, you have three different types. You have an open project-- everyone can see it, everyone can see the data inside of it. Anyone who is a member of the hub can simply say, I want to join, no one has to approve it. So it's wide open data. You have what are called closed projects. Everyone in the hub, anyone in your company can see the project. They cannot see inside of it and they cannot join it without being invited or asking to join and being approved. And lastly, you have a secret project. The only people who can see secret projects, like in a personal hub, are the people who are already members. They can't join ad hoc, they have to be explicitly invited.

So you can have a skunkworks project that is highly confidential in your organization. You don't want a broad group of people seeing into it-- perfect use case for a secret project. Only the people explicitly given permission to be in that project see what's inside of it.

The other nice thing is there is a concept of groups and roles. So in a team hub, you can set anybody up as an admin in a project, you can set up anyone as an editor in the project, and you can set up individuals as view only. So if you have marketing folks or machine shop folks, contractors potentially, you don't want them modifying data, deleting data or doing anything like that, but they need to be able to view and mark it up, which we'll show a bit later. You can use a view role, which is really nice.

So this gives you extra granularity on permissions within a given project on what the invited members are. And this is unique to the team hub. Yes?

AUDIENCE: Just from the previous slide the different project [INAUDIBLE] switch. Like, say, [? a secret project ?] then becomes [? a public ?] project.

KEVIN SCHNEIDER: Yep. Any project admin can change the project at any time, that's correct. And we'll take a quick look at how that's done. So you can start something secret and later on make it public, and if you've got something that's going and you need to make it secret later, you can close it up, close it off.

So one mistake with projects we see a lot is people may just make one massive project and put a bunch of folders in that one project and store everything there. Well if projects now are the way you invite people, you control permissions, and you're managing data and who can access what, they become much more important to use in greater numbers.

Typically I would tell people use a project per product or product family. If you have a nice cluster of the same people working on the same product, that would be a good use case for a project. It makes it easier to search, it makes it easier to use some of the collaboration tools.

If you have 50 products in one project and you go look at the activity feed to see what's happening, you're going to see interleaving of all sorts of activity across a bunch of projects that doesn't mean much. But if you have a single project for a product, that activity feed that you see on the side pane will be way more meaningful because it's just what's happening within the scope of that product.

So this is a good example. I have tons of projects. Some of them may just have two or three models in it. Others have an entire complex concurrent engineering product team working inside of it. It varies. But that means I don't mix activity, I don't mix up permissions. There's a few other things we'll look at, like calendars and wiki, some other tools that you can use to collaborate, they don't interleave. So big suggestion. Really think through setting up projects, and use projects, don't do one mega project.

Inside your projects, there are a couple unique characteristics of Fusion, one of which has some limitations about how to what you can delete today. So one easy way to manage what you can and oftentimes can't delete is just build a folder called Trash. That's what we do. We build a folder called To Trash. Anything that you want to delete but it can't because it has a reference in a previous version, we just squirrel it away in the Trash folder.

There's two other things we do. We have a Quarantine folder. So when you're working in a design team, particularly these days with a number of sites, you can go get 3D parts off the web, anything we import goes into quarantine first. And I highly recommend doing something like this, put it in quarantine. Somebody in the design team cleans it up, make sure the data's actually dimensionally accurate. You don't be referencing things that people just grab and you don't know is really a quality third party model to reference.

So we put all those imports into quarantine, it gives you a place to work on them, and you just enforce a rule with a team-- don't make any references to any data in quarantine. Once it's cleaned up, we move it out of quarantine into a purchased part folder, or we're structuring folders by sub assembly, move it out of quarantine. But it's just a nice way to give people a place to put things and keep stuff organized.

And lastly, we use an Archive folder. Sometimes you have data or you went down a path. You liked it, you don't want to delete it, but it's not really part of the active working set, we move that information into archive. And generally, the latest version of whatever product we're working on shouldn't have any references in the archive, just move things in there that are historically relevant that you want to keep.

This will reduce a bunch of clutter in your project view, your data view, and it also just gets people used to having some discipline around organizing and working with their data.

So let's talk a bit about managing assemblies. When you actually want to get started and have design teams build an assembly together, there's some tricks. Lots of tools. If you used Inventor or SolidWorks or Pro E, most of the time you build parts, you fully define the part, you create an assembly, you instantiate the parts, you may do some in-place activate to build some in-context relationships, and essentially you assemble a product from piece parts. We would call this bottom-up. Looks like I have a slide advance up.

Top-down, we're going to start with the assembly and we're going to work down in detail the parts out. The top tends to be the most familiar from folks coming from other tools, the bottom is really what Fusion excels at. And so we joke a bunch, but there's some habits-- if you're used to the Inventor or SolidWorks way, they are worth unlearning, and we're going to show you some tricks on how to make that a little bit easier.

So most of the designs we'll show today are all done, they're done with a layout to drive the overall dimensions and primary engineering constraints in your faces for those designs. It allows us to make really easy and fast changes. It's not like in-context from Inventor or SolidWorks, it's quite different, actually. It's not like adaptivity if you're familiar with that inside of Inventor.

But what we can say is Fusion was designed on purpose to be a top-down, layout-driven design tool. And what that kind of looks like is if we kind of just take an abstract-- we're going to make a little table here. We have a design. At the root, it's just the empty assembly. We're going to model a volume. That volume represents the size of the table we want to make.

We can use that volume to then build individual piece parts. You can actually constrain to those volumes. So we're using that volume as a layout upon which to design roughly our piece parts. And then finally, once we have those rough piece parts done, we can hang off all of the purchase parts-- bolts, nuts, washers, pieces like that.

So one thing that's different about Fusion is you don't assemble finished parts. Assembly and modeling our interleaved, and you can actually assemble components that are halfway finished. So this way, you progressively build your structure, you progressively build detail, and then at the end, you put all of you purchase parts.

So we've found this much simpler for new people to learn. It means multi-part modeling and assembly modeling work exactly the same. There's not one that works one way and another that works the other way. It means you can change things a lot, which helps you with your design creativity, simple to change, changes are easy to make, and cross-component relationships are all contained within that one design. So it's very robust for you to make changes and have it all update. So those tend to really make the top-down approach in our mind easier.

The problem with this, of course, is that all that top-down work is done in one design. And if it's in one design, it has one version history, and that largely means only one person can work on it. That's very limiting if you have a design team.

So what we've done is-- this class we'll talk a bit about an alternative but variation of this idea, which is basically to do a skeleton. So the example I showed looked like this. It's a top-down design. Everything was in one file, which is the box around it. They all share one version history. Of course people can't work on this. What we really want is a structure that looks like this. We want to create linked documents so many users can work in parallel. They can design in the context of the skeleton as they need to make changes, but we can start to distribute the work out to a team to work in parallel.

Making sense so far? So that finally gives us team member 2 might work on this subassembly, these parts. Team member 1 might work on the two top assemblies. Team member 3 may be responsible for some other subassembly and a collection of parts, and now we now we have parallelism.

So I'm going to reuse that tree model. The variation that happens here is we have our root design, our root assembly. We're actually going to insert a link to the skeleton now. And that linked skeleton has a bunch of information about geometry and size. It's just like the volume I showed you before.

We'll build another subassembly, which is the bottom frame, and the skeleton will be inside of it. So that designer working on the bottom frame has the volume for reference. We'll build another subassembly that's linked, which is the tabletop. It has the skeleton inside of it, so that designer has the reference for size for designing the tabletop.

And then finally, those components and the piece parts all get assembled back together. So we've taken the same idea as the top-down design, but instead of it being one file, one version history, it's now distributed into multiple. We'll look at this live in a minute, makes it a little easier to understand.

Perfect. So first thing, just as an example, here's one of the projects we talked about, right? Here's an archive, a quarantine, and the to trash, just a quick reminder of organizing some things. We'll come back.

So first off, let's just look at the overall assembly. So just like the pictures, it's a table. Nothing particularly unique here. But you can see the very first design that was placed was this skeleton design. I'm going to open that up so you can see what's inside of it.

Not particularly complex. You'll notice there's a few joints that position the components. The base of the design, the tabletop. Pretty short history that makes up this particular design. What I have done is created a couple parameters that control the size of the skeleton, because we want to control the size of the table. Really easy. So if in this case we said, let's make the table 72 inches.

Now you'll notice in my browser, because all of the different designs-- and I'll show you how this was done. All the different designs referenced that skeleton. The base has the skeleton inside of it and the components built. If I just say, go ahead and get the latest of my design, it's going to load the skeleton up, it's going to rebuild all of the subassemblies, it's going to rebuild the top-level assembly, and the entire table is going to rebuild.

So we have a very simple layout that drives model size across multiple subassemblies that are all linked together with associativity. So now one team member can go work on the base, one team member can go work on the table, another team member could go work on the foot step structure, and you're finally able to get parallelism across the team.

So let's build this example from scratch so people can see how this works. So the very first thing I'm going to do is just make a new top-level design. Let's just call this New Top and save it. Now I'm going to build another new design. We'll save this, call it Skeleton01. And we're not going to do anything complex, but it will give you a good idea of how this might work.

I've put a couple of sketches in. In this case, maybe I'll extrude one of those as a body. Let's turn this sketch back on. And I've done an offset work plane. So we're just laying out some basic overall dimensions of a particular design. I'm going to do one more extrude.

Now I've returned to the new top, and we're going to insert that into the current design. We'll just put it right at the origin. This way, everything is located to one common world origin. Now this is where we get into breaking up the different subassemblies. So this will be sub 1. And once again, we just insert the skeleton inside of it.

All right. Now, this-- I own this Subassembly-1 subassembly, I'm going to design some components in the context of one of these volumes. So right from here, I can do that. We're going to create a new component. I might start using that model face to build some plates, in this case. Maybe we're going to build a welded frame using this.

So we've got one component on one side, another new component, and last, another new component. Where am I? There we go. Well, this should give us enough for now. So I don't need to see the skeleton all the time, I can turn it off. You can do some things like change the appearance. Sometimes I'll put Air as a visual appearance just so it looks like wire frame.

But what we've done is we've used that underlying inserted design essentially as a framework upon which to build our detailed design. There's any number of ways you can reuse this. You can use sketches, we can use construction geometry, which we're going to do in a moment. But all of that's been built associatively to the underlying skeleton.

So to show that working, if we come back to the skeleton and we just changed the sketch geometry, we'll save our skeleton, we'll come back to our subassembly, it's out of date, we say Update, it rebuilds, and everything has moved fully associative to the underlying skeleton. When we come back to the top-level and we insert our subassembly-- let me save this. All right. Come back to the top, here's where things get really nice.

If I insert this subassembly into top, my team member's done work, we're starting to integrate this into the top-level assembly, notice without having to do any extra positioning, it's already in the right place. Because the skeleton defines the position of all of the work that you do in the subassembly, you're building off of a master coordinate system where everything is positioned relative to the skeleton.

So now the subassembly comes in, we can just position it right at the origin and it will always be in the right place relative to all of the other subsystems we design. In this case, usually the top-level assembly, there's almost no need to do any joints where we're moving components around. You can literally insert everything into the design right at its origin, it's modeled in place, you can rebuild the top level assembly in a matter of seconds if you need to create a variation or you want to put different subsystems together.

Because again, you can use that skeleton to go build three or four different ideas on how you want that subassembly to look. We could make a cast version, a welded version, a steel tube frame. They all share the same skeleton, they're all built off the same geometry. When we go into the top-level assembly, we can literally swap those subassemblies out for their peers to see different design ideas in context.

So, you get really nice parallelism by using this approach, plus you get a lot of ability to swap and try variations in your design, which is really common as a team. So it's super productive and powerful for us to divide up a design like this.

As an example, we built a while back-- Machine All. So this was an internal project we worked on. We used all the techniques I showed you. It's roughly 1,800 parts in the finished version with all of the fasteners, bolts, and washers, but it's an entire industrial router.

There's a frame, there's a bed, there's a y gantry, there's an x and z gantry, the entire-- there's a tool changer, there's internal components. So this entire structure is built off of one master skeleton that drove about six people designing in parallel with probably about 10 major subsystems that all came together. Designed in about two weeks as a internal test project. So this shows a practical example of that technique on a real design with quite a lot of detail and depth in all of the engineering and work that's there. So, some good techniques just on structuring the assemblies in order to have more effective parallelism.

While we're here, now is a good time for me to switch back. Most of you probably will be familiar with a view that looks like this in Fusion. This is our Data view, and you'll see the little green heads that are here. This is my personal hub. If you remember back to the very beginning, I'm going to circle back and hit on a couple of points that we saw before.

That's telling me that those are projects to which I'm invited-- I don't own them. So I can see a mix of projects that come from other people along with projects that belong to me. This is that aggregated view.

I have a team hub, and there's a very specific way for me to switch to a team hub. It's this hub switching UI. It won't show up for you unless you belong to a team hub. So from here, I can say, go ahead and take me to my personal team hub. And when I do that, the site pane is going to flip over, and it's going to reload a whole different set of data.

You'll also notice now-- let me go back to the project listing. There's no green heads. There's no sharing, there's no aggregating here, this is all my company's data. Everything in here belongs within our one hub. So this shows some nice ways that the data gets separated and is more clear.

If I click on the link, it'll actually pop open a browser view, and we can see some of the other capability that's there. So here's a list of all my projects. I showed this earlier. Quite a lot of small detailed ones. So let's look at the Bike Light project. This is a closed project. I have set this up so I have to logins so I can show you what it looks like for other people. The login that I have here is not currently a member of this project, so I can simply say, I want to request access. The admin will get a notification, they can approve the request, and I will find-- and I will be allowed in.

You can actually see the types of projects that are listed here, who they're created by, and I can create a new project if necessary. If I close this for the magic of Chrome, I'm going to click on this link again, I'm going to come in as a different user. So now we can see that those very same projects, if I come in down to Bike Taillight, this user's already a member of that project, so I got right in. You can see that I'm the project admin for this particular project.

If I want to make any changes-- to your question, can I change it after the fact? I can change these after the fact. If I invite other people and this data is very sensitive and I don't want other folks to be able to come in without permission, I can simply turn off contributors. That means explicitly admins have to approve anyone invited into this project. It just really tightens up the boundaries on permissions on this particular project.

If we wanted to view and manage, I could see a list of all the people who were here. As I mentioned before, this is where you now get access to Change Roles. We can see if there are people who've asked to join. So as I showed you the first few seconds ago coming in and I had the Join button, that would appear here as a join request and we could manage that.

In addition, we get the admin tools we mentioned. So this lets me do things like change the name, globally enable or disable contributors for all projects, and change how invitations are handled. I can see all the different members that are invited across all projects. So I have visibility into who has access to my data, both pending and sent; a list of all my projects, both archived and normal and their current disposition; and then access to the current state of my subscriptions for this particular hub. Yes, sir?

AUDIENCE: [INAUDIBLE]

KEVIN SCHNEIDER: Yes.

AUDIENCE: [INAUDIBLE] to see which projects [INAUDIBLE].

KEVIN SCHNEIDER: Which projects they're a part of. When you come into Members, I believe we can get to that-- I'm pretty sure there is a way to get there.

AUDIENCE: [INAUDIBLE]

KEVIN SCHNEIDER: Let's talk afterwards. I think there's a trick to get there. Yeah. So these just shows some of the admin settings for team hubs that we talked about before. All right. You don't want to see this slide. There we go.

So in our example, our demo, we had our structure broken up into individual pieces. And the trick in there is that skeleton that's referenced everywhere, that gives you the framework on top of which you can build your associative components. If you go to Create Drawings of an assembly designed that way, you're going to have a side effect-- every layer, every subassembly has a skeleton inside of it, and that skeleton has solid bodies or sketches or work geometry inside of it.

And the very first time you're going to make a view, you're going to go, what the heck is that? Because those bodies are going to be visible. So one thing you need to know is in the browser of the drawing view, you can very quickly just suppress the skeletons. It just takes a second, go down the tree, turn the skeletons off. They'll disappear, they won't be part of the view calculation, they won't show up in the parts list, it just omits them from the data inside of the drawing.

So that's the one thing that you need to do by hand if you do the skeleton approaches. In drawings, just remember, I need to go turn off the skeletons for the views to be correct.

So as your teams are working, there are some best practices that are good to try and enforce to make the productivity in those assemblies better for everybody. So first, use components. It sounds obvious, but you'd be surprised the number of designs we see where people just have a bunch of bodies modeled together, and then at the very end, convert a few of them into a component.

So first and foremost-- as soon as you know you need a component as a general rule of thumb, make a component, and activate it, and model inside of it. It has a bunch of benefits. It makes the timeline easier to work in, it makes the scope of the part visibility-wise, reduces clutter, it makes your model easier to understand. I wish I could turn off-- we'll fix that next time. It means you can group bodies together more logically, and it just simply-- in general, it simplifies the team if you're working together, because people can understand the component hierarchy in the intention you're looking to build.

So use components as early as you can. If we talk about bodies and components, just a quick review, there's what I'll call the root, it's basically the top-level node of the browser. You can have any number of bodies at the root. You can have any number of components at the root. Components can have any number of bodies and components can have any number of children.

It's a little different than something like SolidWorks or Inventor where you tend to have only components with bodies. It's not typical to have assemblies with directly bodies inside of them.

On the topic of bodies, they're great because they define the type of geometry you're working with. That maybe TSplines, mesh bodies, surface bodies, or solid bodies. So they're more about containing a type of geometry than they are about describing a part, which is why a part tends to be made up of multiple bodies, but an assembly really is not well-represented by multiple bodies, it's better represented by multiple components.

Only joints work with components, that's really important. Drawings are much easier to make of assemblies with good component hierarchy. Only components have building materials Information, like part number and description. You can insert components multiple times. You cannot do that with bodies, bodies are unique. You can save a component out to a new design. Components can be inserted into other designs.

Components have an origin, so if you're worried about position or placement or mass properties relative to a frame of reference, components are much better for that. And again, activating a component scopes the timeline to a subset of the timeline, making it much, much easier to work on more complicated designs.

On the topic of inserting linked components, if you're working in your personal hub, which is, as we talked about at the beginning, what most people have out of the box, you can insert components only within the scope of a project. Another nice benefit of moving to a team hub is that you can insert components across projects, which allows you to have more design reuse and set up things like libraries.

The other thing to know about references or inserts is that they're version-specific. When you insert a design, you insert a design at a version and the design will not update until you explicitly ask for a new version. Again, this is different than tools like SolidWorks or Inventor, which tend to grab the latest design every time you open the design. In Fusion, we only open to the last-- to the saved state, which explicitly references explicit versions.

So let's talk about a few other tips. When you get into complex assemblies, understanding timeline and browser and graphics, a nice way to do that is to turn on color swatches. Here you can see the browser's colored, the graphics are colored, and the timeline is colored. And we see where every feature belongs based on color coordination and we can even see features that are multi-component features. It's because they have multiple colors for the components which they affect. So this just makes a nice way to work in an assembly.

Now one thing I find a bunch of people don't know that's a nice option-- go back to the bike-- is you don't have to have the rainbow fruit flavors in the graphics. You can have the graphics look with materials and appearances, but still get the benefit of color swatches in the browser, and this is the way I prefer to work.

To do that, right here at the gear on the bottom, you can turn on and off color swatch. So you're probably used to seeing Fusion look like this. You can always hit Shift-N turn on all the color cycling everywhere, but if you don't want the color cycling in the graphics, just turn on color swatch from that end. And this is a really good trick just for everyone to get used to running this way because you get the benefit of the browser and the timeline coloring, but you're not forcing people to get the coloring in the graphics if they don't need it.

I've mentioned Activate a couple times, but you can see here in this particular design, we've activated to this top blue member. And when we do that, the long timeline filters out any feature that doesn't belong to that component. So we end up with very simply seeing the sketch extrude, fillet, and shell that makes that one component. So it gives you only those things that created that geometry and filters it out.

Now there are two ways to make components. There's Create Component from the browser, and there's a Create Component button on the toolbar. The browser one is just a quick shortcut to get a component created, but if you're teaching new users, I would recommend going to the toolbar because you actually get a command dialog.

It lets you set the component name, it can activate that thing automatically, you can select a parent if you know you want to put this someplace further down. You just get extra control if you use the Create Component button on the toolbar than the shortcut in the browser. So it's a good place for people to start, and it's a good way to reinforce this rule of always create a component as early as you know to.

One other thing I get pretty uptight about, my timeline that can get really long. I like to make it as simple as possible for people to open my design and understand what's there. So I tend to preach a lot around do some modeling, then position what you've just modeled. Do a little bit more modeling, and position that component.

A lot of times I'll see people with timelines with a ton of modeling and then 50 joints at the end. And if you ever have to do any editing in the middle of the timeline when you're rolling back, none of the components are positioned. So you're editing in the middle of the assembly and parts will freely move around and can be dragged around. So just some good discipline. Again, it's just best practice. Do some modeling. As soon as you know where that component should be positioned, position it.

If you're using the skeleton approach that I showed you, you don't actually need any geometric references in order to assemble things. If things are not moving, everything can be a rigid joint or effectively grounded at origin because everything is already in the right place with respect to the world coordinate system as we saw.

So you can actually create a component and ground it the very first thing-- it could be empty because it's already in the right place. But just in general, model some position, model position. If you're rolled back or someone's looking at this timeline, they see a Create Component, they see a sketch, they see a position, it's really nice to say, OK, if I need the joint for that component, with good discipline like this, you can pretty much guess that the very first joint after the component is the joint that is positioning that part.

And if I come down to this end, I see another component at the end. That joint is the joint that positions that component. It just makes that association much easier.

OK, so now that we have a team setup and a team hub, and we have a skeleton-based assembly where we've got people working in parallel, how do those people actually work with each other effectively? In order to do that, there's a couple of things we have in play to help.

One is data badging. It's not the best, I'll be the first to admit this, but it's all we have. So we need to talk about where it is so you know how to use it as effectively as possible. In my opinion, it's easiest to see in the web view, which I'll show you in a moment. It only shows in use by four things that are explicitly opened by a user. If you open an assembly with 50 references, it's not going to mark the 50 references as in use, it's only going to mark the top open because only the top is actually in use at that point in time.

So what does that look like? Well in the web view, any data that's in use by team members gets a blue banner, gets a little red dot, and it will tell you explicitly who's it in use by. This particular design was in use by me. So obviously, you probably don't want to go open that and start modifying it.

You can. We don't prevent you from doing that because versions are stored and every version is stored in time when it was created, but you can start creating some trouble where your interleaving versions with team members. So use badging as a good way to avoid collision on versions with your key members.

Inside of Fusion itself, you can get to that same data, but it takes a little extra work. You go to a particular design, click on the version tag. If that design is opened by a team member, you'll immediately see who it's opened by. So obviously it's not particularly productive to have to click on every version tag to see the in use by data, which is why I recommend just keeping the web view open as a way to see your data view and what's going on. It's much faster than having to click through your site pane to see what's happening.

But when you're in that side pane, when you open up that tab, you do get access to a couple extra things that are useful. If you do get version interleaving, this is how you can fix that. You can find the version that really should be the latest version, you can promote it. If you're curious what your colleague did, you want to open up his version from that list of versions, you can open it up to see what's there. So it does give you access to all of those versions very effectively and easily. You can see this both in the web view and in Fusion's desktop point.

The next thing you might want to do is start having people collaborate by commenting. And one thing I find that folks get a little tripped up on is that commenting inside of Fusion is actually very context-aware. It knows what version you're commenting on, it knows what workspace you're commenting in, and in some cases, it actually knows which object you're commenting on.

So when you get comments or markups in your commenting pane and you click on one of those, it's actually going to tell you specifically when you roll over that version, this comment is on an older version and in the SIM environment. And if you click on that comment to load it, it's going to open that version, it's going to switch to the SIM environment, and it may even zoom to a particular object onto which that comment was made.

So it's quite powerful in that commenting is very context-aware, but you can get people a little surprise going, I don't understand why I'm looking at the CAM environment, or I was working in the CAM environment, someone made a comment, it took me out of CAM and put me into modeling. Because the comments are context-aware, it's pretty important to just understand that it's version, workspace, and object-specific.

Lastly, you can comment on the web, you can comment in your mobile app, and you can comment in the desktop, they're all in the same activity feed, they all share across each other. The only one caveat is if you're looking at comments in the web page, they don't automatically pull. You do have to hit refresh on the page to reload the comments. Something I hope we fix soon.

How many people here have used or ever made a comment in Fusion? I got one. This is an area that does quite a lot, actually. It's pretty powerful for exchanging information between team members, and it's worth spending some time looking at it.

I talked to you before about scoping your project and making your project work into a product. That's because project has some other collaboration facilities inside of it. One is a wiki where you can document pages, create documentation if you want, reports. It also has a calendar if you want to capture information about key dates, deliverables, activities, decisions, or anything like that along with your product.