# Addressing more complex business processes in DF

### Assumptions:
- Form might have a list of steps to-be-executed in order to complete the form. This is the form workflow.
- [Invariants](https://hackmd.io/@argonauths/ryx0K-bjT) may define additional business logic that impacts form execution. Applicable independently from form workflow or applicable in a certain step.
- When a form requires to mimic roles, i.e., actor A fulfills and signs part X, actor B part Y and actor C part Z, form workflow imposes the same step repeated three times. Each step contains pages that are shown within this step.

### Workflow concept

1. DF has a set of supported steps that have logical consequences within the app. Any customized workflow defined for a form must adhere these steps.
2. List of supported steps:
a. `pending` – not started
- default starting step
- form schema modifications possible
- form prefilling possible

b. `work_in_progress` – a person has started fulfilling the form or it is the next cohesive part of the form for another person
- form schema modifications not possible
- form prefilling not possible
- additional configuration possible, primarily presenation concerns like list of pages to include

c. `review` – may occur after `work_in_progress`
- form schema modifications not possible
- form prefilling not possible
- additional configuration possible, i.e., signature(s) to include or provide summary for the form part under review.
Signature component advances from being form attribute to a logical step

d. `complete` – form workflow done, all invariants are met
- may dispatch external notifications
2. Endpoint that creates the form enables to provide workflow steps, i.e.

    {
      config: { 
        workflow: [
          { s: "work_in_progress", p: [ list of pages] },
          { s: "review", s: [ list of expected signature attrs ] },
          { s: "work_in_progress", p: [ list of pages] },
          // ... no review step === no signatures
          { s: "complete" },
        ]
      }
    }
    

### Rule concept for invariants

1. Although [invariants](https://hackmd.io/@argonauths/ryx0K-bjT) has broad scope and impact, we focus on invariants that employ conditional expressions.
2. If an expression passes, there's a way to specify what is the behavior, i.e. show X.
3. Rules are distinct to workflows at this stage. It means rules apply to specific attributes.

[
  { # rule
    l: "rule label",
    a: 'attr.path',
    t: "condition",
    c: { # present for type "condition"
      e: "expression" # LUA based
      m: /* matching */ {
        // here we define "the impact" of matched condition, i.e.:
        // - show an attr or the whole reference
        // - ...
      }
    }
  },
  { # another rule
     ...
  },
]