TMF632 v4 Party Management - Outbound Notification

Use TMF632 Outbound Notification API for party management tasks such as creation, update, and event notification. Party can be an individual or an organization that has any kind of relation with the enterprise. Party is created to record individual or organization information before the assignment of any role. Party API manages the data resources such as Individual and Organization. Currently, the API is used to manage Individual resource that represents a single human being (man, woman, or child). This can include customers, employees, or any other person the organization needs to store information about. Outbound notifications can be configured to be triggered for change events on the parent entity (Contact) as well as for relevant sub-resources, see Supported Sub-Resources for TMF Outbound Notifications for the list of supported sub-resources in scope.

/api/notification/individualCreateEvent
/api/notification/individualStateChangeEvent
/api/notification/individualAttributeValueChangeEvent(status field)

The user must configure the notification framework to detect CDC events and invoke the relevant TMF Open API implementations that generate the event payloads and forward them to the target systems configured within the API.

This API has been tested with an external system using TMF-aligned customizations. It may not include all optional fields and may not work out-of-the-box with your system. Customizations will likely be required. We recommend a thorough evaluation to ensure it meets your specific needs.

Note

Available In

This API is available in the managed package and Salesforce platform.

Prerequisites

MuleSoft License required: MuleSoft Direct for Communications Cloud (add-on for Communications Cloud) or MuleSoft Anypoint Base Subscription.
Communications cloud license required: Communications Cloud Growth.

Assumptions

The notification uses a fire-and-forget approach. Salesforce does not process or store the response in any objects. MuleSoft logs and tracks all received notifications.
In alignment with TMF v4 standards for event notifications, the system sends the same payload, which includes the full individual resource and the supported related sub-resources, for all events.
Access to the target system is authenticated using the OAuth 2.0 Client Credentials grant type.
In the case of a failure when invoking the target system endpoint, the request is retried up to three times, with a two second interval between attempts.
TMF632 v4 Inbound API response may include optional fields. According to TMF specifications, if the outbound Event Notification payload contains unsupported optional parameters, the downstream system may reject it with a 4xx error. To avoid this, tailor the payload to include only the optional fields supported by the client.
For the POST payload sent to the external system, ensure that generated response includes only the optional parameters that are supported to prevent a 4xx error response.
Salesforce and MuleSoft do not have a centralized event hub configured by default. Customers are responsible for setting up their own event hub to manage subscribers. Outbound notifications are generated and sent directly to a single, client-defined target endpoint.
The Allow users to relate a contact to multiple accounts feature enables a single contact to be associated with multiple accounts through the AccountContactRelation object in Salesforce. Since this feature is disabled by default, the contactToMultipleAccountsEnabled query parameter must only be set to true when the feature is enabled, and only during the creation of integration definitions.

The following table summarizes the change events supported for the Contact entity, along with the required configurations to trigger them through the Notification Framework.

When configuring Object Integration Definitions, ensure you use the exact RelatedFieldName values provided in the table below.

Important

TMF Resource	Salesforce Entity	Scenario	changeEventType Supported	Notification Event Path	RelatedFieldName
Individual	Contact	Creation of a Contact record	Create	`/api/notification/individualCreateEvent`	”RelatedFieldName”:“Id”
		Updates to attributes of a Contact record	Update	`/api/notification/individualAttributeValueChangeEvent`	”RelatedFieldName”:“Id”

The core entity does not include a dedicated status field. This API is designed for the core model (not the managed package), so the status is set to “initialized”. To enable event notifications based on a custom status, a custom status field must be created and maintained. Additionally, the Salesforce Notification Framework subscription should be configured, and the Mule API updated to include this field in the outbound notification payload.

Note

Sample Outbound Notification Request

This is a sample payload sent to the target system endpoint for the event Type: IndividualCreateEvent.

The event notification payload is same for all three events (IndividualCreateEvent, IndividualStateChangeEvent, IndividualAttributeValueChangeEvent). The eventType value will differ between the three events.

Note

