How we build secure workflows for workflow-heavy teams

Most teams we speak to want the same thing from AI-assisted workflows: less admin, faster follow-up, fewer things falling through the cracks — without putting client data at risk or losing control of who sees what. That is entirely achievable, but it does not happen by accident. It happens because the workflow is designed with security and privacy built in from the start, not bolted on after someone pastes a spreadsheet into a chat window.

This article walks through how we set that up in practice. We use a fictional but realistic example — Riverside Accounts, a 12-person firm in the Midlands handling VAT returns, payroll, and year-end accounts for local SMEs — and show exactly how we would design, build, and run a secure client-onboarding workflow for them.

The problem Riverside Accounts wanted to solve

When a new client signed up, the office manager copied details from an enquiry form into Xero, created a folder in SharePoint, emailed the partner for AML checks, and chased the client for ID documents over email. Nothing was wrong with the people — the process was fragmented. Client names, NI numbers, bank details, and company financials lived in inboxes, attachments, and half-filled spreadsheets. The partner knew this was a GDPR and AML risk, but "we have always done it this way" had stuck.

They wanted a workflow that could: pull a new enquiry from their CRM, prepare a client folder structure, draft a welcome pack, flag missing AML documents, and notify the right person — without copying sensitive fields into tools that were not approved, and without AI making decisions that only a qualified accountant should make.

What "secure workflow" means for a firm like this

Before writing a line of code, we agree what secure means for this specific business. For Riverside Accounts, that boiled down to five principles:

• Data stays where it belongs. Client PII and financial records remain in approved systems (SharePoint, Xero, their CRM). The workflow moves references and summaries — not full document dumps — unless there is a documented reason.
• Least privilege everywhere. Each connection uses the narrowest access possible. The onboarding workflow can create a SharePoint folder and read CRM fields — it cannot delete client records or access unrelated mailboxes.
• AI assists; people decide. AI can draft a welcome email or summarise what is still missing from an ID checklist. It cannot approve a client, sign off AML, or send anything to the client without a named human review step.
• Everything is logged. Who triggered what, when data moved between systems, what AI produced, and who approved it — all recorded in an audit trail the partner can inspect.
• You can turn it off. If something feels wrong, the workflow can be paused without breaking access to the underlying tools.

Step 1 — Classify the data before you connect anything

We start with a simple data map. For client onboarding, Riverside Accounts had four tiers:

This table drives every design decision that follows. Restricted data never leaves SharePoint. Confidential data can be referenced by the workflow ("client VAT number on file: yes/no") but not pasted into an AI prompt as raw text. That single rule eliminates a whole class of accidental leaks.

Step 2 — Design the workflow with explicit boundaries

We map the target workflow end to end before building. For Riverside Accounts, the flow looked like this:

NEW ENQUIRY (CRM webhook)
        │
        ▼
┌───────────────────┐
│ Validate & enrich │  ← read-only CRM + Companies House (public data)
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Create client     │  ← SharePoint folder from template (scoped app access)
│ folder structure  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Draft welcome     │  ← AI: internal tier only, no restricted fields
│ pack & checklist  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ HUMAN REVIEW      │  ← office manager approves before anything sends
│ (office manager)  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Send welcome +    │  ← email via Microsoft 365 (OAuth, sent-as user)
│ document request  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Monitor uploads   │  ← checks folder for required docs (metadata only)
│ & chase reminders │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ PARTNER SIGN-OFF  │  ← AML complete → create Xero contact
│ (partner)         │
└───────────────────┘

Two human gates — office manager review before client contact, partner sign-off before the client exists in Xero — are non-negotiable. The workflow cannot skip them. That is a design choice, not a training issue.

Step 3 — Write typed workflow code you can review

We implement workflows as typed TypeScript — not opaque drag-and-drop chains that nobody can read. Each step is a function with clear inputs and outputs. That matters for security: you can code-review exactly what happens to client data before anything goes live.

Here is a simplified version of how the "draft welcome pack" step is structured. Notice how restricted fields are excluded at the type level:

// What the workflow is allowed to pass forward
type ClientOnboardingContext = {
  enquiryId: string;
  companyName: string;
  contactName: string;
  servicesRequested: ('vat' | 'payroll' | 'year-end')[];
  partnerAssigned: string;
  // Explicitly NOT included: niNumber, bankDetails, idDocumentUrls
};

async function draftWelcomePack(ctx: ClientOnboardingContext) {
  const checklist = buildDocumentChecklist(ctx.servicesRequested);

  const draft = await aiAssist({
    purpose: 'draft-welcome-email',
    // Only internal-tier fields enter the prompt
    input: {
      companyName: ctx.companyName,
      contactName: ctx.contactName,
      services: ctx.servicesRequested,
      missingDocuments: checklist.filter((d) => !d.received),
    },
    // Firm-approved template constrains the output
    templateId: 'riverside-welcome-v2',
    // No training on client data
    retention: 'none',
  });

  return { draft, checklist, status: 'pending-review' as const };
}

The TypeScript types act as a contract. If someone tries to pass a bank account number into the AI step, the code will not compile. That is a small example, but it scales — every integration point gets the same treatment.

Step 4 — Secrets, connections, and scoped access

Riverside Accounts uses Microsoft 365, a cloud CRM, Xero, and SharePoint. Each connection is set up with purpose-specific credentials stored in a secrets vault — never in the codebase, never in a shared spreadsheet, never in environment files emailed around.

