Cascade Rules and Aliases

The cascade rules specify which operations are allowed when using the Composite Object APIs. The Cascade Delete Rule also triggers an auto-delete of detail records in a Master-Detail relationship.

About Cascade Rules and Aliases

• Cascade rules are established by the application designer. They determine which operations are allowed on dependent objects in a relationship.
• The alias gives the relationship a name. In the data stream passed to the composite request handler, the alias is a wrapper for the dependent records in a relationship. The resulting structure looks like this:

primary record
  |...primary record data...
  |relationship alias for secondary object
  |   secondary record #1  
  |      |...secondary record data...
  |      |relationship alias for tertiary object
  |      |   tertiary record #1
  |      |      |...tertiary record data...
  |      |      |...
  |      |...
  |   secondary record #2  
  |...

Notes:

• Relationships can nest to arbitrary depth.
• Relationship aliases will generally have the same name as the dependent object.

Cascade Rules

Cascade rules restrict or allow add, update and delete access to related objects. They determine which operations are allowed on subsidiary objects in a composite relationship.

The following choices are available:

Relationship Type	Foreign Object Id	Junction Foreign Object Id	Add	Update	Delete	Orphan Delete
One to Many	Other than User	--				--
One To Many	User	--	--		--	--
Many to Many	Any Object	Other than User			--
Many to Many	Any Object	User	--		--	--
Many to One	Any Object	Any Object	--		--	--

Specifying Aliases and Cascade Rules

Prerequisites:

1. All objects and junction tables have been created.
2. Lookup fields have been defined in the objects to establish the relationships

To specify aliases and cascade rules:

1. Designer > Objects
2. Select the primary object in the relationship.
   For example, if Order_Items has a Lookup to Orders, then Orders is the primary object, and Order_Items is the dependent object.
3. In the Properties tab, scroll down to Related Information
   A list of dependent objects appears. So if Order_Items has a Lookup to Orders, then Order_Items appears in the list. (The Users object always appears three times: for the creator of the object, for the current workflow owner, and for the most recent person to modify the object.)
4. Select the object relationship you want to specify.
   For example, select the Order_Items object. The Manage Object Relationship window appears.
5. Specify the type of relationship: Either One-to-Many or Junction if this is a junction object for a Many-to-Many relationship.
   If you select many-to-many:
   1. The 'Select Foreign Object field lists the targets of the other Lookup fields in the junction object.
      (Typically there will only be one, but there could be more.)
   2. From that drop down, select the secondary object in the Many-to-Many relationship
      The next drop down is then automatically populated with the lookup field.
6. Specify the name of the relationship alias.
   Typically, that will be a lowercase, plural version of the dependent object's name, but you may need different aliases if the same object is used in multiple dependent relationships. For example, in the Order object, the alias for the Order_Item object might typically be specified as items.
7. Specify the cascade rules. Depending on the type of relationship you have defined, you can enable the capability to:
   1. Add dependent records
   2. Update dependent records
   3. Delete dependent records in a one-to-many relationship
   4. Do an "orphan delete" for a many-to-many relationship
      (Automatically delete the dependent record if no more records point to it.)