Using Relationships

About Relationships

•About Relationships

•About Link Fields

•About Using Link Fields in Relationships

•Relationship Types

•Relationship Cardinality

•Groups in Relationships

About Relationships

A business object relationship lets two business objects collaborate. More specifically, it lets the records included in the business objects work together. In a relationship, business objects can belong to other business objects or simply be associated with other business objects.

Each relationship contains these business objects:

•Parent business object: This business object is the center of a relationship with one or more child business objects. Only a master business object can function as a parent business object.

•Child business object: This business object is the supplier of additional data to a parent business object.

For example, the Incident business object can have a relationship with the Notes business object so that you can track notes pertaining to a specific incident. Because the incident is a master business object, it becomes the parent to the notes, the child business object.

When you add a relationship to a business object, you must specify the exact internal reference name, as specified by the Internal Reference Name parameter.

You cannot create any new relationships that have a null reference name. See About Empty Internal Reference Names for more information.

About Link Fields

The application links records in a relationship through a constraint that specifies how records find each other. In most cases, a relationship uses the standard constraint, a parent link field, which is included in the child and stores the RecID of the parent. Sometimes a special constraint is required or an additional constraint is needed in the parent. In these cases, a relationship relies on a link field.

A link field is a special application field that stores the RecID of a record. It also stores a category for identifying and linking records in a business object relationship. When you create a master-child or standard-child business object, the application creates the parent link field for you.

About Using Link Fields in Relationships

Starting in Neurons for ITSM Release 2016.2, the behavior for how link fields are used within relationships has changed. You can no longer use a link field with a many-to-many relationship. In most cases, the Ivanti Service Management Release 2016.2 upgrade will locate any relationships that are defined in this manner, and will adjust them so that they will continue to work as they did in Release 2016.1. We recommend that you correct these relationships to work correctly before upgrading to any subsequent releases.

The link behavior was changed because the combination of a link field and a many-to-many relationship does not make logical sense, and therefore cannot be properly supported by the application. The link field needs to point to a record in the related business object. Many-to-many relationships do not point directly to the other business object; they use an intermediate table that tracks the links between the two business objects. Configuring a link field on a many-to-many relationship was allowed in previous versions, therefore, customers who have configured this scenario are experiencing unexpected behavior by the application.

The new behavior may cause errors in upgraded environments. In certain instances, you may have defined a link field relationship, but after upgrading to Neurons for ITSM Release 2016.2, that relationship disappears, because the relationship was a many-to-many link field relationship. One example of this is the KnowledgeLink field in the Incident business object. Previously, the relationship and binding fields were populated but after the upgrade, they are unpopulated and the application does not allow you to change them. This is as designed, because we no longer support the many-to-many relationship for link fields, because we updated the link field relationship to only allow relationship matching directly to another business object.

You cannot represent a many-to-many relationship with a single key value. A link field can only contain one RecID, but for a many-to-many relationship there can be several RecIDs. For example, employees can be members of several different teams and teams have multiple employees. This is a many-to-many relationship with many RecIDs (each employee has a RecID). In the past, you could create a relationship between one of the employees and many teams and store it here; however, that was incorrect because no one RecID was correct to enter here. In this release we are removing the ability to incorrectly create and use relationships in this way. To handle this properly, you must create a new relationship that is either one-to-one or one-to-many. You can then set the relationship and binding fields for this relationship.

One example of correctly creating a link field relationship is the escalation watch relationships for the Incident business object. There is one general relationship defined that is one-to-many called IncidentAssociatedEscalationWatch and then there are four other relationships defined with link fields that are one-to-one, called IncidentAssocClosingEscWatch, IncidentAssocResolutonEscWatch, IncidentAssocResponseEscalationWatch, and IncidentAssocWaitingEscWatch.

Relationship Types

•Contains: The child business object belongs to, and is dependent on, the parent business object. The application loads, saves, and deletes the child business object with its parent business object. These relationships are listed under the Relationships tab.

•Associates: The child business object is related to the parent business object, but does not belong to it. The child business object is independent. These relationships are listed under the Relationships tab.

Contains and Associates Relationship Types

•Named: These relationships are application driven relationships used specifically in the Configuration Management Database (CMDB). They are used by the CI Map to qualify relationships in either direction, and to qualify how they are related. They cannot be created in the application. They are listed under the Named Relationships tab for the Incident business object and the CI business object.

