to quote myself ādonāt build up data silosā.
In order to make triggers / integrations etc. easier, external software needs to know, when something is happening in SuiteCRM.
Examples:
opp is closed won - trigger data transfer to ERP
lead just called and asked for x - update interest in Mautic / marketing automation
invoice has been issued - transfer to the accounting software
etc.
Iāve used this one before:
which seems to not be actively maintained anymore.
If this feature would find its way into core, SuiteCRM would bring quite some more value to the table - since software shouldnāt live in silos nowadays.
(yes, I know - itās possible to develop custom logic hooks and use the DB as well - but how many more people could benefit from this feature, when no PHP code is required?)
Itā s been on my āto doā list for a while to put together a web hooks library plugin. Currently working on the Kanban and a few other projects thatās been eating up my time!
? Itās quite good conceptionally, just outdated.
If you want to / got capacity, we can look at it together and see whether we can upgrade / revive it together.
I see webhooks in SuiteCRM as a Workflow Action, alongside other possible actions.
This way you can leverage all the currently existing events, add webhooks as simple steps in processes, have a UI to mange them, trace what happened, etc.
@pgr I agree, i think you need a workflow action & a webhooks module to be honest. The module sets up the Webhooks (Url, authentication, headers, method, etc) and then the Workflow triggers it.
The module could possibly even be āmodule awareā so the list could be filtered in the workflow.
That way it keeps the workflow actions clean and simple and allows config in a central location, it also allows all the code to be kept in a module rather than in the action.
I would also be interested in setting up a module that is a Webhooks listener as well, because too many systems make things complex so to not have things like N8N (which IS excellent however its another system I only use for listening and translating to Suite) would be ideal.
Both good ideas, I was thinking something a little less complex, with like a dozen or so prebuit and self contained webhooks like: new contact added, new opportunity added, opportunity stage change, etc.
The @digital-boss plugin that @BastianHammer works well for me, but doesnt use Workflow, it looks like youy can set conditions but its not easy (a manual json array needs saving for that).
The Sidorkin one I havenāt tried but would do what you want via workflow..
I think something flexible (to cope with sending to whatever endpoint - so needs configuration somewhere) combined with workflow (so any module basically) would be fairly simple to set-up.
I like the pre-configured ease of doing things here.
The disadvantage is, that I cannot configure the payload. If my requirement doesnāt fit the preset payload, Iāll always have to use a middleware and first make another request.
The fire & forget approach works in the best case, but in business systems & integration, Iām always a bit sceptical. If companies grow, integrations need to become more reliable, monitored and ideally self healing. (basically, the queueing feature of Mautic)
@markbond the @digital-boss one stopped working for me during one n8n upgrade. And it only works with n8n. Iām using ActivePieces in some projects and a few times a Python middleware.
Itās good with n8n, but only with n8n.
The Sidorkin one is a bit more complex and the code has to be updated / fixed.
But after getting the hang of it, I find this a very good approach.
The fact that it has two layers is quite good as well. First the standard via workflow, then the queue via the plugin itself. It opens up some interesting options for the future (retry-mechanisms, integration monitoring, etc.)
I think my meaning was that we probably need a mix of both, so a preconfigured Webhook (possibly holding a data config and pattern) and the action that triggers it to a queue as per Sidorkin (which is a very good idea as a workflow can re-trigger it if necessary).
The Sidorkin one also has flaws, so if your endpoint deals with create and update for example in Sidorkin and digital-boss you need to configure it twice, whereas if you hold a central config (like credentials in n8n) you only configure once.
Sidorkin as well replaces aow_utils purely so you can save a password encrypted as a field, if all that was in the module that replacement isnt necessary.
I think its sort of pick the best fit from both (and improve the documentation)
ādonāt build up data silosā.
. It will be of great help to many SuiteCRM users. 
