The schedule you built (cmn_schedule_maintenance with "Applies to = IP Switch", "Source = CI Class", and a condition on Operational Status) is the class/condition-driven mechanism used purely by Change Conflict Detection. When someone raises a Change against a switch and clicks "Check Conflicts," the platform evaluates at that moment whether the switch matches your condition, it never writes anything back to the CI record itself. There's no field-population step involved; it's a runtime lookup, not a link.
The "Maintenance schedule" column you see empty on the IP Switch list is a completely different thing — it's a direct reference field (maintenance_schedule) on the CI that points to the cmn_schedule table (a Schedule record with Type = Maintenance), not to cmn_schedule_maintenance at all. This field is populated by manually selecting a schedule on each CI (or via a script/import), there is no OOB automation that takes your class+condition rule and back-fills this field on matching CIs.
So you haven't done anything wrong technically, you've just built the condition-based schedule correctly for its intended purpose, but that purpose was never "populate a field on the CI." Both mechanisms are documented as intentionally separate: one for dynamic conflict evaluation, one for direct CI-level assignment.
If your goal is Change Conflict Detection working correctly (most likely case, since you're using "Applies to CI class + condition"):
- You don't need to fix anything on the CI records, this is expected behavior.
- Just confirm the system property change.conflict.currentwindow is set to true (this is what tells Conflict Detection to actually consult cmn_schedule_maintenance records).
- Test it: raise a test Change against a switch with Operational Status = Operational, use "Check Conflicts," and confirm it correctly flags/clears based on your schedule window.
If your goal is to see the "Maintenance schedule" field populated on each switch (e.g., for reporting, CI form visibility, or other logic that reads that field):
- You'll need actual cmn_schedule records with Type = Maintenance, then reference them directly in the maintenance_schedule field on each CI, either manually, via a bulk list edit, or an import/update set.
- There's no native "apply to class X where condition Y" auto-fill for this field. If you want that behavior, it would require a custom Business Rule or Scheduled Job (on insert/update of cmdb_ci_ip_switch) that checks your condition and sets maintenance_schedule accordingly — this isn't something ServiceNow does out of the box today.
If all you care about is conflict detection working (not the field visually showing on the list), you're likely already done, the empty column is a red herring, not a bug.
