Hey @shane b​ Racheal from the support team here 👋

Are you mapping your external_id? When mapping with Custom Objects, you must map the ID to the external_id field otherwise it will create duplicates with each GET request. You can read more about setting up a Custom Action here and more about mapping relationships here.

Hello @racheal​ 👋

That's actually one of the first suggestions that support had me try. Upon checking we confirmed that external ID was mapped correctly and the response mapping was successful. This would suggest that the issue is unrelated to the external id not being mapped properly.

I've been going back and forth with support for a couple of weeks now and they aren't sure what the issue is. It sounds like it may be too new? Has anyone else been able to successfully replace a custom object array on a conversation?

Looping in @kevin b​ in case he can advise on that 👍

I'm having the same issue. I'm only able to show users 5 orders from "buttons from object data" and I can never clear these out to get new orders.

It's definitely a blocker for us and making it impossible to use the custom actions.

@shane b​ did you ever solve this?

@racheal​ any solutions that you have found yet?

@diana t12​ we never got an answer here

Hi @david g13​ , @user1539​, @shane b​ , here is @Brian McKiernan​ answer in another thread on a similar topic that you might find helpful 👍

Here is Brian's feedback:

Hi @user1539​ @david g13​ I'm Brian, the PM at Intercom working on Custom Objects.

Thanks for the feedback - firstly, we absolutely hear you on this one and it's something our team has heard from our customers several times since our initial V1 of the Custom Objects capability last June. Our journey here with Custom Objects is still relatively early and we're keen to learn about how we can add use cases, improve the capability over time.

re the issue: What I expect to happen is that the orders shown are the same as the ones fetched by the custom action

While it's a little bit of a "workaround"; if you relate the Custom Object "Order" to the Conversation object (rather than the User Object), then this should give you the expected behaviour (note we have a hard limit currently of 5 custom objects ordered by last updated).

Why does this work: This works because conversations are essentially ephemeral i.e. an End User will create a new conversation with each inbound request to refund an order. Thus it'll be a new Custom Action request that is triggered and only the Orders returned from that call will be related to the Conversation. Whereas when related to the User; the Orders are appended to any other Orders that might already be related to the User (e.g. from a prior refund conversation) and thus it will show the last 5 orders irrespective (helps to map the datetime field here to ensure the right sorting) as to whether they were returned in the most recent custom action response request or not.

Hope this helps - any questions feel free to add in the thread.

Brian