This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
When I use the DateTimeStart function in two different locations in my workflow, I sometimes get different results that are off by one second. This wreaks havoc on my workflow as I rely on the original time stamp at various points in my workflow.
This is still erroring when I run a time stamp in a batch macro. Each iteration of the macro is generating a different time stamp, but I just want the time stamp for when the macro first began running, not each iteration time.
This sounds as though the issue is that DateTimeStart returns the date and time of the current process / module. When you batch your workflow to run for each instance specified by the control parameter - the workflow (module) is running and resetting numerous times resulting in many different DateTimeStart values being output.
1. If your workflow runs relatively quickly - you could calculate a column for DateTimeStart after the results of the batch macro have been processed to representing the time that the workflow was first run rather than the time the batch macro was run.
2. If you want the exact time your batch macro runs, then once the batch macro has finished running and all the records continue are output - you can summarize the lowest value for your DateTimeStart column and append back to the results prior to any further processing.
I've attached a workflow to try to illustrate both above solutions.
Thanks @lmorrell . I ended up just making the starting time stamp in the main app outside the batch macro and passing it through the macro as a input.
I still do think the time stamp feature needs to be worked on though, and perhaps the technical team can take a look at it. For a regular workflow, there should be no reason that it returns a value partway through the workflow. Cheers.