The IIndividualPartyManagementPOST Apex interface provides extensibility for POST 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.
Transforms the incoming request before validation and mutation processing. It can supply default values, normalize formats, and map client-specific fields to the canonical Account request structure.
- Apply a default Account status or type - Normalize names, phone numbers, and website URLs - Standardize country and region codes - Map legacy fields to TMF632 fields
Ensures consistent, standardized Account data at the point of creation.
Carry Custom Validation Flags
configureDefaultValidations
Adds organization-specific validation flags to the validation context. These flags are subsequently read by applyCustomValidations to determine which policies should be enforced for the create request.
Supports per-organization creation policies by carrying configurable validation flags into custom validation processing.
Enforce Custom Business Rules
applyCustomValidations
Reads the configured validation flags and evaluates organization-specific business rules before the Account mutation is built. Invalid payloads are rejected early with an HTTP 400 response and a clear validation message.
- Reject duplicate Accounts based on organization rules - Require registration details for business Accounts - Validate permitted Account types or lifecycle states - Require additional fields for specific regions
Rejects invalid payloads early and prevents inconsistent or noncompliant Account records from being created.
Set Organization-Specific Account Fields
customiseMutationPayload
Adds or modifies organization-specific Account fields in the GraphQL mutation payload before execution. This supports fields that extend beyond the standard TMF632 schema.
- Set an internal customer segment - Add a source-system identifier - Populate custom risk or compliance fields - Store organization-specific classification data
Persists custom Account fields beyond the TMF632 data model while preserving the shared API contract.
Audit or Integrate After Creation
handlePostOperation
Runs after the Account creation mutation completes and performs post-operation side effects using the creation result. It can write audit records, publish events, or invoke downstream integrations.
- Write an Account-creation audit record - Publish an Account-created event - Synchronize the Account with billing, CRM, or analytics systems - Trigger onboarding or compliance workflows
Enables reliable auditing and downstream processing after successful creation while keeping side effects separate from the core operation.
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.
Add a custom flag consumed by applyCustomValidations.
1global class OrganizationPostConfigValidationsExt implements comms_apex_ext.IOrganizationPartyManagementPOST {2 global static Map<String, Boolean> configureDefaultValidations(3 Map<String, Boolean> defaultValidationConfiguration,4 Map<String, Object> context5 ) {6 Map<String, Boolean> overrides = defaultValidationConfiguration != null7 ? defaultValidationConfiguration.clone()8 : new Map<String, Boolean>();9 overrides.put('nameUniquenessCheck', true); // your own flag, read in applyCustomValidations10 return overrides;11 }12 // ... other hooks return null / empty map ...13}
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)
1global class OrganizationPostValidationExt implements comms_apex_ext.IOrganizationPartyManagementPOST {2 private static final Set<String> ALLOWED_TYPES = new Set<String>{ 'Customer', 'Partner', 'Prospect' };3 global static Map<String, Object> applyCustomValidations(Map<String, Object> context) {4 Map<String, Object> result = new Map<String, Object>();5 if (!(context.get('requestBody') instanceof Map<String, Object>)) {6 return result;7 }8 Map<String, Object> body = (Map<String, Object>) context.get('requestBody');91011 Object typeObj = body.get('organizationType');12 if (typeObj instanceof String && !ALLOWED_TYPES.contains((String) typeObj)) {13 result.put('validationStatus', 'fail');14 result.put('validationMessage',15 'organizationType must be one of: Customer, Partner, Prospect.');16 }17 return result; // empty => proceed; validationStatus="fail" => HTTP 40018 }19 // ... other hooks return null / empty map ...20}
customiseMutationPayload
This hook modifies the mutation payload before deleting a customer record. Use this to add deletion metadata, set soft-delete flags, or apply business logic transformations.
1global class OrganizationPostHandlePostOpExt implements comms_apex_ext.IOrganizationPartyManagementPOST {2 global static Map<String, Object> handlePostOperation(3 Map<String, Object> graphQLQueryResultAsMap,4 Map<String, Object> constructedTMFResponse,5 Map<String, Object> context6 ) {7 // Read the created Account Id from the mutation result (organizationData alias).8 String newId = extractCreatedId(graphQLQueryResultAsMap);9 if (newId != null) {10 EventBus.publish(new Organization_Created__e(Account_Id__c = newId));11 }12 return null; // ignored for POST13 }141516 @SuppressWarnings('PMD')17 private static String extractCreatedId(Map<String, Object> resultMap) {18 try {19 Map<String, Object> data = (Map<String, Object>) resultMap.get('data');20 Map<String, Object> uiapi = (Map<String, Object>) data.get('uiapi');21 Map<String, Object> org = (Map<String, Object>) uiapi.get('organizationData');22 Map<String, Object> record = (Map<String, Object>) org.get('Record');23 return (String) record.get('Id');24 } catch (Exception e) {25 return null;26 }27 }28 // ... other hooks return null / empty map ...29}
Full Implementation Example
Here’s a complete sample Apex implementation using all supported hooks.
1/**2 * Complete TMF632 Organization (Party Management) POST API extension,3 * demonstrating all hooks with business logic.4 */5global class OrganizationPartyManagementPOSTExtension implements comms_apex_ext.IOrganizationPartyManagementPOST {678 private static final Set<String> ALLOWED_TYPES = new Set<String>{ 'Customer', 'Partner', 'Prospect' };91011 // Hook 1: normalize the request body.12 global static Map<String, Object> transformRequest(Map<String, Object> context) {13 if (context != null && context.get('requestBody') instanceof Map<String, Object>) {14 Map<String, Object> body = (Map<String, Object>) context.get('requestBody');15 if (body.get('organizationType') == null) {16 body.put('organizationType', 'Customer');17 }18 }19 return context;20 }212223 // Hook 2: the built-in checks are always enforced; return empty (no custom flags).24 global static Map<String, Boolean> configureDefaultValidations(25 Map<String, Boolean> defaultValidationConfiguration,26 Map<String, Object> context27 ) {28 return new Map<String, Boolean>();29 }303132 // Hook 3: enforce an approved organizationType.33 global static Map<String, Object> applyCustomValidations(Map<String, Object> context) {34 Map<String, Object> result = new Map<String, Object>();35 if (context.get('requestBody') instanceof Map<String, Object>) {36 Map<String, Object> body = (Map<String, Object>) context.get('requestBody');37 Object typeObj = body.get('organizationType');38 if (typeObj instanceof String && !ALLOWED_TYPES.contains((String) typeObj)) {39 result.put('validationStatus', 'fail');40 result.put('validationMessage',41 'organizationType must be one of: Customer, Partner, Prospect.');42 }43 }44 return result;45 }464748 // Hook 4: add custom Account fields to the create mutation.49 global static Map<String, Object> customiseMutationPayload(50 Map<String, Object> graphQLAsMap,51 Map<String, Object> context52 ) {53 Map<String, Object> node = new Map<String, Object>{54 'path' => 'organizationData',55 'addFields' => new Map<String, Object>{ 'Industry' => 'Telecommunications', 'AccountSource' => 'Web' }56 };57 return new Map<String, Object>{ 'nodes' => new List<Object>{ node } };58 }596061 // Hook 5: side effect only (return ignored).62 global static Map<String, Object> handlePostOperation(63 Map<String, Object> graphQLQueryResultAsMap,64 Map<String, Object> constructedTMFResponse,65 Map<String, Object> context66 ) {67 return null;68 }69}
Response Structure
Request Body
A TMF632 Individual create payload supports the following input fields:
Scalars:@type (must be Organization), name (required), organizationType.
contactMedium[]: Each item includes an @type discriminator and a corresponding value field:
PhoneContactMedium → phoneNumber
FaxContactMedium → faxNumber
GeographicAddressContactMedium → street1, city, stateOrProvince, postCode, country
relatedParty[]: Each item includes a role, @type, and partyOrPartyRole (id + @referredType).
@referredType = "Individual": Creates an AccountContactRelation, or links Contact.AccountId when Shared Contacts is disabled.
@referredType = "Organization": Creates an AccountAccountRelation. This requires PartyRoleRelation configuration, and the role must match a configured RoleName.
j