The interactive HMI shapes can be configured to only be enabled when certain tag conditions are met. This can be useful for creating simple workflows for operators when steps need to be followed in a specific order, or when data shouldn't be entered unless certain conditions are met (a machine is running or not running, for example). Note that this feature only works on Text Input, Button, Dropdown, Combo Box and Toggle shapes.

To set up these workflows, select a valid shape on the diagram canvas, then click the 'Configure Workflow Rules' button in the left panel:

That will open a popup window to configure the shape's workflow rules. Click the green + icon on the right to create your first rule or add additional rules to an existing list:

Each rule is made up of several parts:

• Source Tag Name: The tag this rule is going to monitor to determine if the shape should be enabled. Multiple rules for the same shape can look at different tags.

• Source Tag Parameter: The parameter of the source tag set above that this rule will look at. This is chosen from a list of parameters like Value, alarm limits, etc. Note that some of the options in this dropdown depend on features being enabled on that tag. For example, choosing to base a rule on an alarm limit value will not work if that alarm limit isn't enabled on the tag.

• Data Type: This is the data type (string, float, boolean, etc) of the Source Tag Parameter being monitored for this rule. In most cases, Prophecy will automatically select the correct data type to match the value returned by the Data Acquisition Engine. In the case of 'Value', the user will have to select the data type, as that can vary by tag. This setting determines which Conditions are available (see below). If this is set incorrectly for the 'Value' tag parameter, the rule may not work properly.

• Condition: This is the comparison the diagram will make between the value it pulls out of the source tag and the comparison value you configure below. The available options vary based on the Data Type set above.

• Value: The Source Tag Parameter value you configured the rule to use can be compared to this 'hard-coded' value, using the Condition you configured above. The allowed values in this field will vary based on the Data Type chosen above. For example, you will not be able to enter 'Bob' for the comparison value of an integer tag value. This field will be disabled if a Target Tag Name is specified (see below).

• Target Tag Name: Rather than comparing the source value to the value that can be specified above, you can compare it to a value from another tag. Choose the name of that tag here. This field will be disabled if a pre-defined value is specified above.

• Target Tag Parameter: The parameter of the target tag set above that this rule will look at. This is chosen from a list of parameters like Value, alarm limits, etc. Note that some of the options in this dropdown depend on features being enabled on that tag. For example, choosing to base a rule on an alarm limit value will not work if that alarm limit isn't enabled on the tag.

• Data Type: This is the data type (string, float, boolean, etc) of the Target Tag Parameter being monitored for this rule. In most cases, Prophecy will automatically select the correct data type to match the value returned by the Data Acquisition Engine. In the case of 'Value', the user will have to select the data type, as that can vary by tag. If this is set incorrectly for the 'Value' tag parameter, the rule may not work properly. The editor will not allow this data type to be set to one that is incompatible with the Source Tag data type above. For example, you cannot configure a rule to compare a boolean to an integer.

The image below shows an example set of rules that will only enable a button if one tag value is greater than a preset value, and another tag's value is 'true'. If either of those conditions are not met, the button will be disabled.

Note that when designing a workflow, shapes further 'down' the workflow will generally require more rules. The first button might only require a single check for validity. The second will (probably) want to duplicate that first check, as well as add another, and so on.