question

Process Flow was designed as a way to graphically define logic in your model. Rather than hiding logic in triggers on objects through messages and entry/exit triggers, we wanted to expose all of that in something that was easy to read and follow. Process Flow is self documenting as you build your process and apply names to each of your activities. It becomes very easy to walk non-engineers and non-programmers through a process when it's graphically laid out.

In addition to exposing logic, Process Flow also reduces the need for writing code. Each of the activities is designed to a very limited amount of logic. This allows you to break everything up into very small steps and keep away any of the 'hidden' logic that is found in all of the standard FlexSim 3D objects. Process Flow can help make very complex problems much simpler and easier to handle. Things that would otherwise require a lot of custom coding to accomplish in standard FlexSim can now be done with just a few activities and little to no code.

Tokens are really the heart of making Process Flow work. They store all of the data on them that the activities use. As a token moves through the model, it collects data that can be accessed and manipulated. We designed the tokens to be as small and memory friendly as possible. You'll notice when you drag an activity out that many of the property fields have a Label: labelName in them. This syntax (which is equivalent to saying getlabel(token, "labelName")) was added for two reasons:

1. For a new user who isn't comfortable with coding, it provides a more concise label access on the tokens that is easier to read less 'scary'.
2. It's faster execution that executing code, and as this label access happens all over the place, it made for some decent speed improvements.