While building a Creatio business process, it’s quite common to use the system’s current date to denote the moment a record update is being made. We just need to use the current date system variable and Creatio will automatically assign the current date/time when the process runs.

However, depending on how this is used, you might end up seeing some unexpected results. In the examples below, we’ll attempt three different solutions to update the date and time. The final attempt will finally tweak our process enough to get us our desired result. Check it out.

Attempt #1: Use the Current Date and time system variable in multiple places in a process

Let’s say our main goal is to look at the time spent and determine if it is more or less than 5 minutes. To simulate this example, we can set up a process that assigns an Activity record to start at the current date and time. We can also set the end time to 5 minutes plus the current time in the immediate next step. This is covered in “A” of the process shown below.

Next, we read back the values of the Start and End date and put it on a page to show the results (area “B” in the process above). When executed, we expect the page to show the End time as exactly 5 minutes ahead of the Start time.

When we run this process, it looks like the times are 5 minutes apart. But if you try to calculate the difference between the two dates, it is not going to be just 5 minutes.

Why would this happen? Well, let’s set up a more detailed version of the same Start & End dates using an updated formula.

And here is the result of this change:

Notice how this time we also see the milliseconds. Even though the hours, minutes and seconds indicate a 5 minute difference, there are a few extra milliseconds in the End time that indicate the time difference is more than 5 minutes.

Any subsequent calculations will then malfunction as a result of this millisecond level precision. The reason for this is when the business process goes from one step to the next, the current time has moved slightly, and therefore the current time plus 5 minutes produces a slightly different result. Even if the start and end date were assigned in the same step, there is still the possibility of a millisecond level variance because the values are being assigned sequentially and each time it does the assignment a few milliseconds will have passed.

Attempt #2: Use a system parameter to store current date/time and reuse the same parameter in multiple places in a process

Our next option is to set up a centralized process parameter and assign it the current date & time. The hope is that the centralized parameter will supply the same base date and time to all steps and therefore will not produce a millisecond variance.

The process elements would need to change slightly, so we’ll use the centralized parameter:

Then, we’ll use this same parameter for the Start and End times:

In theory it seems like the parameter will hold the current date and time and this parameter will get used in multiple spots, so we should have the same baseline date and time.

However, when testing, this did not appear to be the case. From observing the execution behavior, it appears the parameter is just a placeholder for the current date and time. So, even though this parameter is used in different steps of the process, the actual current time is evaluated at the time of execution, leading to the same problem we had before.

Attempt #3: Use a system parameter, but force the current date time to be set at the start of the process

Based on the previous two examples, it looks like we need to:

1. Use a centralized value (parameter) so that we have the same time reference
2. Assign this value in a way that forces it to take the current time as soon as the process starts.

To accomplish this, let’s try to use the same process format as the previous example, with one additional script element at the start of the process:

The script code needs just a couple of lines to assign the current UTC time to the centralized date parameter:

Now if we execute the process, the Start & End times are exactly 5 minutes apart, even down to the millisecond.

Now that we have the values set up precisely, any subsequent calculations should work correctly and produce the expected results during process execution.