Best practices and examples

Use these recommendations and examples to manage custom properties consistently and avoid unexpected results.

Custom properties support multiple workflows, including filtering, rules, automation, reporting, and storing customer or device information. The best approach depends on what the property stores, where the value applies, and how the value will be used.

Create custom properties at the SO level when possible

Create custom properties at the Service Organization (SO) level to manage them from a single location. Creating properties at lower levels, including customer or site, can support specific exceptions but makes properties harder to consistently manage.

Example

You want to create a Service Tier property used across multiple customers. Create the property at the SO level to manage it centrally, then apply or update the value for the relevant customers.

Use device classes for broad device targeting

When creating device custom properties, use Device Classes to apply the property to broad groups of devices, including workstations, laptops, or servers.

Use Operating Systems when the property must only apply to specific operating system versions.

Example

You want to store a maintenance window value for all servers.

Create a device custom property and apply it to the Server device class. This makes the property available to all server devices without creating separate properties for each operating system.

Use drop-down lists for controlled values

Use drop-down list properties when users must choose from a defined set of values. Drop-down lists help prevent typos and inconsistent values, especially when custom properties are used in filters, rules, or automation.

Example

You want to group devices by maintenance window.

Create a drop-down list property with values for example:

  • Not defined

  • Monday 3 AM

  • Wednesday 5 AM

  • Friday 1 AM

You can then create filters to target devices based on the selected maintenance window value.

Drop-down values and scope

If a drop-down list custom property is created at a higher level and made available to lower levels, users at those levels can:

  • Add values visible only to that level.
  • Edit the values they create.
  • Set a default value from the available options.

Use placeholder values when helpful

Use a default or placeholder value to support filtering, reporting, or exports. For example, values like Not defined, None, or Null can make it easier to identify non-updated properties.

If an automation policy will populate the value later, leave the default value blank or use a placeholder based on how you plan to filter or report on missing values.

Example

You create a custom property named Patch Group.

Set the default value to Not defined. After review, update the value to Group A, Group B, or Group C.

Create a filter where Patch Group = Not defined to identify devices still needing a value.

Review filters and rules before changing values

Filters are dynamic. Changing a custom property value can affect rules or automation using it. Before changing values, review any filters, rules, scheduled tasks, or automation policies that depend on the custom property.

Example

If you update a device from Not defined to Friday 1 AM, the device matches the filter and becomes part of the rule target group. Once the device matches the filter, it is associated with the rule and its settings. Changes affecting filter membership cause rules using those filters to reprocess on the next run.

Use Save and Propagate carefully

Use Save and Propagate only when the updated value should apply across multiple devices, sites, or customers. This action updates those targets and can overwrite existing values.

Example

You update a customer-level property from Standard to Premium.

Before using Save and Propagate, confirm all affected customers, sites, or devices should receive the same value. If some values should remain different, update only the intended targets.

Use password properties for hidden or sensitive values

Use password custom properties to hide values from users who do not need to view them, including keys or sensitive configuration data.

Example

You need to store a customer-specific installation key used by an automation policy.

Create a password custom property so the value can be used by automation without exposing it in standard custom property fields.

Use custom properties as automation inputs and outputs

Automation policies can use custom property values as inputs or update them as outputs.

Use this approach when automation needs to read customer-specific or device-specific values, or to store collected data in N-central.

Example: Use a custom property as an automation input

You have an automation policy to install software and requires a customer-specific installation key. Store the key in a customer custom property, then configure the automation policy to use it as an input.

Example: Use a custom property as an automation output

You have an automation policy that collects a device value.

Configure the policy to write the result to a device custom property. After the policy runs, the value is available in custom properties and can be used in filters, rules, or reporting.

Use custom properties to target filters, rules, and automation

Custom properties help target filters, rules, and automation based on specific criteria.

Example

You want to run automation only on devices assigned to a specific location.

  1. Create or update a custom property: Location.

  2. Assign values: Dundee or Ottawa.

  3. Navigate to Configuration > Filters.

  4. Create a filter where Location = Dundee.

  5. Use the filter in a rule or automation workflow.

The rule or automation applies only to devices that match the value.

Use custom properties to store business information

Custom properties can store business-specific information not available by default in N-central.

Examples include:

  • Location

  • Owner

  • Department

  • Service tier

  • Contract type

  • Compliance status

  • Maintenance window

Example

You want to track the service tier for each customer.

Create a customer custom property named Service Tier with values Gold, Silver, or Bronze. Use the value to group customers, support reporting, or target rules and automation based on the service level.

Summary

Use custom properties to store, classify, filter, and automate based on customer or device information.

For best results:

  • Create properties at the SO level when possible.

  • Use Device Classes for broad device targeting.

  • Use drop-down lists for controlled values.

  • Use placeholder values to support filtering and reporting.

  • Review filters and rules before changing values.

  • Use Save and Propagate only when the same value should apply across multiple targets.

  • Use password properties to store sensitive values.

  • Use custom properties as automation inputs and outputs.

Related articles