Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

Improvements to WebHooks StructureDuplicate

As you may or may not know, I've created an integration between Jive and Marketo that uses WebHooks, and I see tons of value with just that piece of the integration.  However, we are nearly 6 months into our integration, and as we start to add more and more uses of WebHooks, we are finding that the rigidity in configuration is sending us down a path where there is a foreseeable management problem. Currently, a WebHook is defined as a distinct Server Call (such ://host/context/resource?parameter=values…)  rather than a distinct resource ( ://host/context/resource )  … This means that in the event I want to call the same WebHook service with different parameters, I have to setup completely new WebHooks.  For things like integrating with VEvent, where we need to pass in new Ids each time a new event comes up…this means a constant creation of new one-off WebHooks that rarely gets deleted. To help with this, I propose the following model be setup: 1.)  Create an independent "Host Record" responsible for (://username:password@host) information (this will keep users from having to copy/paste service credentials over and over again, and should those credentials change…it makes it one place to do it. 2.)  Alter the WebHook structure such that it has a "Host Record" as a child attribute and store (/content/resource/parameters names) as the WebHook.  Basically setting up the skeleton of the WebHook call. 3.)  Create a "Templated Parameter Values" Construct, that can store sets of Parameter Values for a specific WebHook.  Values may be 1234,ABC,xsd13 in the set, but providing a pretty name like "Welcome Email" to provide context to what they mean will help people select them from a drop down.   This allows the business is isolate business rules to a series of Named sets … such that the WebHook Flow reads…Call WebHook "Send Jive Notification" with Parameter Set:  "Welcome to Jive" What's the Flow Like, beginning to End? Go to Admin > WebHooks > Create New First thing is to select an existing host and/or create a new one (modal pop-up I'd imagine, if create new) Add the Context + Resource Path Information … plus any parameter placeholders that are needed.  Perhaps syntax is {{webhook.param=foo}} or something similar.  This can be put into either the JSON payload or URL field. Save WebHook Add "Templated Parameter Values" to the new Webhook (can only be used with that web hook).  This could be something that looks like a raw JSON object, and/or a render UI with text inputs for every param in the WebHook.  Users could add in static value or reference lead/company variable information. Now, To Call the WebHook, simply create your Smart Campaign…select "Call WebHook" (drag to panel) After the WebHook is selected…the Flow Step renders an additional field that has a drop-down of "Templated Parameter Values" names to select from, or the user can select "add values manually" and the UI lets the person add a 1-off set of values.  Whether the input is free-form text or individual fields, I am indifferent. The difference?  In the current paradigm we have 5 (soon to be 6-7) endpoints for WebHooks.  These are written to be very generic and rely on parameters to control their behavior.  In configuring our needs (we are just getting started)  we are using only 4 of the WebHooks End-Points and we have nearly 40 WebHooks defined.   In this new structure, it would be 1 Host Record … 4 WebHooks … and 2-8 "templates" per WebHook.  This makes a huge difference in maintenance, and the end-user experience when calling a web hook in a flow step. That's all I had for now, but definitely wanted to get that out of my head.

Stream Cadence \ DailyDuplicate

In Engagement programsI would prefer that there was a "Daily" email option under Stream Cadence. Daily would mean that depending on the days of the week you set, they could get one email on each of those days.That would change the logic for "Weekly" emails, which would mean if you selected each day of the week, they could only receive one email per week, but it could be on whichever day of the week was 1 week after the last engagement email they received. Or 2 weeks after the last engagement email they received.Under this example, because it was set on Weekly, not Daily, this screenshot would mean that every 2 weeks (from the last engagement email that was sent) someone is eligible to receive an email any day of the week except Monday & Friday.Use Case - I'll never use daily emails unless it's for something super specific like a multiday user conference. My users don't want to hear from me that often. But I do believe that you should approach people in respect to when they approached you first. If you have a VP who is slammed all week long while they're in the office. But every Sunday morning while having coffee they have a calm moment to check email & do a bit of research. They came to my site first & downloaded something & were added to the engagement program on a Sunday. I'd like them to continue to recieve correspondence in respect to that initial approach.As a future case, the Cadence of Random. What I think lulls people into no longer reading your emails is to always send them on Tuesday at 2pm. This new cast system is great, but I think over time people get a bit desensitized to the repetition.