1{
2  "id": "d35161e0-e2ec-11ef-8c9a-02bec51f016d",
3  "eventId": "string",
4  "eventTime": "2025-02-07T06:04:20.966Z",
5  "eventType": "IndividualCreateEvent",
6  "correlationId": "0001ade9-3f74-0b99-dbc4-42e73424b774-1",
7  "timeOccurred": "2025-02-07T06:04:20.966Z",
8  "event": {
9   "individual": {
10      "birthDate": "1978-04-23T00:00:00.000Z",
11      "familyName": "Johnson",
12      "fullName": "Robert William Johnson",
13      "gender": "Male",
14      "givenName": "Robert",
15      "legalName": "Robert William Johnson",
16      "title": "Mr",
17      "status": "initialized",
18      "contactMedium": [
19        {
20          "mediumType": "MailingAddress",
21          "characteristic": {
22            "city": "Boston",
23            "country": "USA",
24            "postCode": "02108",
25            "stateOrProvince": "MA",
26            "street1": "25 State Street"
27          }
28        },
29        {
30          "mediumType": "OtherAddress",
31          "characteristic": {
32            "city": "Chicago",
33            "country": "USA",
34            "postCode": "60601",
35            "stateOrProvince": "IL",
36            "street1": "123 Michigan Avenue"
37          }
38        },
39        {
40          "mediumType": "Phone",
41          "characteristic": {
42            "phoneNumber": "+13125557890"
43          }
44        },
45        {
46          "mediumType": "MobilePhone",
47          "characteristic": {
48            "phoneNumber": "+16175551234"
49          }
50        },
51        {
52          "mediumType": "Email",
53          "characteristic": {
54            "emailAddress": "robert.johnson@example.com"
55          }
56        },
57        {
58          "mediumType": "Fax",
59          "characteristic": {
60            "faxNumber": "+16175552345"
61          }
62        },
63        {
64          "mediumType": "HomePhone",
65          "characteristic": {
66            "phoneNumber": "+16175553456"
67          }
68        },
69        {
70          "mediumType": "OtherPhone",
71          "characteristic": {
72            "phoneNumber": "+16175554567"
73          }
74        },
75        {
76          "mediumType": "AssistantPhone",
77          "characteristic": {
78            "phoneNumber": "+16175555678"
79          }
80        }
81      ],
82      "relatedParty": [
83        {
84          "id": "002xx000005AcbXYZ",
85          "name": "Tech Solutions Inc.",
86          "role": "employer",
87          "referredType": "Customer"
88        }
89      ]
90    }
91  }
92}

Outbound Event Notifications Field Mappings

TMF Field	TMF Type	Is it Mandatory ?	Supported	Mappings
id	string	No	TRUE	Mule correlation Id
eventId	string	No	TRUE	inputPayload.eventId
eventTime	string	No	TRUE	inputPayload.commitTimestamp as UTC
eventType	string	No	TRUE	”IndividualCreateEvent” or “IndividualAttributeValueChangeEvent” or “IndividualStateChangeEvent “
correlationId	string	No	TRUE	inputPayload.correlationId
timeOccurred	string	No	TRUE	inputPayload.commitTimestamp as UTC
event.individual	object	Yes	TRUE	The mappings details for the Individual resource.

Supported Sub-Resources for TMF Outbound Notifications

This section outlines the sub-resources within TMF632 for which outbound notifications can be configured for create, update, and delete operations.

Refer to Assumptions section for essential configuration guidelines and design assumptions required to enable TMF outbound notifications on these sub-resources.
The TMF sub-resource ContactMedium is mapped to attributes of the parent Salesforce Contact entity. To enable notifications for changes to ContactMedium attributes, create the corresponding Object Integration Definition on the Contact entity. Set the RelatedFieldName to Id to reference the Contact entity’s identifier.
For each sub-resource listed below, use the RelatedFieldName specified in the table to configure the Object Integration Definition mappings. This ensures that the Salesforce Notification Framework triggers notifications accurately for the corresponding change events.

Note

For each sub-resource listed below, use the RelatedFieldName specified in the table to configure the Object Integration Definition mappings. This ensures the Salesforce Notification Framework triggers notifications accurately for the corresponding change events.

TMF Sub-resource: RelatedParty
Salesforce entity: AccountContactRelation (applicable when the Allow users to relate a contact to multiple accounts feature is enabled).

TMF Resource	Salesforce Entity	Scenario	changeEventType Supported	NotificationEvent Path	RelatedFieldName
relatedParty	AccountContactRelation	A new account is linked to an existing contact record.	Create	`/api/notification/individualAttributeValueChangeEvent`	`"RelatedFieldName":"ContactId"`
		Updates are made to an account already associated with a contact record.	Update	`/api/notification/individualAttributeValueChangeEvent`	`"RelatedFieldName":"ContactId"`
		An existing account is removed from a contact record	Delete	`/api/notification/individualAttributeValueChangeEvent`	`"RelatedFieldName":"ContactId"`

Sample Notification Framework Payload Request

Below is a sample payload when a new Account is associate with a Contact.

1QueryParamter : “contactToMultipleAccountsEnabled = true"
2
3 [
4
5{
6  "entityId": "07kLT000000BrFVYA0",
7  "entityName": "AccountContactRelation",
8  "eventId": "00000919-6881-2a4c-a19d-59030ed936d9_1",
9  "commitTimestamp": 1750390429000,
10  "commitNumber": 1750390429795262466,
11  "correlationId": "00000919-6881-2a4c-a19d-59030ed936d9",
12  "changedFields": {
13    "LastModifiedDate": "Fri Jun 20 03:33:49 GMT 2025",
14    "AccountId": "001LT00000dmmlRYAQ",
15    "CreatedById": "005LT000006GmRpYAK",
16    "IsActive": "true",
17    "CreatedDate": "Fri Jun 20 03:33:49 GMT 2025",
18    "ContactId": "003LT000003hKGHYA2",
19    "IsDirect": "false",
20    "CurrencyIsoCode": "USD",
21    "LastModifiedById": "005LT000006GmRpYAK"
22  },
23  "changeEventType": "Create",
24  "enrichedFields": {
25    "ContactId": "003LT000003hKGHYA2"
26  }
27}
28]

When the Allow users to relate a contact to multiple accounts feature is disabled, changes to a contact’s associated account must be captured by configuring the Object Integration Definitions to listen for update events on the Contact.AccountId field.

Note