Workflow design process

Edit online

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 of 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)