Query Re. Billing Feb & March Sherry FitzGerald

[awogan06]

Our API figures for “Appointments” seem to have taken a huge jump in Feb & March this year.

Our developer thinks this is related to an issue in Reapit where an appointment was stuck in a loop trying to update but Reapit continually returned a blank property code and so was never updated or removed from queue and there was nothing to alert us to this.

We don’t know if this was a bug or why the property would have been disassociated from the viewing. Our developer has put in some code to alert us if this happens again on our side. Can you get someone to shed some light on this with the viewing code below to see if this is why our costs increased considerable.

Viewing Issue.docx

[AshDeeming]

Hi @awogan06
Please could you advise your app name?

[awogan06]

It's the SF Web Connector

[awogan06]

Good morning Ash I was just wondering if there was anything further on this?

[HollyJoyPhillips]

Hi @awogan06 , we can’t see when the appointment was updated to remove the property ID but appointments can, although uncommon, be created without associated Property ID. The loop occurred as the appointment was updated (either via the SFG connector or in the CRM) and a webhook event fired. Based on that webhook the SFG connector created a PATCH (updated), this then triggered a webhook (correct behaviour).

However, each time it created a webhook event, the SFG connector ran another PATCH, which is where the loop continued until 2nd April.

As the system is designed to create events based on updates, it worked as it should. The response to each event may not have taken into account that the property ID wasn’t present.

Unfortunately, we only retain our logs for 1 month (due to the sheer size of each request) so it’s not possible to identify if it was the connector that updated the appointment and removed the property ID or if it was in AC but the loop wasn’t something that was executed via the Platform. Having read your comment though, it seems measures have been put in place from the connector side to cater for this going forward.

Hope that helps.

[awogan06]

Thanks for coming back Holly. Yes our developer has put something in place to alert us if this happens again but it would have been good to identify if it was the connector that updated the appointment and removed the property ID or if it was in AC. I did raised this issue on 16th April so would you still not have had your logs for March at this time to review?

[HollyJoyPhillips]

Hi @awogan06 unfortunately not with the amount of detail to determine when the property ID was dropped.

[awogan06]

Thanks Holly

We had another example last week if that's any help

The property is TER210124,
Applicant ID is TER240361 and the appointment was for the 18th May

[HollyJoyPhillips]

Hi @awogan06, that is helpful, thank you.

We were able to see the webhooks that were emitted on appointments modified on 13/05:

• Appointment modified on 10:39 to change negotiator from TPT to DFL
• Appointment modified at 15:33 which no longer included the property ID

The SFG Web Connector created a PATCH request on 15/05. This confirms it wasn't an integration or Platform that removed the property but was actioned within the CRM.

I would suggest reaching out to the CRM (Desktop Team) to obtain more detailed logs but as I understand it, their logs are only retained for 7 days. We're happy to help if you have a more recent example?

[awogan06]

Thanks so much Holly