Workflow Service Description and Assumptions

Description (Copied from Kuali Project)

Example Workflow - Copied from Kuali Project

This service controls business processes, orchestrating multiple participants which may be human or machine. If you have a more extended description, you may want to select a portion of it (rather than the whole thing) as the excerpt that is shown on the main page. Just place the "excerpt" macros around the part you want to show up on the description page.

Assumptions (Copied from Kuali Project)

• Workflow Definitions are created ahead of time during configuration
• The combination of factors (typically, type+state+operation) used in the triggering of a particular workflow should be configured in the SOR
  • Ex. We expect to be able to configure what combination of luType, luState and operation triggers what Workflow Definition (or rule to find it)
• Data used to determine which workflow to trigger should not change through the process.
• The path of the workflow may be determined in part by the data in the object
  • Ex. Courses administered by the English department may proceed along a different path than those administered by the Physics department
• Some of the data might be added during the workflow process
• We don't expect the application or user to pick the workflows

Key Concepts

• Especially things that become common sense, and so usually missed by new reviewers

Dependencies

• Note other services that are consumed or that are closely related to this one

Background Documentation

• If we have notes from community design meetings, link to them here.
• If we have relevant sections in Spectrum or another such document, link to them here (or cite section numbers, etc.)