[David Cutler]

Great question @Vince !

Since I’m in an office that only two of us use Revu on a regular basis I don’t have the answer.

I’m sure @lizlarsen and @Doug McLean will have some suggestions/real life experience.

[Troy DeGroot]

This depends on many factors and there are probably several correct answers.

• If I just add a new Toolset, I just share the .btx file and have them double-click to load it. Then, Save Profile.
• If there are a lot of changes, I would have them delete the Profile .bpx, Toolsets .btx, and Custom Column .xml files. Then, load the entire Profile again.
• Some companies save the Profile in a locked folder on a network and map all the individual user computers. This way you can make the change globally. Some run a script to delete and deploy profiles every weekend. The rest here is anyone taking the time to build their own custom tools, might lose them (every weekend)
• Maybe this older post will help some too. Best Practices for Sharing Bluebeam Revu Tools Profiles

[David Cutler]

I’d be soooo frustrated if my custom tools were overridden every weekend! 🤣

[Troy DeGroot]

I just make sure I show those users how to save them locally.

[Vince]

Many thanks @troy-degroot !

[Liz Larsen]

Late to the party, sorry.

If it’s only toolsets you’re wanting to distribute, I’d just put them on a network drive and tell everywhere where’re they’re located and how to add them to their own profile.

Since you mentioned wanting to keep them updated, make sure your team knows the difference between “Import” and “Add”. Import makes a copy and saves it on the user’s computer (I believe), whereas Add actually maps to the network drive so your users will automatically see any toolset updates when they close and re-open Bluebeam.

[David Cutler]

“Fashionably Late” @lizlarsen , “Fashionably Late”. We will let you by this time since you’ve been in the weeds on the JavaScript challenge of the week. 😎

Great tip on the “Import” vs “Add” options for the tool sets.

[Vince]

Thanks @lizlarsen – that is really helpful!

[Vince]

Hi @lizlarsen – one quick question – if the ‘add’ method is used will the root file be updated every time any user saves the profile?

[Liz Larsen]

Short answer: no.

Longer answer: The Toolchest root file itself does not care when the profile gets saved. The Toolchest file only gets updated when you click the lock, make a change, then click the lock again. This being said, if you’ve got users’ Toolchests pointed to a network drive, <i style=”font-weight: bold;”>make those Toolchest files read-only.

When the user saves their profile, the only thing about Toolchests that gets updated is which Toolchests are loaded and active, plus the path of those Toolchests.

And, if I got any of that wrong, someone please feel free to correct me.

[Vince]

Thanks @lizlarsen ! I think I’m going to play it safe on this one and get the users to ‘import’ just in case anything goes wrong. They can all be emailed if there is a change to the tools, custom columns, etc..

[Isaac Harned]

Agreed this is the best option, just comes with one little caveat:

When exporting to a network location, Tool sets will be Locked, meaning that to make any changes to the set, user will basically have to unlock or check out the toolset. This can be annoying if you have a base set of tools that needs to change in minor ways along the process.

In our situation, our markups involve alot of visual properties that might need to be changed as we go through highlighting ductwork (i.e. colors that don’t mesh well together or are harder to see through when ductwork overlaps). Our process was originally to store the toolsets on the network, but I would see little random tools added to my chest, or little properties modified in my base tools. It would be great if we could assign permissions to them, but unfortunately, anyone you give access to will be able to unlock it.

What I do now is an export to local storage with dependencies into a folder. Then I manually move the folder to a shared location (it was not exported to the network location directly, so it will not have the lock). When setting up a new system, my training dashboard will instruct users how to manually copy that folder into their “AppData\Roaming\Bluebeam Software\Revu” \version folder, then they can open revu, import the profile, which will come with the tool chests. If a user wants to replace the toolset with the original, the folder will remain in the app data folder and can be dragged from the imported folder to the main “Revu/(version)” folder, and if there is an update to the Master file on the network, that toolset can be dragged directly to replace the same toolset. This eliminates the multistep re-import as long as they are named exactly the same.

[Doug McLean]

I’m with everyone else on this… my answer, it depends. 😁

What I’d more like to know is to how to NOT export every tool chest with a Profile.
I have a lot of job specific tool chests that don’t need to be shared with the team.

[Liz Larsen]

I’d like an option to export a profile with only things I specify. Like when you export a CSV summary of markups, you can pick and choose what you want exported.

I’d like an “Export Profile” button and a dialog box pops up with checkboxes. Same with an “Import Profile” button. It’ll say “This profile contains custom toolbars, X number of toolchests, and custom statuses” with an option to import whichever you need.

[Doug McLean]

I’m thinking this is a perfect “Make a Suggestion’ item

[Troy DeGroot]

Good visual @lizlarsen “just like the export CSV window”. I’d like to see a list of all the ToolSets, Line Style files, Hatch Pattern files, Custom Column files, Export Configs, Stamps, PDF Templates, Email Templates, and Saved Filters in the Markups List. This way you know exactly what’s included. As someone who builds and shares Profiles all the time, it’s frustrating to never know for sure what’s included when saving a Profile. You have to go to each one of these locations and make sure to save to profile before you save the profile.

[Isaac Harned]

Workflow could be to only allow those toolsets to be visible in the main working profile, then have a field profile to distribute with those tools not visible. I’m sure that’s already your workaround, but the best idea I had.