The scheduler and orchestration engine built with and for Liberty Next. It runs inside the framework process — no separate worker, no broker, no companion daemon. Schedule cron jobs, run ETL pipelines, mirror LDAP, fan out HTTP calls, and let operators watch every run live from the same UI as the rest of the application.
What it solves
Without Nomaflow this usually means cron tabs scattered across hosts, Python scripts in different repos, no shared retry logic and no single place to see “what just ran”. With it: one catalogue of jobs, one history of runs, one live log tail — in the same UI as the rest of the application.
Pull data from an operational store into a reporting store, on a schedule.
Fetch from a third-party service every hour, with retry on failure.
Mirror users and groups from the directory into the application.
Prune old records, archive PDFs, delete expired sessions.
Run only when something happened — a file landed, a count crossed a threshold.
An operator triggers it from a button after a release, with parameters.
How it works
A job is a catalogue entry; the in-process scheduler fires it on cron, an interval or a manual trigger; the step engine runs SQL, Python and HTTP steps with retry and timeout; the run history surfaces every run with a live log tail.
Patterns
Cron at 02:00 → SQL Copy from source pool to target pool → success notification.
Cron hourly → HTTP step with bearer auth → Python transforms the payload → SQL write.
Cron every 4 hours → LDAP Sync step → upsert into the users table.
Cron daily → SQL count of old rows → conditional Python step deletes past a threshold.
Cron every 5 minutes → Python lists a folder → per new file, SQL Copy + archive move.
Cron every 5 minutes → HTTP step against your healthz → email alert after 3 failures in a row.
The pieces are deliberately small — a step does one thing. The pipelines compose them; the run history surfaces what happened.
The right fit
The design point is “the operational glue most internal apps need” — not “every orchestration use case”. For the 80% case, it removes a lot of pipe-laying.
A short honesty list, so expectations match what’s there. These are tradeoffs, not gaps to fix — the design point is the small, install-scoped case.
Steps inside a job are linear; you can chain jobs through Dependencies, but the model is “step by step”, not “graph”.
The scheduler runs in the framework process. Heavy parallel batches (thousands of concurrent steps) are not its strong suit.
Nomaflow knows which steps ran; it doesn’t track which columns flowed from which source to which target.
You can replay a finished run; “re-run for every day of the past 90 days” is a Python step you write.
No second stack
Nomaflow reuses the framework’s connectors, permission model, encryption layer and Settings UI. There’s no “Nomaflow database” to install, no “Nomaflow user accounts” to manage — if a team already has Liberty Next, they already have Nomaflow.
Reach data sources and APIs through the same declared queries your screens use.
Database connections, shared with the rest of the framework.
job:<name> permission gates per role; :session_user for audit on triggers.
Connector credentials, webhook URLs and OAuth secrets — all encrypted at rest.
The Jobs builder and step editor live there — nothing extra to install.
Live updates on run state, step transitions and the log tail.
FAQ
Nomaflow is Nomana-IT’s scheduler and orchestration engine, built with and for Liberty Next. It runs cron-scheduled, interval or manual jobs made of linear step pipelines, with retry, timeout and backoff, and keeps a history of every run with a live log tail.
No. Nomaflow runs inside the Liberty Next process — no separate worker, no broker such as Redis or RabbitMQ, no companion daemon. It reuses the framework’s connectors, pools, roles, encryption and Settings UI, so there is no Nomaflow database or user accounts to manage.
Jobs are created in the Jobs builder in the Settings UI — no configuration files to write by hand. A job chains steps of five types: SQL Query, SQL Copy, Python, HTTP and LDAP Sync. Custom Python steps cover logic the declarative steps don’t.
The Runs page lists every run with its status and lets you drill into each run, with a live log tail pushed over Socket.IO. Notifications go to Slack, email or a webhook on run outcomes, through channels defined once at framework level and used by every job.
When workloads span a dozen services and need a global DAG view, when a single step takes hours and needs autoscaling, when you need dynamic task expansion or fan-out / fan-in DAGs, or when you already run one of those tools for everything else. Nomaflow targets the small, install-scoped case.
Nomaflow is built with and for Liberty Next. Install the framework, create a job in the Jobs builder, and watch your first scheduled run live.