CMDB Discovery Issue: Mandatory Attributes

[Kalpan2]

I have am encountering issue with Network Subnet discovery. The "glide.required.attribute.enabled" property is set to false, yet the Network Routing Device - Light pattern spits "Missing mandatory field(s) [owned_by,support_group] in table [cmdb_ci_ip_switch]. Add input value for mandatory field(s) in payload".

Any suggestions will be helpful.

[RK2]

Hi,
Please check if these attributes marked as mandatory at DB level or from CI class manager.

[Selva Arun]

Hi @Kalpan2 ,

The issue you're encountering with the Network Subnet discovery and the error regarding "Missing mandatory field(s) [owned_by, support_group] in table [cmdb_ci_ip_switch]" suggests that the discovery process is attempting to populate the cmdb_ci_ip_switch table, but the mandatory fields owned_by and support_group are not being provided in the payload.

Even though the glide.required.attribute.enabled property is set to false, this property only disables the enforcement of mandatory attributes at the platform level (e.g., when creating or updating records via the UI or API). However, patterns and discovery logic may still enforce mandatory fields as part of their design.

Here are some steps to troubleshoot and resolve the issue:

1. Verify the Mandatory Fields in the Table

Check the cmdb_ci_ip_switch table to confirm that owned_by and support_group are marked as mandatory fields. To do this:

• Navigate to System Definition > Tables in ServiceNow.
• Search for the cmdb_ci_ip_switch table.
• Open the table and review the owned_by and support_group fields to confirm if they are marked as mandatory.

If these fields are mandatory, you will need to provide values for them during discovery.

2. Update the Pattern to Provide Values for Mandatory Fields

The error indicates that the Network Routing Device - Light pattern is not providing values for the owned_by and support_group fields. To resolve this:

• Navigate to Discovery Patterns in ServiceNow.
• Search for the Network Routing Device - Light pattern.
• Open the pattern and review the Identification Section or Payload Section to check if the owned_by and support_group fields are being populated.
• If not, you can duplicate this pattern and turn off the OOB and make sure to migrate all the classes:
• Add logic to populate these fields with default values.
• Use variables or script steps to dynamically assign values based on your organization's requirements.

3. Set Default Values for Mandatory Fields

If you cannot modify the pattern or if the fields are not critical for your discovery process, you can set default values for the owned_by and support_group fields:

• Navigate to System Definition > Dictionary.
• Search for the owned_by and support_group fields in the cmdb_ci_ip_switch table.
• Add default values for these fields (e.g., a generic user or group).

This ensures that the discovery process does not fail due to missing values.

4. Check the Discovery Log for Additional Details

Review the discovery logs to gather more information about the failure:

• Navigate to Discovery > Status in ServiceNow.
• Open the discovery job that encountered the issue.
• Review the logs for the specific step where the error occurred.
• Look for additional details about why the fields are missing and whether the pattern is failing to retrieve the required data.

5. Consider Making the Fields Non-Mandatory

If the owned_by and support_group fields are not critical for your discovery process, you can make them non-mandatory:

• Navigate to System Definition > Dictionary.
• Search for the owned_by and support_group fields in the cmdb_ci_ip_switch table.
• Uncheck the Mandatory checkbox for these fields.

Note: This approach should only be used if these fields are not required for other processes or integrations.

6. Test the Discovery Process

After making the necessary changes, rerun the discovery process to ensure the issue is resolved:

• Navigate to Discovery > Discovery Schedules.
• Run the schedule which contains this IP Address.
• Monitor the discovery status and logs to confirm that the error no longer occurs.

7. Engage ServiceNow Support (if needed)

If the issue persists despite the above steps, it may be related to a bug or a specific configuration in your instance. In this case:

• Collect the discovery logs and pattern details.
• Open a case with ServiceNow Support for further assistance.

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration

Selva Arun