Before you connect AI to business systems

A connected tool is only the starting point

An AI assistant that summarises a document has a different job from one that changes a customer record. Before connecting either to business systems, agree what it should use, what it may change and who deals with an uncertain result.

Recent product changes make this a timely question. OpenAI's 1 October 2026 Business update added plugin and marketplace management in its Admin console. Its administration guidance distinguishes installing a plugin from granting app access, enabling actions and choosing approval behaviour. The practical implication: seeing a tool in a menu does not settle what a workflow is allowed to do.

This checklist is for business owners and operations teams planning a connected AI workflow. It is a preparation method, not a claim that any particular product or setting is available in your account.

1. Describe one complete job

Choose a task with a clear beginning and end: turn an incoming enquiry into a draft brief, find an answer in approved procedures, or extract fields from a document for review. Write down the input, expected output and person responsible. Avoid starting with permission to handle an entire department's work.

Record the current process first. How long does a typical item take? What needs checking? Where do people correct mistakes? Those observations give you a useful baseline for a pilot.

2. Separate reading, drafting and changing

Read: identify the exact documents, folders or records the task needs, and the account it will use to reach them.

Draft: decide where a proposed answer or update will be saved, and how a person will see its sources and unresolved questions.

Change: list each permitted action separately. Updating a record, sending an email and deleting an attachment are different actions. Give the pilot only the access its agreed job requires.

Check the actual execution account, including for scheduled work. OpenAI's team-task documentation, for example, says access depends on the configured connected accounts. A successful request in one person's chat is not proof that a shared background task has the same access.

3. Make review part of the workflow

Name the person who can accept, correct or reject a proposed change. Show them the proposed action, affected record and supporting information. Decide what happens if they are unavailable: an item waiting for review should remain visibly pending.

Where the platform supports it, use action restrictions and approval controls alongside written instructions. Check which controls apply to the actual conversation, agent or scheduled task; they are not interchangeable. Test the result rather than assuming a prompt enforces a permission boundary.

An illustrative enquiry workflow

Receive an enquiry → prepare a draft brief → review → update the approved record.

An assistant reads a permitted enquiry and drafts the requested work, contact details and missing information. A team member checks the draft against the original message. Only the approved fields move into the customer-management system; uncertain details remain questions.

If the update fails, the item stays pending. Before retrying, check whether a record was already created. This is an illustrative design to scope around your systems, not a client result or a promise of automatic compatibility.

4. Test the awkward cases

Use approved, representative examples: a normal request, missing information, a duplicate, conflicting source documents and an account without access. Agree the expected behaviour for each before running the pilot. Include text in an incoming document that tries to redirect the task; it should not override your workflow instructions.

Check more than the wording of an answer. Did the right record change? Was a rejected action withheld? Could the reviewer identify the source? Could the team tell a completed item from a failed or pending one?

5. Decide who owns it after launch

Assign an owner for instructions, connections, exceptions and ongoing costs. Keep enough run history to diagnose failures, while avoiding unnecessary copies of sensitive information. Agree how to pause the workflow and return to the existing process.

Compare the pilot with your baseline: time spent including review, corrections required, exceptions and completed work. Expand only when the agreed checks pass. Repeat relevant tests when the model, connected app, permissions or business process changes.

Prepare your first workflow

Prepare one example of the task, the systems involved, permitted actions and review owner. Our AI implementation service starts from business workflows. Where information needs to move between applications, explore business systems integration.

Discuss the workflow with Detron to work through the scope, available access and checks a pilot would need.