2

We have developed a custom activity that returns the date and should populate DE/ This date is used in Wait by attribute activity which follows custom activity. The problem we face is that we receive 200 response and JB allows contact to progress through the journey (exit custom activity and enter wait by attribute activity) before date is updated in the DE. Therefore, contact just skips the wait by attribute activity. We tried SOAP and REST requests but it does not help.

Do you have any ideas on how to ensure that DE is updated before letting a contact to exit the custom activity. Could it be achieved with outArguments? (as far as I understand they could be used only in other custom activities and therefore won't help in this case)

6

You should add in a decision split after your custom activity that checks whether that date is NULL in the data extension. If it is, then have a wait step (15mins - 1hr) before you rejoin the path and proceed to your wait by attribute step. This would also allow your application time to log any contacts where the insert failed and then run batch jobs to try and perform the action again before that step occurs.

Relying on your custom activity to generate data that will be utilized immediately following its execution is just setting yourself up for failure and leaves you with little recourse for resolving any errors that come up.

| improve this answer | |
  • Thank you, Jason. That's exactly what we came up with. And it works well so far but it does not look like a really elegant solution. And could you elaborate a bit more on your last statement regarding relying on custom activity? Could you provide some details/insights on what created such opinion on your side? – Artur Krotkov Dec 4 '19 at 16:07
  • 1
    Unfortunately there are a lot of scenarios in SFMC where you have to throw elegance out the window to reach the solution lol. The reason for my opinion on that is that you are leaving yourself dependent on the execution window between your app, the hosting service and marketing cloud. In a normal web app we can add in safeguards/fallbacks that can deal with any contingency, but you are limited in SFMC in what you can implement (which is why I suggested the above). The extra 15min-1hr wait provides you some cushion for any issues while not really impacting your original use-case. – Jason Hanshaw Dec 4 '19 at 16:24
  • Jason, we managed to achieve reliable results by using outArguments and defining them specifically in Wait by Attribute activity. The attribute outArgument became available for selection as a Journey data once we configured it in the correct format in the custom activity. Now Wait by Attribute activity explicitly waits for the data from custom activity and the journey itself is very elegant. – Artur Krotkov Dec 8 '19 at 7:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.