Finaudax
← All chaptersChapter 6 of 8

Integrations and operational automation

You only connect AI to systems after processes, data, and exceptions are manageable.

After this chapterYou can design an integration with minimal rights, reliable transfer, approval, and runbook.
Your progress0 of 48 lessons
6.1

The process before automation

Do not automate an unclear process; make decisions and exceptions visible first.

Map trigger, input, transformations, decisions, actions, systems, and wait times. Note where value and transfer loss occur.

Remove unnecessary steps before technology. Measure variation and exceptions; an unstable process requires standardization or limited assistance first.

  • Trigger
  • Input
  • Decision
  • System
  • Exception
  • Waiting time
This is how you can use this

An invoice flow slows down due to unclear approval boundaries, not because of text entry.

Try this prompt
Model [process] as-is and to-be with trigger, steps, decisions, systems, waiting time, errors, and exceptions. Eliminate waste before AI.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Observe ten cases and count variants and exceptions.

6.2

Connect calendar, email, CRM and spreadsheets

Design per system source, identity, permissions, fields, and write-back rule.

Make clear who has access to which mailbox, calendar, records, or sheets. Separate reading and writing and define field mapping, source of truth, and conflict behavior.

Use minimal scopes and a test environment. Log actions without unnecessary sensitive content and confirm external communication or critical changes.

  • System
  • Identity
  • Scope
  • Field mapping
  • Source of truth
  • Write gate
This is how you can use this

A CRM connection reads assigned leads and writes a draft note, not a final deal status.

Try this prompt
Design the connection between [systems]. Specify identity, read and write rights, field mapping, source of truth, conflict rule, logging, and approval gate.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Draw one data record from source to destination and back.

6.3

Choosing automation levels

Start with assistance and increase autonomy only based on evidence and recoverability.

Use a ladder: inform, draft, recommend, execute after approval, limited automatic and autonomous within hard boundaries. Error impact, detectability and reversibility determine the level.

Record KPIs, guardrails and fallback. A successful low-risk pilot does not prove that financial or public actions are appropriate.

  • Assistance
  • Recommendation
  • Approval
  • Autonomy
  • Guardrails
  • Fallback
This is how you can use this

Support answers are first proposed before proven low-risk categories proceed automatically.

Try this prompt
Place [tasks] on an automation ladder. Justify with impact, detectability, reversibility, and evidence. Provide promotion and fallback criteria.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Classify ten process steps and choose one candidate for a promotion.

6.4

Validation, duplicate processing and recovery

An integration must safely detect, block, and recover from errors.

Validate formats, mandatory fields, business rules, and source version. Use unique keys or idempotent actions so that a retry does not create duplicate mail, booking, or payment.

Design time-outs, retry limits, quarantine, and compensation. Keep enough audit information without logging more sensitive data than necessary.

  • Schema
  • Business rule
  • Unique key
  • Retry
  • Quarantine
  • Compensation
This is how you can use this

A repeated webhook uses the same order ID and does not create a second order.

Try this prompt
Create error and recovery rules for [integration]: validation, idempotency key, time-out, retry, quarantine, compensation, and audit fields.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Simulate a time-out after a partially successful action.

6.5

Human approval as a pattern

An approval step shows what changes, why, and with what risk.

The reviewer receives source data, proposed action, changes, uncertainty, and consequences. Only present meaningful decisions to limit approval fatigue.

Determine authority, confirmation fields, and reason for rejection. Critical actions do not receive implicit approval on timeout.

  • Decision context
  • change
  • Risk
  • Reviewer
  • Rejection
  • Timeout
This is how you can use this

A quote check shows the price source, margin deviation, and customer conditions next to the send button.

Try this prompt
Design an approval screen for [action] with source, proposal, modification, uncertainty, consequences, confirmation fields, rejection, and timeout.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Test with someone who did not build the process.

6.6

Monitoring, incidents and runbooks

A production flow needs signals, thresholds, an owner, and a recovery procedure.

Monitor volume, success, latency, error categories, corrective work, guardrails, and costs. Combine technical and business metrics; technically green can hide poor customer outcomes.

The runbook describes diagnosis, pausing, manual fallback, communication, recovery, and post-incident review. Practice before a real outage.

  • Signal
  • Threshold
  • Alarm
  • To pause
  • Fallback
  • Postmortem
This is how you can use this

A price flow pauses with a rising override rate, even if the API remains available.

Try this prompt
Create a monitoring plan and runbook for [workflow] with metrics, thresholds, alert route, kill switch, fallback, communication, and postmortem.
Quick knowledge check

Which approach best fits this lesson?

Your practical assignment

Conduct a table-top incident and measure recovery time.

Chapter assignment

Bring everything together

Design a single integration with process map, permissions, mapping, automation level, error handling, approval, and runbook.