Skip to content
AM

Editing custom field values on records

After a substrate field is declared, an agent or authorized integration can set its value through the generic record-write surface. The current Customer 360 contact detail page displays record data but does not provide a substrate custom-field editor.

Edit with an agent

Use inblack_update_record and provide the entity type, record ID, and custom-field patch. The tool merges the supplied values; it does not replace every custom field on the record.

Before approving the write, verify:

  • The entity type and record ID identify the intended record.
  • Every key is already declared in the active schema.
  • Picklist and multi-select values match the declared options.
  • Date values use YYYY-MM-DD or RFC 3339.
  • Formula fields are omitted because they are computed.

The write fails as a unit if a supplied value is unknown or invalid. It does not partially apply valid fields.

Required fields

Required fields are enforced on full record creation. A partial update may omit a required field because the stored value remains. Setting a required field to an empty value fails validation.

This enforcement is in the write boundary, not only in a form or browser control.

Bulk corrections

There is no generic csv_import MCP tool for substrate custom-field updates. Pillar-specific import tools do not imply a generic custom-field import contract.

For bulk corrections, use an authorized integration that calls the supported record-write path per record, records failures, and can resume safely. Test the transformation against a small set first, especially after a breaking schema change.

Product-group fields

Commerce product-group field values follow the Commerce catalog workflow instead of inblack_update_record. Confirm which custom-field system owns the declaration before editing values.