Change is in the air: Actions, Data Connectors, and Procedures

Until today, Flexivity’s AI did one kind of thing: it answered customer questions, drafted replies, resolved conversations within the scope of what your knowledge base said. All of that is grounded, controlled, and governed by Progressive Autonomy — the ladder from Assist (AI drafts, agent ships) to Resolve (AI handles the conversation end-to-end).

But a lot of customer requests don’t just need an answer. They need something to happen. A refund issued. A shipping address changed. An order cancelled. A subscription updated.

Today’s launch extends what the AI can do into those changes — with the same controlled, grounded, step-by-step approach you already know.

Three pieces, launching together:

• Data Connectors — the plumbing that lets the AI reach the systems where your customers’ records live
• Actions — the capability for the AI to make changes in those systems, with the same ladder of autonomy that governs its conversations
• Procedures — plain-language instructions that tell the AI how to handle a specific kind of request, orchestrating lookups, questions, conditions, and changes

Each one is useful on its own. Together, they let Flexivity close the loop on requests that need something done, not just answered.

Data Connectors: Reach into your systems

The AI needs to see the customer’s actual records to do anything useful about them. Data Connectors give it that reach — safely.

• Stripe: find the customer, list their recent charges, look up one charge, list their recent invoices, refund a charge in full or in part.
• Shopify (beta): orders, products, and pages.
• Any MCP server: connect anything that speaks the Model Context Protocol, add tools one by one, and choose what each one does. Zapier is supported through its MCP server, which reaches 9,000+ apps — a Google Sheet, a Zapier Table, or an app your team already uses.

A few things that matter about how this works:

• Always about the customer on the ticket. The customer is identified from your help desk. Nothing the AI writes, nothing the customer types in the conversation, can point a lookup at someone else. In chat, a customer is looked up only when they’re signed in. A charge or invoice belonging to another customer is never returned.
• You decide what the AI sees. For each tool, each field of the result is passed or withheld. Flexivity keeps little of what it reads — and never a name, address, email, or phone number.
• Nothing runs until you turn it on. Every tool starts Off. Test it first — including as a specific ticket’s requester — before you enable it. Each connector shows its health and recent activity.

Data Connectors is out of beta today.

Actions: What the AI does with those systems

Looking things up is read-only. Actions are what happens when the AI needs to change something — refund a charge, cancel an order, update an address.

Change comes with risk, so change is governed. Flexivity now has a second ladder, beside the seven levels of Progressive Autonomy, that controls what the AI may do when it writes:

What the AI does for each write mode:

• Manual - Hands the ticket to a person with what to do, and prepares nothing.
• ‍Assist - Prepares the change on the ticket. An agent approves, edits the amount, or rejects it. This is the default.
• ‍Hold - As Assist, while the customer stays in the conversation. They’re told a colleague is confirming, and told it’s done once the change is approved and your system confirms it.
• ‍Execute - Makes the change itself, within the tool’s limits, and tells the customer once your system confirms it.

The two ladders work together: Hold and Execute apply at the Resolve conversation level, where the AI is already carrying the conversation end-to-end. At every other conversation level, write modes work as Assist — a change is prepared on the ticket for an agent to approve.

Write mode is set per tool and per brand. A refund tool might be at Assist for most brands, Hold for one with a mature deployment and clear policy. The choice is yours.

Prepared changes on the ticket

Every change the AI prepares shows up in the Flexivity panel as a card. It shows what the change will do, every check it ran (each Passed or Not passed), and when it expires. Approving runs it exactly once; the decision is recorded on the ticket as an internal note.

Safeguards before every change

The point of this launch isn’t that the AI can do things. It’s that it can do things safely.

• Checked before it runs, and again when it runs. The record being changed must come from a lookup for the customer on that ticket. Every tool has limits — by default at most one change per customer per 24 hours, which you can tighten but never loosen. A change that moves money needs a largest amount per change before the AI may make it unattended.
• Only an administrator can choose Execute. Agents can’t flip a tool to unattended on their own.
• A circuit breaker puts a person back in the loop when unattended changes run unusually. The system watches itself.
• Agents can mark a change the AI made “This change was wrong,” and each tool’s page shows what happened to its changes, by brand and by write mode.

Available today on Zendesk and both hosting modes of osTicket (needs Flexivity plugin 2.10.0 or later, and self-hosted install agent 1.6.0 or later).

Procedures: Teach the AI how your team handles a request

Reading records and writing changes is capability. Deciding when to do each one — on which tickets, in which order, with which questions, under which conditions — is logic.

Procedures are how you tell the AI that logic, in plain language. No code. No workflow builder. No vendor engagement.

Three ways to start:

• From one of five samples: Order status, Cancel before shipping, Damaged item refund, Damaged item refund (store order), Address change.
• By pasting the Standard Operating Procedure your team already follows, which Flexivity drafts for the AI.
• From a blank page, if you want to write it from scratch.

You write what the AI should do in natural language. Name a tool by typing @ — or write “look up the order” and Flexivity proposes the right tool for you to confirm.

Before a procedure goes live, the Reading tab shows what Flexivity understood: the steps in order, the tool each step uses, the questions it may ask (including which ones ask for a file, like a photo of the damage), its conditions, and its handovers. If what you wrote and what Flexivity understood don’t match, you fix it before it ever runs.

Then it’s enforced in code, not just as instructions to the AI:

• A change is prepared only when the procedure reaches it. The AI can’t skip ahead.
• The target of a change must come from a lookup for this customer. No freelancing on which record to touch.
• A condition like “only if the order has not shipped” is checked against that record before the change can run.

Test conversations let you check that a procedure behaves as expected — including that a change is not prepared when it shouldn’t be. The samples that change something come with one of each.

Edits create a draft; the published version keeps running until you publish the new one. A procedure that changes something is published only once its tests pass. Each conversation keeps the version it started with.

Putting it together

Imagine a customer writes in: “My order #12345 arrived damaged — the screen is cracked. Please refund.”

With a Damaged Item Refund procedure in place, Flexivity:

1. Matches the ticket to the Damaged Item Refund procedure
2. Uses a Zapier-connected tool to look up order #12345 in your order management system
3. Asks the customer for a photo of the damage (per the procedure)
4. Checks the conditions: order is within the refund window, charge exists on Stripe
5. Prepares the refund via the Stripe refund tool, with the amount and reason filled in
6. Based on the tool’s write mode: an agent approves (Assist/Hold), or the AI runs it directly (Execute, if an admin set it so and the amount is within the threshold)
7. Tells the customer the refund has been processed, once Stripe confirms it

Three pieces, one coherent flow. The procedure orchestrates. The connectors reach — Stripe natively, your order system through Zapier. The action makes the change, within the write-mode ladder you set.

Where this fits

Progressive Autonomy was already about controlled AI — a ladder you climb when you’ve earned the trust, with the boundary staying wherever you set it. Today’s launch extends that philosophy from conversations into the systems where your customers’ records live. The AI can now do things, not just say things. And the control over how far it goes stays with you.

If you’ve been following along: Procedures sit alongside your knowledge base in Flexivity. Both ground the AI in your context. The knowledge base covers the information customers need; procedures cover the steps your team takes. The AI uses both.

Documentation is here: Capabilities, Procedures, Data Connectors, and Prepared Changes for Zendesk and osTicket.

If you’d like to see this running in your own help desk, book a demo or see pricing.

‍