--- title: "Robocorp Integration" description: "Robocorp Control Room (now Sema4.ai) runs and supervises Python and Robot Framework automations. Workflows start process runs, manage work items and their files, read step run output and artifacts, keep assets and secrets current, and react when a run completes or needs attention." url: https://flowrunner.ai/integrations/robocorp date_modified: 2026-09-04T14:59:52-07:00 --- # Robocorp [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Robocorp Control Room (now Sema4.ai) runs and supervises Python and Robot Framework automations. Workflows start process runs, manage work items and their files, read step run output and artifacts, keep assets and secrets current, and react when a run completes or needs attention. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 3 triggers · 63 actions · API key · available [Robocorp website](https://sema4.ai/) · [Platform Documentation](https://sema4.ai/) · Capability data verified 2026-08-25 1. On Process Run Unresolved fires, meaning the robot finished with records it could not process 2. List Work Items filtered on failed returns exactly the records that stalled 3. Get Work Item with data included pulls each payload, since payloads are omitted by default 4. List Step Run Console Messages retrieves the robot's own log for the failing step 5. Each failure posts with its record, its error, and the log excerpt attached 6. Update Work Item Payload applies the corrections the agent can determine with certainty 7. The process owner decides which remaining items to retry and which need handling outside the robot ## What This Integration Enables Robocorp Control Room, now Sema4.ai, has a state in its data model called unresolved, and it means something worth pausing on. It does not mean the robot crashed. It means the run completed and individual records inside it could not be processed. Control Room already draws the line between a system failure and a work item that needs a human. That distinction is the entire premise of [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service), arrived at independently by an RPA platform, and it is the reason this connector is more interesting than the usual start a job and watch it finish. FlowRunner takes that state and does something with it. Agents start process runs with the exact work items they name, watch them through triggers rather than by polling a queue that may take hours, gather the payload and the robot's own console output when something stalls, and put the failure in front of the person who owns the process with everything needed to decide. Alongside that, the [connector](https://flowrunner.ai/concepts/connectors) covers the estate the robots run on: task packages and their versions, assets and vault secrets, workers and worker groups, assistants that people run by hand, and the webhooks the triggers depend on. What agents recover automatically is the part with an unambiguous answer. [Automation exceptions](https://flowrunner.ai/concepts/automation-exceptions) get a person, which is what the human gate below is about. ### Without FlowRunner **Unresolved runs sit in a dashboard**: The run finished, some records did not, and nothing routes that to a person **Failure alerts with no evidence**: Somebody is told a robot failed and starts by opening Control Room to find out why **Retries are a manual afternoon**: Fixing payloads and re-queueing failed records is done one at a time by hand ### With FlowRunner **An unresolved run reaches a named owner**: The exception state the platform already tracks becomes a routed request for a decision **The failure arrives explained**: Record, error, console output, and the failing step's artifacts travel with the alert **The mechanical part of recovery is automatic**: Payload corrections that are unambiguous get applied, and only judgment reaches a person ## Use Case Scenarios ### Every failed record becomes a decision, not a statistic An invoice posting robot ends its run unresolved with 6 of 900 records failed. The agent lists the failed work items, fetches each payload with data included, and pulls the console output for the step that raised the error. Three failures share the same cause, a supplier code that changed upstream, and the agent corrects those payloads and retries them. The remaining three are genuinely ambiguous, so they post to [Slack](https://flowrunner.ai/integrations/slack) or [Microsoft Teams](https://flowrunner.ai/integrations/microsoft-teams) one message per record with the payload, the error, and the robot log attached. The finance lead answers each one in the thread. What used to be a dashboard number is now six specific questions with names on them. ### A robot fed by the systems it works on behalf of Work arrives from somewhere before it becomes a robot's problem. A ticket in [ServiceNow](https://flowrunner.ai/integrations/servicenow), a record in [Snowflake](https://flowrunner.ai/integrations/snowflake), a row in an operational database: the agent gathers and validates it, then calls Create Work Item to put the payload in the process input queue, and Start Process Run when the batch is ready. Creating an item starts nothing on its own, which is exactly what makes this pattern safe: the queue accumulates, the agent checks it, and the run begins on a schedule or when a threshold is met. Anything that fails validation before it reaches the queue never becomes a robot failure at all. ### Deploying a new robot version without opening Control Room When a task package needs a new version, the agent calls Get Task Package to obtain the upload form data, publishes the new zip, and confirms the processes pointing at it with List Processes before anything runs. Credentials for that robot live in the vault rather than in a payload, so a rotation workflow calls Update Secret, remembering that it replaces every item in the secret rather than merging, which means the full set has to be sent. Shared reference data goes through Create Asset Upload instead, addressed by name so no id lookup is needed. A build in [GitHub](https://flowrunner.ai/integrations/github) can start the whole sequence. ## Human-in-Loop Highlight Run Work Item Batch Operation has three modes, and one of them is not what it looks like. Retry re-runs the robot against the items, which is honest: an item that is still broken fails again, visibly. Delete removes them. The third, marking items as done, processes nothing at all. It declares the records handled so they stop blocking the queue, which is exactly right after somebody dealt with them by hand somewhere else, and exactly wrong as a way to clear an alert. It is the single operation in this connector that can make a real business failure disappear without anybody resolving it, and it looks identical to progress from the outside. So FlowRunner agents retry freely and never mark anything done. When the corrections they can make with certainty are applied and items remain, the agent hands them over: "Run 3312 has 3 items still failing after retry. Item 88214 has no matching purchase order in the ledger. Item 88301 has a supplier code the robot does not recognize. Item 88377 failed twice on a timeout against the vendor portal. Retry the timeout, or were these handled outside the robot?" Only the person who actually resolved something can truthfully say it was resolved. That claim is not one an agent is entitled to make on their behalf, which is what a [digital andon cord](https://flowrunner.ai/concepts/digital-andon-cord) is protecting. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 63 actions ### Workspace 1 - **Get Workspace** Returns the workspace this connection is scoped to. The cheapest connection test, and a wrong workspace id shows up here rather than as a mysteriously empty list later. ### Processes 3 - **List Processes** Returns the workspace's processes. A process is the runnable unit: it names the steps, the task package each step runs, and the worker that executes it. - **Get Process** Returns one process with its steps, workers, and notification configuration. - **Create Process** Creates a process from a list of steps. The step structure is nested and specific, so building one in Control Room and reading it back is the reliable way to learn the shape. ### Process Runs 6 - **Start Process Run** Starts a process. Three mutually exclusive input modes exist and picking the wrong one is silent, so a workflow chooses deliberately between the default input, named work items, and whatever is waiting in the queue. The run is asynchronous. - **List Process Runs** Returns the workspace's process runs, newest first. The unresolved state is the one that matters operationally. - **Get Process Run** Returns one run with its state, timings, and who started it, which is how a workflow distinguishes its own runs from a schedule's or a person's. - **Stop Process Run** Stops a running process. Its two flags decide what happens to work already executing and to the untouched queue, and terminating mid robot can leave a target system part way through a transaction. - **Delete Process Run** Permanently deletes a run with its step runs, logs, and artifacts, destroying the execution evidence an audit would want. - **List Process Run Outputs** Returns what a run actually produced, which the run's state does not tell you. ### Work Items 6 - **List Work Items** Returns work items, optionally filtered by process, run, or state. The failed state is the one to watch, and it is why a run reports unresolved. - **Get Work Item** Returns one work item. Payloads and files are omitted unless data is explicitly included, which otherwise reads as an empty item. - **Create Work Item** Adds a work item to a process input queue. Creating an item starts nothing: it waits until a run is started against the queue or the process schedule fires. - **Update Work Item Payload** Replaces a work item's payload. It replaces rather than merges, so a partial correction means reading the item first. - **Create Work Item File** Requests an upload slot for a file on a work item. It returns a pre-signed URL rather than uploading anything itself. - **Run Work Item Batch Operation** Retries, deletes, or marks failed work items as done, in bulk. Retry is the recovery path. Marking as done processes nothing and is what this page's human gate exists for. ### Step Runs 6 - **List Step Runs** Returns the individual step executions inside a process run. A run is a container; the step runs are where the robot actually executed. - **Get Step Run** Returns one step run with its state, timings, and the worker that executed it. Where a failure names its step. - **List Step Run Console Messages** Returns the robot's console output for a step run. The actual robot log, and the first place to look when a failure is not explained by Control Room's own states. - **List Step Run Events** Returns a step run's lifecycle events, which is more precise than the state field for working out where time went or how many retries happened. - **List Step Run Artifacts** Returns the files a step run produced, including the detailed execution report a failure alert is usually worth attaching. - **Get Step Run Artifact** Returns one artifact's metadata and a short lived download URL, so fetch it rather than storing the link. ### Task Packages 5 - **List Task Packages** Returns the workspace's task packages, which hold the robot code a process step runs. The package type decides how a new version reaches it. - **Get Task Package** Returns a task package with a download URL and the form data for uploading a new version. Zip packages only, since git linked packages are managed by Control Room itself. - **Create Task Package** Creates a task package. The type decides what else is required, and it cannot be changed afterwards. - **Update Task Package** Changes a git linked package's configuration. Changing an existing package's type is not supported through the API. - **Delete Task Package** Permanently deletes a task package, and any process step pointing at it breaks. ### Assets 6 - **List Assets** Returns the workspace's assets, which are shared data files robots read at run time such as configuration or lookup tables. - **Get Asset** Returns an asset including its payload. The identifier accepts a name, so a workflow never has to look an id up. - **Create Asset** Creates an empty asset. This only reserves the name, and a robot reading it before the content arrives gets nothing. - **Create Asset Upload** Sets an asset's content, in one call for small payloads and through a returned upload URL for large ones. - **Get Asset Upload** Returns an upload's status, which is how a workflow confirms a large multi step upload actually completed. - **Delete Asset** Permanently deletes an asset, and any robot that reads it starts failing at run time rather than at deploy time. ### Secrets 4 - **List Secrets** Returns the vault secrets in the workspace by name and description. Control Room never returns a secret's values through the API, which is the point of the vault. - **Create Secret** Creates a vault secret. The right way to give a robot a credential, instead of putting it in a work item payload where it ends up in logs and run history. - **Update Secret** Replaces a secret's items. It replaces all of them, so rotating one password means sending every key the secret holds. - **Delete Secret** Removes a secret from the vault. Any robot that reads it fails at run time from then on, with no warning at deploy time. ### Workers 5 - **List Workers** Returns the workers linked to the workspace. A worker is a machine that runs robots. - **Get Worker** Returns one worker with its state and when it was last seen. The check to run when a run is stuck waiting. - **Update Worker** Renames a worker. Name is the only field the route accepts. - **Delete Worker** Unlinks a worker from the workspace. Irreversible, and the machine has to be re-linked with a new token to come back. - **Create Link Token** Generates a token used to link a new worker machine to the workspace. An expiry is required, so a token cannot be made permanent, and the value is returned only once. ### Worker Groups 12 - **List Worker Groups** Returns the workspace's worker groups. A group is how a process step targets a pool of machines rather than one named worker. - **Get Worker Group** Returns one worker group. - **Create Worker Group** Creates a worker group. - **Update Worker Group** Renames a worker group. - **Delete Worker Group** Deletes a worker group. Irreversible, and a process step targeting it has nowhere to run afterwards, though the workers themselves stay linked. - **Add Worker To Group** Puts an existing worker into a worker group. - **Remove Worker From Group** Takes a worker out of a group. The worker stays linked to the workspace. - **List Worker Group Link Tokens** Returns the link tokens issued for a worker group by name and expiry. The values are not included, so this is how a workflow spots one about to lapse. - **Create Worker Group Link Token** Issues a link token so a new machine joins that group when it links. The value is retrievable in Control Room rather than from this response, so a person collects it. - **Get Worker Group Link Token** Returns a link token's name and expiry, but not its value. - **Update Worker Group Link Token** Changes a link token's name or expiry. The way to extend one about to lapse without reissuing it, which matters because the value cannot be read back to hand out again. - **Delete Worker Group Link Token** Revokes a link token. Any machine not yet linked with it can no longer join. ### Assistants 5 - **List Assistants** Returns the workspace's assistants, which are robots a person runs on demand rather than on a schedule. An assistant cannot be started through this API, by design. - **Get Assistant** Returns one assistant. - **Create Assistant** Creates an assistant from a task inside a task package. Control Room checks the task name exists rather than creating something that cannot run. - **List Assistant Runs** Returns assistant runs. How a workflow audits what people ran by hand, which is usually the part of an automation estate with no record. - **Get Assistant Run** Returns one assistant run with its state and who ran it. ### Webhooks 4 - **List Webhooks** Returns the workspace's process webhooks with their endpoints and events. Each row includes its signing secret, so the response is a credential. Where a trigger that has gone quiet is diagnosed. - **Create Webhook** Registers a process webhook. A webhook is bound to one process, so watching several processes means several webhooks. - **Get Webhook** Returns one webhook including its signing secret. - **Delete Webhook** Removes a webhook. Doing this by hand while a trigger is running silences that trigger with nothing to indicate it. ## Triggers 3 triggers ### Event Triggers 3 - **On Process Run Started** Fires when a process run actually begins, rather than when it was requested, since a run can wait for a free worker. Useful for stamping an external ticket with the run id that later correlates a completion back to it. - **On Process Run Completed** Fires when a process run finishes successfully. Far better than polling, because a run can take minutes or hours depending on queue depth. It does not fire for an unresolved run, so a workflow watching only this one misses every partial failure. - **On Process Run Unresolved** Fires when a run finishes with work items the robot could not process. This is the failure signal, and it is not a crash: the run completed and individual records did not. It is the trigger the human gate on this page is built on. ## Frequently Asked Questions ### What can FlowRunner do with Robocorp? FlowRunner agents can run Get Workspace, List Processes, and Get Process in Robocorp, plus 60 more actions. ### Does connecting Robocorp to FlowRunner require OAuth? No. Robocorp connects to FlowRunner with an API key, no OAuth flow required. ### Can Robocorp trigger a FlowRunner workflow automatically? Yes. Robocorp supports 3 triggers that can start a FlowRunner workflow automatically. **Work at Robocorp?** This integration exposes Robocorp to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/robocorp. Site index: https://flowrunner.ai/llms.txt