How many configurations are too many?

I have the same problem, I have a faucet with different supply styles and different valve styles and different finnish styles and different spout styles and with or with out some extra options. It leads to about 1600 different configurations. The solution that I have found to deal with this problem is the use of the design table for the building of the different configurations. It is preaty difficult to learn, and once I learned some of it I was still confused on other issues. But what I found out was that there were some buggs in the solidworks software that make the configurations off by different degrees of configurations. What I mean is that the part number and the different features that were to be displayed in the modle were not matching. (sorry for the spelling I suck at it) but any how I have figured out how to make the 1600 configs but I did not figure out how to get the right names on the right part configurations of the assembly. This also works for the part level but the assembly level makes it more dificult. You can pick configuatons of configurations in your design table. Let me know if this helps and if you try this on a small scale to see how it works.
Basicly you use a design table and turn things on and off by using patterns of S & U (suppress and unsuppress) in your design table.
Thank you
Terry

If you can manage to do it Terry's that would be a good way to organize the configurations from a centralized source (the design table). Another way to simplify the selection of configurations would be to use derived configurations. You could have 100 top level configurations, which is a lot easier to weed thru, but then each config would have 12 derived configs below them. The opposite might work even better - 12 configs with 100 sub configs each. I'm not sure if a design table can be used to specify derived configs, but if it can then you could use Terry's method in conjunctions with the derived configs. Yet another option would be to have 3, 4 or 12 assembly files, each with 100 configs. How well this would work depends on how often you change from one assembly to another while inside an upper level assembly. Hope that helps.
-Mahir

If you can manage to do it, Terry's method would be a good way to organize the configurations from a centralized source. Another way to simplify the selection of configurations would be to use derived configurations. You could have 100 top level configurations, which is a lot easier to weed thru, but then each config would have 12 derived configs below them. The opposite might work even better - 12 configs with 100 sub configs each. I'm not sure if a design table can be used to specify derived configs, but if it can then you could use Terry's method in conjunctions with the derived configs. Yet another option would be to have 3, 4 or 12 assembly files, each with 100 configs. How well this would work depends on how often you change from one assembly to another while inside an upper level assembly. Hope that helps.
-Mahir

You could have 100 top levelconfigurations, which is The design table was a given from the start. I wouldn't create configurations any other way, at least not this many. As I said, the problem I'm having is not creating the configs but rather the users finding the one they need to put in their assemblies.
I think I may break it down into a few top level assemblies but what sucks about that is that they will be identical models just with different properties.
dp

If PDM is an option there are some that will manage configs as parts. You can then search for the config you want based on the description.
You might be able to write a macro to search on the descriptions also.
I have often wanted to be able to search within File/Open, Config lists etc. Anywhere a list is given in SW it should be searchable if it can grow to a large size.
I don't think you can manage Derived Configs from a DT.

Just another thought here. It appears that the issue here is having the configurations available for users to use in their assys. If it's ok to not store a master copy of each config, then how about letting the user create a job-specific copy of whatever config they need when they need it? That way you only store & rebuild a much smaller file.
One of the SWW sessions I went to last year focused on just such a thing in that all the possible combinations of this product generated about a million configs - way too many to maintain. The design table in the assy file had one line in it, and they fed info to it in such a manner as to create strings that defined certain part configs, lengths, etc. Let me know if you need more info.
WT