Share this page
General Workflow Information
The more time you spend planning a workflow, the fewer problems you will have during its execution. This section explains issues that you should be aware of during the planning phase.
Workflow Control Property
Each workflow is based on one enumerated property, called the workflow control property. You choose this property from those already available for the item type or create a new property.
If you use an existing property, it will probably need some modifications. In StarTeam, to review the properties for an item type that are available for customization, select item > Advanced > Customize. The Customize dialog lists the properties. Some of the application’s enumerated properties are more customizable than others:
- A property with the red and yellow icon is an application field. It is always an enumerated type and is fully customizable. You can add to, disable, rename, and reorder the enumerated type’s values.
- A field with the white and blue icon is a restricted enumerated type. You can change only the names the application displays for the enumerated type’s values. Usually these fields have built-in workflow characteristics.
In most cases you will decide to create your own enumerated property for the item. Each step in your workflow takes the name of a value in the workflow control property. It is recommended to create the workflow first to find out what steps you need, assign names to them, and create the property to have those names as values.
Workflow Responsibility Property
You must also select one of the item type’s properties to be used as the workflow responsibility property. This can be a custom property. It must be a user ID property, one that accepts user names as its values.
Notification Agent sends email messages asking users to accept responsibility for each item at each step in the workflow. Then Notification Agent sets the workflow responsibility property to the name of the user who accepts responsibility.
Multiple Workflows for the Same Item Type
Within a server configuration, all projects and views have the same properties for their item types. When you create a property for an item type, that property becomes available in all items of that type in the server configuration, regardless of where the items reside. This is what makes it easy to share and move items, but it can complicate workflow is some circumstances.
For example, suppose that you have two projects, one that uses an APE and one that uses the standard properties dialog for the item type. The standard properties dialog has a Custom tab that will show any fields you have created for the other project’s workflow. If any of these properties were created as required fields, the users in the project using the standard properties dialog must provide a value for them. The users in the project with the workflow do not need to be aware of this property. It does not have to appear on the form that they use, and whether or not it was created as a required property does not affect them.
Now suppose that the two projects both use workflow for the same item type, but that the workflows are different. Suppose that the first project’s workflow uses all the values for the workflow control property, but the other workflow uses only a subset of those values. If an item is moved or shared from the first project to the second while it is in a state that is not recognized in the second project, that item is stranded in the second project until its state is changed. You would probably want that change to cause the item to branch.
If you are aware of possible pitfalls, you can eliminate or compensate for them before they occur.
