This topic relates to vFire Core 9.2.0, released in December 2014. You may also wish to view other new features, or the release notes in full.

Dynamic Screens

The 9.2.0 release sees the introduction of dynamic screens, where parts of the screen that an officer or customer is completing can be made available depending on dynamically changing conditions.  You can configure rules that will make parts of the screen hidden, read-only or optional until certain conditions are met, at which point they become visible, enterable or mandatory.

Advantages

This helps to keep the screen simple, and reflect the order in which you want things done, helping the officer or customer complete the task in hand quicker.

Where can Dynamic Screens be used?

You can apply these to most of the elements that make up a screen – fields (including HTML fields), headings, and entire tabs or sections. Buttons can even be hidden until required, according to your needs. Wherever the properties Hidden, Read Only or Required appear on a screen element, this new feature can be used.

Who can use this feature?

Once applied by the system administrator, this feature is available for both officers and customers using vFire Core and vFire Customer Portal.

Examples of Dynamic Screens in Action

The following sections illustrate some examples of how dynamic screens can help. You may want to:

• display a warning on the screen if a call is about to breach
• hide non-essential fields when customers are logging a Critical incident
• only show implementation details on a Change after it is Authorized
• hide unnecessary detail on a Service form until you need to add it to the catalog

Breach Scenario

In this screen, the Incident has reached breach level 2.

Once it reaches level 3, the screen changes to display a warning:

Critical Situations

On the vFire Customer Portal, the customer only has to complete the essential details, if it is a critical issue:

Logging a Change

Within a Change, the implementation details are hidden until the request is authorized:

Entering Catalog Information

On the Service Details screen, detailed catalog information is hidden until you need to complete it:

Setting up Dynamic Screens

Dynamic screens are easy to set up – first you define a rule, then you can apply it to as many fields as you want. If you define the rule on a parent screen, it will be available to all its child screens, should you wish to use it.

Rules are defined in a new sub-tab within the View Screens tab when viewing a screen in Designer. Select Create New and use the standard vFire Rules Builder to create your rule. (The Rules Builder is already used for setting up rules for AI Ops, Manage CMDB Task transactions and in the Integration Platform.) Give your rule a unique name, save it, and the rule is ready to use.

 

The Rules Builder allows you to build rules based on the following field types: Text , Numeric, Drop Down, Single Value QD, List Box, Checkbox and Date. It does not support fields of type Text Area, Multiple Value QD or Multi-Select.

 

If you look at a field’s Properties, you will find that most have at least one of the properties Hidden, Read Only or Required, and often all three. Rules appears after “No/Yes” in the drop-down on Read Only and Hidden, and after “None” in the Field Rule drop-down in the Required Field Configuration dialog (if you select the On Condition option).

Pick a rule for the desired property, save the screen, and you are done. Thereafter, if the condition is true, then the behavior will apply.

Dynamic Fields and Actions

You have extra options for the Required property. Here you can link a rule to one or more Action, so that when you perform that action, the rule is applied. For example, you can leave some fields optional until you forward the call, at which point the system will check the rule, and if the condition is true, it will ensure that those fields are filled in first.

This additional feature is available for the following Actions:

Calls	Save/Defer, Forward Internal, Forward External, Close
Requests	Save/Defer, Forward Internal, Submit, Complete
Tasks	Save/Defer, Forward Internal, Complete

You can also make fields Required for Actions without setting a rule, in which case the fields will always become mandatory when that action is invoked.

Improvements on Earlier Versions

Earlier versions of vFire Core had a simplified, less flexible version of this feature. It only allowed you to either make a field Required for one or many Actions, OR for one or many Priorities, OR for one or many Call Statuses. The new version still allows linking to just Actions or just rules, but you can also combine Actions with rules and the rules are much more flexible.

If previously defined, the old rules will be displayed and continue to work. Deselect Required and save the screen to make the new features available to configure.

Additional Information

Not everything has the Hidden, Read Only or Required properties – in some cases they would not make sense – but wherever they appear, the dynamic behavior is available.

Fields that are on related records, such as a customer’s telephone number on a Call screen, are Read Only by definition, so the option to apply a condition to this is not available. As they are not enterable, you cannot make them Required either, so again this cannot be made conditional. You can however make them conditionally Hidden.

FAQ

What happens to screen rules I created using the old Rules Builder?

Any existing rules will be upgraded to the new Rules Builder format and applied in the same way as before.

Can I apply rules to Custom fields?

Yes.

Can I apply many rules to a single screen element?

No just one. If you want to apply two rules, just create a third rule that contains both of the others.

Are rules available on other screens?

Yes - you can see rules from parent screens.

If I clone a screen with rules, are the original rules available on the new screen?

Yes

Does this affect the behavior of the Unique field property?

No – that continues to work as before.

Is it available yet in other parts of vFire, such as vFire Officer and vFire Portal?

Not yet. They will act as if these properties are not set.

Top Tips

• Make sure your Rule name is unique.
• Be careful with your logic – don’t make a field required while it is hidden or read-only!
• Rules you create for a screen will also be available for any child screens, should you wish to use them.

Worked Examples

Here is how to set up the examples mentioned above.

Rule	Apply to Hidden property of … field	… on Screen
SLA Alert Level <> Level 3	new HTML Editor type field with warning	Call Details
Call Priority = Critical	all fields down to Description	Call Submission
Completion Status = Unspecified	Implementation Details (collapsible section)	Request
Service Portfolio Status = Unspecified	Catalog Information (collapsible section)	Service