Local Save Does Not Work - Follow Up

 After speaking with an Autodesk developer we now know that our issue is related to past eTransmit use. Revit mistakenly retained a flag it uses to mark that file as such.

If we can successfully use Synchronize with Central and we get that message when we use Save then the correct response to the warning dialog is the top option: "Save this model as a central model in its current location - Revit will remove this message and allow users to create local copies of the model."

Remember, the message is accurate for files that have been created via eTransmit too. In our situation the files were working fine on BIM 360 but they retained the flag that should have been removed when they were added to the cloud.

Info Added 6/4/2021: The warning is triggered ONLY in the following scenario:

The warning is triggered ONLY in the following scenario: The model has been transmitted and then upload to BIM 360 from Revit using the option “Work temporarily”.

To eliminate this warning for future project, please make sure you choose “Save as a central model in its new location” when uploading the models to BIM 360 from Revit.

Insert From File and a Worksharing File

I bumped into a subtle conflict this evening. I created a new file from a stock template. I then used Insert from File > Insert Views from File to acquire a few drafting views. When I closed this new project and decided to open the file the harvested drafting views are stored in this message appeared.

Keep in mind that no files were actually open at the moment. I was looking at the Recent Files list yet when I attempted to create a new local file for the project I just used Insert From File on the message popped up. This means that the file is technically still open in RAM as far as Revit is concerned, it's just not open for me to interact with.

I had to exit Revit so it could relinquish its hold on the file before I could start Revit up again to get back to work.

Tags Dimensions and Linked Files

I've mentioned this subject in the past. I'm writing to bring it up again and to focus on how Revit deals with tags and dimensions differently when we apply them to elements that are in linked files.

First as a reminder, when a linked file changes and a user reloads that link in their Local File other users are not necessarily seeing the same version of the Linked File. That's because reloading a link is a local change, a personal action, that doesn't get passed along to the Central File when we use Synchronize with Central (SwC).

Let's imagine User A has reloaded a linked model and they've placed tags on doors and rooms that they observe are now present in the link. User A uses SwC to share this new tagging effort. Now User B, who already has a Local File open, decides to use Reload Latest or SwC to share something they've done or see what work other users have contributed.

It's important to note that User B did NOT use Reload in Manage Links or via right-click on the linked file in the Project Browser FIRST. As a result User B gets the warning in the next image. Don't be confused by the mention of Coordination Monitor which can be confusing. It can make us think we're dealing with something that has been involved with the Copy/Monitor tools.

The Tags are Orphaned, they've lost their relationship with the linked file's elements they are supposed to identify. You can see one tag is highlighted in orange in the image above. In the next image we can see what the floor plan really looks like in the linked file (and what User A sees). It's not quite the same as what User B thinks it looks like is it?

Let's now imagine that User A continues to work by adding the dimensions you see in the image above too. After they finish doing that they use SwC.

User B now decides to use SwC or Reload Latest, AGAIN without using Reload on the linked file. Their reward is a larger collection of warnings (see next image). The first three warnings are dedicated to the dimensions User A added to their Local File. There are no equivalent elements in the version of the linked file that User B sees so Revit's only recourse is to delete them ... or ... choose Cancel ... which is actually a better choice. If User B cancels and then Reloads the linked file first that will eliminate the warnings entirely.

The remaining warnings are focused on the newly orphaned door and room tags that can't find their parent elements. If we select one of the orphaned tags we can either use Pick New Host or Reconcile Hosting. The former will need us to pick a door to associate the tag with. The latter will open the Reconcile Hosting browser which shows us everything that has been orphaned so far. We can select individual items and right-click to use Pick Host or Delete the tag if that's a better choice.

Keep in mind, once this orphaned status occurs it sticks. Merely reloading a linked file afterward isn't going to fix it. We'll be forced to deal with Reconciling Hosting. In some situations it might be faster to delete the tags and use Tag All to place them all over again.

This might be an opportunity for an enterprising developer to write a routine that looks at orphaned families and picks the closest possible host? Better still...Autodesk?

My recommendation, if you MUST use tags and dimensions on linked files?

Develop the habit of reloading the necessary linked files BEFORE using SwC or Reload Latest.

