Businesslogic

Businesslogic publishes an Excel workbook as a JSON REST API. Workflows read the model's input and output schema, validate their inputs against it, and execute the spreadsheet as a callable calculation.

Verified 3 actions API key available

Businesslogic website Platform Documentation Capability data verified 2026-08-25

A quote request or renewal reaches the flow from the CRM

Agent assembles the model's inputs from the deal record

Describe reads the workbook's current input and output schema

Execute With Validation refuses any input key the workbook no longer accepts

The workbook calculates and returns its outputs

The result posts to the deal thread alongside the exact inputs that produced it

When the schema has moved, finance confirms the new mapping before any number goes out

What This Integration Enables

Businesslogic makes an argument most automation tooling refuses to make: the business already wrote the logic. Pricing tiers, commission splits, rebate ladders, loan amortization, freight surcharges, all of it lives in a spreadsheet that somebody in finance has maintained and defended for years. The usual next step is to have an engineer read that workbook and rewrite it somewhere else, at which point the company owns two versions of the same math and a permanent reconciliation problem. Businesslogic publishes the workbook itself as a JSON REST API, so a FlowRunner agent calls the model rather than a copy of it.

Three actions. That is not a gap in the connector, it is the shape of the product: run the model, read its contract, or do both in one guarded call. What matters is which one a flow reaches for. Execute is the fast path when the schema is known to be stable. Describe returns the JSON Schema of the model's inputs and outputs, and it reports the new shape after the business re-publishes, which is the whole point of the product. Execute With Validation reads the schema first and refuses inputs the workbook does not recognize, because the failure this API is prone to is not an error, it is a confident wrong answer. FlowRunner's human-in-the-loop discipline is what turns that difference into something a person actually sees.

Without FlowRunner

The model lives on one laptop Pricing, commission, and margin logic sits in a workbook that one person opens and everyone else asks about

Re-implementation tax Getting the same math into an app means an engineer rewrites the formulas, and the two copies drift from the day they ship

Silent staleness The business edits the sheet, nobody tells the system that consumes it, and the difference shows up in a customer conversation

With FlowRunner

The workbook is the API Finance keeps editing the model they already own, and flows call it directly instead of copying it

One authority, no fork There is no second implementation to reconcile, because there is no second implementation

Drift becomes an exception A renamed cell raises a visible error and reaches a person, instead of quietly producing a plausible number

Use Case Scenarios

Quotes that finance never has to re-check

A deal reaches a certain stage in HubSpot and the agent assembles the inputs the pricing model expects: seat count, term length, region, and the discount tier the rep asked for. Rather than calling Execute directly, it calls Execute With Validation, so a mismatch between the flow's field names and the workbook's current inputs stops the run instead of quietly pricing the deal with last quarter's stored values. The returned outputs go back onto the deal record, and a summary posts to the deal channel in Slack with every input listed beside the price. When someone later asks why the number is what it is, the answer is on the record rather than in a rep's memory.
A model the business keeps editing

Commission plans change at the start of a quarter, and they change in the spreadsheet, because that is where the plan was negotiated. Finance re-publishes the workbook and the token and endpoint stay the same. On its next run, the payout flow calls Describe, compares the returned schema against the shape it was built for, and finds two new inputs and one renamed cell. It does not guess at a mapping. It stops, reports the difference, and waits. Once the mapping is confirmed, the flow calculates every rep's payout, writes the results to a sheet in Google Sheets, and stages the journal entries in QuickBooks Online for review.
The calculation that used to be an email

Freight surcharges, rebate accruals, and blended-rate calculations tend to live with one analyst, and requests reach them as messages. Here the workbook is published once, and the flow answers those requests directly: an inbound record supplies the inputs, Execute returns the outputs, and the analyst reads a queue of results rather than a queue of requests. The logic did not move and the analyst still owns it. What changed is that opening the file is no longer part of answering the question.

Human-in-Loop Highlight

The hazard in this connector is not a failed call, it is a successful one. Send salery_per_month instead of salary_per_month and Businesslogic accepts the request, calculates with whatever that cell already held, and returns a number with nothing in the response to say an input was dropped. A renamed cell produces plausible output indefinitely, and no downstream check can catch it, because the answer looks exactly like a right answer. So the agent treats schema drift as the automation exception it is. Before a payout or pricing run, it calls Describe, diffs the returned input names against the mapping the flow was built on, and when they differ it posts: "The commission model now accepts ramp_month and no longer accepts tenure_months. Nine reps are queued. Should tenure_months map to ramp_month, or is this a new input finance needs to supply?" The controller answers once and the run proceeds. The agent never invents the mapping, because a wrong guess here does not fail, it publishes.

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

3 actions

Running the model

Execute Sends input values into the published Excel model and returns its calculated outputs. The fast path, for a tight loop where the schema is known to be stable.
Execute With Validation Reads the model's schema, checks the inputs against it, and only then runs the model. It raises when a key is unrecognized or a required input is missing, naming both lists and the inputs the model actually accepts. It costs one extra request per call and it is what most flows should use.

Reading the contract

Describe Returns the JSON Schema of the model's inputs and outputs. It reports the workbook's current shape, so it is the operation that tells a flow whether the business has moved the model underneath it.

Frequently Asked Questions

What can FlowRunner do with Businesslogic?

FlowRunner agents can run Execute, Describe, and Execute With Validation in Businesslogic.

Does connecting Businesslogic to FlowRunner require OAuth?

No. Businesslogic connects to FlowRunner with an API key, no OAuth flow required.

Can Businesslogic trigger a FlowRunner workflow automatically?

Businesslogic doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Businesslogic

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us