Custom Fields Specific to Device Types in Netbox #7977

New Issue

adam · 2025-12-29T20:30:41+01:00

adam commented

2025-12-29 20:30:41 +01:00

Originally created by @chesronw on GitHub (May 2, 2023).

NetBox version

v3.5.0

Feature type

Change to existing functionality

Proposed functionality

I would like to request a new feature for Netbox that would allow us to add custom fields specific to a device type. Currently, we can add custom fields to all devices, but we would like to have more control over which devices have these fields.

The reason for this feature request is that we have different types of devices in our network, such as servers, access points, and switches, and we only want certain custom fields to appear on specific device types. For example, we may want to add a custom field for server rack unit or switch port status, but we don't want these fields to appear on access points.

Having this feature would make it easier for us to manage our network inventory and reduce clutter on the interface. It would also help ensure that we have the necessary information for each device type without having to scroll through irrelevant custom fields.

Thank you for considering this feature request. We believe it would greatly enhance the functionality and usability of Netbox.

Use case

Imagine a company that has a large network with different types of devices, including switches, routers, servers, and access points. The IT team wants to track specific information for each device type but wants to avoid cluttering the interface with irrelevant custom fields.

For example, they want to track support levels for switches and routers, but not for servers and access points. They also want to track SQL licenses for servers but not for other devices.

Without the ability to add custom fields specific to device types, the IT team would need to add all custom fields to all devices, leading to a cluttered interface and potential errors.

With the proposed feature, the IT team can define custom fields for each device type. This allows them to easily track support levels for switches and routers, SQL licenses for servers, and firmware version for access points, while avoiding clutter on devices where these fields are not relevant.

Overall, the proposed feature would provide greater flexibility and control in managing custom fields for different types of devices, allowing IT teams to track specific information efficiently without cluttering the interface.

Database changes

No response

External dependencies

No response

Originally created by @chesronw on GitHub (May 2, 2023). ### NetBox version v3.5.0 ### Feature type Change to existing functionality ### Proposed functionality I would like to request a new feature for Netbox that would allow us to add custom fields specific to a device type. Currently, we can add custom fields to all devices, but we would like to have more control over which devices have these fields. The reason for this feature request is that we have different types of devices in our network, such as servers, access points, and switches, and we only want certain custom fields to appear on specific device types. For example, we may want to add a custom field for server rack unit or switch port status, but we don't want these fields to appear on access points. Having this feature would make it easier for us to manage our network inventory and reduce clutter on the interface. It would also help ensure that we have the necessary information for each device type without having to scroll through irrelevant custom fields. Thank you for considering this feature request. We believe it would greatly enhance the functionality and usability of Netbox. ### Use case Imagine a company that has a large network with different types of devices, including switches, routers, servers, and access points. The IT team wants to track specific information for each device type but wants to avoid cluttering the interface with irrelevant custom fields. For example, they want to track support levels for switches and routers, but not for servers and access points. They also want to track SQL licenses for servers but not for other devices. Without the ability to add custom fields specific to device types, the IT team would need to add all custom fields to all devices, leading to a cluttered interface and potential errors. With the proposed feature, the IT team can define custom fields for each device type. This allows them to easily track support levels for switches and routers, SQL licenses for servers, and firmware version for access points, while avoiding clutter on devices where these fields are not relevant. Overall, the proposed feature would provide greater flexibility and control in managing custom fields for different types of devices, allowing IT teams to track specific information efficiently without cluttering the interface. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature status: under review labels 2025-12-29 20:30:41 +01:00

adam closed this issue

2025-12-29 20:30:42 +01:00

adam commented

2025-12-29 20:30:42 +01:00

@stavr666 commented on GitHub (May 2, 2023):

For example, they want to track support levels for switches and routers, but not for servers and access points. They also want to track SQL licenses for servers but not for other devices.

I'm trying to understand your scenarios, but it seems not really practical.
From my PoV, most users of Netbox implement it as source of tracking different approaches and/or automate some (or most) processes.
Your FR looks like you have exceptional basic-level scenarios for small teams, where you put some staff in netbox "just in case someone asks".

