Non-primary design options are by definition not a valid part of the project so should not be included in the concept ‘everything’ if everything means the whole current valid project.
I think Speckle should (by default) ignore all non-primary Design Options. In the picture below a secondary design option is used to make an overview of Doors but is being sent in the stream when I send ‘everything’.
Hey Duncan,
This is really good feedback. I definitely agree that typically people are only going to want to see their primary design option in a stream. Quick question for you, as I assume you use Revit more than myself, do you see a use case for retaining the option to send all the design options instead of only the primary one?
hi @conner I can’t think of a situation where that would make sense. It would be full of variations of the design overlapping in meaningless ways.
How Revit works is that every time one makes a design option there are at least two options: the ‘Primary’ which is shown in the ‘Main Model’ and should be part of ‘send everything’, and as many other options as one makes.
It might be useful to export individual Design options, for example for the doors above. But I think that is an edge case and is not really how Revit is designed.
Myself I think there are three places where Design Options can be handled:
Never underestimate the autonomy of users to do weird things. I’ve seen design options used and abused in many different ways.
While I think the Primary only as default is a good call, I can remember examples where losing others would be problematic.
A bunch of ways, but the two most significant would be Design Options used in place of what would have been better as Worksets.
Secondly, which was ingenious if mad was Design Options used for fit-out where Primary was shell and core. I suppose this was a special case of the first example.
In both instances jettisoning Design Options not primary would have been detrimental. It’s all manageable with the options you put forth, but it would need to be communicated and as such @connor suggestion option to toggle the functionality would be both that, and the override option.
@DuncanNZ I’m imagining a scenario where maybe there is a design option that lives exclusively in one option and has no counter-part in another option. For example, maybe a client is considering adding a canopy to a project. I would then model that in a design option so if we decided not to not add the canopy, I could just turn it off. But maybe I would want to see that alongside the rest of my building in a Speckle stream (and maybe @jonathon is right and I really should be using a workset for that 
). Regardless, we already have an existing issue dealing with the scope of the “everything” category [Revit] `Everything` filter doesn't truly grab _everything_ · Issue #1308 · specklesystems/speckle-sharp · GitHub. I’ll mention this thread in that issue so that we consider it when we get around to fixing that.
How about the following, for now:
Keen to hear your thoughts! Cc @JdB
Thank makes sense! I think this suites more use cases then sending all design options.
Maybe allow the user to specify which design option to send (or maybe all) in advanced settings?
hi @teocomi !
I think this idea would be great not only when sending “everything” but also applied to sending by Filters.
Revit (afaik) doesn’t provide a way to filter by design option. So currently when I send by filter, all the design options are arriving to speckle.
Yes, that’s what we’ve done 
, to recap when sending from Revit to Speckle, design options will be excluded unless:
Not to muddy the waters but . . . Is there a way to export all design options at once? It seems now only the primary design option or the selected design option is exported.
The use case would be to be able to explore a set of design options in PowerBi to evaluate cost implications of thoose options. In order to do that effectively I would need a way to seperate out each design option so they can be turned on and off in power BI. If I can export all design options I could use a slicer to access the different options.
Since there is no way of sending a design option seperate in revit, ie turn off your main model and then only send the design option, sending different design options would result in duplicate main model or design option set data.
The only way I can think to solve this problem is to create a boolean set, potentially based on the elementId and the DESIGN_OPTION_PARAMETER. (nested in the [data][toplevel][parameters]DESIGN_OPTION_PARAMETERS) That way one could eliminate the duplicate data of the main model and other overlapping design options for multiple exports?
Is there any documentation on this process of evaluating design option data in powerBi?
No problem with muddying waters all viewpoints are valid.
Howeverm I think at this point the solution to your suggestion would be to send the Design Options as individual Model Branches and then aggregate the data as two queries and whatever pivots you need to do in PowerBI on the basis of the Branch that contains the data. This will be far easier than trying to unpick objects present in two design options if all were sent as an aggregate.
That’s my gut feeling but willing to be convinced otherwise.
FWIW - I’m inclined to explore the otherwise scenario. I have a similar use case to @bfortunato (minus Power BI) - where I want to programatically analyze the different options and produce takeoffs (and visualizations):
I agree, that the current best case seems to be the separate branch scenario, but I feel like that will get challenging to manage quickly due to the permutations of options:
I would likely need to make a custom speckle connector just to export all the above branches/views in a consistent/easy manner that doesn’t involve 40+ user clicks and 
that the user doesn’t mess up and export a view to the wrong branch.
So, I’m tempted to:
No Really...Everything Please option
Open to feedback if anyone has horror stories of trying this already.
Thanks
I can take note of the Design option requirements and we’ll add it to the backlog, this has yo-yo’d a little over time with differing requirements, so may well need to be an advanced option. We’ve tried to resist too many hidden features behind options because no one seems to explore, discover or use many of them, even when well documented.
For repeatability, I’d favour curated holistic 3d views rather than by elevation, but without the nuanced Design option support, alternative workarounds would likely be needed.