People operationsEnterprise operations

People operations

A fortnight of small tasks with a start date, and three months of check-ins — none of it holding a process open between its moments.

DjiniousWorkflowAgent automation

A DjiniousWorkflow run parked on a button drawn on the node itself: an onboarding graph waiting for somebody to confirm the desk is ready, with the checklist it published in the output pane.

Delays · timers · a button on the node

Onboarding is mostly waiting, and most automations of it fire everything on day one because holding a process open for eleven days is expensive. Here it is not: a delay is an event with a future time on it, a repeating check is a timer row, and a run parked on a button costs one row.

The probation graph is a single run that spans three months, wakes three times to prompt the manager, and ends itself after the last one. Its period is the only thing a deployment changes.

How the graphs run

Six checklist items fanned out to their owners
Each dated back from the start date.
A delay while the equipment order settles
An event with a time on it, not a worker holding still.
A button on the node for ‘the desk is ready’
Because that answer needs no reason attached.
One run, three check-ins, ninety days
Armed as a timer row that survives every restart.

On the canvas

flow:delay · flow:interval · ui:trigger · entities:create · views:*

It ships with the product

This project ships with DjiniousWorkflow. One command seeds it, another runs every graph in it, and the captures here came out of those runs.

Where a graph leans on a fixture rather than a live system, it reads the fixture where your deployment would read a database — swap the node at the top and the rest of the graph does not change. The engine work — the fan-out, the gather, the approval, the publish — is the product’s own.