The IIndividualPartyManagementPATCH Apex interface provides extensibility for PATCH operations through Apex pre- and post-hooks and GraphQL query customization. Implementations can validate incoming requests, modify query structures, and refine the response to support business-specific retrieval rules while maintaining TMF-compliant behavior.
Examines and transforms the request before validation and mutation processing. Protected or unauthorized fields can be removed from the update payload before the write occurs.
- Remove system-managed identifiers - Prevent clients from changing ownership fields - Strip restricted financial or security attributes - Remove fields that are read-only for the caller’s role
Protects controlled fields by stripping disallowed values before they can be persisted.
Enforce Value Policies on Update
applyCustomValidations
Applies organization-specific business rules to proposed field values before the update mutation is built. Invalid updates are rejected with an HTTP 400 response and a clear error message.
- Reject invalid lifecycle-state transitions - Enforce permitted ranges or enumerated values - Require dependent fields when status changes - Prevent updates that violate regional policies
Stops invalid updates early and preserves business and data integrity.
Add Custom Validation Flags
configureDefaultValidations
Enables, disables, or adds validation flags for update requests. This allows each organization to define the checks required before an update can proceed.
- Require record-existence validation - Enable optimistic concurrency checks - Require version matching - Apply stricter validation to regulated records
Supports per-organization update policies without changing the shared update implementation.
Stamp Audit Fields on Update
customiseMutationPayload
Adds audit and provenance fields to the GraphQL mutation payload before execution. This allows metadata beyond the TMF632 schema to be persisted with the update.
- Add lastModifiedBy and lastModifiedAt - Record the source channel or integration - Store a request or correlation ID - Capture the reason for the update
Persists provenance and audit information beyond the standard TMF632 data model.
Enrich the Update Response
handlePostOperation
Processes the mutation result before it is returned to the client. It can add calculated values, derived fields, audit metadata, or information obtained from related systems.
- Add a customer health score - Include update audit metadata - Return normalized display values - Add related status or eligibility indicators
Delivers a richer, more contextual response without modifying the underlying TMF632 schema.
transformRequest
This hook transforms the request context before processing any operation. It is invoked early in the request lifecycle, allowing implementers to adjust the context for subsequent extensibility hooks.
1global class IndividualPatchTransformRequestExt implements comms_apex_ext.IIndividualPartyManagementPATCH {234 global static Map<String, Object> transformRequest(Map<String, Object> context) {5 if (context != null && context.get('requestBody') instanceof Map<String, Object>) {6 Map<String, Object> body = (Map<String, Object>) context.get('requestBody');7 // Business rule: last name changes must go through a separate governance flow.8 body.remove('familyName');9 }10 return context;11 }121314 // ... other hooks return null / empty map ...15}
configureDefaultValidations
This hook enables, disables, or modifies the built-in validation rules before they execute.
Add a custom flag consumed by applyCustomValidations.
1global class IndividualPatchConfigValidationsExt implements comms_apex_ext.IIndividualPartyManagementPATCH {234 global static Map<String, Boolean> configureDefaultValidations(5 Map<String, Boolean> defaultValidationConfiguration,6 Map<String, Object> context7 ) {8 Map<String, Boolean> overrides = defaultValidationConfiguration != null9 ? defaultValidationConfiguration.clone()10 : new Map<String, Boolean>();11 overrides.put('emailDomainCheck', true); // your own flag, read in applyCustomValidations12 return overrides;13 }141516 // ... other hooks return null / empty map ...17}
applyCustomValidations
This hook validates custom business logic before retrieving customer record. If validation fails, it rejects the request and returns an error response.
The handler processes return values as follows.
Success:
Return a map with validationStatus set to “pass” (case-insensitive).
The API request continues normally.
Other fields in the map are logged but not used.
Failure:
Return a map with validationStatus set to “fail” (case-insensitive).
The API request is terminated immediately.
Raise a ValidationException containing
message: value from validationMessage key (or “Validation failed” by default)
details: value from validationDetails key (optional)