Announcements

Welcome to ACC Ideas! View the ACC Product Roadmap here. Top-voted ideas may be considered for future development. Learn more about the feedback process here.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Publishing and Schedule

Publishing and Schedule

Publishing is an essential part of Revit Cloud models and worksharing, because all parties (including design teams, management, etc) would generally like access to the latest models versions through Docs and/or Design Collaboration. This also ensures better version handling and backups.

 

For workflows that require publishing only models which are approved, the "Live" (Work in Progress) model should be non-accessible to other teams, and sharing through Design Collaboration should be utilized (after publishing either manually or by schedule).

 

Therefore I think the entire publish workflow needs rethinking.
Publishing should not be reliant on Design Collaboration at all. It should be possible to publish and set up a publish schedule from Docs, as done from within Revit, per model or per folder, with or without links, etc.
Either that, or at a minimum allow creating ACC project templates which already have the publish schedule defined for each team.

 

Unfortunately, right now in order to set up a publish schedule, for each team there must first be a model uploaded, and then a schedule has to be set up individually for each team through Design Collaboration. This is time consuming and not straightforward, plus we don't use Design Collaboartion at all in most of our projects except for the need to set up the scheduled publishing, which again does not belong there in my opinion.

10 Comments
Chad-Smith
Advisor

You are correct.

The more I think about, I feel that Design Collaboration as a whole needs to be dismantled and its features redistributed into Doc/Files and Model Coordination.

orenco14
Contributor

100%, publishing does not belong in Design Collaboration contrary to what the term "publish" suggests.

Acatually I think separating and renaming the publish stage should solve a lot of confusion and add reliability and usability. 

 

"Live" Revit cloud models should be represented as such in ACC. They should not have features such as published views, issues, etc and should be separated from their published contureparts. This should solve a lot of confusion to all parties envolved, and also allows easier access to downlad "Live" Revit files without opening the software.

Linking to "Live" models is a high-trust workflow that is suitable for many.

 

Publishing should be moved from Design Collaboration into Docs.  Scheduled publishing should be available in an easy folder-based manner and set up in an ACC project template.

Then published models should be separate files located at a designated folder location. Publishing should be renamed to demonstrate that this process is more in the realm of the model owner, and still not necessarily in the realm of sharing or "publishing" to other consultants. Publishing is firstly a tool of the model originator. The choice whether published models are shared with other consultants is made by managing the folder permissions in ACC. Publishing is an essential part of Revit Cloud models and worksharing, because all parties, including the model originator would generally like access to the latest models versions through Docs and/or Design Collaboration. This also ensures better version handling and backups. These published models should have ACC features as they do today like published views, issues, etc.

Revit models which are uploaded to ACC through the web or desktop connector should be treated as "published" models (hence again the need to rename the publish procedure).

Linking to "published" versions should be available and could benefit some projects where more control is needed on changes, as opposed to "Live" linking, but a high-trust workflow is still necessary.

 

The above workflow should be sufficient in many projects and for many companies.

 

For when a low-trust workflow is necessary, we are now ready to step from the realm of the model originator to the realm of sharing (or what I consider to be "actual publishing") to other consultants. This could be done by sharing packages as we know it from Design Collaboration, or by simply copying models into shared folders (while keeping track of versioning). 

 

Finally, when a very-low-trust workflow is needed a consume action is taken by the consultant copying shared models of other designers into their own consumed folder.

 

To summarize, publishing should be renamed and streamlined into the originator process, while separating this from the "Live" models (which is actually what happens behind the curtains and is why many people are confused and do not understand the difference between live and published models).

For Share/Consume, an easier approach could be offered by a simple yet smart copy command in Docs which retains relations between models version history and overrides the previous verion. Packages and timelines should still be available through Design Collaboartion.

Chad-Smith
Advisor

@orenco14 wrote:

Acatually I think separating and renaming the publish stage should solve a lot of confusion and add reliability and usability.


I agree that the Publishing in Design Collaboration is definitely one of the biggest areas of confusion. All too often, members will create a Package without any regard to Publishing first. There is a disconnect in member's minds between where the models are stored in Docs, vs where they distribute the models in DC. Putting the Publish process in Docs alongside the model would help members to associate the models with publishing.

 


@orenco14 wrote:

For Share/Consume, an easier approach could be offered by a simple yet smart copy command in Docs...


It's interesting that you said this, and it's something I have been thinking about in light of today's Release Notes which has an upcoming Coordination Space Configuration feature.

You could create your own simplified WIP/Shared folder structure, assign folder permissions, and use the Copy function to 'share' models between WIP and Shared. Then, you could use the upcoming Coordination Space Configuration to create a coord space at the Project Files level and be very selective about which folders you want. And you can create as many customised coord spaces as you need.

This way you should be able to get all the benefits of a less confusing process by using Docs, and still use the coordination in Model Coordination. As for Publishing, the model owner would still have to do this in Revit.

b.balser
Contributor

Yes to this.. at a minimum, it should be possible to set up automatic publishly on a weekly or monthly basis even if Teams haven't been established.

crau
Participant

The ability to "publish" a model as a separate function from Design Collaboration and it's respective "teams" (of which I have other issues regarding overriding of permissions when existing folders are used to create a team) should absolutely be available purely to ensure automated backups exist of the cloud project. I can think of many times when my workflow has included the need to download the model & its links for whatever reason, then upon opening the zip folder / models locally, find that the version of the model I downloaded was not the latest relative to the "live model" content because the download function is tied to the published version. For many users, my office included, the high-trust method of live-linking models is controllable to a point with role-based permissions at a per discipline folder level. This gets messy quickly if Design Collaboration is initiated after project setup and the permissions we've spent time setting change without warning - particularly when for ease of setup, the automated publishing for the "team" folders is set to a higher level parent folder. An example being the Team folder named: BIM Models, and the subfolders within that being per discipline. 

clenon
Observer

Chiming in to say I agree. publishing/teams are the biggest source of confusion for our office on ACC.

HGC-Jchandler
Advocate

You should be able to schedule publishes at whatever interval suites the project for all models on that project, workshared or not. 99% of our models are non-workshared cloud models, meaning we currently have no option to automate publishing. Now that Bridge only syncs when models are published, and there is no longer a "Publish All" button like there used to be in manage cloud models, the ability to schedule is critical. 

jstipanovich
Advocate
Glad to see I'm not the only person miffed by this. Two things need to happen in my opinion: Schedule Publishing should be part of Docs, not Design Collaboration (it being in Design Collaboration makes NO sense) Scheduled Publishing needs to include a Publish Without Links option. I like the idea given above of dismantling Design Collaboration and distributing it's features to Docs and Model Coordination. While they're at, dismantle the Desktop Connector too which is another confusing and clunky interface that doesn't feel like it belongs.
Braden_Campbell
Contributor

I totally agree with this!

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea