Include fields created specifically for journeys to be available within the webhook and API results
@Andrew Tomlinson MAN We've started to look at this and it would be useful to understand more about your use case. What will you do with the Journeys data? This will help us consider what we need to build.
@Mike Emery: hi Mike, our intention would be to use these fields for many different data types, for example we are thinking of adding a cancellation process which could include the reason for cancellation, if at all possible we would also like to map the text value selected to a key value that we can use in our warehouse to map without joining on varchar values, if not it's no issue but would be a nice to have. Other data types would be date time e.g. date the plan was requested to cancel, the user that requested the cancellation. We also want to include a fixed sales process where the user who is selling the plan is stored as the sales user, the plan type is recorded, the value of monies paid is recorded, and certain customer details and confirmations are verified. What we are finding is that we are quickly using up the available additional fields, and users are forgetting to add dates, names, and certain values that we need to accurately record the sales. When we receive a webhook we stage and process the data into a Kimball DW so having these fields on the same webhook would be ideal, if not then as long as we have a relation between the two and the webhook is triggered within a reasonable time of the other webhooks then we can process them as separate entities and bring them together on our side.
Let me know if you need further details.
@Andrew Tomlinson MAN: Many thanks
@Andrew Tomlinson MAN: Thanks for the info it's really useful. Just out of interest when you webhook the information across would you be looking at including all data known on the lead (both Journeys and FLG fields) or would you prefer a webhook to fire when a journey is completed just including the data stored on that journey?
@Karen Barker: preferably a constituent list of fields. If that list is different for each journey it would be no real hardship under our use case to code an input for each specifically, however if other customers are intending this for quite a few journeys I suppose it could become cumbersome.
Yes, also very important for us. Ideally through FlowXO or even just webhooks in general.
Thanks for the suggestion, Andrew. Outputs from Journeys is certainly something we will be considering in the future.