If you get the warning messages in the images above, use CANCEL. Make a note of the elements the warning(s) is(are) focused on. Most likely the warnings are being issued because you need to use Reload on the linked files first.

I'd also consider a moratorium on applying tags or dimensions to linked elements while the link is being changed aggressively. For example, if we know that the link is going to undergo some massive redesign we should just agree to stay away from tags and dimensions until it settles down again.

It's also a good idea to let other people know that you have changed an integral linked file so they can all use Reload (link) to catch up together.

Create New Local is Disabled

I've written about this in the past, like THIS ONE. Today I noticed another circumstance where the option is disabled even though it shouldn't be. When we browse to open a project we can click on a file listed among the contents of a folder. If we do that then Create New Local is enabled and checked by default. At least that's true if other circumstances are not preventing it, like those described in my other post.

What I saw today is that if I choose to type some of the file name in the file name field Windows will supply me with a list of file names that begin with those letters, cool Windows behavior. If I select the correct file using that list then Create New Local sleeps through the effort and fails to become enabled.

Want to see it happen?

Create a Local File - How Often

Every time...

I no longer reuse Local Files. My attitude and habits have changed a little over the years. I wrote this POST in 2008 and then THIS on in 2011. I've touched on the subject many times within the context of other workset related posts.

I treat my Local File as ephemeral...temporary... I make use of the Open File option Create New Local each and every time I start working on a project again; yes even if I just stopped working earlier to have lunch or join a conference call.

Revit 2017 - Enabling Worksharing

The process for enabling worksets has changed with this release because Collaboration for Revit (C4R) has been incorporated into Revit directly. This allows someone to subscribe and begin using it quicker. They might even be able to do so without any (or much) EyeTee intervention.

The first evidence that there is something different is on the Collaborate ribbon tab; there is a Collaborate button next to the disabled Worksets button. There is a new Communicate panel too.

In the past enabling worksets began with clicking on the Worksets button but now we start by clicking on Collaborate. This takes us to the fork in the road necessary to permit sharing the project via A360/C4R whether we are able to use it or not, just in case. If the file hasn't been saved before clicking Collaborate we get a message asking us to do that.

Then the Collaborate dialog appears asking us to specify which method of sharing the project we need; Collaborate within your network or Collaborate using A360.

