Avoka - Person accounts

The purpose of this document is describing the current problem on Salesforce-to-Avoka data synchronization, for Person accounts, on generation of App forms and how to solve it.

Problem Description

Right now there is a problem when sending some data from Salesforce to Avoka, when an application form needs to be generated, that leads to inconsistent or incomplete data in Avoka forms.

Some of the scenarios which lead to that situation are:

  • On a Prospect/Corporate account on Salesforce, selecting as Contact to generate the form an Authorized Contact which is a Person Account on Salesforce.

  • On a Prospect/Corporate account on Salesforce, selecting as Contact to generate the form an Authorized Contact which is a Contact on Salesforce, but that Contact being related to a different Account through the AccountId relation.

This is not a problem anymore for FX (currency-services) because the contact is being removed from the form generation, however it is specially critical for TF, specially because during the TF qualification process the original contacts have been already replaced by person accounts and they cannot be chosen for the TF contact generation as has been explained above.

Background

Until now, the Avoka Prefill generator has been following the standard data modelling architecture of Salesforce, about having an Account and a Contact related to it through the AccountId Lookup relationship.

We have been feeding the Prefill generator with the Contact Id, and then retrieving the Account data from that Contact relationship.

But, we have more complex relationship scenarios used at Ebury, in which one Contact can be related to many different Accounts. So, for that we have been using the Authorized Contacts relationship (AccountContact__c junction object).

This document will describe the relevant changes needed for Avoka Forms to be auto-completed depending on the selected Authorized Contacts on Salesforce.

Solution

The Avoka Prefill generator will be fed with the Authorized Contact Id, and the relevant data will be retrieved from that relationship object.

image alt text

The solution will need to be applied iteratively to all 3 flows integrating Avoka forms in Salesforce, as they send Account and Contact information to Avoka to prepopulate the forms, those flows are:

  1. Foreign Exchange (FX).

  2. Trade Finance (TF).

  3. Document Collector (DC).

From a technical point of view, we will need to take into account updating the following modules:

  • Change the Avoka Services which are placed in Salesforce, they will need now to identify the AccountContact__c relationship and fill its Id in the avoka__Transact_Post__c.avoka__Prefill_Sobject_Id__c (this field was previously populated with the Contact Id).

  • Update the Prefill Generator records in Salesforce, to add the AccountContact__c SObject to the JSON, adding the related SObjects through Account__r and Contact__r.

Note: This last change will also change the structure of the Prefill XML which is sent to Avoka, because the data related to each record were encapsulated in a markup of the type ..., but now will be encapsulated in .... This will need to be handled by Avoka.

  • Last point, and related to the note above, we will need to create a new form version for all the forms in Avoka used by Salesforce, and update the Input XML Prefill Mapping to be able to extract the relevant data from the Prefill XML to populate the Avoka forms.

Alternatives

Removing the contact form the form generation as we are doing for FX, however this is not feasible for TF as having the signatory prefilled in the form is a business requirement.

Caveats

NA

Operation

This should not have negative impact but the opposite, it will solve legacy issues the users have been suffering for years.

Security Impact

NA

Performance Impact

NA

Developer Impact

The developers will need to perform changes in 2 different systems at the same time, Salesforce and Avoka, hence they will need to be careful on the consistency of the changes they perform.

Data Consumer Impact

NA

Deployment

We need to be aware that the deployments will need to be synchronized in time, as any transaction which is performed in the middle of a deployment will have corrupted/wrong data, or even no data at all.

In order to avoid unhandled errors during the minutes the services will be out of sync, we will be blocking the access to the form generation in Salesforce displaying a clear message notifying the feature is in maintenance and will be available in a few minutes. This feature will be built using a switch that will be activated only during the release window.

Previously we would have notified users via status page that the feature would be in maintenance mode. A second notification will be sent when the services are running again.

Dependencies

This Salesforce development will have a dependency with Avoka Transact Manager.

References

NA