•Embedded: You can extend contains and associates relationships to become embedded relationships. An embedded relationship is a special relationship where the child business object is embedded into the parent business object to display one special child record. You always embed a single business object into a parent. The single business object can be a member of a business object group.

For example, you can embed the Address.Phone business object into the Employee business object so that a home phone (one special record) displays on a contact record. You can also embed the entire address group, that is, all of the Address. business objects, such as Address.Email, Address.Mail, and so on, into the Employee business object to display phone numbers, mailing addresses, and email addresses.

•Normal: If a relationship is normal, the primary key is part of the parent business object and the foreign key is part of the child business object.

Relationship Cardinality

Cardinality refers to the number of business objects on each side of the relationship. The following describes the relationship cardinality:

Notation	Each Parent Business Object is Related to	Each Child Business Object is Related to
1 : 0...1	0 or 1 child	1 parent
0...1 : 1	1 child	0 or 1 parents
0...1 : 0...1	0 or 1 child	0 or 1 parent
0...1 : 0...N	0 to any number of children	0 or 1 parent
0...N : 0...1	0 or 1 child	0 to any number of parents
0...N : 0...M	0 to any number of children	0 to any number of parents

Some examples include:

One-to-many: One contains many or one contained in many. For example, one employee (parent) can have many incidents (children). Or one alert (parent) can be sent to many employees (children).

One-to-one: One associates with one. For example, one employee (parent) has only one service level agreement (child).

Many-to-many: Many associates with many. For example, an employee (child) can be a member of more than one group business object (parent).

Many-to-one: Many associates with one. For example, an employee (child) can be a member of just one department (parent). If a relationship constraint is set to many-to-one, the application does not allow you to delete the parent business object because then the relationship would no longer be many-to-one (it would be many-to-none). For example, if an employee has a relationship with a department, the application does not allow you to delete the department, because there are many employees associated with it.

Groups in Relationships

Groups can be part of a relationship, and can function as a parent or as a child. How they function depends on whether the group is a master or standard group.

Viewing Relationships for a Business Object

1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.

2.Open a business object.

3.Click the Relationships tab. The application displays a list of the relationships for this business object.

Field	Description
Relationship Name	A unique name without spaces or special characters.
Display Name	The name that appears to users.
Cardinality	The cardinality of the relationship between the business objects. See Relationship Cardinality.
To Business Object	A relationship has two business objects. One is the current business object. This specifies the other business object in the relationship. For example, if the current business object is the Release business object, and the value under this column is Change, the relationships is between the Release business object and the Change business object.
Binding	The relationship type. Can be one of the following: Associated: Makes the current business object related to the child business object so that if you delete the current business object, the application does not delete the child business object. Contains: Makes the current business object the parent business object in a parent-child relationship. If you delete the parent business object, the application deletes the child business object that is specified in the relationship.
Through Fields	Specifies the constraint fields that relate the business objects.
Condition	An additional restriction that both records must satisfy for them to be related. Business objects are considered to be related only if the condition is evaluated as true.

Adding a Relationship to a Business Object

1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.

2.Open the business object to be the parent business object.

3.Click the Relationships tab. The application displays a list of the relationships for this business object.

4.Click Add new.... The application displays a list of business objects.

5.Select the business object to be the child business object. The application displays the Relationship's Details page.

6.Enter information into the fields.