When we choose Collaborate within your network Revit enables and creates two User-Created Worksets called Shared Levels and Grids and Workset1 (like in the past) but it doesn't open the Worksets dialog (like it used to). This allows us just to get on with our work using the Active Workset (Workset1 by default). If we need to create additional worksets then we'll find the Workset button is enabled, just click it to open it (Workset dialog, as in the past.

The Communicator button is tied to using C4R. It is a separate window (dialog) that can display information about your project team activity, if you're sharing the project using A360. Imagine concepts from Worksharing Monitor combined with Instant Messaging features and that's what you've got. FWIW, it used to be able to dock inside the Revit UI but it doesn't do that now. If you've got two or more monitors you'll probably prefer it on one of them instead anyway. This is what it looks like if I'm not logged into A360 and not using it to share this project.

At some point we'll need to Save the file and like in the past we'll be warned that this is the first time we've done that since we enabled worksets; click Yes.

Remember, if you'd like to set the default Open option to Specify remember to use Save As instead of Save. You only get a chance to do that with Save As. This allows us to choose which Worksets Revit should load before it opens the project entirely. This can have a significant impact on how long it takes to load a project.

At this point we are still working in the Central File, which isn't practical to share the project nor is it advisable. I can determine that by looking at the Save icon on the Quick Access Toolbar (QAT), it is disabled and the Synchronize and Modify Settings button next to it is enabled. The project's file name listed on the Title Bar doesn't include my user name either. By the way, we need to SwC to relinquish our ownership of the User-Created worksets properly. The only way to do that is to use SwC (Synchronize and Modify Settings), via the dialog that appears. The Synchronize Now button does NOT do that.

Now that worksets are enabled and relinquished we need to close the project so the team can get started by creating their Local Files. When I browse to the Central File to start work I need to make sure that Create New Local is enabled and double check the Open option is assigned to Specify.

Remember doing so will cause this dialog to appear before Revit begins opening the project further.

Okay, now get to work; in your Local File!

A Case for Worksets - Opening Linked Files

It is common to choose to avoid enabling Worksets when we don't need to let more than one person access our project at the same time. If we rely on using linked files then we can benefit from not avoiding them. For example, if you've ever wanted to open a linked file at the same time as the file you are currently working in you've seen this warning message.

Revit doesn't like opening a linked file in the same session, without unloading the link in the current model first, but it won't mind doing so if you open a second session of Revit. Revit uses separate memory allocation for each session. That means it isn't possible to use Copy to Clipboard with Paste Aligned when we are using two sessions. If you let Revit unload the link instead you won't see any changes in the host project until you save, close and reload the linked file. A good many users regard that cycle of steps to be annoying.

When we enable Worksets we have a Central File but work in a Local File. If all the project files we use have enabled Worksets then when we open any of the Linked Files we are creating a new Local File. Here's the tricky part...technically that's not the SAME file we Linked. The Linked File is (should be) based on the Central File (it's name and location)...the Central File is linked, not our Local File.

Yes this means you can now open a linked file in the same session of Revit. You can make changes in either file and use Synchronize and Modify Settings to store the changes in the Central File(s).

Now before you get too excited, you still have to use Reload on the Linked File that's been changed. That's not really any different than having another user making changes to the Linked File and having to use Reload to see their changes. It does make it easier to go back and forth between models quickly; eliminates the open/close part. Eventually you have to use Reload to see any changes regardless.

If you are a sole user and still intimidated by Worksets; just remember you only have to have one Workset for it to be enabled, for Revit to work. Revit creates two default Worksets for us to use (Shared Levels and Grids and Workset 1) but we don't have to be too concerned with assigning elements to any but Workset 1. That's assuming we don't really need Worksets for its fundamental purpose; allowing concurrent access to the same data by more than one person.

Something to consider if open/closing and unloading/reloading links is annoying.

Oh, I should mention that this starts to disintegrate if you are opening more than two files that are inter-related, linked into each other. For example, imagine a Host Model, Linked Model 01 and Linked Model 02. The Host Model has linked both of the linked models. If Linked Model 01 is also linked into Linked Model 02 and we then open both of them as well as the Host Model we will encounter this kind of message when we make changes to Linked Model 01 and then attempt to reload it in the Host Model.

The file in question is also present in the other open Linked Model and that is what Revit is objecting to. We'll also find that the file is unloaded automatically. We'll have to close the other file that it is visible in before we can successfully reload it. As such my habit is to limit my use of this technique to two open files at a time.

Be Careful Creating a Central File in 2015

A thread at Autodesk's Revit User Community Forum caught my attention yesterday. It seemed as though the culprit was something I've written about before, that user's were accessing the project via different shared resource paths. After digging in a bit deeper it turns out the issue, or at least an issue, is that Revit 2015 is more sensitive to how we navigate to the a shared resource.

This is what happens when I browse to a shared folder via My Computer and click on the Drive letter S:

This is what I expected to see (disregard the project name, I was experimenting with being logged in and out of A360 too):

A clue or warning you can watch for is what Revit displays at the top of the Save As dialog.

If you see the drive letter in the description then you'll likely end up with that as your path. I believe you should only see the folder the central file will be in if you are mapped correctly.

It is my habit to always use Synchronize and Modify Settings before closing the Central File, after creating it. As such I can see what the path that Revit captured is. When I notice that it is wrong, like the first image above, I can fix it, get the correct UNC path recognized instead by taking these steps (see the image that follows too):

• Close the Central File (after noticing the wrong path reference)
• Create a local file (before any other users start to work)
• Use Synchronize with Central
• Click Browse and click Browse again in the next dialog box that opens
• Select the Central File by browsing to it via the shared resource path instead, type it in directly if necessary.
• Click Open
• Click OK (the correct UNC path should appear now)
• Click OK (The path is fixed)

If you are creating a central file be very careful about how you browse to the project folder. Verify you have the correct path established before letting users begin working on the project.

Cannot Create a Local File

I read about a couple items in a thread at RFO that could affect creating a Local File in addition to to what I've mentioned in the past.

Revit appends our username to the local file it creates for us. That addition could cause a local file's name to exceed the maximum number of characters, which is 260 (file name and path). That's 256 plus the four characters associated with the drive letter, for example C:\ (space/null after the back slash).

The other possibility mentioned is having Auto Off-line Access enabled.

Gosh computers and software are fussy buggers!

Revit Worksets Error - Element has been Deleted

David Baldacchino shared an issue with me that he's run into recently.

Here's how he described the issue.

As a standard, we create our central files with the option "Specify" so users are prompted to pick which workset to open/close when creating a local file. If a user is in a local RVT 2013 file AND THEN another user tries to open a detached copy in Revit 2014 to upgrade it (whether doing this directly from the central file or a local file), the Revit 2013 user/s will start getting errors stating that elements were deleted from the central file when they try to edit. They are also locked out of touching anything until the upgrade process finishes. This issue does not happen if the Specify option is not used. This behavior is not expected and undesirable.

Sounds like it can be avoided, if the file needs to be upgraded, by keeping people out of the active project file. I'm not sure I'd want someone to upgrade a project that someone is actively adding new work to with the previous release. Regardless if it occurs it explains why the error message Elements have been deleted appears.

Local File Location

Can a Local File and Central File be in the same folder? Sure.

Revit doesn't really care if a local and central file are in the same folder, as long as Revit doesn't think they are the same file. I do it all the time when I'm doing testing at home. As long as I let Revit create my local file with a unique name it doesn't care where the files are. In a real office setting it doesn't make any sense to put a central file on a workstation. It also doesn't make any sense to put Local files on a server either.

Usually EyeTee wants nothing important on workstation so they can schedule regular backups. The reality is they are getting a backup of the project, the Central File. Local files are nothing more than a "working copy" of the project and they ARE meant to be perishable. If you heed the advice on this blog you are already creating a new local every day or, like me, every time you start work on a project.

Create New Local Disabled

Usually the culprit is the network path (previous post). If it is intermittent, as in it worked a few minutes ago but now it isn't, it can be something else. It is probably file access, meaning Synchronization with Central by others or someone opening their own local file at the same time.

I find the create new local option is disabled occasionally when there are a lot of other users active. If I select the file and the option is disabled I click on another central to see if it is network related. My thinking is if it does it for several central files then somethings wrong with "me". If I wait a few seconds or minutes I find that clicking on the file again will allow Revit another "look" at the file and the option "wakes up".

It may just be busy people and activity between locals and the central.

Why Does My File Name Include the Word Central

The practice of adding the word "central" to a project file name came about in the early days of Revit to help users see the difference between any stand alone project file, their own local file and the actual central file for their project. Unless you notice a folder with a matching name plus "_backup" there isn't anything obvious to tell us that a file is "special" (central or local file). We used to copy the central file to our own computer and change the name to include our username to identify our local file as different from the central file. With the extra "-central" in the project file name it was easier to see its "specialness".

Since Autodesk changed how to make a local file it is less desirable to add the "-central" to the name. This is because when Revit creates the local file it adds our username to the resulting local file. If we use "-central" in the name we get something like this:

1234 BigProject-central.rvt (the central file)
1234 BigProject-central_Username.rvt (local file, including the -central part)

What made sense then doesn't now.

There are firms that still use a customized process to generate local files (there are other threads about that). For them it may still be advisable or desirable (even required) to continue including the "-central" in the project file name. If you just use the Open and check the "Create New Local" option it isn't as desirable or necessary.

Working in the Central File

We are supposed to work in local files. Occasionally people will fire up Revit and end up working in the central file instead. These days it is more deliberate because they have to un-check the Create New Local option to do so.

Revit has been tweaked over the years to deal with central file editing. I've read claims in a couple books recently that working in a central file prevents other users from using Synchronize with Central (SwC). It isn't true in my experience. If I'm working in a local file I can use SwC as much as I need. The person working in the central file on the other hand will be forced to create a local file when they try to use SwC. They'll get this message.

I can work in a central file as long as necessary, as long as nobody else is working on the project in local files too. Isolation is fine, collaboration is where the conflict arises. We encounter the message above when a change has been made via a local file while the central file is being edited. While someone is editing the central file a local file user has been able to add or alter an element and then use SwC. When the local file user completes a SwC and the person working in the central file attempts to use SwC the central file editor will get this message (remember Save is disabled in a Central File).

The message also explains how to resolve the situation, just Save As to save the file with another name, which turns it into a local file. Now SwC will work.

There are some legitimate reasons to work in the central file, just do it in isolation.

Don't Ever Edit a Central File?

I regularly read the Southern Arizona Revit User Group's blog. A recent post poked me in the eye and I thought I'd respond to it here. Here's the bit that poked me:

...snip
1. Make sure no one EVER edits a Central file directly, once local files have been created. If you do, you will need to recreate all the local files from the new Central file.
...snip

It's good advice, don't work in a central file.

The second sentence is what concerns me, it isn't accurate. If someone does work in the central file no harm is done by doing so. The worst thing that will happen is Revit will force that person to save the central file as a local file before allowing for synchronization to occur. If other people are actively working in their local files and someone opens the central directly they are very likely to get this message (after doing some work for awhile) when they attempt to save.

This dialog isn't guaranteed to appear no matter what. It only shows up when there is some conflict between the central file that is being edited and changes made in a local file. The more users there are the more likely it will show up.

The dialog title (Local File not Synchronized) is a little confusing because it appears when editing the central file and trying to save. It's the central file that couldn't save. The solution is to use Save As to create a new file (local file as a result) and then use Synchronize with Central (SwC) again.

Assuming it is necessary to work in the central file, the only way to completely avoid running into it is to only work on a central file when there are no other active local files in play.

Why would it be necessary to work in a central file? Read an earlier post.

Central File Naming

I've always recommended appending the word "Central" to the file name of a project that is using Worksets. I've done this because I want to make the file "special" or distinctive to users. With the new Local File process I described in yesterday's post I find myself rethinking this habit.

Revit will append the username to the Local File for us so we don't have to worry about the Central and Local files having the same name (technically Revit doesn't care about this though). We do have to acknowledge that putting "Central" in the file name will remain in the file name plus the username, for Local Files.

A couple examples would help?

Using my established recommendation:
Our Big Project-central.rvt [Central File on server]
Our Big Project-central_username.rvt [Local File on local pc]
Our Big Project-central_username_ddmmyyyy_hhmmss.rvt [additional files]

Abandoning my recommendation:
Our Big Project.rvt [Central File on server]
Our Big Project_username.rvt [Local File on local pc]
Our Big Project_username_ddmmyyyy_hhmmss.rvt [additional files]

I offer this as something to consider. If most of your projects have Worksets enabled anyway then perhaps making the file name "distinctive" isn't as important as it might seem?

Working in the Central File - Breaking the Rule

You've probably been warned a multitude of times to stay out of the central file. You may have even had this angry baby tell you off? When is it okay to work in the central file? Never...except...

Keep in mind, most of these examples should only be done while others are NOT working in local files!

Security Guard mode - You want to make Revit interfere with users who seem determined to delete or move important elements repeatedly. This can be done by checking out a specific workset like Shared Levels and Grids for example. Then when you STC you "refuse" to return the User-Created Workset. This should be done in the central file using a special username, different than the rest of the team like Super Admin for example. Keep in mind that this is merely a modest hurdle for an experienced user to get past but it should deter the average user enough to point out that they were getting in harms way.

Managing Linked Files - Linked cad files and Revit models have a way of "disappearing" when they are managed in local files. At issue is the assumption by Revit that a linked cad file or Revit model should not be loaded into other user's local files for them. Revit expects the user to decide when to load them. If these linked files are managed in the central file the changes to the central file are taken more "seriously" by Revit when others use STC to publish and acquire any changes to the project. Users should avoid using File Manage links in local files. Use Visibility/Graphics or Temporary Hide/Isolate to manage the short term visibility of linked data files instead. Naturally any such links that are not needed should be removed as soon as possible.

Making a new Central File - You can use Detach From Central (DFC) to create a new central file instead but it still involves at least selecting the original central file. If you don't use DFC then you use File menu > Save As > Click the Options Button and check the option: Make this a Central file after save. This dialog option:


Note: You can also use DFC on a local file.

Working by yourself - If you are the only person working on this project routinely and you just want to take advantage of collateral benefits of using worksets then you can just work in the central file. There is nothing wrong with working in a local file instead however and it is even a good idea as it gives you some additional redundancy should something go wrong with your network or computer(s).

Clean Up after Others - Sloppy workset use means lots of elements on the wrong worksets. It is easiest to clean up after everyone when nobody is working in any local files. Open the central file, borrow every workset and get to work.

[Tip: Check all four workset "show" check boxes, select any workset, then use keyboard combination CTRL + A to select All worksets, then click the Editable button.]

When you are done be sure to STC and return everything you borrowed.

Did I forget any? Lemmeno!

Central File in "Four Easy Steps"

Step One - Good Location/Name (server folder and nice name)
Step Two - Enable Worksets (adds two parameters to DB)
Step Three - Save your Work (commit the DB changes)
Step Four - Synchronize with Central (SWC, return your "books")

If you scroll first you'll realize that these four easy steps seem quite long. It takes me some time to explain them but they don't in practice. The variable in how long it will take has to do with when you decide to start the process. Doing it earlier with little in the model will take less time than later with most of the project modeled.

Edit April 21, 2017 - The above is still true conceptually. With the release of Revit 2017 this process has changed a bit. Please refer to THIS NEW POST instead.

Step One - Good Location/Name

File Menu > Save or Save As - Browse to your server and project folder. Use a "good name". This is the most important step, if done incorrectly you can still fix it now. If you wait until after step three, you have to "start over".

Keep in mind, a central file must be created in the correct folder at the outset. If you create a central file in the wrong folder and then try to move it Revit will regard the file as a Local File instead. That might be confusing but that is how Revit is "wired". It records the original folder location and if it is moved the file is treated as a Local File instead.

Similarly you must use the name you really want, now...no changing your mind or the same thing happens, Revit considers the new file a Local File.

Pick your location and name carefully and then act. If you make a mistake, Fix it NOW...assuming you realize it is wrong.

Step Two - Enable Worksets

File menu > Worksets or Worksets Toolbar > "Puzzle Icon"

Revit opens this dialog to confirm your intentions.


Clicking OK causes Revit to add two parameters to every item in the database, Workset and Edited By. Using the Library metaphor I like, this is the "book shelves" and the "library card" user information. It will take less time to do this step if done early in the project. It takes longer the more "model" there is to process.

I recommend you keep the two default worksets that Revit offers you. If you need others you can create them once Revit offers you this dialog box (as soon as it finishes adding the two parameters to the database).


Revit won't let you delete "Workset1" now or in the future. You can rename it but you might find yourself confused later if you want to delete "that" workset and Revit won't let you. For this reason I tend to keep it as a "catch-all" workset for items that I can't decide how to organize yet. You can delete "Shared Levels and Grids" if you like or rename it but again it serves an "obvious" role. Obvious worksets work better as a organization tool.

Step Three - Save your Work

File menu > Save - This is your last chance to "run away". This dialog confirms that you are going to commit your changes to the database and your project will become a real "central" file.


This commits the changes to the database structure that we made in the previous step. The file is now a Central File and you've gone beyond the point of no return. Any changes to the file location or name are going to require special action on our part to keep our team collaborating.

Step Four - Synchronize with Central (SWC)

When we started this process, once we moved beyond Step Two we became the "owner" of everything in the database. When we did Step Three Revit returned most of the elements we borrowed for us but it did not return the User Created worksets. We need to STC in order to return everything so that the whole team can begin working on the project. This is the dialog Revit presents to SWTC when you use the File menu > Synchronize with Central. Note that you don't get a dialog when you use the toolbar button instead. That is a quick SWC and it does not return User Created worksets either.


Note the check in User-Created Worksets and the comment. Do yourself and anyone else who works on your project with you a favor, add a comment. Put something meaningful in each time you bother to SWC. This helps track down a problem later or to determine how far back to go when you must start "over" again at an earlier point in the project's design phase. These comments are visible when using the File menu > Show History or Backups features.

You now have a Central file ready for your team to begin collaborating!

Okay...you got me! There is a fifth step!

Step Five - Close the Central File!

File menu > Close - This closes the central file and from now on nobody should work directly in the central file, as a rule. There are exceptions to the rule but that is a different post.

Now on to creating your Local Files!

Revit Workset Quick Reference