Workflow processes can be designed to incorporate the most
effective ways of completing business tasks. You can evaluate your
current practices and determine how you can improve or standardize
them before you design workflow processes.
When you create a workflow process, the product
directs records through paths that you specify. When you design a
process, be sure to consider what can happen at each decision point
and include all the paths that a record can take. You could begin
your workflow implementation with simple processes. You can always
build in more complexity in a later revision.
To design optimum workflow processes, consider the
following guidelines:
- Generic processes require less maintenance than
highly specific ones. For example, you could modify roles that resolve
to an individual more frequently than roles that resolve to a person
group.
- When designing processes, consider when you want
the product to generate notifications. The product can generate notifications
when the following events occur in a process:
- A record reaches a decision point (node)
- A record follows a specific path (connection line)
in a process
- Task assignments are made
- When designing processes, consider how you want
to handle null values. A process could reach a decision point that
evaluates data on the record and that data could be missing from the
record.
- When a record takes the negative path, you can
design the record so that it can be modified to take the positive
path. You could also design the record to exit the process permanently.
- If a record can go through a process again after
it has been rejected, you can define a limit to the number of times
a record can repeat the process.
- Try to avoid having separate groups of nodes and
connection lines that perform the same function at different points
in a process. It is more efficient to reuse the same code through
looping or through creating a subprocess.
- Simple processes involving a limited number of
nodes are easier to troubleshoot and maintain. If the number of nodes
in your process grows too large, you could break down the process
into subprocesses.
- When writing Structured Query Language (SQL) statements,
consider how the SQL syntax affects how the product interprets the
statements. The following examples demonstrate the use of the colon
in SQL statements:
- ASSETNUM - (without a colon) Instructs the product
to go to the database for the asset record
- ASSETNUM - (with a colon) Instructs the product
to use the asset record in memory (the record currently on the window)