Flow 5.3 is here!

Flow 5.3.0 was officially released on Wednesday 6th May 2020, and you definitely want to upgrade to this version now!

Among the various tweaks made to Flow with each release, the following are the highlights in version 5.3.0:

More, More, More Performance!

The team went deep under the hood to improve the performance of the Flow Config tool and the Flow Data Engine.

You'll notice a vast improvement in the loading time of the Config tool.  In some cases, based on benchmark tests performed in the Flow labs, the loading performance has improved by more than 500%!

We were looking forward to wowing you with these improvements in the next major release of Flow (currently codenamed Flow 6.0), but decided "why wait?"

As you work with the Config tool, especially in the Model View, where most of us spend the majority of our time in, notice the fluidity with which Flow responds to your requests.

In the near future, you can look forward to yet more enhancements in the Model View, as well as the same performance boosts being applied to Reports and Templates.

Even with the groundbreaking changes made to the Config Tool in this release, make sure that you're doing all that you can to improve the performance of all the components in your Flow Platform - check out these articles:

A Major Focus on Events

When most people talk about Flow, they think in terms of "Measures".  That makes sense, considering the fact that there are far more Flow measures out there... With this release, we decided to also show some love to "Events" in Flow.  Have you unleashed the power of Events in your Flow Platform?

Events have been around since the beginning of Flow, and more and more our customers and integrators are thinking of innovative ways to extract value using Events.  Based on their feedback, we've brought in some nifty functionality around events, such as:


Calculated Attributes

