Two-way syncs in custom apps

Hello there @victorandree,

Is the question about that specific custom field which shows a few different dropdown lists?

Well, no, I guess the question is how to build such an integration in an app of my own, in general. “Sync” for me implies that a single integration links items created in Monday and the external system (Jira).

AFAIK, a custom integration to do the same would require a custom trigger to effectively poll for updates on Monday and react to events in the external system, with a custom action to sync them. Maybe that’s the way to do it?

But sure, I also wonder how to make a dropdown with the specific options.

You can create a custom trigger - which maps data from your service to a monday board, AND when the trigger subscribes, you create a webhook with the API to trigger on changes to the column you are syncing to.

You’ll just need to cache a hash of the last change made md5(itemid+columnid+value) by inbound sync, so that when you get the webhook you can create a hash of the same data to check if its an actual change or a result of an inbound change you made.

No requirement to poll the board for changes.

Hello again @victorandree,

I think a recipe with a custom action + a webhook could do the trick.

Regarding the specific custom field with several dropdown columns, it can not be implemented by external developers as of today.

Cheers,
Matias

Nit: If a webhook fails, then occasional polling may be required to capture any missed updates. monday’s docs do indicate that webhooks are not retried too, so it should be kept in mind that they may not successfully reach you from time-to-time

Thats a good reason to have your webhook handler be dumb simple and place the payload in a queue that can retry, has a dead letter queue, persistent storage, etc.

This at least makes it possible to handle failures on your end, so the only risk is if monday fails to send it, or there is a severe outage where you cant queue. The enqueueing function should be as dumb simple as possible.

Thanks @anon29275264 and @Matias.Monday!

@Matias.Monday mentioned “custom action” while @anon29275264 mentioned “custom trigger”. I’m guessing the “custom trigger” is the critical part here – but I really see it primarily as a way to create a webhook upon subscription, right? I’m not even sure what the action would be with this solution.

The trigger partly gets you the webhook to be created, but also lets you trigger a custom action.

What happens is when your outside data source has data to push, you trigger your custom trigger and send it the fields you want that link up your backend with monday. such as the external identifier, and a custom direction field.

When your webhook you created triggers, you send the item ID that changed and the direction to the trigger.

The custom action then contains what you need to map the fields between the two services. This then gets sent BACK to your backend, along with the ID and direction.

Then your backend acts on it based on the direction and the mappings provided. So there is a decoupling between your notification of the change in your external service, and the process that then does the actual syncing. The triggering side handles the events, and the action side passes the information you need to do the action (sync).

This is oversimplified. You may also pass values from the events that trigger so they flow through to the action side for you to do something with.

Basically a recipe handles telling your app there is something to do, and then also how to do it, and what to do. Then your backend does it.

Right, thanks. Makes sense. I was thinking I could directly update Monday, instead of triggering my custom trigger to trigger an action — but doing it through an action will probably work better from an authorization perspective.

Appreciate the input from both of you 🙂

Yes because you don’t have to worry about storing tokens. Also, you can pass what columns to use from the action - which means nothing is hard coded. (something I would try to avoid for obvious reasons - now you can reuse this on another board for example with no code changes)

Thanks again. Do you see a way to implement this with dynamic mappings, or do you mean to select columns by having a sentence recipe input field in the action for every column I support?

I tried to implement this with dynamic mappings, but I don’t see how I can map the Monday items to my external entity. I can pass the entity as an output from the trigger, and let the action map it to Monday items, but I don’t see how to do it the other way around. AFAIK, there isn’t a way to “run” an “itemValues to entity” mapping outside of the context of the supported built-in triggers.

I guess if the action always gets my external entity and how Monday mapped it to an item, I could figure out the reverse heuristically. Here’s what I mean:

• Let’s say my external entity is tickets, with summary and category fields.
• I create a dynamic mapping corresponding to this entity.
• My custom trigger has ticket as an output field.
• My custom action has ticket as a trigger output input field, and an itemMapping as a sentence recipe input field.

In my recipe, I configure the action with itemMapping having ticket as a source entity.

Now, I can pass tickets from my trigger and in my action, I’ll see how Monday mapped that to a Monday item, so I can create/update Monday items. But I still don’t have a way to translate Monday items to tickets in the external system. Once the action has run once, I could look at how the Monday item values correspond to the dynamic mapping’s values.