Transmittals in Parallel

[Josh Verran]

In the context of revision managment we use the following (standard?) workflow;

1. Create a new Transmittal Set
2. Remove unaffected Layouts
3. Add affected Layouts
4. Add Changes
5. Close Transmittal Set

This works really well.
The hurdle we face, is that sometimes step 4 can take days, perhaps even longer depending on the project.
Often during this time, a separate consultant may request one or more layouts to be transmitted for a separate purpose.
We are trying to come up with a robust workflow for this scenario.
Closing the transmittal early, or adding the unrelated changes to the same transmittal creates inconsistencies in the documentation.

I'm hoping we are not the only ones encountering this hurdle, curios how other people work around.

[scottjm]

We have the same issue.

Deleting the layouts that we don't want to send to the other consultant, but leaving all the changes on those removed layouts, seems to work, but it does mean we have to re-add the sheets to a new Transmittal set, which is obviously double handling. 

[aarkell]

Same issue here and one of the reasons we typically don't use transmittals, as having two or more open at the same time isn't possible yet. Unfortunately a project's path isn't usually so linear! I would be curious to see how others manage to get over this hurdle, as there are some advantages I would like to take advantage of such as revision number tracking and the ability to turn on/off deltas. Currently we skip the transmittal step and just use the change manager with layers/layer combos.