CoPlane Actions: The Front Door to the Back Office

Your back office is already automated. By people.

Someone pulls the bank balance every morning and keys it into the ERP. Someone reconciles the lockbox file against open receivables. Someone approves the payment run, then re-enters the approval in the treasury portal because the two systems don't talk.

The work gets done. It gets done in twelve tabs, by people who know which tab to trust, and it leaves almost no trace of why anything happened.

Today we're launching Actions to change that.

One way to do each thing

An Action is a single, permissioned, auditable pathway to do something in your systems of record: read a bank balance, post a journal entry, release a payment, look up a vendor, create a customer.

An Action's implementation can be simple (a straightforward API call where one exists) or complex (send an EDI message, drop a file in an SFTP folder, query a database, or RPA-style computer use).

Once an Action exists, it can serve as the only way that thing gets done, whether a person does it, an automated process does it, or an AI agent does it. Same permission check. Same record.

Controls that run themselves

Three controls come with Actions, and nobody has to remember to apply them.

Segregation of duties. Clerks prepare, buyers approve price variances, controllers approve postings. Your team writes these rules in a policy file, and CoPlane checks them on every call, whether the call comes from a button, a workflow or a copilot like Claude or ChatGPT for Work. The assistant acts with the permissions of the person using it and no more.

Approval before anything posts. You can give an Action like "post to the ERP" no API endpoint and no AI tool. Then only a workflow can call it, and only after the right person completes an approval task. The approval travels with the posting: CoPlane writes the approver into the ERP's own note on the entry, and the workflow keeps their comment.

Evidence. CoPlane records every Action call, including the refused ones: who called it, from where (an app, Claude, a Copilot Studio agent or a workflow), when, and with what inputs. A failed call stays in the log even when the transaction around it rolls back. When your auditor asks who approved a credit, you open one page.

“

“We're adopting AI tooling across our finance function, and it's been a game changer. But the real challenge is connecting AI assistants to our systems reliably and repeatably. CoPlane gives us a secure way to connect AI to our most sensitive back-office systems and orchestrate governed, repetitive AI-enabled workflows.”

Actions are code

CoPlane is pro-code because it's pro-AI. Coding agents write good code now, and code is the format your company already knows how to review, test, version and roll back. An Action is a typed function in a repository you own. An agent can write one from a system's API docs in an afternoon, and your engineers review it in a pull request like anything else they ship.

That changes who gets to ask for automation. If you work in finance, you don't wait on an integration roadmap. You describe what you need, say a vendor's open items as of December 31, an agent writes the Action, IT reviews it, and from then on you call it from Claude or Copilot Cowork, from a workflow or from a button in an app built for your team.

If you run IT, you approve each connection once, in code you can read. Every new use case after that reuses reviewed Actions under the same policy, so you stop issuing another bot its own service account.

What your IT team gets

One connection per system. CoPlane holds each system's credentials. People, workflows and assistants use Actions and never see them. Your ERP sees a single integration user, so CoPlane writes the real person into the comments and notes the ERP keeps.

Identity from your provider. Roles come from your identity provider, for example AP clerk, buyer, controller and auditor. CoPlane maps each role to the policy, so when you offboard someone in your identity provider, they lose every Action, including the ones they reached through Claude or ChatGPT.

Policy you can review. The rules live in a file your team versions, tests and reads in a pull request. Nobody needs a vendor's admin console to find out who can post.

Your cloud. CoPlane deploys inside your cloud environment. Your data, your credentials and your Actions stay in infrastructure you control.

Room for what the API lacks. When an ERP's standard API can't do something, like approve a held invoice or compute a vendor's balance as of a past date, we add a small extension inside the ERP and wrap it in an Action. An Action can call an API, exchange a file, query a database or drive a screen, and the people and agents using it don't need to know which.

Your copilot's favorite copilot

Ava runs accounts payable at Harbor, a demo company on Microsoft Dynamics 365 Business Central. It's February 2. Apex Industrial Supply's December statement says Harbor owes $39,050. Business Central says $17,150.

She asks Claude which statements disagree with the books. Claude answers by calling Actions. One reads the statements that arrived by email. Another reads Apex's balance as of December 31 straight from Business Central: open items, vendor balance and the payables account all show $17,150. Reconciliation rules have already explained $10,200 of the gap, a check in the mail and goods still in transit. Six items need a person.

Ava resolves the first one in CoPlane with a click. She hands the rest to Claude, which calls the same Action her button called, and her screen updates while it works.

Then she asks Claude to approve a held invoice in Business Central. Claude tries, and the policy refuses: price variances belong to buyers, and Ava works in AP. The refusal goes into the activity log under her name.

Last comes a $300 rebate the vendor credited and Harbor never booked. Claude drafts the credit memo in Business Central, but it can't post it, because Claude has no tool that posts. The draft waits on a task assigned to Connie, the controller. She approves, the workflow posts the credit memo, and Business Central's own note on the entry records who asked for it and who approved it.

The video uses Claude, but nothing in it is specific to Claude: ChatGPT for Work, Copilot Cowork or a Copilot Studio agent can connect to the same Actions over MCP, under the same policy. Those are the three controls from above, on a real ERP. To get past Business Central's standard API, we added a small extension for key-date balances and held-invoice approvals, and wrapped each in an Action.

Surfaces: the screen you need, on the Actions you have

A surface is a custom app that runs inside CoPlane. The Vendor Statement Hub in the video is one: the vendor's statement next to the ledger, built for one team's month-end, and every button in it calls an Action. Surfaces and assistants share the same Actions, so the hub and your copilot stay in step, and the policy that refused Claude would refuse the button too.

Put surfaces and Actions together and you can reach systems no API will ever cover. Plenty of back offices still run on IBM i, the AS/400. We built a surface that renders a live 5250 terminal session, and a set of Actions that drive it: start a session, log in, read the screen, type, press function keys. In the clip below, ChatGPT for Work uses those Actions over MCP to find a passenger's booking in a demo airline system.

The login is an Action with the credentials injected as secrets, so neither ChatGPT nor OpenAI ever sees them. This is an excerpt from a recent walkthrough. We are automating real green screen workflows in production today!

Connected today

Action packs exist today for Microsoft Dynamics 365 Business Central, NetSuite, Workday, Acumatica, Microsoft Graph and Stripe. If yours isn't on the list, a new pack takes a few hours: coding agents write most of it from the system's API, and your team reviews it like any other code.

How an Action works

An Action has a name, a typed input and output, a declared effect (read, write, communication or destructive), and the resources it touches. Every call goes through one executor, which validates the request, resolves the resources, checks the policy, runs the code and records the outcome.

You choose where each Action appears: in surfaces, in workflows, over REST, or to assistants such as Claude, ChatGPT for Work, Copilot Cowork and Copilot Studio through the Model Context Protocol (MCP). Some Actions appear nowhere at all, and only a workflow step can reach them. The posting Action in the video works that way.

Start with one process

Pick the process that costs you the most hours or carries the most risk: vendor statements, the payment run, daily cash. Connect the two or three systems it touches. Run it with your people approving what they approve today, and watch where the time and the exceptions actually go. Your next process reuses those Actions.

See Actions on your ERP

We'll connect CoPlane to your ERP and one process you choose, in your cloud.

Work emailGet in touch

By submitting, you agree to our privacy policy.