TMF629 v4 Resource Mappings

Before using the TMF629 resource mappings, refer to the following.

Constraints and Limitations

• The id, href, and agreement, are not patchable attributes.
• Each element inside contactMedium can be patched like phoneNumber, emailAddress and faxNumber. And only these fields are patchable inside characteristic field.
• All the validations for contactmedium of POST method are also applicable for PATCH method as well.
  • mediumType and characteristic are mandatory.
• Removing of any of the contactmedium entry is supported.
• When updating the contactMedium for non-existing engagedParty no change is observed.
• Ensure that accounts that are patched must be existing accounts in the system.
• Ensure that there is no cyclic dependency for an account.
• It is advised and not mandated to have unique email in every request in the contactMedium.
• The DELETE operation deletes the associated contacts and resets the relation with associated account. If the contact is not deletable, then the corresponding message from database is displayed.
• If multiple entries for same mediumType are present in the request, then only one of the entry for the mediumType is considered.
• When updating engagedParty with an existing or new contact, contactMedium is also updated as per the new contact information. For example, if a customer wants to update engagedParty it is advised to send contactMedium information as well that is updated for a new contact.

Assumptions

• The customer (Accounts Object) created using the API operates in the same fashion as Account records created from Salesforce UI. These can be utilized in all other flows and business processes.
• The Characteristics sub-resource, provided by the customer is a free text. This is not supported in Salesforce out-of-the-box implementation.
• The TMF629 API POST message expects ID for entity references, such as AccountRef, PaymentMethodRef and AgreementRef. The ID should exist in the Salesforce ORG. If not, the API call fails, and an appropriate error message is generated.
• The CreditProfile node is not supported.
• The name and id fields are mandatory for the AccountRef sub-resource.
• The engagedParty association is supported. The relatedParty entity contains the customer details associated with the given account.
• The AccountRef node contains the details of all the accounts that are related to the given customer, that includes service account, Billing account, and so on.
  • In GET API, Account node contains the list of all the accounts that are referred to a customer.
  • In POST API, request is expected to have the id and name of the account. The account with the given id and name should pre-exist in the Salesforce ORG. If not, the API call fails and an appropriate error message is generated.
• The PaymentMethod is not be supported out-of-the-box, as the Object is a custom object and available in the package. However, a customer who wishes to use to the payment method can do so by exposing an Apex end point and internally use the core end point.
• Account Sub-resource:
  • The id and name fields are mandatory for an account. Use existing account's name and id in the payload.
  • If the account has any previous ParentId field, it is updated with the new account that is created.
• EngagedParty Sub-resource:
  • A new contact can be created or an existing contact be used.
  • Id can be passed in engagedParty along with the name and name is updated for the contact Id sent in the request.
• ContactMedium Sub-resource:
  • Maximum only 3 elements can be added in this sub-resource: email, phone, and fax
  • Same information is populated in all the contacts that are created from the engagedParty.
• Agreement Sub-resource :
  • Not supported in the POST request.
• Version in any request greater than or equal to v60.0.
• For uniqueness of the Contact, enable duplicate contact check and add standard contact matching rule and standard lead matching rule. For more information, refer to the following.
  • Standard Contact Duplicate Rule
  • Standard Contact Matching Rule and Standard Lead Matching Rule

These default mappings are supported for the TMF629 resources.

Customer

Sub-resources

AccountRef (Account)

ContactMedium (Contact)

MediumCharacteristic

EngagedParty (Contact)

AggrementRef (Contract)

Validations and Conditions for POST

Following validations and conditions are considered for the POST operation. Account Sub-resource :

• The id and name fields are mandatory for an account, and an existing account's name and ID must be used in payload.
• If the account has any previous ParentId field, it is updated with the new account that is created.

EngagedParty Sub-resource :

• A new contact resource is created with the name sent in the request.
• The id field is not passed in the engagedParty.

ContactMedium Sub-resource :

• At maximum only 3 elements can be added in this sub-resource : email, phone, fax. And the same information is populated in all the contacts that are created from engagedParty.

• It is advised and not mandated to have unique email in every request in contactMedium.

• To reuse the email in multiple POST requests, user must deactivate the duplicate rule by performing the following steps.

  1. Go to Setup.
  2. Search for duplicate rule in quick find.
  3. Select Standard Contact Duplicate Rule.
  4. Select deactivate.

• Agreement Sub-resource: Not Supported in POST request, as agreement cannot exist without an account, and to create an agreement there is not enough data from the payload.

• If multiple entries for same mediumType are present in the request then only one of the entry for the mediumType is considered.