Adding custom sys_schema_attribute records

[ChristopherV430]

Hello,

I'm interested in managing custom application behaviour via custom table attributes.

I know this can just be done by editing the sys_dictionary.attributes field directly but I would like to improve maintainability for future developers/maintainers by instead adding an entry to sys_schema_attribute and using sys_schema_attribute_m2m entries, same as you'd see for OOTB attributes.

When creating a sys_schema_attribute record the above message shows:

"Schema attributes are a predefined set of elements that alter the behavior of the table or column they are applied to. New attributes cannot be created, but administrators can add or remove most attributes from the schema elements to which they are applied. More Info"

The More Info link doesn't go anywhere useful and the "New attributes cannot be created" message is clearly false.

My question is:

1) What is the purpose of this message?

2) Are there any reasons not to create "sys_schema_attribute" records, from what I can tell all it would do is provide context to any custom table/field attributes. What's the downside?

Apologies if this is the incorrect forum, unsure where to post such a general platform development question.

Thank you

[pavani_paluri]

Hi @ChristopherV430 ,

The message “New attributes cannot be created” is a bit misleading. It’s really a guardrail from ServiceNow to discourage admins from extending sys_schema_attribute in ways that aren’t officially supported. Schema attributes are meant to be a predefined set of behaviors that the platform itself recognizes (things like auto_number, can_read, etc.). The banner is there to remind you that these attributes are system‑defined and not guaranteed to work if you add your own.

Technically, you can create new records in sys_schema_attribute, and they’ll show up in the Admin Console and link via sys_schema_attribute_m2m. But the downsides are worth noting:
- They may not be recognized by all platform tooling (Studio, schema maps, automated testing).
- They could break or be ignored in future upgrades.
- ServiceNow Support may flag them as “unsupported customization.”
- Future developers might assume your custom attribute is out‑of‑the‑box and expect platform‑level behavior when it’s really just metadata you added.

If your goal is maintainability, the safer approach is either:
- Stick with sys_dictionary.attributes and document your custom flags clearly, or
- Create a separate custom metadata table to store application‑specific attributes. That way you get structured context without touching unsupported internals.

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for

Kind Regards,

Pavani P

[pavani_paluri]

Could you Please accept the solution if that answers your question.

Thanks,

Pavani

[frankapoth]

I am interested in adding attributes to an OOTB sys_dictionary record without modifying its attributes field. I want to avoid modifying the record itself for upgrade safety. If I were to add the attributes I want using the sys_schema_attribute_m2m table, would that be a safe and effective alternative? I'm a bit confused because there seems to be two ways to add attributes and I am not certain which approach is best practice.

[ChristopherV430]

Hey Frankapoth,

Unfortunately adding entries to sys_schema_attribute_m2m does trigger an update of the direct sys_dictionary.attributes field, so even if you use that table you're going to end up modifying the sys_dictionary table itself.

sys_schema_attribute and sys_schema_attribute_m2m seem to be just to simplify management, I believe all attribute checks just read the sys_dictionary itself at the end of the day so there's no way around modifying sys_dictionary.attributes, either directly on the OOTB table or by extending it.