Contact Objects #1100

New Issue

adam · 2025-12-29T16:28:50+01:00

adam commented

2025-12-29 16:28:50 +01:00

Originally created by @Bill-Irvine on GitHub (Jul 14, 2017).

Originally assigned to: @jeremystretch on GitHub.

Issue type: Feature Request

This may well be out of scope for Netbox as a technical application but thought i'd gauge interest in this feature.

I find myself managing several sites with the same contact. When that contact for example changes an email address, phone number, or someone takes over their role i am updating all the sites with that contact listed.

If this is changed to a contact object that we then attach to these sites we have a central place to manage these people without duplicating the data in separate sites.

From here we could add functionality such as adding several contacts to a site (primary, secondary), we could stipulate between a business contact or a technical contact, add which company they work for, have an api get request that lists contacts for a child object such as devices (useful for managing outages and notifications).

Let me know your thoughts.

Originally created by @Bill-Irvine on GitHub (Jul 14, 2017). Originally assigned to: @jeremystretch on GitHub.  ### Issue type: Feature Request This may well be out of scope for Netbox as a technical application but thought i'd gauge interest in this feature. I find myself managing several sites with the same contact. When that contact for example changes an email address, phone number, or someone takes over their role i am updating all the sites with that contact listed. If this is changed to a contact object that we then attach to these sites we have a central place to manage these people without duplicating the data in separate sites. From here we could add functionality such as adding several contacts to a site (primary, secondary), we could stipulate between a business contact or a technical contact, add which company they work for, have an api get request that lists contacts for a child object such as devices (useful for managing outages and notifications). Let me know your thoughts.

adam added the status: accepted type: feature labels 2025-12-29 16:28:50 +01:00

adam closed this issue

2025-12-29 16:28:50 +01:00

adam commented

2025-12-29 16:28:51 +01:00

@modir commented on GitHub (Jul 27, 2018):

Not only would it be useful to have several contacts for sites, but for providers as well. There we often have as well a technical contact and a business contact.

@modir commented on GitHub (Jul 27, 2018): Not only would it be useful to have several contacts for sites, but for providers as well. There we often have as well a technical contact and a business contact.

adam commented

2025-12-29 16:28:51 +01:00

@SzymonKurowski commented on GitHub (Jun 8, 2019):

I have similar business needs in my organization (multiple contacts per site). I like the approach described above.

Is there anyone who is currently working on that? I would like to offer my contribution.

@SzymonKurowski commented on GitHub (Jun 8, 2019): I have similar business needs in my organization (multiple contacts per site). I like the approach described above. Is there anyone who is currently working on that? I would like to offer my contribution.

adam commented

2025-12-29 16:28:51 +01:00

@SzymonKurowski commented on GitHub (Jul 1, 2019):

There is a one key point to discuss. How to deal with current contact information added to Site model.

To implement this feature it is necessary to add new model (i.e. Contact) and then if we move contact from Site to the Contact model – it will break a backward-compatibility.

For the first iteration, I would leave Site contact fields (it can be treat as a main contact to the site) and add Contact model for any specific contacts. Additionally, each contact from Contact model can refer to more than one site.

Please let me know if you have any thoughts.

@SzymonKurowski commented on GitHub (Jul 1, 2019): There is a one key point to discuss. How to deal with current contact information added to Site model. To implement this feature it is necessary to add new model (i.e. Contact) and then if we move contact from Site to the Contact model – it will break a backward-compatibility. For the first iteration, I would leave Site contact fields (it can be treat as a main contact to the site) and add Contact model for any specific contacts. Additionally, each contact from Contact model can refer to more than one site. Please let me know if you have any thoughts.

adam commented

2025-12-29 16:28:51 +01:00

@mtbutler07 commented on GitHub (Nov 5, 2019):

+1 For adding multiple sources for contact information for sites.

@mtbutler07 commented on GitHub (Nov 5, 2019): +1 For adding multiple sources for contact information for sites.

adam commented

2025-12-29 16:28:51 +01:00

@ryanmerolle commented on GitHub (Nov 11, 2019):

I say for backwards compatibility, I would implement the way in which @SzymonKurowski mentions with one alteration:

If no legacy site contact is recorded for a site, then netbox can default to showing the new contact fields.
If a legacy site contact is recorded for a site, netbox will show the contact with a note directing the user to the new model.

@ryanmerolle commented on GitHub (Nov 11, 2019): I say for backwards compatibility, I would implement the way in which @SzymonKurowski mentions with one alteration: - If no legacy site contact is recorded for a site, then netbox can default to showing the new contact fields. - If a legacy site contact is recorded for a site, netbox will show the contact with a note directing the user to the new model.

