Avoiding a race condition

I am creating an endpoint in Central to create or match a Person Details Record to allow new Customers to become registered on the system when they anonymously submit a form from Host. I have it set up so that the Central endpoint responds with the new Person Details ID. In the API Call (on the Host end), this gets copied to the CASE:Central Person ID field. (This is assuming the Person Details record must be newly created). I also have a rule to create the CASE → Person Details (Remote) relationship when CASE:Central Person ID changes. This wirks, but it feels like a race condition with the Remote Object Syncing, as this rule might trigger before the sync occurs. In fact, if instead of copying the Person Details ID into a field, I instead set the API Call to link the CASE to the Person Details (Remote) based on the received ID, I get an invalid Object error.

Does the platform make any guarantees about this situation, or am I simply getting lucky one way round and unlucky the other? It would be nice if before attempting to create any remote relationships, the platform could force a sync (or allow users to trigger this) – however, it looks to me that given this fails when done in the API Response handler that this is not the case.

Any further insight would be greatly appreciated.

Hi, we currently do something similar matching person records to Central - and you’re right about the race condition. This is because once the Person is created in Central, it still takes time for the ‘remote object’ record to sync back to the Host.
Our solution is to send over the case reference that created the Person in the API, and have a ‘record created’ rule in the host (based on Person (remote)) that links the records together at that point

Thanks James, that confirms what I had thought about the situation and sounds like a decent solution!