Rules and Workflows
Workflow refers to the rules that apply when changes are made to a particular type of record.
An example workflow could be: "When a bug report is created in a state of Open, email Engineering, when it moves to In Testing, email QA, when it is Closed, email the person who submitted it".
The various stages - e.g. Opened, In Testing, Closed - that the record can be in are referred to as states and the workflow engine allows the creation of guards that control how the states may be changed. For example "Do not allow the State to be changed from Open to In Testing unless the Cause of Bug field has been filled in".
Changes in state are referred to as state transitions and the rules that are applied when a workflow changes from one state to another are referred to as actions.
So, in the example above, we have:
States: Open, In Testing, Closed.
State Transitions: Open > In Testing, In Testing > Closed.
Actions: Email Engineering for creation/Open transition.
Email QA for the Open > In Testing transition.
Email submitter for the In Testing > Closed transition.
Guards: Do not permit Open > In Testing transition if Cause of Bug field is empty.
All this is a lot easier in practice, using the GUI, than it seems on paper.
Agiloft provides a graphical interface that makes it easy for the administrator to see and edit the workflows that apply to a particular type of record.
Tables inherit the workflows from their parents. Consider the following hierarchy:
If you create a workflow for Contact, then select Lead and look at its workflow, you will see the Contact workflow that you just created has been applied to it as well.
However, workflows do not have to be the same between parent and child tables. For example, you can augment the workflow for Lead by adding additional states, state-transitions or guards. This will not alter the workflow for Contact, nor will it break the linkage to the workflow for Contacts – if you add additional states/transitions/actions to Contacts, they will automatically show up in Leads.
In brief, sub-table workflows don't contain a copy of the parent workflow, they contain the parent workflow plus their own additions to it.
If you are in a sub-table and try to delete one of the state transitions or edit one of the actions that was inherited from the parent, the system will warn you that this change will affect the parent workflow.