Create Relationships

Create the following relationships. If you are using the sample data, these may already exist. UFM also requires the Conduit_Conductor relationship. This should have been created in the basic configuration for Conduit Manager.

When building a relationship, the ArcCatalog relationship wizard wants to know where to find the unique identifier for the parent (that’s the primary key) and where this same identifier is placed in the child (that’s the foreign key). The application is then able to “match” the parent and child because all the children have the parent’s unique identifier. For the primary and foreign keys, Conduit Manager supports using ObjectID or GlobalID except for the Conduit_CrossSectionAnnotation relationship, which does not support GlobalID. This is because feature linked annotation relationships cannot be globalized.

IMPORTANT: As a best practice, you should decide which field type to use for all relationship keys. In other words, all relationships should use ObjectID, or all relationships should use GlobalID (except for Conduit_CrossSectionAnnotation, as noted above). You should not mix and match the field types.

The tables below are for new relationships. If you have existing relationships that you need to convert from ObjectID-based to Global-ID based, see the topic Migrate Existing Relationships to use GlobalID.

Conduit_DuctBank

Origin table:	Conduit feature class
Destination table:	DuctBank feature class
Relationship type:	Simple
Notification:	None
Cardinality:	One to Many
Attributes?	No
Primary Key:	ObjectID or GlobalID
Foreign Key:	ObjectID or GlobalID

PriUGElectricLineSegment_Duct

Origin table:	PriUGElectricLineSegment
Destination table:	Duct
Relationship type:	Simple
Notification:	None
Cardinality:	Many to Many
Attributes?	Yes
Fields to Add:	PhaseDesignation (long integer) Cables (long integer) You must enter these two field names exactly as shown. Field model names are not supported in attributed relationships; thus, the application is looking for these fields exactly as they are displayed.
Origin (Conductor) Primary Key:	ObjectID or GlobalID
Destination (Duct) Primary Key:	ObjectID or GlobalID
Origin (Conductor) Foreign Key:	PrimaryUG_ObjectID or PrimaryUG_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, PrimaryUG_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.
Destination (Duct) Foreign Key:	Duct_ObjectID or Duct_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Duct_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.

SecUGElectricLineSegment_Duct

Origin table:	SecUGElectricLineSegment
Destination table:	Duct
Relationship type:	Simple
Notification:	None
Cardinality:	Many to Many
Attributes?	Yes
Field to Add:	PhaseDesignation (long integer) Cables (long integer) You must enter these two field names exactly as shown. Field model names are not supported in attributed relationships; thus, the application is looking for these fields exactly as they are displayed.
Origin (Conductor) Primary Key:	ObjectID or GlobalID
Destination (Duct) Primary Key:	ObjectID or GlobalID
Origin (Conductor) Foreign Key:	SecondaryUG_ObjectID or SecondaryUG_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, SecondaryUG_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.
Destination (Duct) Foreign Key:	Duct_ObjectID or Duct_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Duct_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.

FiberCable_Duct

Origin table:	FiberOpticCable
Destination table:	Duct
Relationship type:	Simple
Notification:	None
Cardinality:	Many to Many
Attributes?	Yes
Field to Add:	PhaseDesignation (long integer) You must enter this field name exactly as shown. Field model names are not supported in attributed relationships; thus, the application is looking for this field exactly as it is displayed. IMPORTANT: In the next step, you assign the autoupdater “ArcFM UFM Duct to Conductor Relationship” to this relationship. The autoupdater “ArcFM UFM Duct to Conductor Relationship” requires an attributed relationship in order to track phases for electric implementations. Fiber implementations use the same autoupdater, even though there is no equivalent to phase with fiber cables. Thus, the PhaseDesignation field is required to satisfy the autoupdater’s needs, but it does not itself bear any functionality for fiber.
Origin (FiberOpticCable) Primary Key:	ObjectID or GlobalID
Destination (Duct) Primary Key:	ObjectID or GlobalID
Origin (FiberOpticCable) Foreign Key:	FiberCable_ObjectID or FiberCable_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, FiberCable_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.
Destination (Duct) Foreign Key:	Duct_ObjectID or Duct_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Duct_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.