For tracking support levels, attached licenses (isn't any software management already include this kind of process?) etc., you can use right now:

Comments section with pre-defined structure
Tags with attached config contexts
Individual config context
Custom fields with JSON type and regex-validator to check if it have only required fields

All of them can be parsed by external software and remove your concerns about bunch of empty custom fields.

Also, why your scenario include only devices? Why similar conditions not applied to Clusters and VMs, or even IP addresses and prefixes. They also can have conditional requirements for extended information.

If some of your scenario make sense for other Netbox users, I'll prefer FR with "hide when not defined" toggle for all CFs. This way you can throw as much fields as you like, use it as wide as current implementation, but have more clean view of objects, than existing:

@stavr666 commented on GitHub (May 2, 2023): > For example, they want to track support levels for switches and routers, but not for servers and access points. They also want to track SQL licenses for servers but not for other devices. I'm trying to understand your scenarios, but it seems not really practical. From my PoV, most users of Netbox implement it as source of tracking different approaches and/or automate some (or most) processes. Your FR looks like you have exceptional basic-level scenarios for small teams, where you put some staff in netbox "just in case someone asks". For tracking support levels, attached licenses (isn't any software management already include this kind of process?) etc., you can use right now: - Comments section with pre-defined structure - Tags with attached config contexts - Individual config context - Custom fields with JSON type and regex-validator to check if it have only required fields All of them can be parsed by external software and remove your concerns about bunch of empty custom fields. Also, why your scenario include only devices? Why similar conditions not applied to Clusters and VMs, or even IP addresses and prefixes. They also can have conditional requirements for extended information. If some of your scenario make sense for other Netbox users, I'll prefer FR with "hide when not defined" toggle for all CFs. This way you can throw as much fields as you like, use it as wide as current implementation, but have more clean view of objects, than existing: ![image](https://user-images.githubusercontent.com/84839985/235706078-7e5f602e-fcb0-4959-9886-d9046f120077.png)

adam commented

2025-12-29 20:30:44 +01:00

@ITJamie commented on GitHub (May 2, 2023):

I would also like to see this, to be more specific to be able to limit custom fields to objects with specific "roles".

From an backend pov, all "device" custom fields would exist on all devices, however the view and edit forms should only show those fields for devices with that particular role.

It would allow for sanitisation of the edit and view screens, to make them more user friendly.

from an API / automation POV it wouldnt matter that those fields exist

@ITJamie commented on GitHub (May 2, 2023): I would also like to see this, to be more specific to be able to limit custom fields to objects with specific "roles". From an backend pov, all "device" custom fields would exist on all devices, however the view and edit forms should only show those fields for devices with that particular role. It would allow for sanitisation of the edit and view screens, to make them more user friendly. from an API / automation POV it wouldnt matter that those fields exist

adam commented

2025-12-29 20:30:46 +01:00

@jeremystretch commented on GitHub (May 5, 2023):

I'm afraid you're trying to squeeze too much functionality out of custom fields. Custom fields are a convenience afforded for situations where you need to store some extra data with objects that isn't accommodated by the built-in fields. They are a compromise which stops short of actually manipulating underlying database table schema, providing a degree of flexibility offset by several limitations.

This approach works okay for what it is, but absolutely will not scale to support conditional logic. You would essentially be attempting to replicate relational database functionality entirely within the application, rather than in the database built expressly for that purpose.

The only feasible, scalable, maintainable solution for the cited use case is to introduce a purpose-built model delivered via a plugin, with a proper schema and relational fields to perform as needed. This is actually quite easy to do (check out our plugin tutorial) and will easily deliver a much higher ROI than trying to hack something together with custom fields.

@jeremystretch commented on GitHub (May 5, 2023): I'm afraid you're trying to squeeze too much functionality out of custom fields. Custom fields are a convenience afforded for situations where you need to store some extra data with objects that isn't accommodated by the built-in fields. They are a compromise which stops short of actually manipulating underlying database table schema, providing a degree of flexibility offset by several limitations. This approach works _okay_ for what it is, but absolutely will not scale to support conditional logic. You would essentially be attempting to replicate relational database functionality entirely within the application, rather than in the database built expressly for that purpose. The only feasible, scalable, maintainable solution for the cited use case is to introduce a purpose-built model delivered via a plugin, with a proper schema and relational fields to perform as needed. This is actually quite easy to do (check out our [plugin tutorial](https://github.com/netbox-community/netbox-plugin-tutorial)) and will easily deliver a much higher ROI than trying to hack something together with custom fields.

