ZDS

Kintana Standards

Kintana is all about decisions.

At each manual step you must present the user with a list of choices.

Kintana's term for a set of choices such as : 'Approve', 'Cancel', 'Decline' is a 'Decision'

To add a new step you need to select a 'Decision' from the 'Decisions' list on the 'Workflow Step Sources' dialog and drag it over to the 'Workflow' construction window.

If there is no ready made Decision with the choices you want, you will need to add a new decision to the list.

When selecting a decision, you need to know :

How many choices it supports.

Whether it contains the choices you want.

Unless you've been very consistent in naming decisions you'll likely find yourself opening a decision dialog, clicking on the Validation [Open] button to see what choices the decision has to offer, and doing this again and again while trying to find a decision that matches your requirements.

What we need is to be able to quickly and unambiguously locate without a lot of clicking:

The 1,2 3 or 'n' way group of decisions we're interested in.

The decision in that group with the choices we need (if there is one).

The following standard will help you do this, and also ensure that you don't create decision sets that are essentially duplicate sets of choices, or use variant names for the same choice.

It's important to be consistent when presenting choices to the user. For example if you've settled on the word 'Decline' for the user to disapprove something, you don't want to muddy the waters by using alternatives such as 'Disagree' or Not Approved' which mean the same thing.

The recommended format for decision names is very simple. For example:

D3 Approve, Cancel, Decline

D4 Approve, Cancel, Decline, Revise

D4 Approve | Cancel | Decline | Revise

where the number 'x' following the 'D' is the number of choices followed by the choice names in alphabetical order, separated by comma or vertical bar delimiters.

The maximum size of a Decision string is 50 characters. If you run out of space just use trailing ... to indicate there's more.

Enter 'Decision' in the 'Description' field of the decision.

Change the name of the validation supporting the decision so it's the same as the decision name.

You have a longer length field to work with here so over flow should not be a problem.

Enter 'Decision' in the 'Description' field of the validation.

A side benefit is that you'll find that it's a lot easier to find a particular validation in what is usually a rather long list when the numerous validations providing drop down lists in support of decisions are all neatly sorted into 'Dx's, and their description field clearly identifies them being used to support decisions.

The opposite also applies : Drop down validations that support things other than decisions are now easier to locate.

If you decide to implement this standard, there's a script here that can help you with the task of changing your decision and validation names.

We suggest you start by running this. Look for duplicate decision sets, and variations in individual choice names.

It'd be nice if ...

The 'Workflow Step Sources' dialog is one of the very few places in the Kintana GUI where a tree structure is used. It would be very nice if we could click on a decision and get it expanded to a sub-tree without having to click two dialogs open to get to the validation.

And even nicer if the bullets were larger and contained numbers indicating the number of choices in the decision set.

For example:

(3) Approve | Cancel | Decline
     :.. Approve
     :.. Cancel
     :.. Decline

Kintana™ and 'HP PPM (Project and Portfolio Management)'™ are trademarks of Hewlett Packard Corporation.