adam commented

2025-12-29 16:28:52 +01:00

@ryanmerolle commented on GitHub (Nov 11, 2019):

It would also be useful to apply the contact object relationship to:

Sites
Regions
Tenants
Manufacturers
Providers

You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that.

@ryanmerolle commented on GitHub (Nov 11, 2019): It would also be useful to apply the contact object relationship to: - Sites - Regions - Tenants - Manufacturers - Providers You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that.

adam commented

2025-12-29 16:28:52 +01:00

@adamkf commented on GitHub (Mar 12, 2020):

@ryanmerolle: I agree this relationship might be useful across multiple object relationships. We managed a couple thousand internal subnets in our org and currently use custom fields to assign ownership responsibility for given subnets (eg: Network Team, Dev Team 1, Dev Team 88, Individual Person 23, etc) so when our security group reaches out and says "who owns this infected machine" we have a starting point.

This FR has been around since 2017. Has anyone made progress toward it? I'm happy to throw my time at as we have a need internally.

@adamkf commented on GitHub (Mar 12, 2020): @ryanmerolle: I agree this relationship might be useful across multiple object relationships. We managed a couple thousand internal subnets in our org and currently use custom fields to assign ownership responsibility for given subnets (eg: Network Team, Dev Team 1, Dev Team 88, Individual Person 23, etc) so when our security group reaches out and says "who owns this infected machine" we have a starting point. This FR has been around since 2017. Has anyone made progress toward it? I'm happy to throw my time at as we have a need internally.

adam commented

2025-12-29 16:28:52 +01:00

@athompson-merlin commented on GitHub (Mar 27, 2020):

FWIW, I don't need extended contact capabilities on Sites, but I do desperately need Contacts on Tenants instead.
Having an optional Contact[s] object attachable to every top-level object would be ideal, who knows where I might need to hang contact information someday.

@athompson-merlin commented on GitHub (Mar 27, 2020): FWIW, I don't need extended contact capabilities on Sites, but I do desperately need Contacts on *Tenants* instead. Having an optional Contact[s] object attachable to every top-level object would be ideal, who knows where I might need to hang contact information someday.

adam commented

2025-12-29 16:28:52 +01:00

@jorp commented on GitHub (Jul 2, 2021):

Would it be too much of a hassle to be able to bring contact information in from LDAP? Setting a contact as a specific user or group would be pretty beneficial.

@jorp commented on GitHub (Jul 2, 2021): Would it be too much of a hassle to be able to bring contact information in from LDAP? Setting a contact as a specific user or group would be pretty beneficial.

adam commented

2025-12-29 16:28:52 +01:00

@pisaniej commented on GitHub (Aug 30, 2021):

What kind of relationship would a Contact have to an object?

For example, would virtualization.VirtualMachine be able to have multiple Contacts? I could see this being useful for an internal contact relating to an object, along with adding another for external vendor information.

@pisaniej commented on GitHub (Aug 30, 2021): What kind of relationship would a Contact have to an object? For example, would `virtualization.VirtualMachine` be able to have multiple Contacts? I could see this being useful for an internal contact relating to an object, along with adding another for external vendor information.

adam commented

2025-12-29 16:28:52 +01:00

@jeremystretch commented on GitHub (Oct 15, 2021):

There are several themes in the discussion above that are important to identify individually:

Being able to reuse contact information for multiple objects without duplication
Being able to assign a contact to objects other than sites
Being able to assign multiple contacts for a single object
Conveying the nature of an assigned contact as it relates to the object (e.g. technical contact vs organizational owner)

I also want to highlight something @ryanmerolle pointed out:

You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that.

It's important to recognize that NetBox's function is not to serve as a corporate directory. Our goal here is to efficiently convey contact information for a subset of existing object types within NetBox and nothing more.

In the interest of moving forward with this feature, I'd like to propose an implementation. First, we would introduce a new Contact model within the tenancy app, with the following fields:

Name
Title
Address
Phone number
Email
Comments

Because we want to be able to reuse contacts among objects, and because we want the ability to associate multiple contacts with an object, it makes sense to model these as many-to-many relationships with an interim "through" model indicating the nature of the relationship. Although not the best-performing option, this will grant us the greatest amount of flexibility.

Then, there's the open question of which NetBox models can have contacts associated with them. We could take a more liberal approach and enable contact assignment for all primary and organizational models (essentially the "meat" of NetBox). However, we also need to bear in mind the imposed overhead, particularly because we're dealing with many-to-many relationships: Each relationships between the Contact model and another model effects a new SQL table to track the M2M assignments. There are performance implications for the REST API as well, if we decide to return associated contacts for each object.

