Picture Monday at half past seven. The receivables clerk opens her drafts folder and every overdue customer already has a follow-up waiting, each one citing the invoice, the job it paid for and what the customer last said. The accounts that should not be chased are held, with the reason written down. She did not export a report, open the job schedule or search her inbox. That is what happens when a workflow connects not just your people, but your business systems: 10X the ROI of your existing AI, in a receivables office.
So yes, a workflow can work in your systems instead of waiting for someone to export from one and paste into another. The workflow carries how your company does the work; a connector lets it read what it needs in one system and leave its output in another. The work that matters crosses systems shows how to map the handoffs between systems. This piece answers the next question: what a connection can see, what it can change and who decides.
Three systems, one Monday.
Illustrative example with invented data. Greenline Grounds, an invented 45-person landscaping contractor serving homeowners’ associations, commercial sites and homes.
Every Monday, Greenline’s receivables clerk follows up on overdue invoices. It used to take three systems and most of the morning. She exported the aging report from the accounting system. For each overdue invoice she opened the job schedule to confirm the crew had finished the work, because a customer whose irrigation repair is still open is not a customer to chase. Then she searched her email for the last exchange, so she would not repeat a reminder or ignore a reply.
The judgment in that routine is the valuable part, and it stays. The workflow follows Greenline’s rules: a light reminder at 15 days, a request for a payment date at 30, a call once an account passes 60 days or misses a promised date, and no follow-up while a complaint is open or a payment may already have arrived. The connectors remove the exporting, the tab-switching and the pasting. Greenline started from the overdue-invoice follow-up preparation workflow template and adapted it to those rules.
What each connection can see, and what it cannot change.
Each connector has one job. Its permissions are set in the connection and in the system itself, not written into the workflow’s instructions and left to good behavior. Greenline’s operations manager, who approves the company’s systems, signed off each one.
Illustrative example with invented data. Greenline Grounds’ three connections for the Monday follow-up.
| Connection | What it can see | What it cannot change |
|---|---|---|
| The accounting system | Open invoices with amounts and due dates, payments received but not yet matched, and each customer’s billing contact. | Any invoice, payment, credit or customer record. It cannot send a statement. |
| The job schedule | For each invoiced job: whether the visit was completed, the crew lead’s notes and any open complaint or callback. | Any job, visit or crew assignment. It cannot close a complaint. |
| The clerk’s last exchange with each customer about the invoice. | Anything except her drafts folder, where it may save a draft. It cannot send a message. |
Illustrative example with invented data. The prepared follow-up, Monday 2 November 2026.
Overdue-invoice follow-up: Monday 2 November
- Drafted (14)
- One follow-up per overdue customer, each citing the invoice, the amount, the date the crew completed the job and the customer’s last message. All fourteen are in the clerk’s drafts folder.
- Held (2)
- Invoice 2214, a commercial site: the job schedule shows an open complaint about an unfinished irrigation repair. Held until the crew lead closes it. Invoice 2230, a homeowners’ association: a payment of the same amount arrived on Friday and is not yet matched. Held until the bookkeeper matches it.
- To call (3)
- Two homeowners’ associations more than 60 days overdue, and one homeowner whose promised payment date of 26 October has passed.
- Read from
- The accounting system as of 7:00 this morning, the job schedule, and the clerk’s email threads from the last 90 days.
- Changed
- Nothing in the accounting system or the job schedule. Fourteen drafts saved; none sent.
The workflow prepares. The clerk reads every draft, edits what needs her voice, sends each one herself and makes the three calls.
How we choose a connector.
Many connectors are built on the Model Context Protocol (MCP), an open standard that gives an AI application one common way to reach tools and information in other systems. How instructions and connections work together explains it in more depth. Whatever sits underneath, we choose each connector in the same order.
- The system’s own connection.A growing number of business systems publish a connection for AI themselves. Its maker maintains it, and it respects the permissions you already set there. It is always our first choice.
- A proven third party’s.Where the system offers none, a provider that specialises in connections often does. We choose one with a record of keeping its connections current, and we check exactly what it can reach before your approver reviews it.
- One we build.Where neither exists, we can engineer the connection ourselves, limited to the reads and the changes the workflow needs. A new connector is never assumed: whether to build one is agreed in scoping, after the workflow has proved itself on exports.
Until a connection is approved, the same workflow runs from an export or an upload. Its rules and tests do not change; the connection removes the step where someone moves information by hand. If you change AI platforms, the workflow moves with you and the connections are the part you set up again, as What moves between AI platforms sets out.
The connection sheet, ready to copy.
Fill in one sheet per workflow before any connection is set up, and keep it with the workflow.
Connection sheet: [workflow name]
- The systems. List every system the work touches today, including email and shared folders. Done when: the people who do the work cannot name one that is missing.
- What it reads. For each system, the records the workflow needs and nothing more. Name fields where it matters: amounts and due dates, not bank details.
- What it may change. For each system, one of three answers: nothing, drafts only, or named updates. Start from nothing and add only what the work needs.
- Who says go. The role that sends, posts or records each output. Nothing is sent, posted or recorded until that person acts.
- The route. For each system: its own connection, a proven third party’s, or one we build. Until it is approved: [export, upload or shared folder].
- Where the limits are set. Confirm each permission is set in the connection or the system itself, not only in the workflow’s instructions.
- The test. Run the workflow on last month’s cases with the connections in place. Done when: it read what was expected, changed nothing it should not, and the owner has checked every output.
Where to start.
Start with repeated work: a connector set up once pays back on every run. Your plan in the Fully Powered Planner says which workflows each team should be practising; the connection sheet says which systems each of those workflows needs.
Connecting a workflow to systems you already use is part of building it wherever a connector already exists, and what gets connected is agreed when we scope the work. The 2-Week Workflow Sprint finds an area of your business, captures how your team does the work by asking them, and builds the workflows out. Fully Powered Connectors is our name for choosing those connections, setting them up and keeping them working; our security page explains how we handle your information.
All of it runs on the AI platform your team already uses: ChatGPT, Claude, Copilot or Gemini. AI prepares the work; a person checks it and decides. Your organization keeps control of how the work gets done.
Bring one piece of work your team exports and pastes for every week, and the systems it touches.