Keir & Ben both have some good info. A few more things to add;
- Define their acceptable and unacceptable use prior to using them (this may impact company policies and procedures)
- Consider how the instances are going to be detailed. If you allow/require instances to have their own drawings, this will add complexity. It is easiest/most robust when all instances are controlled on one single drawing. That drawing is of the generic and uses tables with repeat regions to define the instances and the associated dimensions. Don't override the shown dims, but rather change the dim text to "@S" and then the values are shown in a table.
- Make sure the table dims are all named, or the above won't work well.
- Define your numbering policy. For instance, are you going to use dash numbers? i.e. the generic is numbered "123456" which matches the drawing number and then the instances are; "1233456-1", "...-2" etc. Does everyone (mfg, purchasing, doc control, etc) have the same concept of what a dash number is? This can be a big thing in terms of ISO type certifications.
- Revisions; can instances have different revisions? From a practical point, the generic must be equal to or "higher" than the highest instance. i.e. if one instance is at rev G, the generic must be at least at rev G. Or, must all instances, the generic and the drawing all be at the same rev? (easiest)
- What happens to obsoleted instances? Deleting an instance is a VERY BAD thing. So, how are you going to obsolete an instance when it is no longer wanted? (Setting to an OBS release level works, but access control impacts a users ability to later modify the generic.)
- I will also reiterate a comment from above, nested family tables are a bad idea unless use is very strictly controlled and you have a very robust process in place to insure proper use.
Note, FTs are really good for commercially purchased library parts like fasteners.