You can associate one collection with another by specifying a subcollection. Members of subcollections are not considered to be members of the containing collection. A collection can be a subcollection of multiple collections. This is important because it means that multiple instances of a collection can appear throughout the hierarchy as subcollections of other collections (or subcollections). This also means that you can delete one instance of a collection and still have other instances of that same collection appear elsewhere as subcollections,
Subcollections do not inherit the attributes of the parent collection. Each subcollection has its own identity and membership rules, and the query that creates a collection is completely separate from the query that creates the subcollection. Subcollections function in the same way as nested distribution lists within an e-mail system, and their inclusion in the collection is simply a convenient way of gathering several diverse groups of clients into a single group to be acted on in some way.
Operations Across Collections and Subcollections
Most operations that you can perform on a collection can also be performed on its subcollections. If collection B is a subcollection of collection A, operations performed on collection A can optionally be performed on collection B as well.
For example, if you want to advertise a program to collection A, and collection B is a subcollection of A, you can choose to advertise it (or not) to collection B and its subcollections as well. If you choose not to advertise it to collection A's subcollections, it will be advertised only to the members of the original collection. (If any resources are members of both collection A and collection B, they will receive the advertisement.)
 Note |
|---|
| By default, when advertising a program, the New Advertisement Wizard includes subcollections. If this is not desirable, you should clear the Include subcollections check box to avoid advertising the program to unwanted clients. |
Creating Subcollections
Two types of subcollections can be created:
- Dependent subcollections. Dependent
subcollections are created as a new collection under an existing
collection. When this is done, the subcollection is dependent on
the collection under which it was created, as long as you do not
link other collections to it. If the subcollection is linked to
other collections, the subcollection becomes a linked collection
while attached to more than one collection.When you delete a
collection, any dependent subcollections of that collection are
also deleted. Any advertisements, queries, or collection membership
rules that are dependent on the subcollection are impacted by its
deletion. Because of this, it is strongly recommended that you use
the Delete Collection Wizard to delete any collections that may
contain dependent subcollections.
- Linked subcollections. Linked
subcollections are created when one collection is linked with
another existing collection. This can be one of the default
collection, a collection created for your specific enterprise, or a
subcollection of another collection. With linked collections, when
you delete a collection, linked subcollections are not deleted if
they still exist as either an independent collection or as the
subcollection of another collection. This remains the case until
all but one of the linking collections has been deleted (and the
subcollection does not exist as an independent collection). At that
point, the subcollection becomes a dependent subcollection of the
remaining collection.
Subcollections can be created for existing subcollections to almost any depth. However, because each layer added contributes to the complexity of the collection, it is recommended that you do not create subcollections with more than 10 tiers in depth.