adam commented

2025-12-29 20:30:47 +01:00

@chesronw commented on GitHub (May 8, 2023):

I understand your point, but I still think that having the ability to show or hide custom fields on specific devices or objects would be a useful feature for many users. While custom fields may have limitations, they are still a valuable tool for storing extra data, and adding conditional logic would only enhance their functionality.

Additionally, while creating a separate plugin for this purpose may be feasible, it would require users to install and maintain yet another plugin, which may not be ideal for everyone. By integrating this feature into the core functionality, it would be easier for users to manage and use.

Overall, I believe that adding the ability to show or hide custom fields based on specific criteria would be a valuable addition to the platform, and would benefit many users.

@chesronw commented on GitHub (May 8, 2023): I understand your point, but I still think that having the ability to show or hide custom fields on specific devices or objects would be a useful feature for many users. While custom fields may have limitations, they are still a valuable tool for storing extra data, and adding conditional logic would only enhance their functionality. Additionally, while creating a separate plugin for this purpose may be feasible, it would require users to install and maintain yet another plugin, which may not be ideal for everyone. By integrating this feature into the core functionality, it would be easier for users to manage and use. Overall, I believe that adding the ability to show or hide custom fields based on specific criteria would be a valuable addition to the platform, and would benefit many users.

adam commented

2025-12-29 20:30:47 +01:00

@jeremystretch commented on GitHub (May 8, 2023):

I understand your point

I'm sorry but I don't think you do.

I still think that having the ability to show or hide custom fields on specific devices or objects would be a useful feature for many users

I'm not arguing that it wouldn't be useful, if it was feasible. I'm arguing that it's not feasible.

Additionally, while creating a separate plugin for this purpose may be feasible, it would require users to install and maintain yet another plugin, which may not be ideal for everyone.

Neither would trying to hack together a solution using custom fields, but the plugin approach is at least well-supported and maintainable.

@jeremystretch commented on GitHub (May 8, 2023): > I understand your point I'm sorry but I don't think you do. > I still think that having the ability to show or hide custom fields on specific devices or objects would be a useful feature for many users I'm not arguing that it wouldn't be useful, if it was feasible. I'm arguing that it's not feasible. > Additionally, while creating a separate plugin for this purpose may be feasible, it would require users to install and maintain yet another plugin, which may not be ideal for everyone. Neither would trying to hack together a solution using custom fields, but the plugin approach is at least well-supported and maintainable.

adam commented

2025-12-29 20:30:47 +01:00

@JoeIzzard commented on GitHub (May 10, 2023):

I'd argue it's more feasible and maintainable for this to be tackled at the core level instead of requiring us to develop a plugin per device type.

We have a large selection of device types that would benefit from custom fields being tied to them. This is something we have had in asset management systems for a while. For example, I know this isn't what Netbox is designed or aimed at but it a clear example from our organisation, we have large dimmer rooms handling power to a number of devices. This may mean a dimmer is powering a switch etc. The dimmer is made from modules, these modules don't have a serial number for the assembly, instead we need to record:

Controller Serial
Controller Revision
RCD Serial
RCD Part Number
RCD Revision
RCD Production Date

I could model this in Netbox, but would then be stuck with those fields appearing on my switch.

Adding/Modifying a field in the custom field schema to link to device type through a list would allow us to specify which device types a custom field applies to. For ease, the field is displayed in the UI if it is present in the list, or has a value assigned. It could also be schema'd so that the device type is what has the link to custom fields which would reduce lookup time.

I don't know tons about the Netbox schema so can't say that those ideas would 100% work but there are almost certainly ways we could handle this better that requiring 100s of plugins.

Happy to put together a more complete proposal if you can point me to any info on the current Schema etc.

