Syncing Backend onCoversationCreate event to Frontend actions

Hi everyone,

I’m developing a Freshdesk app to enhance the process of updating company notes, and I’m facing some challenges with syncing data between the backend onConversationCreate event and the frontend ticket.addNote event. Here’s an overview of what I want to achieve and the obstacles I’ve encountered.

Goal:

  1. Capture Note Privacy Status: I need to determine if a note added to a ticket is private or public.
  2. Conditional Company Notes Update: If the note is private, I want to prompt the agent with a confirmation dialog, allowing them to decide whether to append it to the company’s notes.

Current Approach:

  • Backend with onConversationCreate Event: I’m using the onConversationCreate event to capture the privacy status of the note (private or public) and store this data in $db.set(). When I test locally by navigating to localhost:10001/web/test, I can see the events being triggered as expected. However, when running the app, it seems that I’m not receiving any console logs or confirmations that the data is being stored—possibly due to the serverless nature of the backend.
  • Frontend with ticket.addNote Event: I’m using the ticket.addNote event in the frontend to show the confirmation dialog. However, since ticket.addNote doesn’t provide information about the note’s privacy status, it’s difficult to conditionally display the dialog based on the note type.

Attempted Workaround:

I tried to store the note’s privacy status using $db.set() in the backend and then retrieve it in the frontend after ticket.addNote is triggered. Unfortunately, this approach hasn’t worked—I keep encountering a “not found” error, and it seems like onConversationCreateHandler may not be storing the data correctly.

Questions:

  1. Is there a recommended approach to reliably sync data between backend/serverless events and frontend click events in Freshdesk apps?
  2. Are there any best practices for triggering frontend actions based on backend events like onConversationCreate?
  3. Should I consider managing this functionality solely in the backend? If so, how can I effectively implement a confirmation dialog in the backend or notify the frontend?

Any advice or insights would be greatly appreciated!

Thanks in advance for your help!

Hey @Rhea_Le

I am pretty surprised that the ticket.addNote has no payload, but guess we can’t change that.

Are you sure, that you don’t run into a race condition?
What I mean is, that serverless part has not yet stored the value, when frontend tries to retrieve it?

I am not 100% sure if serverless and frontend can access the same data storage???
I’ve found nothing specifically telling not - But I also found nothing in the docs, stating that it is possible.

What you could try is to use SMI to retrieve the data.
So that data handling is done solely in the serverless part and frontend calls the SMI function to retrieve the data.

One question - What do you mean with “… However, when running the app, …”.
You mean uploaded and installed in your instance?
Or do you expect to see logs from events on your instance when using “fdk run”?
I think the second is not really possible, as far as I know.
So there’s no comparable option as “dev=true” for frontend apps in serverless.

Hope that helps, best
Tom

1 Like

@Freddy - Is it possible to access the same key-value storage from frontend and serverless?

@ThomasH Thank you for your response!

I was thinking about this last night too and I think that it could indeed be a race condition. The ticket.addNote click handler is activated before the the note is actually saved. I thought about adding a slight delay but this is probably not the best approach.

I just tested the SMI method of registering a function and invoking it in the frontend when the ticket.addNote is clicked. That worked perfectly!! Thank you so much. I think this is the way to go for sure for what I’m trying to achieve.

Thank you again for your helpful response.

1 Like

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.