You can incorporate processes and other business rules relevant to your organization by adding workflows to the asset management system of a Model Manager server. While assets — as described so far — primarily act as containers for project data, workflows enables you to extend assets as to capture the project process itself. This includes, for example, defining the various stages of a project, the group of people involved in each project stage, and how a project may evolve between different stages.

A workflow is typically defined as a collection of workflow states and a collection of workflow transitions in-between those states. The workflow management system of a Model Manager server builds upon the asset types and attributes you have added to the asset management system — see Adding New Types of Data Using Attributes and Adding New Types of Assets. Workflow states are determined by the attribute values of assets. Workflow transitions happen when those attribute values are modified by saving new versions of assets. The workflow state history is directly reachable through the version history of the asset.

For a primitive attribute workflow, the workflow state is the current value of a primitive attribute on an asset. A workflow transition corresponds to changing that value by saving a new asset version. The workflows themselves are applied in the asset management system by adding them to asset types.

The workflow state for a primitive attribute is defined by the current state values for the attribute. For a Combo box, Radio button, User picker, or any other widget in which users specify a single value, the state value is simply the attribute value itself. For widgets in which multiple values may be specified — for example, Checkbox list, List box, or Users picker — the workflow state is a collection of state values.

In the workflow management system, state values are examples of state conditions. A state condition is a condition posed on the current state values. It is either satisfied or not satisfied. For a state condition of State value type, the condition is satisfied if its defined value is one of the current state values.

A state expression is a state condition written as a filter expression using the Model Manager search syntax. The state condition is satisfied for a collection of state values if the filter expression would match assets with corresponding attribute values when searching.

A Model Manager server also has built-in state conditions that can be used as dynamic shorthands for state values and state expressions. The Any state value condition, for example, is satisfied for an attribute with any non-empty value, the No state value condition is satisfied for an empty value, and the Current user condition is satisfied for the user currently saving an asset. See Table 3-8 for a complete list of all built-in state conditions for primitive attribute workflows.

You can define a default value for a primitive attribute by specifying that a state value is a default state condition. The corresponding value of a default state condition is automatically set for a primitive attribute if the current attribute value is empty — either when adding a new asset or when updating an existing asset with an empty value. You can also specify some of the built-in state conditions as default.

Transitions occur if the state values for the primitive attribute are modified when saving an asset. Some state values may be removed; others may be added. A transition is defined as a collection of state conditions that are satisfied before saving an asset — the from-state conditions — and a collection of state conditions that are satisfied after saving an asset — the to-state conditions. A transition is enabled if all its from-state conditions are satisfied. An enabled transition has fired if all its to-state conditions are satisfied.

An action transition is a transition that is represented on the Asset page as a button. When a user clicks the button, a new version of the asset is saved with all state values matched by the from-state conditions removed and all state values identified by the to-state conditions added.

A primitive attribute workflow may be in one of two modes. A process workflow restricts the possible values of a primitive attribute to the state conditions of type State value explicitly defined for the workflow. Changes to the attribute can only be performed via action transitions — modifying an attribute value in some other way is prevented by Model Manager. As the name suggests, you typically use this type of workflow to set up some process in which assets move through various “stages” as described by the workflow’s state values. More than one state value may be satisfied at any given time for attributes that can store multiple values in an array. Transitions of type Action transition for a process workflow typically correspond to tasks that should be performed to reach the next stage.

A free workflow does not impose any restrictions on the values for the primitive attribute, nor how the values may change via transitions. Workflows of this type are typically used to define default values or to grant permissions for primitive attributes. They are also useful as secondary workflows to run some type of side-effect when a transition for some other workflow fires — see Workflows for Composite Attributes and Workflows for Asset Types.

You apply workflows for primitive attributes present as members of a composite attribute by adding them as member workflows to a composite attribute workflow. This enables you, for example, to set up a workflow process for the collection of data found in each table row on the Asset page. Composite attribute workflows are applied in the asset management system by adding them to asset types.

A composite attribute workflow can also be used to set up dynamic dependencies between primitive attributes by defining state conditions and transitions for the composite attribute workflow itself. A transition may have one or more activities that conditionally runs when a transition fires. A perform transition activity can be used to automatically perform an action transition for a primitive attribute workflow when the transition for the composite attribute workflow fires. A transition cancellation activity can be used to prevent a save if some state conditions are satisfied when the transition fires.

You apply workflows for primitive and composite attributes by adding them as member workflows to an asset type workflow — the overall workflow defined for the asset type itself. Similar to Workflows for Composite Attributes, you can add state conditions, transitions, and activities for the asset type workflow, thereby enabling you to set up dependencies between different primitive and composite attributes on the Asset page.

By adding permissions to the workflow of an asset type, you can define access control rules that apply to all assets with that asset type. You can, for example, grant permissions to users and groups that are allowed to add new assets, open the Asset page for assets, or save new versions of existing assets. The permissions can even be granted conditionally based on the current values for primitive and composite attributes.