Context
Workflows are coded, declarative@Step graphs (0094,
0102). Tenants also want to adjust them and to build simple automations
(“when a student enrols, if the plan is premium, send a welcome pack”) without a deploy. A free-form workflow engine driven by
tenant data would be the runtime schema engine that 0011 rejects.
Decision
- Layer 1 — code first. Workflows, steps, actions and triggers are written in code.
- Layer 2 — configurable knobs declared in code, such as
@Step({ configurable }), settings (0108) and hooks, are set in the studio. Code decides what can be configured. - Layer 3 — tenant automations, UI first: “when event, if condition, then action, workflow, wait, notify or approval”, composed only from registered triggers, conditions and actions. An automation is versioned data that references code and adds none. Publishing one needs a dry run, approval at L2 (0099) and is audited.
- The studio visualises coded workflows and live runs from the manifest and the journal.
- Tiering: the visualiser and layer-2 configuration are free; the layer-3 automation builder is Pro.
Consequences
- Tenants get automation without any path to run code that was not reviewed.
- Every trigger, condition and action an automation may use must be registered, which is a design chore per module.
- Automations run through the action pipeline, so iam, approval and audit apply to each step.