-
Notifications
You must be signed in to change notification settings - Fork 2
Integration with external CRMs #10
Comments
@marcinkoziej this needs clarification and brainstorm when you are back from holidays ;) |
The action pipelineMy idea for conceptualizing all this post-processing is an action "pipeline", which is an ordered set of functions which will be called in asynchronous manner on the signature (or different action). I think that pipeline will be set per-action_page, because there could be maybe different opt in policies, and different CRM's to post to. So for instance, for a new signature:
An external service could be called by "webhook" pipeline steps. There would be two types:
Webhooks and DOSI think we should read a little bit more about webhook delivery issues, I found this: |
Automation systemsThese look very coooool. Maybe we can set up one of them to check out how easy/hard it is to use them? And what can be done with them? Can they implement the double opt in mechanics? |
So what you suggest (trying to make explicit limitations/simplifications):
Proca is responsible to maintain the state (position in the workflow) for every signature. What about we turn that on its head and we let the external systems handle the state, eg instead of pushing each signature to the CRM (+risk of DoSing it), we let the external system fetch (give me up to 100 signatures after id=xyz - or timestamp) the CRM - or external system- being in charge of knowing what it fetched last and what it needs to fetch to make it more responsive, we can have a webhook to notify (max once per every x second) than a new signature has been collected yeah, worth looking at automation system, great idea! |
Yes, they would not be done in parallel. |
Writing integrations (using push or pull) is now a lot easier with @proca/cli |
the aim of proca is to be able to push the signatures and supporters contact details to the organisers' communication tools (CRM, mailinglist...).
This is triggered by an event in proca (eg new petition signature), might need a different workflow based on the event data (eg push it to the mailing list only if the signatory optsin).
In the future, these events/workflow could be chained, like:
Shall we write ad-hoc components to integrate with various CRMs (eg one for civi, one for mailchimp...)?
Or should we already integrate with a event/agent & automation system?
at these opensource ones seems to be interesting:
Requirements for going external:
and ideally having a batch mode (ie. instead of triggering one call per event, being able to batch them, like all the signatures in the past minute or by batch of 100)
I think we should go with an existing event/workflow system eventually, not sure when
Right now, we need a system to export signatures, at minima as a CSV ;)
The text was updated successfully, but these errors were encountered: