Sub-Objects

Last updated
Save as PDF

There are certain items that contain information that pertains only to a certain record, and therefore exist only within that record. Because they are "owned" by a record, they cannot be accessed outside of it.

In TeamConnect, these items are referred to as sub-objects. Categories, task and project assignees, contact addresses, emails, and skills are all examples of sub-objects.

Both system and custom objects can have sub-objects, and different objects have different sets of sub-objects. For example, custom objects have the sub-objects Categories, Assignees, and Relations. The sub-objects of the system object Appointment are Categories, Attendees, and Resources. The following table provides a complete list of the sub-objects that are available for TeamConnect objects.

Sub-object List

Object	Sub-objects
Object	Categories	Assignees	Relations	Other
Account	x
Appointment	x			Attendee Resource
Contact	x		x	Address Email Fax Internet Address Phone Rate Skill Territory
Document	x
Expense	x
History	x
Invoice	x			Line Item
Task	x	x
Custom Object	x	x	x
Involved	x		x
Embedded Custom Object	x

Each sub-object has its own value set, or group of values, that must be defined in order to add that sub-object to a record. For example, to add a project assignee, the following values must be specified: an assignee (or user), a role, status (active or inactive), and the date of assignment.

Some values, such as status and date of assignment, are set automatically by the system. Others, such as assignee and role, must be entered by the end-user. In the end-user interface, sub-objects are added to a system or custom object record through a batch screen, where the data entry fields in each row indicate the values that are necessary for the sub-object. For details on using batch screens, see Working with Batch Entries.

If your design requires templates and wizards, it is important to know a sub-object's value set and which values have to be set manually in the template. If any required manual values are not included in a template, the sub-object will not be added by the wizard. For more details, see Adding Sub- objects to Templates.

Embedded Custom Objects

An embedded object is a simplified custom object created within (or embedded in) another custom object. They are similar to child custom objects, but have fewer capabilities.

A child object is a custom object in a hierarchical relationship with another custom object. It has all the functionality of a custom object (such as wizards, rules, assignees, and phases), and has a dynamic life cycle and workflow.

An embedded object has a hierarchical relationship with a custom object, but does not have workflow or a dynamic life cycle. Embedded object records are best suited for static information—information that is not likely to change as the parent record moves from phase to phase.

Embedded objects do not have a workflow or dynamic life cycle. As outlined in the Properties of Embedded and Child Object table, you cannot define phases, assignees, or rules in embedded objects. They are best suited for information that is not likely to change as the parent record moves from phase to phase. Because the information is owned by the parent record, it is not relevant to other records.

The following table compares embedded objects and child objects in key functional areas.

Properties of Embedded and Child Objects

Functional area or property	Embedded objects	Child objects
Accessible through All Services	No	Yes
Accessible through parent record	Yes	Yes
Can be contact-centric	Yes	Yes
Can have child objects	No	Yes
Unique ID	Yes	Yes
Auto naming patterns	Yes	Yes
Phases and phase transitions	No	Yes
Assignees	No	Yes
Categories	Yes	Yes
Custom fields	Yes	Yes
Blocks	No	Yes
Object views	No	Yes
Search views	Yes	Yes
Rules	No	Yes
Templates	No	Yes
Wizards	No	Yes
Related objects	No	Yes
Involved parties	No	Yes