Using 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 docid\ glnu2hzf6vfsaju j 10m for more information 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 using link fields in relationships starting in 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 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 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 number of potential parents number of potential children 1 0 1 1 parent 0 or 1 child 0 1 1 0 or 1 parents 1 child 0 1 0 1 0 or 1 parent 0 or 1 child 0 1 0 n 0 or 1 parent 0 to any number of children 0 n 0 1 0 to any number of parents 0 or 1 child 0 n 0 m 0 to any number of parents 0 to any number of children 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 from the configuration console, click build > business objects to open the business objects workspace open a business object 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 docid\ szcp qyw98hbg7iwleeu2 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 from the configuration console, click build > business objects to open the business objects workspace open the business object to be the parent business object click the relationships tab the application displays a list of the relationships for this business object click add new\ the application displays a list of business objects select the business object to be the child business object the application displays the relationship's details page 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 docid\ suej5xmlyduoz68lbfgae disabling this audit type removes the previously audited data 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 docid 8q8mln7tr pjweicgjpn7 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 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 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 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 from the configuration console, click build > business objects to open the business objects workspace open the parent business object click the relationships tab the application displays a list of the relationships for this business object 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