Robolytix
Analytics & DataConnect AI agents to Robolytix, a real-time process monitoring and analytics platform. Agents send Sonar checkpoint messages and report each run's outcome so automation health is measured rather than assumed.
What This Integration Enables
Robolytix is a monitoring platform for RPA and business process automation, and its central idea is the Sonar: a lightweight checkpoint message that a process sends as it runs, from which Robolytix reconstructs the execution. That design decision is what makes it useful in a flow and also what determines how you should build against it. Robolytix does not watch your automation from outside. It knows exactly what your automation tells it, which means the value of the whole picture rests on the honesty of the reporting. FlowRunner agents do two things here. They list the processes configured in the account, each of which carries the GUID needed to address it. And they send Sonar messages carrying a Sonar Name, the process GUID, a type of Start, Common, End, or Error, a Run ID that correlates every message belonging to one execution, and optionally the service that sent it.
The discipline that makes this connector worth using is entirely in how the messages are constructed. A run should open with Start and close with End, use Common for intermediate checkpoints, and use Error to report a failure. The Run ID is what stitches those together, so a flow has to generate one at the start and carry it through every branch and every retry, because two runs sharing a Run ID merge into one execution in the reconstruction, and one logical run split across two Run IDs shows as two runs and understates the failure rate. Two things this connector does not do, stated plainly. It cannot create or configure a process: List Processes reads what was set up in the Robolytix Platform, and there is no operation here that registers a new one. And it has no triggers. Nothing in Robolytix starts a FlowRunner flow; the flow starts because the work started, and the Sonar messages are what it reports along the way. Change detection, in the sense other connectors mean it, does not apply, because this is an outbound reporting surface rather than a data source. The connector is built and verified against Robolytix's official API.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A Process That Reports Its Own Duration
An invoice intake process runs several times a day across document capture, validation, ERP posting, and notification. The agent calls List Processes once to resolve the process GUID, generates a Run ID as the batch opens, and sends a Sonar message with type Start. As each stage completes it sends a Common message named for that stage. When the batch posts successfully it sends End. Because every message carries the same Run ID, Robolytix reconstructs the run and shows the elapsed time between checkpoints, which is what turns "posting feels slow this week" into a stage name and a number.
Failures That Are Visible as Failures
The same process hits a document the validation step cannot resolve, and the flow routes it to a person. Rather than the run simply stopping, the agent sends a Sonar message with type Error naming the checkpoint that failed, then continues the exception path. In the Robolytix view that run appears as a failure at a named stage rather than as an execution that started and never finished, and those two look identical in most monitoring until someone reads the logs. The weekly reliability figure the operations lead reads is built from runs that were classified, not from runs that were forgotten.
One Health Surface Across Several Automation Tools
An organization runs some processes in an RPA tool, some in FlowRunner, and some in scripts. Because the Sonar message accepts an optional Service field naming the tool that sent it, the agent reports FlowRunner runs into the same Robolytix processes that the RPA platform reports into, using the same process GUIDs. The result is a single view of automation health across tools rather than one dashboard per vendor, and the operations lead reviewing it can compare like with like. The agent also posts the weekly summary to a channel in Slack so the number reaches people who will never open the platform.
Human-in-Loop Highlight
Every other connector in this catalog has a write that changes a customer, a record, or a balance. This one has a write that changes what everybody believes. Robolytix reconstructs a run entirely from the Sonar messages the process sends, so Send Sonar Message with type End is a claim that the run succeeded, and type Error is a claim that it did not. When the outcome is unambiguous the agent classifies it and moves on. The problem is that real processes generate ambiguous outcomes constantly: a step that failed and succeeded on retry, a batch where nine of ten documents posted, a downstream call that returned success with an error inside the body, a run that completed after a person intervened by hand. Send End on those and the health dashboard says the automation is fine, and the metric that operations uses to decide where to invest is quietly wrong in the direction that flatters it. Nobody catches that, because a monitoring system whose data is written by the thing it monitors has no independent check. So the classification rule is owned by a person, not by the agent. Any outcome the rule does not cleanly cover goes to the process owner before it is reported: "Run [Run ID] on process [name] finished in a state the rule does not classify. Checkpoints reached: [Sonar names and timestamps]. Detail: [what happened, for example 7 of 10 documents posted and 3 routed to exception handling]. Report as End, as Error, or amend the rule so this case is classified automatically next time?" The owner answers, the agent sends the message, and the amended rule covers the case unattended from then on. Opening runs, sending checkpoints, and closing clean successes need no human at all. Deciding what counts as a failure is human-in-the-loop work, because that definition is the only thing the health number actually means.
Agent Capabilities
2 actionsProcesses
1- List Processes Retrieves all processes in the account. Each process includes the GUID used as the process identifier when sending Sonar messages. This is read-only: processes are configured in the Robolytix Platform, and this connector cannot create one.
Monitoring
1- Send Sonar Message Records that a monitored process reached a checkpoint. Takes a Sonar Name, the process GUID, a Type of Start, Common, End, or Error, a Run ID that correlates every message belonging to one execution, and an optional Service naming the tool that sent it. A run should open with Start and close with End, use Common for intermediate checkpoints, and use Error to report a failure. Because the Run ID is what stitches a run together, generate it once at the start and carry it through every branch and retry.
Frequently Asked Questions
What can FlowRunner do with Robolytix?
FlowRunner agents can run List Processes and Send Sonar Message in Robolytix.
Does connecting Robolytix to FlowRunner require OAuth?
No. Robolytix connects to FlowRunner with an API key, no OAuth flow required.
Can Robolytix trigger a FlowRunner workflow automatically?
Robolytix doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Robolytix
$100 in credits. No card required. Connect in minutes.