Remember those fields we spoke about in the blog post “Discover a new reality for those messy activity logs...”? This is part 2.
Ok, it’s time for those helper fields to pull double duty. See, helper fields absolutely help for breaking up the activity log. They also can help simplify your complex multi-leg processes to keep them from breaking, processing out of order or otherwise failing.
Let’s say you have a process that consists of 5+ smart campaigns working consecutively to fulfill a variety of data processing needs for records being created/updated.
Many times our first reaction is to start building out very elaborate smart campaigns using a variety of triggers and filter criteria. We painstakingly review and test these processes trying to ensure that the processing happens the way we need it to, in the order we need it to.
Inevitably, there’s a hole somewhere in the bucket. This leads to us troubleshooting to understand where the process failed for a record or records. This is very tedious and time-consuming stuff.
But, we can absolutely help smooth this journey out and make the processes much more reliable, readable in the activity log, and able to stretch across workspaces if needed.
To do this we use those helper fields to trigger subsequent processes instead of an elaborate set of triggers looking for various data value changes. This is what it looks like:
-
Use your helper field to kick off your processes and call out the activity in the logs .
-
At the end of your first smart campaign flow , enter a data value change for your helper field. It should indicate which smart campaign(s) serve as your second leg of processing.
-
Something like <—-Send for data mapping—-> would work just fine.
-
Other examples would be <——Send for date stamping——>, <——Send for normalization——>, etc.
-
Start your next smart campaign with a data value change trigger that looks for the value you entered at the end of your previous processing leg above.
-
You will still use combinations of filters to evaluate a record’s eligibility for the smart campaign. This is especially important for branching processes that handle records differently depending on things like geography, lifecycle status, job title, etc.
-
Repeat these steps for each smart campaign except for the last one. Since it doesn’t lead to another smart campaign you don’t need it in the final smart campaign’s set of flow steps.
That’s it. Now you can keep your processing tight and orderly. You’ll notice that your errors on interdependent processes will diminish, and to boot you can see at which point a person falls out of your process. That makes troubleshooting much easier.
DISCLAIMER: This content was created before the advent of executable campaigns, but I'm posting here as I believe it still has value and can be applied in different use cases.
.png)