Field	Description
Relationship Details
Designer Name	The name of the relationship. The application enters a dummy value when you first create the relationship. You can change this name; however, after you save the relationship for the first time, you cannot change this value.
Display Name	The relationship name that is displayed in the UI. You can change the name that the application displays in the UI, but that does not change the actual (designer) name of the relationship.
Internal Reference Name	The exact, internal reference name for this relationship. You set this value when you initially create the relationship. However, after you save the relationship for the first time, you cannot change the value. This name is part of the relationship key name and the other object relationship key. You use this name in expressions when you refer to other business objects. We recommend that you make the name compact and meaningful because there can be several relationships between the same two database tables. To set the value, click not set and enter a value.
Relation to	The related business object. The application automatically populates this field based on the business object that you selected in step 5 above.
Relationship Key	Specifies the name of the relationship. You use this name in expressions when you refer to other business objects. The application automatically populates this field and you cannot change it. It is in the format <relation_to>#.<internal_reference_name>.
Other Object Relationship Key	Specifies the name of the other object relationship. You use this name in expressions when you refer to other business objects. The application automatically populates this field and you cannot change it. It is in the format <business_object>#.<internal_reference_name>.
Direction	Specifies the direction of the relationship, either normal or reversed. Can be used for troubleshooting. The application automatically populates this field and you cannot change it.
Relationship is Audited	Specifies if the relationship is to be audited. The application automatically creates an entry in the audit history log when the relationship is used to link or unlink related business objects. See Accessing the Audit History.
Full Text Search Enabled	Enables the relationship to be included in full-text searches. For queries to return related business objects, at least one field in the business object and related business objects must be enabled for full-text search.
Prevent Delete when Linked Objects Exist	Shown only if the value of the Direction field is set to Normal. Prevents you from unexpectedly deleting linked business objects, which could cause problems. When checked, you cannot delete an instance of the business object type that contains the relationship definition if one or more related business object links exist. This setting only applies to one side of the relationship. For example, IncidentAssociatesChange is a many-to-many relationship. The Incident business object definition contains a relationship definition for IncidentAssociatesChange. The Change business object definition contains a reverse relationship definition for IncidentAssociatesChange. If you check Prevent Delete when Linked Objects Exist for the Incident business object but do not check that field for the Change business object, when an incident is linked to a change, you cannot delete the incident until the link is removed. However, you can delete the change without first removing the link.
This Business Object	Defines how many parent business objects are permitted relative to the child business object (cardinality).
Zero or one	Specifies that a parent record in this business object either has a zero-to-one or a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child).
Exactly one	Specifies that a parent record in this business object has a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child).
Zero or many	Specifies that a parent record in this business object either has a zero to many or a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children).
Many	Specifies that a parent record in this business object has a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children).
One of the following: Primary Key (if normal direction) Foreign Key (if reversed direction)	The primary key (if this is a normal relationship) or the foreign key (if this is a reversed relationship). The application automatically populates this field, but you can overwrite it.
Binding Type
Associates with	Makes the current business object related to the child business object so that if you delete the current business object, the application does not delete the child business object.
Contains	Makes the current business object the parent business object in a parent-child relationship. If you delete the parent business object, the application deletes the child business object that is specified in the relationship.
Use Link Table (for many-to-many relationships)	Read-only, and only used with many-to-many relationships. Defines how the data is passed between records. In a many-to-many relationship, two business objects are considered related when the appropriate record containing RecIDs of two business objects exists in a link table. If this option is selected, you can use the default Fusion Link table, which contains standard constraints called parent link fields (housed in the child and store the RecID of the parent), or you can enter another database table to be used as a link table.
Related Business Object	Defines how many child business objects are permitted relative to the parent business object (cardinality).
Zero or one	Specifies that a parent record in this business object either has a zero-to-one or a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child).
Exactly one	Specifies that a parent record in this business object has a one-to-one relationship with a single child record. For example, an employee (parent) can have one service level agreement (child).
Zero or many	Specifies that a parent record in this business object either has a zero to many or a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children).
Many	Specifies that a parent record in this business object has a one-to-many relationship with its child records. For example, an employee (parent) has many incidents (children).
One of the following: Foreign Key (if normal direction) Primary Key (if reversed direction)	The foreign key (if this is a normal relationship) or the primary key (if this is a reversed relationship). The application automatically populates this field, but you can overwrite it.
Relationship Attributes
Commonly Used	Not used.
Is Asymmetric	Specifies if the relationship is asymmetrical, which means that there is no reverse relationship. The application automatically populates this field and you cannot change it.
Condition	Adds a condition as an additional restriction, combining fields from the current business object and functions from the functions folder. The business objects are considered related only if the condition is evaluated as true. To create a condition, click none. The application displays the Expression Editor. Select the fields or functions and click Save. To delete a condition, delete it from the Expression Editor and click Save. For an example, see Example: Hiding Related Items in Closed Status. NOTE: If you add a condition to a relationship, it works in addition to, and not instead of, any other conditions that may be set for the business object. You can also set conditions by using filters for child tabs, by using visibility expressions, and more.
Group object type selector	Specifies the child type, based on the parent type. Used when the related business object is a group object. You can specify a field in the parent business object that dictates the child business object type. For example, you can use a field on the Incident parent business object to specify the type of form shown. The child business object must be in one of the child tabs on the business object user interface. When the type field changes, the child business object type changes, using matching values where possible. If there is no child business object, the application automatically creates a new one using the original type. If the type field value cannot be matched to a child object type, the application removes the child business object link.
Update fields	Copies data from the field specified for this business object to the field specified for the related business object when they are linked. Click the add icon to add a row for specifying data to push from this business object to the related business object. For example, you can push the priority of an incident (this business object) to the task (related business object). Starting in Neurons for ITSM Release 2016.1, the application automatically synchronizes the Only when field is empty and Overwrite defaults, but preserve user edits fields to be symmetric within a relationship and its reverse relationship. Any potential non-symmetric values are corrected as part of the Neurons for ITSM Release 2016.1 upgrade so that if you check a property value, the application also checks the counterpart value in the opposite relationship.
Set field	The field in this business object that contains the information to be copied. The application automatically lists a field, but you can change it by selecting a value from the drop-down list.
To <related business object>'s field value	The field in the related business object where the information is copied to. Select a value from the drop-down list.
Only when field is empty	Only copies the data to the field in the related business object if that field is empty and if there are no business rules defined to populate this field. NOTE: If you check this option and have already checked Overwrite defaults, but preserve user edits, the application automatically unchecks Overwrite defaults, but preserve user edits. You cannot check both options.
Overwrite defaults, but preserve user edits	Only copies the data to the field if the field contains a default value, but does not copy the data to the field if there have been any changes made. NOTE: You cannot check this option if you checked Only when field is empty. To check this option, first uncheck Only when field is empty.
Update <related business object>'s fields	Copies data from the related business object to this business object when they are linked.
Set field	The field in the related business object that contains the information to be copied. The application automatically lists a field, but you can change it by selecting a value from the drop-down list.
To this object's field value	The field in this business object where the information is copied to. Select a value from the drop-down list.
Only when field is empty	Only copies the data to the field in this business object if that field is empty and if there are no business rules defined to populate this field. NOTE: If you check this option and have already checked Overwrite defaults, but preserve user edits, the application automatically unchecks Overwrite defaults, but preserve user edits. You cannot check both options.
Overwrite defaults, but preserve user edits	Only copies the data to the field if the field contains a default value, but does not copy the data to the field if there have been any changes made. NOTE: You cannot check this option if you checked Only when field is empty. To check this option, first uncheck Only when field is empty.
Link objects referenced in fields	Links the field to the related business object whenever a user selects this business object. For example, if you link the team field from the related business object to this business object, whenever a user selects this business object in a form, the application automatically populates the form with the value of the team field from the related business object. To add a field, click the add icon . The application automatically adds a field. To change the field, click it and select another field from the drop-down list. To delete the field, click the delete icon .
Link objects referenced in <related business object>'s fields	Links the field to this business object whenever a user selects the related business object. For example, if you link the team field from this related business object to the related business object, whenever a user selects the related business object in a form, the application automatically populates the form with the value of the team field from this business object. To add a field, click the add icon . The application automatically adds a field. To change the field, click it and select another field from the drop-down list. To delete the field, click the delete icon .

7.Click Save. The application validates the values that you entered and if there are no problems, saves the relationship.

Deleting a Relationship

Some business object relationships are locked to prevent the modification or removal of items that the application requires. Your customization level determines which relationships you can delete.

To implement definition changes in your live application, create and commit a definition set containing the modifications. Ensure you have rights to create and commit definition sets.

Relationships have dependencies that, upon deletion, can be broken. For example, a task can no longer be assigned from an incident if the relationship between the incident and the task is deleted. Ensure that you are comfortable with deleting the relationship and have properly prepared for its deletion.

1.From the Configuration Console, click Build > Business Objects to open the Business Objects workspace.

2.Open the parent business object.

3.Click the Relationships tab. The application displays a list of the relationships for this business object.

4.Click the delete icon at the end of the row of the relationship to remove. If the icon is grayed out, you cannot delete this relationship.

The application removes the relationship.