Skip To Content


Associations model relationships between features that are not geometrically coincident. This allows modeling connectivity between points that are not coincident, the structural support of assets, and features encased within other features.

The three types of associations are as follows:

Each type of association has its own type of network rule that can be created to ensure data quality by restricting the types of features that can be associated. These rules are enforced when creating associations using the Modify Associations pane and also when importing. If a rule does not exist to support an association, the Import Associations tool will fail.

Work with associations

Associations are created, modified, and deleted using the Modify Associations pane. This is where association rules are checked to ensure the selected features can connect, attach, or be contained. Network rules can be created to allow associations to be established between features as long as utility network feature restrictions are honored.

All features in a utility network have an attribute called Association status. It indicates the type of association a feature participates in, the role the association plays in a relationship, and any properties that are set, for example, visible content. Analytic events use this attribute to determine the relationships between features.

See Association status attribute for more details.

View associations

Associations do not have attributes or a Shape field, and they do not support relationship classes or join tables. Associations are internally managed in a system table. Although associations do not have a Shape field, you can view associations using the following workflows:

See Control association visibility for more information about viewing associations.

Association roles

Structural attachment and containment associations require that an appropriate association role is assigned to the feature classes representing the structure or container features. The Set Association Role tool is used to designate the specific association role type along with additional properties. The Role Type of Structure or Container is assigned to feature classes using specific asset groups and asset types. An association role must be set before creating structural attachment and containment rules.

  • Container—Features can be a container in a containment association.
  • Structure—Features can be a structure in a structural attachment association.

Association roles are assigned to feature classes that support being a structure in a structural attachment association and a container in a containment association. To review the valid feature classes, see Feature restrictions. Once an association role is assigned, features from these feature classes can be included in an association as long as they have supporting network rules.

To determine if a feature class has an association role set, review the Network Properties for the utility network. From here, expand the appropriate domain or structure network and inspect the Association Role column for specific feature class asset groups and asset types.

Review the following section for additional properties that are set for association roles.

Deletion Semantics, View Scale, and Split Policy

There are additional properties that can be defined with the Set Association Role tool. The properties are applicable to specific associations roles, and will vary depending on the Role Type specified. See the list of association properties and if they apply to a Container or Structure.

  • View Scale—Container only
  • Deletion Semantics—Container and Structure
  • Container Split Policy—Container only (structure line feature class)

The View Scale property is specific to the container role. It determines what map scale to set when you enter containment mode, for example, 1:100.

Deletion Semantics apply to both the container and structure association roles. They determine how child features are handled when the parent feature is deleted. For example, if a pole structure is deleted, the deletion semantics control how the items that are attached are impacted. In regards to containment, when the container is deleted the deletion semantics control how content features are impacted.

The following are the three types of deletion semantics:

  • Restricted—If content or attachment features exist, an error is returned when attempting to delete the container or structure. The content or attachment features must be removed before deleting the container or structure.
  • Cascade—When a container or structure is deleted, its content or attachment features are also deleted.
  • Set to none—When a container or structure is deleted, its content or attachment features are not deleted; instead, it is removed from the containment or structural attachment association.

The Container Split Policy property is specific to the container association role and only set for Structure Line feature classes. It is used to determine how content is treated when a container feature is split. The options for the container split policy are Do Not Split Content (default) or Split Content. If using a split policy of Do Not Split Content, a new container feature is created from the split operation and content is not split. The content feature is maintained as content to both parent containers. With the policy of Split Content, content features will also be split and properly associated with the new container features created during the split operation. See Split container and content features for more details.

To learn more, see Set or modify an association role assignment.