@JoeIzzard commented on GitHub (May 10, 2023): I'd argue it's more feasible and maintainable for this to be tackled at the core level instead of requiring us to develop a plugin per device type. We have a large selection of device types that would benefit from custom fields being tied to them. This is something we have had in asset management systems for a while. For example, I know this isn't what Netbox is designed or aimed at but it a clear example from our organisation, we have large dimmer rooms handling power to a number of devices. This may mean a dimmer is powering a switch etc. The dimmer is made from modules, these modules don't have a serial number for the assembly, instead we need to record: - Controller Serial - Controller Revision - RCD Serial - RCD Part Number - RCD Revision - RCD Production Date I could model this in Netbox, but would then be stuck with those fields appearing on my switch. Adding/Modifying a field in the custom field schema to link to device type through a list would allow us to specify which device types a custom field applies to. For ease, the field is displayed in the UI if it is present in the list, or has a value assigned. It could also be schema'd so that the device type is what has the link to custom fields which would reduce lookup time. I don't know tons about the Netbox schema so can't say that those ideas would 100% work but there are almost certainly ways we could handle this better that requiring 100s of plugins. Happy to put together a more complete proposal if you can point me to any info on the current Schema etc.

adam commented

2025-12-29 20:30:47 +01:00

@jeremystretch commented on GitHub (May 10, 2023):

I'd argue it's more feasible and maintainable for this to be tackled at the core level instead of requiring us to develop a plugin per device type.

I can't imagine why you would possibly need a separate plugin per device type, and this assertion strongly suggests that you've not put real consideration into the idea.

I'm not going to burn any more time debating this. If you disagree with my take, I have a challenge for you: Try building it. Anyone qualified to debate the feasibility certainly must be capable of building a prototype implementation. Once that's done, and you've negated my concerns about performance, maintainability, and scale, you're welcome to submit a detailed implementation proposal for discussion.

@jeremystretch commented on GitHub (May 10, 2023): > I'd argue it's more feasible and maintainable for this to be tackled at the core level instead of requiring us to develop a plugin per device type. I can't imagine why you would possibly need a separate plugin per device type, and this assertion strongly suggests that you've not put real consideration into the idea. I'm not going to burn any more time debating this. If you disagree with my take, I have a challenge for you: Try building it. Anyone qualified to debate the feasibility certainly must be capable of building a prototype implementation. Once that's done, and you've negated my concerns about performance, maintainability, and scale, you're welcome to submit a detailed implementation proposal for discussion.

adam commented

2025-12-29 20:30:47 +01:00

@chesronw commented on GitHub (May 10, 2023):

@jeremystretch thanks for your time!
The whole idea behind it was to make Netbox better with this idea.

No problem! we are going to take a look how we can fix this internally without having an extra documentation tooling beside Netbox.

@chesronw commented on GitHub (May 10, 2023): @jeremystretch thanks for your time! The whole idea behind it was to make Netbox better with this idea. No problem! we are going to take a look how we can fix this internally without having an extra documentation tooling beside Netbox.

adam commented

2025-12-29 20:30:47 +01:00

@JoeIzzard commented on GitHub (May 10, 2023):

@jeremystretch i May have misunderstood your suggestion to use plugins then. It came across to me as a suggestion to have a plug-in for each device type that handles the custom fields for that device type.

Are you instead suggesting a plug-in that is essentially just custom fields but with the ability to link them to device types?

I'm more than happy to build a prototype and work with you and team to actually see if it is feasible, hence why I offered to put together a more comprehensive Schema and implementation suggestion, to suggest that because I'm interested in the feature I must be unqualified to implement it is rude and not really very fitting of an open source project.

@JoeIzzard commented on GitHub (May 10, 2023): @jeremystretch i May have misunderstood your suggestion to use plugins then. It came across to me as a suggestion to have a plug-in for each device type that handles the custom fields for that device type. Are you instead suggesting a plug-in that is essentially just custom fields but with the ability to link them to device types? I'm more than happy to build a prototype and work with you and team to actually see if it is feasible, hence why I offered to put together a more comprehensive Schema and implementation suggestion, to suggest that because I'm interested in the feature I must be unqualified to implement it is rude and not really very fitting of an open source project.

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#7977