@jeremystretch commented on GitHub (Oct 15, 2021): There are several themes in the discussion above that are important to identify individually: 1. Being able to reuse contact information for multiple objects without duplication 2. Being able to assign a contact to objects other than sites 3. Being able to assign multiple contacts for a single object 4. Conveying the nature of an assigned contact as it relates to the object (e.g. technical contact vs organizational owner) I also want to highlight something @ryanmerolle pointed out: > You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that. It's important to recognize that NetBox's function is not to serve as a corporate directory. Our goal here is to efficiently convey contact information for a subset of existing object types within NetBox and nothing more. In the interest of moving forward with this feature, I'd like to propose an implementation. First, we would introduce a new Contact model within the tenancy app, with the following fields: - Name - Title - Address - Phone number - Email - Comments Because we want to be able to reuse contacts among objects, and because we want the ability to associate multiple contacts with an object, it makes sense to model these as many-to-many relationships with an interim "through" model indicating the nature of the relationship. Although not the best-performing option, this will grant us the greatest amount of flexibility. Then, there's the open question of which NetBox models can have contacts associated with them. We _could_ take a more liberal approach and enable contact assignment for all primary and organizational models (essentially the "meat" of NetBox). However, we also need to bear in mind the imposed overhead, particularly because we're dealing with many-to-many relationships: Each relationships between the Contact model and another model effects a new SQL table to track the M2M assignments. There are performance implications for the REST API as well, if we decide to return associated contacts for each object.

adam commented

2025-12-29 16:28:53 +01:00

@tb-killa commented on GitHub (Oct 15, 2021):

One idea would be:
add Contacts and Contact-Group Model.
Contacts would be Persons like Jeremy mentioned. For another easier way it would be great if Contacts also selectable Users from NetBox.
Contact-Groups are Groups who could be Named and who could be filled with needing Contacts.
For the best affort it would be great if we could assign Contacts and or Groups to All needing Models inside Netbox.

@tb-killa commented on GitHub (Oct 15, 2021): One idea would be: add Contacts and Contact-Group Model. Contacts would be Persons like Jeremy mentioned. For another easier way it would be great if Contacts also selectable Users from NetBox. Contact-Groups are Groups who could be Named and who could be filled with needing Contacts. For the best affort it would be great if we could assign Contacts and or Groups to All needing Models inside Netbox.

adam commented

2025-12-29 16:28:53 +01:00

@jeremystretch commented on GitHub (Oct 18, 2021):

So, I burned an entire day on this, but here's what I ended up doing:

ContactGroup - Self-nesting organizational model for contacts (similar to SiteGroup)
Contact - Represents a reusable set of contact info (name, title, phone, email, etc.)
ContactRole - Functional role of the relationship between a contact and an object in NetBox
ContactAssignment - Binds a mapping of object, contact, and role; also conveys priority

Contact assignments employ generic foreign keys (similar to image attachments) to avoid imposing too much overhead. This allows us to assign contacts to a bunch of models without needing to create additional tables.

I'm sure it still needs a bit of cleanup, but I feel this is a reasonable approach that fulfills all four use cases I identified in my previous comment. The biggest hindrance at the moment is probably that you can't create and assign a contact in one go: the contact must be created first, and can then be assigned to objects. I'm sure we can accommodate a more convenient workflow, but it may require refactoring the generic ObjectEditView first.

@jeremystretch commented on GitHub (Oct 18, 2021): So, I burned an entire day on this, but here's what I ended up doing: * ContactGroup - Self-nesting organizational model for contacts (similar to SiteGroup) * Contact - Represents a reusable set of contact info (name, title, phone, email, etc.) * ContactRole - Functional role of the relationship between a contact and an object in NetBox * ContactAssignment - Binds a mapping of object, contact, and role; also conveys priority Contact assignments employ generic foreign keys (similar to image attachments) to avoid imposing too much overhead. This allows us to assign contacts to a bunch of models without needing to create additional tables. I'm sure it still needs a bit of cleanup, but I feel this is a reasonable approach that fulfills all four use cases I identified in my previous comment. The biggest hindrance at the moment is probably that you can't create and assign a contact in one go: the contact must be created first, and can then be assigned to objects. I'm sure we can accommodate a more convenient workflow, but it may require refactoring the generic ObjectEditView first.

adam commented

2025-12-29 16:28:53 +01:00

@DanSheps commented on GitHub (Oct 18, 2021):

And here I was thinking I was going to take care of contact objects. Guess you beat me too it...

@DanSheps commented on GitHub (Oct 18, 2021): And here I was thinking I was going to take care of contact objects. Guess you beat me too it...

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#1100