IOrganizationPartyManagementPATCH Apex Interface
The IOrganizationPartyManagementPATCH 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.
This interface supports the following hooks.
- transformRequest
- configureDefaultValidations
- applyCustomValidations
- customiseMutationPayload
- handlePostOperation
| Use Case | Hook(s) | Description | Example Scenarios | Benefit |
|---|---|---|---|---|
| Block Updates to Protected Fields | transformRequest | Examines and transforms the request before validation and mutation processing. Protected, read-only, or unauthorized fields can be removed from the update payload before the write occurs. | - Remove system-managed Account identifiers - Prevent clients from changing ownership fields - Strip restricted financial or compliance attributes - Remove fields that are read-only for the caller’s role | Protects controlled Account fields by stripping disallowed values before they can be persisted. |
| Enforce Value Policies on Update | applyCustomValidations | Applies organization-specific business rules to proposed Account field values before the update mutation is built. Invalid updates are rejected with an HTTP 400 response and a clear error message. | - Reject invalid Account lifecycle transitions - Enforce permitted values for type, status, or segment - Require dependent fields when Account status changes - Prevent updates that violate regional policies | Rejects invalid updates early and preserves business, compliance, and data integrity. |
| Add Custom Validation Flags | configureDefaultValidations | Enables, disables, or adds validation flags for Account update requests according to organization-specific policies. | - Require Account-existence validation - Enable optimistic concurrency or version checks - Require additional validation for protected Accounts - Apply stricter checks 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 Account update. | - Add lastModifiedBy and lastModifiedAt- Record the source channel or integration - Store a request or correlation ID - Capture the reason for the Account update | Persists provenance and audit information beyond the standard TMF632 data model. |
| Audit or Integrate After Update | handlePostOperation | Runs after the update mutation completes and performs post-operation side effects using the update result. It can write audit records, publish events, or invoke downstream integrations. | - Write an Account-update audit record - Publish an Account-updated event - Synchronize changes with billing or CRM systems - Invalidate related caches or search indexes - Trigger compliance or notification workflows | Enables reliable auditing and downstream processing after a successful update while keeping side effects separate from the core mutation. |
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.
Map<String, Object> transformRequest(Map<String, Object> context)
Prevent updates to name.
This hook enables, disables, or modifies the built-in validation rules before they execute.
Map<String, Boolean> configureDefaultValidations(Map<String, Boolean> defaultValidationConfiguration, Map<String, Object> context)
Add a custom flag consumed by 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)
- The client receives an HTTP 400 error response.
Map<String, Object> applyCustomValidations(Map<String, Object> context)
Guard an organizationType transition.
This hook modifies the GraphQL query before execution to add fields, filters, or transformations.
Map<String, Object> customiseMutationPayload(Map<String, Object> graphQLAsMap,Map<String, Object> context)
Stamp an audit field on update.
This hook post-processes and transforms the API response after data retrieval.
Map<String, Object> handlePostOperation(Map<String, Object> graphQLQueryResultAsMap, Map<String, Object> constructedTMFResponse, Map<String, Object> context)
Enrich the response in place.
Here’s a complete sample Apex implementation using all supported hooks.