Projects, Processes, and Jobs
BizOps Engine uses a three-level business hierarchy. The workflow definition is stored at the job level.
Concept Map
Project
└── Process
└── Job
└── Workflow document (steps, edges, metadata)
└── Optional step-data documents
| Entity | What it represents | Typical fields |
|---|---|---|
| Project | Business portfolio or domain bucket | name, description, criticality, domain, status |
| Process | Automation stream inside the project | name, owner, trigger type, health, enabled |
| Job | Runnable configuration instance | name, version, environment, status, last run |
| Workflow | Graph persisted for the job | metadata, steps, edges, viewport |
| Step data | Optional externalized step payloads | referenced by stepDataId on steps |
Projects
Use a project when you need a shared home for related processes — for example Platform Operations, Customer Onboarding, or Finance Close.
Common create fields:
| Field | Why it matters |
|---|---|
| name | Primary label in lists and navigation |
| description | Helps other operators understand scope |
| criticality | Signals business importance (for example High) |
| domain | Groups projects by operating area (for example SRE) |
| status | Active / inactive portfolio state |
Processes
A process describes one automation stream. Multiple jobs under the same process can represent versions, environments, or alternate configurations of that stream.
| Field | Why it matters |
|---|---|
| owner | Accountability for the stream |
| triggerType | Documents how runs are expected to start |
| healthStatus | Roll-up signal for operators |
| enabled | Soft switch for whether the stream is live |
Jobs
Jobs are what you execute. Each job has its own workflow document, scoped by version and environment conventions used in your deployment.
| Field | Why it matters |
|---|---|
| version | Distinguishes successive job definitions |
| environment | Production vs non-production targeting |
| status | Runtime / lifecycle state of the job |
| lastRunResult | Quick outcome of the most recent execution |
Workflow document
The workflow JSON is the source of truth for the canvas:
- metadata — name, description, version, timestamps, author
- steps[] — canvas nodes with action type, action name, parameters, and position
- edges[] — connections between steps
- viewport — optional camera/zoom state for the editor
Legacy imports may still contain React Flow nodes; the client converts those shapes on import. Prefer the current steps + edges model for new work.
Step data documents
When a step payload is large or reusable, the engine can store it separately and keep only a stepDataId on the step. On load, the client may call a batch hydrate endpoint to merge those payloads back into the workflow for editing.
| Pattern | When to use it |
|---|---|
Inline step.data | Small, job-specific configuration |
| External step-data docs | Large tables, shared configs, or payloads reused across edits |
Recommended modeling
| Goal | Recommended shape |
|---|---|
| One business outcome with one happy path | 1 project → 1 process → 1 job |
| Same process in QA and Production | 1 process → 2 jobs (different environments) |
| Shared portfolio with many streams | 1 project → many processes → jobs per stream |
| Experimental redesign of a live job | New job version under the same process |