Automation and AI
Automate the process, not just the parts of it that have an API.
Processes that cross SAP, Salesforce, a database and a shared file drop are automated as one governed unit, using prebuilt connector actions where they exist and code nodes where they do not.
- prebuilt connector actions
- 1,480+prebuilt connector actions
- trigger sources
- 46trigger sources
- code node languages available
- 8code node languages available
- per end-to-end case
- One recordper end-to-end case
The operational problem
The process breaks at the join between systems, not inside any one of them.
SAP handles SAP well. Salesforce handles Salesforce well. The place work actually stalls is the handoff: a file that has to be re-keyed, a status that has to be manually copied across, a mismatch nobody notices until month end.
The audit gap follows the same seam. When three systems and a spreadsheet each hold part of the story, reconstructing what happened for a single order or a single supplier payment means opening all of them and hoping the timestamps line up.
What a working solution has to do
Cover the systems you actually run, not a reference architecture.
Reach every system without a rebuild
SAP, Salesforce, a data warehouse and a shared file drop rarely share an API shape. The process design has to treat that as normal, not as an integration project on its own.
Cover the gap prebuilt connectors leave
No connector library anticipates every custom field, every legacy interface or every internal API. Additional operations use APIs, protocols, databases or Rules + Code inside the same governed workflow.
Keep one process, not five scripts
A process that touches four systems should be one governed unit with one execution record, not four scheduled scripts that happen to run near each other.
Fail loudly, not silently
When a downstream system rejects a write or a file arrives malformed, the process needs a defined exception path rather than a job that simply stops.
How Nexus delivers it
Prebuilt where it exists. Programmable where it does not.
Prebuilt actions for the well-known systems
1,480+ prebuilt connector actions cover SAP RFC calls, Salesforce objects, database reads and writes across MSSQL, Oracle, PostgreSQL and MySQL, and file handling, so the common 80 percent of a process is assembled rather than written.
Code nodes for the rest
Where a custom SAP interface, an internal API or an unusual file format falls outside the connector library, a code node in Python, Bash, Go, Java, .NET, PowerShell or JavaScript and TypeScript via Deno fills the gap inside the same workflow, with its own inputs and outputs captured in the execution record.
46 trigger sources start the work
A file landing in a drop folder, a webhook from Salesforce, a schedule or a database change can all start the same governed process, so the trigger matches how the business actually initiates the work.
Exception branches are part of the design
A rejected write, a validation failure or a missing field routes to a defined branch, whether that is a retry, a correction step or a human review, rather than an unhandled failure.
One execution record end to end
Every action, code step and system response for a single case is retained together, so a finance or operations team can see the whole transaction from trigger to write-back.
Worked example
A purchase order confirmation, matched across two systems and a legacy file format.
- 01
Trigger
A purchase order confirmation file lands in a supplier-facing drop folder, monitored by a Nexus trigger.
- 02
Integration
Connector actions parse the file, retrieve the matching purchase order from SAP, and check the customer record in Salesforce.
- 03
Rules + Code
A code node handles a legacy fixed-width variant of the file that the standard parser cannot read, normalising it into the same structure as the rest.
- 04
Rules + Code
Deterministic checks compare quantities and prices against the purchase order and flag mismatches above a defined tolerance.
- 05
System Action
Matched confirmations update the purchase order status in SAP and log the confirmation against the account in Salesforce.
- 06
Audit
The original file, the parsed data, the match result and both system responses are retained as one record for the order.
Evidence and output
What you get once the process is live.
Execution record
Trigger, parsed data, matched systems and outcome for every processed file or event.
Exception log
Every mismatch, rejection or malformed input, with the branch it was routed to and its current state.
System responses
The payload sent to each downstream system and the response received, tied to the case that produced it.
Throughput view
Volume processed, exceptions raised and time to resolution, visible without exporting logs from four systems.
Products and platform capabilities
Built on the workflow engine, not a separate integration product.
What this solution uses
- The Nexus workflow engine and its connector library
- Code nodes for custom interfaces and file formats
- Governance and audit as described on the platform pages
What it deliberately does not require
- A dedicated integration platform license
- A model or AI step, unless the process needs interpretation, in which case see Governed AI Automation
- A separate reporting tool for exceptions
Who owns it
Usually a shared process between operations and integration engineering.
Process owner
The finance, procurement or operations lead accountable for the outcome the process produces.
Integration engineer
Builds and maintains the workflow, connector configuration and any code nodes it requires.
System owners
The SAP, Salesforce and database administrators who confirm what the process is permitted to read and write.
Architecture session
Bring us the process that still needs re-keying.
We will map the systems it touches, identify where prebuilt actions cover the work and where a code node is needed, and scope a pilot against real cases.