...
Additionally, we want to add other detail depending on where we are in as the process moves along:
Detail | Detail Style | Example |
|---|---|---|
By Desktop Services: | ||
Configuration is already in effect? | Pick either YES or NO | NO |
By Firewall Policy Group: | ||
Reason for disapproval | Descriptive Explanation | This request did not reflect urgency because of Reason A, Reason B, and Reason C. |
The request details in....detail:
...
. |
...
...
Model the Document Workflow
...
- The path that the Request Firewall Change document must take in order to yield a successful lifecycle. This is the route path.
- The various steps in the route path. Each step is called a route node.
- The responsible party or parties who take action on each node. These are either persons, workgroups, or roles.
- The rule scheme applied to each node. These schemes are comprised of rule templates, rule attributes and rules.
Let's lay down a few ground rules about the notation:
Element | Ground Rule |
|---|---|
Request | The first route node, a.k.a. the start node, in the workflow's route path. This is where the Request Firewall Change document is created by an initiator. |
Violet Element | A node in the route path. Each node represents a point in the business process where a responsible party is viewing (and possibly editing) the Request Firewall Change document. |
Lavender Parallelogram | A rule template that is applied to each node. Each rule template is associated with a set of rules and rule attributes. |
Orange Element | A rule attribute associated with a rule template. |
Lime Rectangle | The responsible party or parties who take action on a node. |
Red Arrow | The action that must be taken to get from one node to the next node. |
Blue Join Line | When connected to a rule attribute, it represents a rule that evaluates that rule attribute |
Finish | Means the workflow has completed with flying colors. |
...