One tenant may require a cost centre, another an employee number, and a customer portal may need attributes that have no meaning in a workforce profile. A flexible identity platform should accommodate those needs without allowing arbitrary fields to become an unmanaged second policy system.
Separate schema flexibility from authority
Define which attributes are common, which belong to an identity class and which are tenant-specific. Document the source of truth, data type, validation rules and who may edit each field. If two systems can write the same value, set a priority and conflict rule.
A descriptive attribute can become security-sensitive when it drives employee classification, domain assignment, role eligibility or resource access. Classify fields by impact so a schema update triggers the right review and testing.
Validate data at trusted boundaries
Client-side validation improves usability but cannot protect the stored record by itself. Validate type, allowed values, length and normalisation on the server. Define how empty values, duplicates, renamed fields and older records should behave when tenants update their configuration.
Avoid using a user-controlled attribute as a trusted authorisation fact without verification. An email domain, department name or tenant label can be useful input, but it should not automatically grant privileges unless the policy and ownership model make that inference safe.
Govern access to the schema
Adding or redefining attributes can affect every record that uses them. Restrict schema changes, require approval for high-impact fields and retain an audit trail. Explain what happens to existing records when a field becomes required or changes type.
Tenant administrators may manage a limited set of tenant attributes while platform administrators define the overall schema and allowed types. Make this boundary explicit, especially when custom attributes are configured by an identity provider administrator.
Test migrations and downstream use
Before a schema change, test signup, profile updates, search, provisioning, access reviews and integrations that consume the attribute. Verify older records that do not contain the new field. A schema that works for new users may still break a long-lived tenant.
Maintain a field catalogue with purpose, owner, source, validation, access restrictions and downstream consumers. This makes reviews easier and helps teams decide whether an attribute should be retained or retired.
Questions worth asking
Document purpose, source, type and editor for every custom field?
Validate values server-side and define migration behaviour?
Review attributes that influence classification or authorisation?
Test all downstream consumers before changing the schema?