How Nexus works
Turn a complex multi-system process into one governed workflow.
Combine event triggers, connectors, deterministic logic, real code, self-hosted AI, human decisions and system actions without handing the process between separate platforms.
Execution sequence
The sequence below is the same one used across the platform. Each node has typed inputs and outputs, so later steps can reference earlier results.
- integration actions
- 1,480+integration actions
- event sources
- 46event sources
- runtime language families
- 8runtime language families
- trigger through audit
- One runtrigger through audit
Worked example
One run, step by step.
An invoice exception is a useful example because it touches storage, an ERP system, deterministic rules, document interpretation, a human decision and a write-back. In most platforms that is five tools. In Nexus it is one workflow.
- 01Trigger
A file lands or a webhook arrives
A document is written to storage, a supplier posts a webhook, a schedule fires or a message appears on a queue. The run starts from the event itself rather than from a person remembering to start it.
- 02Integration
A prebuilt action retrieves the record
A connector action reads the related record from SAP or Salesforce, using credentials resolved from the vault at execution time. Where no prebuilt action fits, the same step can be a direct API, protocol or database call.
- 03Deterministic
Rules + Code validates and transforms
Required fields, tolerances, entitlements and calculations are checked in explicit logic. Teams write this in the language suited to the task, and the result is structured output for the nodes that follow.
- 04Sovereign AI
A self-hosted model interprets
A private model classifies the case, extracts values from an unstructured document or drafts a recommendation. Prompts, content and outputs stay inside your environment.
- 05Accountability
A human approval node pauses execution
When policy, value or confidence requires it, the run stops and waits. The reviewer sees the input, the deterministic result and the model output, then approves, corrects or rejects.
- 06System action
Nexus writes back or exposes a Function
The operational system is updated, a downstream service is invoked, or the capability is published as a Function that other systems can call on demand.
- 07Evidence
Secrets and results are recorded
Credentials never live in the workflow definition, and each node result is retained so the run can be reviewed, explained and rerun where needed.
Result
A single execution record shows the trigger, the data read, the deterministic result, the model output, the reviewer and the change written back to the operational system.
Composition
Every node has one job.
Workflows are built from small, explicit steps rather than large opaque scripts, which is what makes an execution reviewable later.
Typed inputs and outputs
Each node declares what it needs and what it produces. Downstream nodes reference those results directly, so data movement through the process is visible rather than implied.
Branching and merging
Conditions route a run down different paths based on deterministic results, model output or a human decision. Paths that need to come back together are merged explicitly.
Passing data between steps
Connector results, code node output and AI responses are all available to later nodes in the same structured form, which keeps a mixed workflow as readable as a simple one.
Triggers
Start from an event.
Nexus supports 46 trigger sources across application, platform and infrastructure events. The examples below are representative rather than exhaustive.
Webhooks
External systems notify Nexus the moment something changes.
Schedules
Recurring runs for reconciliation, reporting and housekeeping work.
API invocation
Another application calls a workflow directly as a service.
Event buses and queues
Messages from enterprise messaging infrastructure start runs.
Storage events
A new or updated object begins document and file processing.
Database events
Changes in operational data initiate downstream handling.
Git events
Repository activity drives platform and delivery automation.
Infrastructure events
Platform signals trigger operational response workflows.
Execution
Use the right execution mechanism.
A workflow is not limited to one style of integration. Each step uses whichever mechanism fits the system in front of it.
Connector actions
Prebuilt operations for common enterprise systems.
HTTP and GraphQL
Direct calls to modern service interfaces.
SOAP
Established enterprise service endpoints.
SAP RFC
Native access to SAP function modules.
MSSQL and Oracle
Direct database reads and writes.
SSH
Command execution on systems with no modern interface.
Code nodes
Real code across eight runtime language families.
Browser automation
Used where no programmatic interface is available.
AI nodes
Self-hosted model calls with retrieval where configured.
Kubernetes and Terraform
Infrastructure operations as workflow steps.
Platform functions
Reusable capabilities callable on demand.
Deterministic logic
Keep deterministic logic deterministic.
Anything that can be expressed as a rule should be expressed as a rule. It is cheaper to run, easier to review and does not vary between executions.
Validation before interpretation
Structural checks, mandatory fields, reference lookups and entitlement rules run first. Cases that fail these checks never reach a model, which reduces both cost and risk.
Thresholds and calculations
Tolerances, limits, pricing and reconciliation arithmetic belong in code, where the behavior is explicit and can be tested against known inputs.
Deterministic control of actions
Which systems a run may write to, and under what conditions, is decided by the workflow rather than by the model. Interpretation informs the decision; the workflow still enforces it.
Sovereign AI
Use AI where interpretation is required.
Models are valuable when the input is unstructured or ambiguous. That is a narrower role than autonomous operation, and a far more dependable one.
Classification
Assign a case, message or document to the right category and path.
Extraction
Pull structured values out of documents, emails and free text.
Summarization
Condense long histories into what the reviewer needs to decide.
Recommendation
Propose an action for a person or a deterministic rule to confirm.
Models run on infrastructure you control, and the deterministic workflow around them governs what data they see and what actions their output can trigger.
Human-in-the-loop
Pause for a person.
An approval node stops execution at a defined point and waits for a decision, whether the preceding step was deterministic or AI-assisted.
What the reviewer sees
The source record, the deterministic result and any model output are presented together, so the decision is made with the same context the workflow used.
Available decisions
Approve, reject, correct the proposed values, request changes or escalate to another reviewer. The decision and the reason are captured with the run.
Resuming execution
The workflow continues from the decision, following the branch that matches it. A corrected value flows into the following nodes exactly as a computed value would.
Lifecycle
Test, publish, observe and revise.
Building a workflow and running it in production are separate states, so changes can be prepared without disturbing live execution.
Draft and published
Edit a draft revision while the published version keeps running.
Test runs
Execute against sample input and inspect the result of each node.
Revisions
Publish a new revision when the change has been reviewed.
Active and disabled
Turn a workflow off without deleting its definition or history.
Execution history
Review previous runs, their status and their duration.
Errors and reruns
See where a run failed, on which node, and rerun once resolved.
Reuse
Reusable building blocks.
Logic that proves itself in one process should not be rebuilt in the next one.
Modules and sub-workflows
A complete internal graph can be exposed to a parent workflow as a single node, so a complex procedure becomes one reviewable step elsewhere.
Functions
Capabilities can be published for other systems and workflows to call on demand, rather than being locked inside one process.
Forms
Forms start a workflow or collect additional data mid-process, which keeps human input inside the governed run instead of in a side channel.
Reusable actions
Connector actions and shared steps are configured once and applied consistently across teams and processes.
Security
Isolation, secrets, access and history.
The controls that make a workflow safe to run in production are part of the platform rather than an add-on.
Workspace isolation
Teams and environments are separated with their own resources and access.
Vault-backed secrets
Credentials are referenced at run time and never stored in the workflow definition.
Role-based access
Permissions determine who can build, publish, approve and operate.
Audit history
Executions, decisions and changes are retained for review.
Architecture session
Map your process with Nexus.
Walk us through the process as it runs today, including the manual steps and the exceptions. We will show how the same sequence is assembled as one governed workflow.