Envoke Contacts API integration #1222
MontrealSergiy
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, Bryan here few question on Envoke integration. What do you think?
You might wish to check some points with James
Plain form vs API based. Following the discussion currently subscription to Envoke Newsletter is being implemented in NeuroHub/CBRAIN using Envoke Rest API. In the same time Envoke features an interactive editor to create subscription forms. That form communicate to Envoke.com directly, rather that via NeuroHub. The main advantage of plain form is that it is possible to embed it to any website (e.g. www.cbrain.ca , www.neurohub.ca or whatever. More, Envoke generates forms fast , and thus thus could be used not only for newsletter but, say, for subscription to any events instead of google forms or such. To use both types of form, probably, some synchronisation efforts will be required. To conform to all legal requirements that may require email confirmation aka double opt-in procedure, while in CBRAIN/Neurohub already supports email confirmation, so API approach helps to avoid extraneous email confirmation.
Shortcomings of Neurohub email confirmation. Adding of email to envoke supposed us to go through email verification. We should not add unvalidated emails. CBRAIN user may change his email latter, yet since no CBRAIN does not validate email change is not propagated to ENVOKE and user will not have further control for it in CBRAIN. He still will be able to unsubscribe using usual email footer link for changing subscription preferences and settings. If you see how to improve, please tell me.
Interests/list. At the moment we only have a Monthly Newsletter. (I see also Events notification yet with 0 subscriptions.) Should I add also Event Notification or it’s deprecated one? Do we plan to anytime soon more newsletters/maillist? If so, should I offer user selection of newsletters? If so could those be hard-coded, provide some admin form to edit list of newsletters, should I pull them dynamically from Envoke which technically easy but does not allow for test/dev newsletters, which we are not yet ready to show to our users.
Consent checkbox. The Envoke form creation guide recommends keep separate the consent checkbox (for receiving info@neurohub.com) letter and list of interests/subscriptions. At the moment for simplicity I offer single yes/no dropdown, but can redesign of course. The selection of interests and consent are conceptually different things, consent is granted for receiving info@neurohub.ca emails in general. User may revoke his consent temporally but keep interest selection. Also it seems consent can be revoked not only via forms but automatically, there is “Reported as spam” consent status, Envoke, most likely, sets it automatically whenever the email provider reports Neurohub infoletters as spam. Typically Envoke's preference form shows the subscription option in the bottom
User migration As the first step Envoke integration implemented only for new users, but after it is deployed I can migrate existing user. Please clarify is it enough to migrate Monthly Newsletter recipient or should I move all the entries.
Synchronisation User might change his preferences or consent through email form. Should I add backward synchronisation (pulling info from Envoke db to Neurohub) or just pull most recent data from Envoke whenever user profiles is gets opened in Neurohub? (Nothing done so far). I think we should limit that for subscription am not sure is it good idea to change NeuroHub email or user name based on Envoke db change.
User Data Do you need address, position or affiliation passed or updated from NeuroHub? At the moment it is only first and last name and email getting passed to Envoke. The title and middle name ignored. Should we inform user that his personal info is shared with Envoke on sign up form, 'license' or else?
Shared emails NeuroHub users may share emails , I guess the first one to give concern to be supported. Or just block them from Envoke integration. Another option is to block Envoke integration for admin users - those are main use case for shared emails.
Deleted user If user deleted, locket etc - should one to remove it from the list? I think no need (not our user - not our problem)
Test users I accidentally changed a real user while developing (I believe I restored back). Should we develop some development environment, say by tagging some users as test /dev only and allowing cbrain only change those in dev mode?
Beta Was this translation helpful? Give feedback.
All reactions