About Relationships
To define the way that objects interact with one another, you can specify relationships at the object-to-object and field-to-object levels. Some relationships are tied to standard fields that automatically link to new objects and are added by default during object creation.
Relationships can define access rights to specific objects or fields or applications, list views included in dashboards, or users assigned to Service Teams or Crews. For instance, the Shift field in the Crew object has a relationship with the Shift object, so that when you click the Shift field in a Crew record, a list of shifts appears.
Relationship Types
You can define the following types of relationships:
• Referential: Generic one-to-many relationships (default).
• Master/Detail: One-to-many relationships that establish a tighter bond between two objects and have lifecycle and access control implications between a master record and its related detail records.
• Hierarchical: Special referential relationships in which objects have self-referencing Relationship fields. Records of the object form a hierarchy and can be navigated by using column and hierarchical views as well as table and calendar views.
• Multiple: Many-to-many relationships that are persisted in a dedicated relation table. Multiple relationships can be ordered or unordered.
Cascade Logic
When records are cloned or deleted, related records are also cloned or deleted based on their relationship types and the following field values:
• Override Clone Logic
• Override Delete Logic
• Invert Clone Direction
• Invert Cascade Delete Direction
Additionally, Active and Private field values in related records can be either updated or left unchanged, based on the following Relationship field values:
• Override Set-Active Behavior
• Invert Cascade Set-Active Direction
• Override Set-Private Behavior
• Invert Cascade Set-Private Direction
Referential Relationship
In this example, the Job field of the Appointment object is a Referential relationship field whose target is the Job object. The source record is an Appointment record, and the target record is a Job record.
Default Behavior
• When records are cloned, related source and target records are not cloned. Cloned source records are still related to original target records, and cloned target records are not related to source records.
• When records are deleted, related source and target records are not deleted. Source records are still related to deleted target records after deletion.
• Updated Active and Private field values are not updated in related source or target records.
Special Behavior
• When the Override Clone Logic field is set to Include in Clone Process, source records are cloned along with related target records. Cloned source records point to cloned target records. Target records are not cloned along with related source records. When the Invert Clone Direction check box is selected, this behavior is reversed.
• When the Override Delete Logic field is set to Include in Deletion, source records are deleted but target records are retained. When the Invert Cascade Delete Direction check box is selected, this behavior is reversed.
• When the Override Set-Active Behavior field is set to Include in Active Setting, Active field values are updated in source records, but not in target records. When the Invert Cascade Set-Active check box is selected, this behavior is reversed.
• When the Override Set-Private Behavior field is set to Include in Private Setting, Private field values are updated in source records, but not in target records. When the Invert Cascade Set-Private Direction check box is selected, this behavior is reversed.
Master Relationship
In this example, the Job field of the Job Requirement object is a Master relationship field whose target is the Job object. The detailed record is a Job Requirement record, and the master record is a Job record.
Default Behavior
• When master records are cloned, related detailed records are also cloned.
• When detailed records are cloned, related master records are not cloned. Cloned detailed records reference the same master records as original detailed records.
• When master records are deleted, related detailed records are also deleted.
• When detailed records are deleted, related master records are not deleted.
• When Active and Private field values are updated in master records, the same fields are updated in related detailed records.
• When Active and Private field values are updated in detailed records, the same field values are not updated in related master records.
Special Behavior
• When the Override Clone Logic field is set to Exclude from Clone Process, when master records are cloned, related detailed records are not cloned. Cloned master records have no detailed records.
• When the Override Delete Logic field is set to Exclude from Deletion, when master records are deleted, related detailed records are not deleted.
• When the Override Set-Active Behavior field is set to Exclude from Active Setting, Active field values in master records are not updated in related detailed records.
• When the Override Set-Private Behavior field is set to Excude from Private Setting, Private field values in master records are not updated in related detailed records.
 |
The following fields are not used in Master relationships:
• Invert Cascade Delete Direction
• Invert Clone Direction
• Invert Cascade Set-Active Direction
• Invert Cascade Set-Private Direction
|
Hierarchical Relationship
In this example, the Parent Group field in the Group object is a Hierarchical relationship field whose target object is the Group object, which means that child Group records are configured with other Group records in the Parent Group field.
Default Behavior
• When parent records are cloned, related child records are also cloned.
• When child records are cloned, related parent records are not cloned. Cloned child records reference the same parent records as the original child records.
• When child records are deleted, related parent records are not deleted.
• When parent records are deleted, related child records are also deleted.
• When Active or Private fields in parent records are updated, the same fields are updated in related child records.
• When Active or Private fields in child records are updated, the same fields are not updated in related parent records.
Special Behavior
• When the Override Clone Logic field is set to Exclude from Clone Process, when parent records are cloned, related child records are not cloned. Cloned parent records have no child records.
• When the Override Delete Logic field is set to Exclude from Deletion, when parent records are deleted, related child records are not deleted.
• When the Override Set-Active Behavior field is set to Exclude from Active Setting, Active field values in parent records are not updated in related child records.
• When the Override Set-Private Behavior field is set to Excude from Private Setting, Private field values in parent records are not updated in related child records.
|
|
The following fields are not used in Hierarchical relationships:
• Invert Cascade Delete Direction
• Invert Clone Direction
• Invert Cascade Set-Active Direction
• Invert Cascade Set-Private Direction
|
Multiple Relationship
In this example, the Group Users relationship is a Multiple relationship, with Group records as the source and User records as the target.
Default Behavior
• When records are cloned, related source and target records are not cloned. Cloned records are related to the same records as original records.
• When records are deleted, related source and target records are not deleted.
• When Active and Private field values are updated, the same values are not updated in related records.
Special Behavior
• When the Override Clone Logic field is set to Include in Clone Process, related target records are cloned, and cloned records are related to these cloned target records. Related source records are not cloned, and cloned records are related to the same source records as original records.. When the Invert Clone Direction check box is selected, this behavior is reversed: related source records are cloned, related target records are not cloned, and cloned records are related to the same target records as original records.
• When the Override Delete Logic field is set to Include in Deletion, related target records are deleted but related source records are retained. When the Invert Cascade Delete Direction check box is selected, this behavior is reversed: related source records are deleted and related target records are retained.
• When the Override Set-Active Behavior field is set to Include in Active Setting, Active field values are updated in target records, but not in related source records. When the Invert Cascade Set-Active check box is selected, this behavior is reversed: the Active field value is updated in related source records, but not in related target records.
• When the Override Set-Private Behavior field is set to Include in Private Setting, Private field values are updated in target records, but not in related source records. When the Invert Cascade Set-Private Direction check box is selected, this behavior is reversed: the Private field value is updated in related source records but not in related target records.
Inter-Field Dependencies
You can also use JSON to define dependencies between Relationship fields within an object. Two types of dependencies are supported: requiredFor and dependsOn. The requiredFor dependency type is used to configure one-way dependence, and the current field must have a specified value for associated dependent fields to be editable. The dependsOn dependency type is used to configure cascading relationships based on one-way or two-way dependencies. One-way dependencies support edits to the current field only when the field specified in dependsOn has a value, and the optional value of the current field is filtered by the value of the field specified in dependsOn. Two-way dependencies support edits to both specified fields, When one dependent field is left blank, all options are shown by the other dependent field, and when one or both dependent fields have specified values, the options of each field are filtered by the value of the other field.
|
Parameter
|
Description
|
|---|---|
|
requiredFor
|
The fields for which the current field is required. Either this parameter or dependsOn must be specified.
|
|
dependsOn
|
The fields upon which the current field depends. Either this parameter or requiredFor must be specified.
|
|
direction
|
Whether the inter-field dependency is the source or target of the named relationship. Optional. Default is source.
|
|
relationship
|
The full identifier of the relationship between two objects with the Relationship data type. Also used to filter optional values when dependsOn is specified. Optional.
|
|
bidirectional
|
Whether there is a two-way dependency between fields A and B. When field B has no value, all options appear in field A. Otherwise, options for field A are filtered based on the value of field B. Used only when dependsOn is specified. Optional.
|
|
cascade
|
Used with bidirectional to define whether the value of the current field must be cleared when the value of the associated dependent field changes. Used only when dependsOn is specified. Optional
|
For more information: