Child Objects

Designer > Objects > {object} > Child Objects

Object Inheritance Model

Object Inheritance provides the ability to build new (Child) objects that contain the attributes of an existing (Parent) Object.

When a child object inherits the fields and behaviors of a parent object, common properties (defined once in the Parent Object) are applied uniformly to the child object. Each child object gains the base attributes of the parent, while contributing additional, unique attributes into a powerful module.

Using the parent/child object model provides the ability to infuse the fields and behaviors of one object to another, which saves time when building objects, and creates a robust data model.

The Object Inheritance option is managed by a Service Provider admin This feature is disabled, by default Learn more: Tenant Configuration Options

How it Works

The Parent-Child relationship is evident when considering the perspective of an object in the hierarchy, looking above or below. The following relationships describe the model shown at the top of this page:

• Parent objects are located above an object

People object is a parent of Employees, Members, etc.

• Child objects are located below an object

Employees object is the child of the People object, and a parent of the Active employees object

Customers object is the child of the People object

• Naming conventions:

• There is one base object, which is located at the top of the hierarchy
• The leaf objects are located at the bottom of the hierarchy
• Objects in the middle can be parents or children, depending on the path (going up or down)

The Object Inheritance model can be carried further, expanding to include multiple categories and subcategories of People, or any kind of object (places, things, etc.)

Example to Create a Parent and Child Object

To create an Object for members of a club or organization:

1. Create a People object, and include the following fields:
   • Mr/Mrs/Ms
   • First Name
   • Middle Initial
   • Last Name
   • Primary Email Address
   • Primary Telephone Number
   • Primary Address, City, State, Zipcode
2. Create a Members object
   • Select People as the Parent Object
   • Click the [Next] button and add the following fields:

   • Membership Number
   • Member since (date)
   • Annual Fee Amount ($)
   • Annual Fee Paid (Y/N)

   • From the Elements Sidebar, click the Pick Existing tab to display the fields from the People object; Click and drag these fields from the People object into the Members object Form
3. Optionally, build out the Member child object with additional elements; Learn more: Customize Objects
4. Save changes when complete

It's easy to understand how these child objects could evolve from a parent object. What's also interesting is that, in addition to inheriting fields, attributes from the parent are applied at the child level.

Inheritance Guidelines

• Single inheritance is supported:

• A parent object can have multiple child objects
• A child object can have only one parent object
• An unlimited number of child objects can be associated with a parent object

• The Base Object (base class):

• is the top-most object in the hierarchy
• is a parent object
• has attributes and behaviors different from other parent objects

• Any attributes in a parent object are common to all child objects (i.e., the child object inherits all the attributes of the parent object)

• All attributes present in the parent object (Forms / Workflows / Validations / Data Policies) are available in the child object

• After a child object is associated with a parent object, the child object cannot be reassigned to a different parent object

• Visibility:

• When referring to a parent object, only attributes present in the parent are visible
• Attributes present in the child object can only be seen when referring to the child object

• Add/Update/Delete operations on a child object will also result in corresponding operations in the parent object (cascading operations)

• Unique Indexes can be defined only on the Base Object

• Data policies defined on a child object affect only that object's records. Data policies defined on a parent object can affect both the parent record and child records.

• When running calendar policies at an object, all rows matching the criteria will be acted upon (whether they belong to the object on which the policy is defined or to the child objects)

• All parent level fields are available to be placed in a child object, but they will not appear in Fields tab in Customization (use the Elements Sidebar to select parent object fields in a child object's Form)

Supported Properties and Actions

Search

Learn more: Search

• Search and retrieve actions on a parent object can only use criteria from fields in the parent object
• Search and retrieve actions on a child object can use criteria from fields in the parent or the child object
• If a field in the parent object is not in the child object's Form, the search and retrieve action will fail

Delete

• When you delete a parent object, all child objects are deleted, as well. You cannot delete a parent object without also deleting its children.
• Deleting a parent object permanently from the Recycle Bin also permanently deletes any child objects that reside in the Recycle Bin
• If a parent object resides in the Recycle Bin, and an attempt is made to restore child object(s) also residing in the Recycle Bin, an error message is displayed (instead, restore the parent object first, then the child object)

Formula Fields

Learn more: Formula Fields

• A formula defined on the parent object is calculated during a parent record operation as well as any child record operation

Reports

Learn more: Reports

• Reports defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
• Learn more: Views, Reports and Object Inheritance

Forms

• Forms defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)

Validations, Data Policies and Workflows

• Entries defined for an object can refer to fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)

Import

Learn more: Import Data

• When importing data into an object, fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level) are available for mapping
• Import uses the Indexes defined in the parent object for data imported to both parent and child objects

Export

Learn more: Export Data

• An Export operation performed on a parent object will export all the records present for the object as well as any child objects in the inheritance chain (following the path down to the bottom [leaf] level)
• However, it will only retrieve the fields that correspond to the exported object and fields from all parent object(s) in the hierarchy (following the path up to the root level)

Mass Operations and More Actions

Learn more: Mass Operations, More Actions

• Mass Operations defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)

Not Supported

The following platform elements can be used in objects that are part of an object inheritance hierarchy, however their functionality is limited to the object where they originate. These elements must be created specifically for use in parent or child object(s):

• Print Templates
• Actions
• Web Forms

For Developers

When one object inherits from another, there are two virtual objects, but only one physical object.

If object B is a child of object A, then:

• For a record added to object A, the object_id value is A's object identifier.
• For a record added to object B, the object_id value is B's object identifier.

A Data Policy written for object A (for example) would apply to both object types of records. In that data policy, you could create conditional behavior based on the object_id. Or you might create a Data Policy for object B, which would only operate on object B's records. Choose the option that makes the most sense for your design.

Considerations

• For each Object there is an associated Object Type Identifier (object_id)
• That value is stored in the object_id field for each record.

• At the Record level there is an associated Record Id (record_id)

When Should the Object Inheritance Model Be Used?

Use Object Inheritance when:

• A parent object can be defined that contains fields common to a group of objects
• Child objects should be created when any of the following elements is required, and are not included in, or related to, the parent object:

• Fields
• Forms
• Actions
• Record Locators
• Indexes
• Validations
• Data Policies
• Assignments (Prospect or Cases Objects only)
• Print Templates
• Web Forms
• Workflows

Views, Reports and Object Inheritance

When creating Views or Reports in objects that are part of an Object Inheritance model, it is important to consider the following:

A Report or View that has no Filters will return all records from the designated object, including records from all parent object(s) in the hierarchy (following the path up to the root level).

To restrict the View or Report to only the desired objects, include the Object Name field in the Selected Fields list, and create a Filter on Object Name field to select only the objects of interest.