LogicGate Risk Cloud
Identity & SecurityConnect AI agents to LogicGate Risk Cloud, a governance, risk, and compliance platform. Agents read records and their linked context, build and maintain the program structure of applications, workflows, steps, and routing paths, and audit who had access.
What This Integration Enables
Read this part carefully, because the shape of the LogicGate Risk Cloud connector is not what most GRC integrations look like. It does not create records and it does not move them. Record field value writes are not part of the public v2 REST surface this connector covers, so on the record side the available actions are List Records, Get Record, List Linked Records, and List Fields. Everything an agent does with a record here is reading it, following its links, and putting it in front of a person.
What the connector does write is the program itself. Applications, workflows, steps, workflow maps, next paths, redirect paths, and conditional edge paths are all fully creatable, updatable, and deletable. In a GRC platform that is not a lesser surface, it is the more consequential one. A record is one finding. A workflow definition is the control that decides how every finding of that type gets handled, and an edge path is the condition that decides which findings reach a reviewer at all. Changing one is a control change, and control changes are precisely what an auditor asks you to evidence. So the useful framing for an agent here is not "process my records faster." It is: keep the structure inventoried, propose changes to it with the reasoning attached, and never let a routing rule move without a person putting their name on it. The connector authenticates by exchanging a Base64 encoded client and secret pair for a short lived bearer token against your own environment host, and it never logs or returns credential material.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A findings queue that arrives with its links already followed
On Record Updated polls for records whose last-updated timestamp has moved, optionally scoped to a single application, workflow, or step, and the first poll establishes a baseline so a year of existing records is not replayed on deployment. When a record in the issue management workflow reaches the review step, the agent calls Get Record for its field values and current step, then Get Step to read the step's assignment settings. It calls List Linked Records with a traversal depth to walk the workflow map out to the related risk and the control it belongs to. The reviewer opens one message in Microsoft Teams containing the finding, the risk it maps to, and the control that was supposed to prevent it, rather than three browser tabs. The record itself moves in Risk Cloud, by a person, in the platform built for it.
Quarterly structure diff for the audit file
An audit asks what changed in the program since last quarter. A scheduled flow calls List Applications, then List Workflows per application, List Steps per workflow, and List Next Paths, List Redirect Paths, and List Edge Paths to capture every routing rule including the field, operator, and priority on each conditional branch. It writes the full inventory to Google Sheets and diffs it against the snapshot from three months ago. New steps, deleted paths, and edge path conditions whose operator changed all surface as rows with names rather than as a vague sense that the build canvas looks different. The connector produced the evidence. The explanation for each change is still a human's to write, and now they can see exactly which changes need one.
Provisioning a workflow from an approved pattern
A new regulatory obligation needs its own assessment workflow, and the GRC team has a pattern they use: an origin step, two chain steps, an end step, and a conditional branch that sends anything above a risk threshold to a second reviewer. The agent calls Create Workflow inside the right application, Create Step four times with the right step types, Update Step Position to lay them out on the canvas legibly, and Create Next Path to connect them. Then it stops. The conditional branch is not written automatically, because that is the piece that decides who ever sees a high risk item. It goes to the control owner as a proposal with the field, operator, and priority spelled out.
Human-in-Loop Highlight
An edge path is a conditional branch that routes a record to one step or another based on a field value, with an operator and a priority that decide which branch wins. That makes Create Edge Path and Update Edge Path the two most quietly powerful actions in this connector. Change the operator from greater than to greater than or equal, or change the priority so a different branch evaluates first, and from that moment every record entering the workflow follows a different route to a different reviewer. Nothing on any individual record says the route moved. The records that stop reaching the escalation step simply stop arriving, and the person who used to review them notices weeks later, if at all. Risk Cloud offers no undo on this: Update Edge Path cannot change the source step, destination step, or evaluated field, so a rethink means Delete Edge Path and Create Edge Path again, and the sibling Delete Application is blunter still, permanently removing an application along with all of its workflows, steps, and records. So the agent proposes and waits. It posts the current condition and the proposed one side by side, the count of records that took each branch over the last quarter from List Records, and the name of the step that would stop receiving work: "Proposed change to the Vendor Risk edge path: route to Second Review when inherent risk is greater than or equal to High, instead of greater than High. 31 records took the old route last quarter. Approve?" The control owner answers, and only then does the agent write it. This is the digital andon cord applied to the machinery rather than to a single part moving through it.
Agent Capabilities
41 actionsApplications
5- List Applications Retrieves a paginated list of applications, the top level containers that group related workflows. The starting point for any inventory or diff.
- Get Application Retrieves a single application by identifier, including its name, type, icon, color, and short code.
- Create Application Creates a new application. Only the name is required; type, icon, color, description, and short code are optional.
- Update Application Updates an application, changing only the fields supplied. Supports toggling the application live and restricting build access, both of which change who can alter the program.
- Delete Application Permanently deletes an application and all of its workflows, steps, and records. This cannot be undone, and it is the largest blast radius available in this connector.
Workflows and Steps
11- List Workflows Retrieves a paginated list of workflows, optionally filtered to a single application. Workflows define the record lifecycle inside an application.
- Get Workflow Retrieves a single workflow by identifier, including its name, record prefix, and parent application.
- Create Workflow Creates a workflow within an application. Application ID, name, and record prefix are required, with optional X and Y positions to place it on the build canvas.
- Update Workflow Updates a workflow, changing only the fields supplied. Supports renaming, changing the record prefix, and repositioning on the canvas.
- Delete Workflow Permanently deletes a workflow along with its steps and records. This cannot be undone.
- List Steps Retrieves a paginated list of steps, optionally filtered to a single workflow. Steps are the stages a record moves through.
- Get Step Retrieves a single step by identifier, including its type, position, and assignment settings. Use it to explain to a reviewer why a record landed with them.
- Create Step Creates a step within a workflow. Name and workflow ID are required, and the step type controls whether the step is the origin, a chain step, or an end step.
- Update Step Updates a step, changing only the fields supplied. Supports renaming, changing the step type, and updating assignment and comment settings.
- Update Step Position Updates only the X and Y canvas position of a step, leaving every other setting alone. The safe way to make a generated workflow readable.
- Delete Step Permanently deletes a step from its workflow. This cannot be undone, and records currently sitting in that step lose the stage they were in.
Routing Paths
15- List Next Paths Retrieves paginated next paths, which route a record from one step to the next, optionally filtered to paths originating from a specific step.
- Get Next Path Retrieves a single next path by identifier, including its source and destination steps.
- Create Next Path Creates a next path connecting a source step to a destination step. The from and to steps are required; user type allowances and assignee requirements are optional.
- Update Next Path Updates the settings of an existing next path. Source and destination cannot be changed, so rerouting means delete and recreate.
- Delete Next Path Permanently deletes a next path, removing the routing connection between two steps. This cannot be undone.
- List Redirect Paths Retrieves paginated redirect paths, which send a record backward to an earlier step, optionally filtered by originating step.
- Get Redirect Path Retrieves a single redirect path by identifier, including its source and destination steps.
- Create Redirect Path Creates a redirect path that sends a record from a later step back to an earlier one. This is how a reviewer returns work for rework, so its existence is a policy decision.
- Update Redirect Path Updates the settings of an existing redirect path. Source and destination cannot be changed.
- Delete Redirect Path Permanently deletes a redirect path. This cannot be undone.
- List Edge Paths Retrieves paginated edge paths, the conditional branches that route a record based on a field value, optionally filtered by originating step.
- Get Edge Path Retrieves a single edge path by identifier, including its condition operator, field, and priority. The three properties that decide who sees what.
- Create Edge Path Creates a conditional edge path between two steps. A field, operator, and priority define the branching condition. Gate this one.
- Update Edge Path Updates a conditional edge path, changing only the fields supplied. The source step, destination step, and evaluated field cannot be changed. Gate this one too.
- Delete Edge Path Permanently deletes a conditional edge path. This cannot be undone.
Workflow Maps
5- List Workflow Maps Retrieves a paginated list of workflow maps, optionally filtered to a single workflow. Maps define the linking relationships between workflows.
- Get Workflow Map Retrieves a single workflow map by identifier, including the two linked workflows and their relationship type.
- Create Workflow Map Creates a map linking two workflows with a relationship type. Source workflow, target workflow, and relationship are all required.
- Update Workflow Map Updates the relationship type of an existing map. The linked workflows cannot be changed; delete and recreate to relink.
- Delete Workflow Map Permanently deletes a workflow map, removing the link between two workflows. This cannot be undone, and it silently breaks any traversal that depended on it.
Records and Fields
4- List Records Retrieves a paginated list of records, filterable by application, workflow, step, and last-updated timestamp. Records are read here, not written.
- Get Record Retrieves a single record by identifier, including its status, current step, assignee, creator, and field values.
- List Linked Records Retrieves records linked to a given record within a target workflow, with an optional traversal depth. This is how a finding gets delivered alongside the risk and control it belongs to.
- List Fields Retrieves a paginated list of fields, filterable by application, workflow, step, field type, and scope. Fields define the data captured on records, and knowing the field inventory is what makes an edge path condition legible.
Access Audit
1- List Access Audits Retrieves paginated access audit log entries filterable by user, event type, and creation time range, covering login, logout, failed logins, and credential events. Feed it into the same review that reads your identity provider so failed login patterns are seen next to everything else.
Triggers
1 triggersEvent Triggers
1- On Record Updated Fires when a record is created or updated, emitting the raw record object, with optional scoping to a single application, workflow, or step. Detection is by polling the record's last-updated timestamp through the API's updated-min filter, with a customizable interval down to 30 seconds, so the interval you choose is the delay you accept. The first poll establishes a baseline without firing, which means pre-existing records are not replayed when the flow deploys and only records updated after monitoring begins reach the flow.
Frequently Asked Questions
What can FlowRunner do with LogicGate Risk Cloud?
FlowRunner agents can run List Applications, Get Application, and Create Application in LogicGate Risk Cloud, plus 38 more actions.
Does connecting LogicGate Risk Cloud to FlowRunner require OAuth?
No. LogicGate Risk Cloud connects to FlowRunner with session-based authentication, no OAuth flow required.
Can LogicGate Risk Cloud trigger a FlowRunner workflow automatically?
Yes. LogicGate Risk Cloud supports 1 trigger that can start a FlowRunner workflow automatically.
Start building with LogicGate Risk Cloud
$100 in credits. No card required. Connect in minutes.