The ability to create attribute values based on other attribute values, even across different events.  Why would you want to do this?  Think about the following requirements:

  • You have two attributes, one called Brand and one called Pack, which the operators select in their Product Run Event Form.  But, the key that you reference everywhere else is SKU, which is a combination of Brand and Pack.  Perhaps the SKU tells you what the pack configuration is, and what the rated speed is. Now, you can create a calculated attribute which concatenates the Brand and Pack attributes - voila!, you have your SKU attribute which you can then use to set other attributes
  • You have an attribute on a Stop Event that you use to categorize the stop into a Micro or a Macro Stop.  You have a business rule that states that if a stop is longer than 3 minutes, then it is a Macro Stop, else it's a Micro Stop.  Until now, you've been getting your operators to classify the stops... Now, you can create a calculated attribute to do that for you!
  • You would also like to include SKU as an attribute in your Stop Event (you're sure that some SKUs cause more downtime than others, right?) and you really don't want the operator to have to select the SKU with each stop.  After all, you have the Product Run event in which they're already selected the brand.  With a calculated attribute, you can "read" the SKU attribute from the Product Run event (which, by the way, is also a calculated attribute itself - see above).  You can even configure whether Flow must look for a Product Run event that is at the same time as your Stop Event (i.e. an "overlapping" event), or if it must look for the previous or future Product Run event.  That doesn't make sense though...
  • But where it does make sense is where you have a Mixer Batch event which has a Batch ID (which you can use Flow to generate) and you want to link your Product Run event to that Mixer Event, because you're interested in including the Mixer Batch ID in your Product Run event for genealogy and traceability purposes.  But your Mixer Batch completes hours before your Product Run starts. In fact, when your Product Run starts, your Mixer is usually busy with the next batch.  No problem!  Create a calculated attribute (e.g. Mixer Batch ID) on your Product Run event and link it to the Mixer Batch ID on the Mixer Batch Event, but tell Flow to fetch the "previous" Mixer Batch event's ID and not the current one.  Or, if there is a potential for the Mixer Batch to overlap the Product Run event, tell Flow to fetch the previous and "first" overlapping Mixer Batch ID

With calculated attributes, you can either use the "Insert" menu in the calculation editor to include various attribute properties in your calculation, or you can write your own C# code (because, let's face it, some of you love to code almost as much as we do).  As with Flow's measure calculation editor, you validate the calculation before deploying the event - Flow will confirm that there are no syntax issues in the calculation.  Of course, if you wanted to add "X + X", but you added "X + Y", the Flow validation is not going to pick that up.

Not in this version, at least... (PS. with that kind of logical error, you're going to end up with a male instead of a female)

For more on using calculated attributes, see the following articles:

Initial Values for Event Attributes

Have you ever configured an attribute and wished that Flow could create for you with a default attribute? 

Or, have you ever wanted Flow to just set an attribute value in a new Event Period to be the same value as the previous Event Period? Perhaps it's the Brand that you're running and instead of manually capturing 

What about this: you've configured an enumeration group which links together multiple attributes (very clever!) and which ultimately yields an attribute that gives you the rated speed for the SKU selected.  Until now, this was possible in Flow, by configuring your Event Period Forms with the enumeration group.  A drawback of this was that you needed to include in your form all the attributes that you needed to yield that Rated Speed attribute. Not necessarily a drawback though - for good purpose, you may need to display those attributes anyway on a form for a super user to correct data capture issues.

Now though, you can achieve all of the above:

  • You can configure an attribute and give it a value, perhaps something rational like 3.1415926535.  A user may still update this value thereafter if need be - the Flow engine merely sets the attribute value to that which you configured
  • You may choose to configure an attribute to use the same value as was entered for that attribute in the previous event
  • An enumeration group may be configured to automatically set numerous attribute values based on other attribute values, so long as they're all in the same enumeration group.

Putting this altogether, you can do something like this:

  1. User selects a Brand and a Pack (separate attributes)
  2. The Flow Engine calculates an SKU attribute (concatenates the Brand and Pack)
  3. The Flow Engine also fetches the Mixer Batch ID from the last running Mixer Batch and puts it in a calculated attribute in the Product Run event
  4. The Flow Engine uses the SKU attribute, in conjunction with the Initial Value configuration, to set three attributes: the Pack Configuration (e.g. 4x6 boxed juices); the Rated Line Speed [boxes/hr] (eg. 15000 boxes/hr); and the Rated Line Speed [cases/hr] (e.g. 750 cases/hr)
  5. The Flow Engine sets another attribute, called "Shift Team", to be the same value as the previous event's Shift Team, using the Initial Value funtionality; since the business rule is that the new team coming on shift must change this attribute for the first Product Run started in their shift.

Read more about how to use these new features here:

A New Way to Configure Limits

Limits are essential to providing insightful information as to whether your processes are optimal or not.  To date, when you needed to adjust your limits, perhaps quarterly or annually due to stretch targets or budgets, a Flow Config tool user was required to open the corresponding measure configuration editors and change the limits manually.

In reality though, it's not the Config tool user that owns those limits, but the process owner.  Alas, the process owner doesn't have access to the Config tool (perhaps a good idea?), and so the onus is back on the Config tool user to assist with these adjustments.

Some of our users devised an ingenious solution to this problem - they used measures in the limit configuration, put these measures onto a Time Period Form, gave the process owners access to the form, and put the ownership of the limits back where the ownership ought to be.

While this is still a preferred solution for this, because of the full audit trail that is visible from the front end of changes made to limits, and the potential to add comments about why those limits were changed, we thought that things could be somewhat simplified for some by creating a Limit Form.

With a Limit Form, even though you may have constant values in your limit configuration, you now have the power of changing these configured limits via the browser.  Of course, only those to whom you've granted access may do this!  When an authorized user changes a limit, Flow will automatically apply that limit value from the date at which that limit was active from.  There is still an audit trail, but you will have to look in the Config tool for these records.

See this article for more information: Configuring Limits using a Form


Access to Another Measure's Limit Values in a Calculation

At times we've been asked whether we can use another measure's limit values in a calculation.  Yes, not another measure's values (because that's a no-brainer: definitely yes), but its limit values - the configured Target, Low and High values.

Why, you may ask?

Think of a situation where you're interested in plotting your Water Usage between an upper and a lower band.  But your business hasn't defined an upper and lower limit for Water Usage, because it's a forward-thinking business and opted to define upper and lower limits for your Water Ratio (where Water Ratio = Water Usage / Production Volume).  This is a better KPI to track, because the business may have different plants with different capacities, so defining Water Usage limits per site is cumbersome.  Also, a plant's water usage may be well below their Water Usage target, so everything looks hunky-dory, but guess what? The plant hasn't produced for two thirds of the week... Having a Water Ratio target will prevent this potentially incorrect view of performance.

But, we digress.

With this new functionality, you can use the Ratio's configured Low, Target, and High values, multiply them out by your Production Volume measure, to get a dynamic Water Usage limit "band" which you can then plot your actual Water Usage against.  If you want to take it further, use the calculated measures which you created above as limits for the Water Usage measure!

You may also be interested in how far off a process is from its limits - going back to our Water Ratio example, let's say the High limit value is 5 liters water per liter of volume produced.  Two of your plants are tracking within that target: Plant 1 averages at 3 liters/liter while Plant averages at 4.98 liters/liter.  They're both within target (so they both look a nice Flow green on the chart) but clearly one is doing something better than the other.

Why not introduce a KPI which compares the actual value with the High limit value - now you'll see that Plant 1 is 40% away from the target while Plant 2 is only 0.4% away from the target.  Get the guys in Plant 2 talking to the guys from Plant 1 ASAP!

Learn more about how to use this functionality here: Using another Measure's Limit values in a Calculation -e.g. Compliance Reporting

New Word-Tree Chart to visualize user-entered Comments

Some of you love entering comments in forms and charts.  And we love that you love entering comments!  Wouldn't it be nice if you could see all the comments entered against a selection of measures for a selected period of time?

Now you can! Using the Comments Chart, new to Flow 5.3.0, you can now visualize all the comments, for the measures you add to the chart configuration, and for the selected time period, in a word tree chart.  You'll see any and all comments, what version of the value they were captured against, what the value was/is at that version, and who entered the comment.

You can choose to, by default, show only the latest comment entered, and branch out the tree manually where additional comments exist.  Or you can choose to view the entire tree by default. 

Read more here: Comments Chart

Ability to Hide columns/rows on Charts and Forms

There are times when you want information on a form, but you also don't want that information if it's not relevant for the selected time period.  Perhaps you have a measure that you're using to capture the amount of produced stock that was quarantined (hey, we all know the meaning of "quarantine").  Additionally, there can be reasons why the stock was quarantined, and you would like the person responsible for data capturing to allocate the quarantined stock against one or more of those quarantine reasons.

So, you add the measure for the total quarantined stock, along with the 3 quarantine reason measures, to your Event Period Form.  But, what if there was no stock quarantined for the selected time range? Do you really want to show 4 blank columns in your form? We'd proffer "no"...

With this new functionality, you can add these 4 measures to the form, and configure them with one of the following visibility types:

  • Hidden When Null - if all values for the measure are null for the selected time range, this measure will be hidden
  • Hidden When Zero - if all values for the measure are zero for the selected time range, this measure will be hidden
  • Hidden By Default - the measure will be hidden when the form is first opened
  • Visible When Null - if all the value are null for the selected time range, then show this measure

The clue is in the name... With all of these visibility types, the form user has the option to click on the Visibility "eye" icon in the top right of the form, and unhide the measures/columns that they wish to see and/or capture data against.

In our example, if all 4 measures are Manual Measures that are Set to Zero, with a visibility type in the form of Hidden When Zero, this will meet our requirement to not show the measures unless they have non-zero values; and to unhide these measures where we need to capture values against them.

We extended this to charts as well - for now, all "table" type charts have the ability to set visibility types on the measures - for some charts (e.g. Time Based Table [Landscape] and Time Base Comparison Table) this property may be used to hide rows, and in other charts (e.g. Time Based Portrait Table and Event Based Table), this property may be used to hide columns.

The difference between forms and charts is that one can't unhide a hidden column/row in a chart.  Also, you cannot set a measure to Hidden By Default in charts. We're mulling this over as to whether to include this in a future version (READ: when we will include this is a future version).

Charts do give you one more special visibility property:

  • Visible When Limit Exception - if there are any values for the specific measure against which this visibility type is configured where the value breached a configured limit, then only will the measure's column/row be displayed.

We thought you'd like this one too! Now you can have "by exception" type reports where the only measures shown in your table are those where there was a problem.  Less is more!

From a backward compatibility perspective, when you upgrade to Flow 5.3.0, all your measures in charts that have visibility type options will be set to "Always Visible", the default behavior of all versions of Flow until now.

SQL 2019 Compatibility

We try to stay on the leading edge of technology, even though at times it is actually the bleeding edge.  While we were dotting the t's and crossing the i's (is that right?) on Flow 5.2.2, Microsoft released SQL Server 2019.  Make no mistake, the team is good, but we also have processes to follow! 

So we had to hold out until now - from Flow 5.3.0, SQL 2019 is fully supported by Flow.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


  • Avatar
    Almero Roux

    Is there a V5.3 Training Manual?