Flow & Workflow
Flow & Workflow is the process automation and orchestration engine at the centre of Nashua 360. It owns a single, unavoidable enterprise problem: work does not stay inside one screen. A ticket that is raised has to be routed, a supplier invoice that arrives has to be approved, a contract that expires has to trigger a renewal review, and a record that changes state has to notify the people and systems that depend on it. Left to individual modules, that coordination fragments into hard-coded rules, inbox chases and undocumented conventions. Flow & Workflow replaces all of it with one declarative engine.
The module gives business owners a visual designer to model processes as flows of triggers, conditions, actions and approvals, backed by a suite-wide event bus that carries every lifecycle event from every module. It sits within System Administration as shared infrastructure, meaning any entity in Nashua 360, from a purchase order to an asset to an employee onboarding case, can start, advance or gate a process without a line of bespoke code. It is the connective tissue that turns a collection of strong modules into a coordinated operating system for the business.
What the engine does
Flow & Workflow provides a complete, no-code process automation toolkit. At its heart is a visual flow designer where processes are drawn as a graph of nodes joined by edges: a trigger begins the flow, condition nodes route it, action nodes do the work, approval and notification nodes involve people, delay nodes hold execution until a chosen moment, webhook nodes reach external systems, and an end node closes the run. Flows are triggered three ways: by an event on any record, on a recurring schedule, or on demand by a person or an AI Worker.
Action nodes cover the operations a business process actually needs: sending email, creating or updating records in any module, calling a registered service across the platform, posting to an external endpoint, and raising in-app notifications. Conditional branching lets a single flow handle every path a case can take, so one design absorbs the exceptions instead of spawning variants. A built-in form builder captures the inputs a manual trigger or an approval decision requires, and SLA timers hold each stage to its deadline, escalating automatically when a step runs long. The result is that a process which once lived in someone's head, or across a chain of emails, becomes an explicit, versioned, observable asset that the business owns and can change in minutes.
The domain and data model
The conceptual model is small and deliberately so, which is what makes it universal. The central object is the flow: a named, self-contained description of how a piece of work should proceed. A flow is expressed as a graph. Its steps are the individual pieces of behaviour, each with a type and its own configuration, and the connections between them carry the logic that decides which step follows which, including the conditions that must hold for a given path to be taken. Because the shape of a process is data rather than code, a flow can be inspected, copied, refined and reasoned about without touching the platform itself.
Every time a flow is set in motion, the engine creates a run: a live instance with its own memory. The run records where execution currently sits, carries the context gathered along the way, the input that started it and the output each step produces, and holds its status from the moment it begins to the moment it completes, pauses or fails. This separation between the design of a process and the individual runs of it is the key idea. One flow can have thousands of runs in flight, each on its own path, each independently resumable after an approval or a scheduled pause. Alongside these sits the approval workflow, a reusable policy that says, for a given kind of record and a given set of conditions, who must sign off and in what order. Approval policy is therefore defined once and applied consistently, rather than being re-specified inside every flow that needs a decision.
Principal workflows
Three patterns cover most of what organisations build. The first is event-driven automation: an author designs a flow, chooses the record event that should start it, such as a case being created or a status changing, and lays out the actions and branches that follow. From then on the engine watches the event bus and fires a matching run the instant the event occurs, with no human in the loop. The second is approval routing: a flow reaches an approval node, the engine creates an approval request, pauses the run and notifies the responsible approvers. Multi-step, parallel and conditionally escalating approvals are all expressed here, so a low-value request can clear on one signature while a high-value one climbs several tiers, all from the same design.
The third pattern is scheduled processing: flows bound to a cron schedule run at fixed times to drive periodic work such as reminders, renewals, reconciliations and housekeeping. A master scheduler evaluates due flows each minute, resumes any runs whose delay has elapsed, and guards against duplicate execution within the same window. Across all three, every run is fully traced. Operators can see which flows are active, follow a run node by node, read the context it carried, and understand exactly why a given path was taken and where a failure occurred.
Functional depth that matters
The precision of a process engine lives in its routing logic, and this is where Flow & Workflow is uncompromising. The condition evaluator supports a rich operator set covering equality and inequality, numeric comparison, string tests such as contains, starts-with, ends-with and pattern matching, set membership with in and not-in, and presence checks for whether a field exists at all. Conditions compose: any group can be combined with logical and, or and not to express arbitrarily nuanced rules, and values are read by dot-path so that deeply nested fields on the record under evaluation are directly addressable. Edges are evaluated in a defined order with a first-match-wins rule, giving deterministic, auditable branching every time.
Execution itself is governed for safety and predictability. Each run advances step by step with its state persisted at every move, so a run survives interruption and resumes cleanly. A bounded step ceiling prevents runaway or cyclic flows. Webhook nodes that reach outside the platform are protected against server-side request forgery and held to a strict timeout, so an external dependency cannot stall a process. The event bus catalogue publishes every event the platform can emit, with dot-notation names and wildcard subscription so a flow can listen to a precise event or a whole family of them. Delay and approval pauses are first-class terminal states, not workarounds, which is what lets long-running, human-in-the-loop processes run for days without holding resources open.
How it fits the Nashua 360 suite
Flow & Workflow is the automation layer every other module builds on, and it earns that position through deep, native integration rather than connectors. It draws directly on the platform's service bus, so any action node can invoke a capability registered by another module without bespoke wiring. It dispatches through the shared Notification Engine, so a flow's messages reach users in-app and by email through the same channel the rest of the suite uses. It runs alongside the ETL pipeline on the master schedule, so scheduled flows and data movement are coordinated on one clock.
Because the event bus carries lifecycle events from across the suite, the module effectively wires everything together. A change in the CRM can open a case in Service Management. An approved requisition in Procurement can create a record in Finance. An expiring agreement in Contract Management can start a renewal review and notify the account owner. A new hire in HR can trigger an onboarding flow that provisions access and schedules tasks. Identity and permissions are honoured throughout, so a flow acts within the same access rules as the people it serves. Flow & Workflow does not sit beside the suite: it is the mechanism by which the suite behaves as a single system.
How AI Workers operate inside it
AI Workers are first-class participants in Flow & Workflow, treated by the engine as users in their own right. Through conversation, a person can ask a Worker to explain what a flow does, why a particular run took the path it did, or which processes touch a given record, and the Worker answers by querying the module's own flow and run data. Workers also act: they design and adjust flows from natural-language intent, start runs, resume paused ones and reroute work when circumstances change, all within their granted permissions.
Their reach extends across every node type. An AI Worker monitors runs for anomalies and exceptions, surfacing a stalled approval, a breached SLA or a spike in failures before it becomes a problem. Where a flow needs information locked in a document or an unstructured payload, a Worker extracts and structures it so downstream conditions can act on clean data. Most significantly, a Worker can serve as an approval or review node itself: the engine pauses the run, the Worker evaluates the request against policy and context, and it either decides within its mandate or escalates to a person with a clear recommendation and its reasoning attached. This turns Flow & Workflow from pure automation into genuine decision support, with human judgement reserved for the cases that truly need it.