• OAuth where possible. Microsoft 365 and Xero use OAuth with refresh tokens scoped to exactly what the workflow needs. We request `Mail.Send` for the shared onboarding mailbox, not full mailbox admin.
• App registrations, not shared passwords. SharePoint access uses an app registration with access limited to the `/Clients` site collection — not the partner's personal OneDrive.
• Webhook verification. The CRM sends new-enquiry events via signed webhooks. The workflow rejects any payload that fails signature validation — so random internet traffic cannot trigger client folder creation.
• Separate credentials per environment. Development, staging, and production each have their own secrets. Test data never touches production Xero.
• Rotation without drama. When a token expires or a staff member leaves, credentials rotate in the vault. The workflow code does not change.

What we tell the client to check with their IT provider

For a 12-person firm, we produce a one-page connection summary their IT support can verify: which app registrations exist, what permissions they hold, who owns them, and how to revoke access. No black boxes.

Step 5 — AI with data minimisation and firm-approved boundaries

AI is useful here — drafting welcome emails, summarising what documents are still missing, suggesting follow-up wording. But Riverside Accounts was right to be cautious. Our rules:

• Send the minimum. Prompts contain only the fields needed for the task. Not "here is everything we know about the client."
• Use firm templates. AI fills in a pre-approved structure. It does not invent policy language or make compliance claims.
• No retention. We configure AI calls so client content is not stored or used for model training by the provider.
• Redact by default. If a CRM field might contain unexpected PII (free-text notes), we strip or truncate before it reaches AI.
• Log the intent, not the content. Audit logs record "AI draft generated for enquiry ENQ-2041" — not the full prompt and response.

Step 6 — Monitoring, alerts, and audit trails

Once live, the workflow runs on a managed orchestration platform with built-in monitoring. Think of it as a flight recorder for your automations: every run is visible, failures alert the right person, and history is searchable.

• Run history. Each onboarding attempt has a trace: started at 09:14, CRM validated, folder created, draft generated, waiting for review. If something stalls, you see exactly where.
• Failure alerts. If SharePoint is down or Xero rejects a contact, the office manager gets a Teams message — not a silent failure buried in a log file.
• Audit export. Monthly, the partner can export a CSV of workflow events for compliance records: who approved what, when clients were created, when reminders went out.
• Anomaly visibility. Unusual patterns — ten onboarding runs in an hour, repeated webhook failures — surface in the monitoring dashboard.

For Riverside Accounts, this replaced the old question of "did that email go out?" with a clear yes/no in a dashboard the office manager checks each morning.

Step 7 — Human review gates that actually hold

The two review steps are implemented as explicit workflow pauses — not informal "please check this" emails.

1. After the welcome pack is drafted, the workflow creates a task in the CRM assigned to the office manager. Nothing sends to the client until they click Approve or Edit and approve in a simple review screen.
2. If the office manager rejects or edits, the audit log captures the change and who made it.
3. When all required documents appear in SharePoint (checked by filename and metadata — the workflow never opens the ID scan itself), the partner gets a sign-off task.
4. Only after partner approval does the workflow create the Xero contact and mark the client as active.

These gates are the difference between "AI-assisted" and "AI in charge." The firm keeps professional accountability. The workflow keeps things moving between those decisions.

Step 8 — Environments, testing, and rollout

We never test against live client data. Riverside Accounts' rollout looked like this:

1. Development — synthetic enquiry data only. Connections pointed at sandbox or test tenants where available.
2. Staging — a copy of the workflow against real tool connections but limited to two internal test clients the partner created.
3. Pilot — three real new enquiries, with the office manager reviewing every step manually even after approval was given.
4. Full go-live — monitoring alerts confirmed, playbook written, partner briefed on how to pause the workflow.

Total build time for this workflow: about three weeks, including security review and a half-day training session for the office manager and partner.

What Riverside Accounts sees day to day

From the team's perspective, not much changed visually — and that is intentional. A new enquiry still lands in the CRM. The difference is what happens next:

• Within minutes, a SharePoint folder exists with the right subfolders and a draft welcome email waiting for review.
• The office manager spends five minutes approving instead of forty minutes assembling.
• The client gets a consistent, professional welcome pack — not a slightly different email depending on who was busy.
• Reminders for missing ID go out automatically on day 3 and day 7, stopped instantly when documents arrive.
• The partner gets one notification when AML is ready for sign-off — not three chasing emails from the office.

Sensitive documents stay in SharePoint. AI never saw the passport scan. The audit trail shows exactly who approved the client. The partner sleeps better.

A checklist for business owners

Whether you work with us or build internally, ask these questions before any AI-assisted workflow goes live:

1. Have we classified what data is public, internal, confidential, and restricted?
2. Does each system connection use the narrowest access possible — ideally OAuth, not shared passwords?
3. Are secrets stored in a vault, rotated without code changes, and separate per environment?
4. Can we see a trace of every workflow run — and get alerted when something fails?
5. Are there explicit human approval steps before client-facing or compliance-sensitive actions?
6. Does AI receive the minimum data needed — with no training retention — and stay inside firm-approved templates?
7. Can we pause or revoke the workflow without losing access to our core tools?
8. Is there a one-page summary our IT provider can review?

If the answer to any of these is "we are not sure," that is the place to start — not with buying another AI tool.

Security is a design choice, not an afterthought

Workflow-heavy teams handle sensitive data every day. The goal of a well-built workflow is not to add risk in exchange for speed — it is to reduce the risk you already have from manual copy-paste, inbox sprawl, and unchecked AI use, while giving your team time back.

Riverside Accounts' onboarding workflow is one example. The same principles apply to dental recall lists, estate agent enquiries, legal matter opening, or trades quote follow-up: classify the data, draw the boundaries, write reviewable code, connect with least privilege, monitor everything, and keep humans accountable where it matters.

If you are weighing up an AI-assisted workflow and want to talk through what secure would look like for your business, book a call — initial chat, no charge.