CCAO-F · module 2 of 7 · 16% of the exam

Workflow integration and solution design

Weight: 16 percent of the exam. This domain tests whether you can look at how work actually gets done in a team and decide which parts Claude should touch, where the humans stay, how to prove it worked, and how to explain it to people who did not ask for it.

What the exam expects

Domain 1 asks whether a single output can be trusted. Domain 2 asks whether a process has been designed properly. The unit of analysis moves from one response to a sequence of steps with inputs, handoffs, review points, owners, and a business outcome someone is accountable for.

The official objectives are: analyse requirements and understand use cases with Claude; use Claude for research, planning, and process optimisation; support solution design and iterative refinement; incorporate Claude into existing workflows to enhance or redesign them; and communicate Claude's value and limitations to stakeholders.

In practice, five decisions recur in every scenario:

1. Fit. Should Claude touch this task at all?
2. Decomposition. Where does the process split into steps, and which steps get help?
3. Checkpoints. Where do the humans sit, and what do they own?
4. Proof. How will anyone know it worked?
5. Communication. How is this explained to stakeholders without overpromising?

You are usually asked what to do first, what is wrong with a proposed design, or which change most improves it.

Deciding fit: which tasks belong here

A task is a strong candidate when it satisfies three conditions together.

Three categories are poor fits, and the exam tests all three:

• Deterministic computation. A fixed formula applied to structured data (payroll, tax calculation, invoice totals) belongs in software that computes. Being fully specified is a reason to use a calculator, not a language model. The exam inverts this deliberately: "the task is well defined, so it is easy to automate" is a wrong answer.
• Live data and transactional writes. Current inventory, today's interest rate, this minute's ticket queue. These come from the system of record through an integration, and reserving stock or committing a transaction happens in that system. A model can converse about inventory; it cannot be the inventory.
• Decisions that commit the organisation. Supplier selection, hiring, pricing, contractual commitments. Claude structures the analysis and drafts the summary; the accountable person decides.

A subtlety worth internalising: most real workflows are mixed. The right answer is rarely "good fit" or "poor fit" for the whole thing. It is "these steps yes, these steps no, connected by explicit handoffs." A payroll question is not "no", it is "the calculation belongs in payroll software, and drafting the variance explanation and employee communications is a genuine fit."

Decomposition and checkpoint placement

Decompose before you automate. A five stage process assessed stage by stage produces a design you can debug. One mega prompt that does all five stages produces an output you cannot diagnose when it is wrong, because you cannot tell which stage failed.

Understand the process before optimising it. If a workflow has grown redundant steps over ten years, making a redundant step faster preserves the redundancy permanently. Map first, prune second, automate third. The exam's favourite version of this trap is "add Claude to the slowest step," which optimises a bottleneck that may be a step nobody needs.

Checkpoint placement is the design decision. Human review belongs:

• Immediately before irreversible or outward facing steps. Before send, before publish, before a write to a system of record. A review that happens after a message reaches a customer detects damage rather than preventing it.
• At the point where high risk claims enter. Where product facts, figures, legal language, or commitments are asserted.

It does not belong after every paragraph, which destroys the time saving the workflow exists to deliver, and it does not belong in a weekly sample when the output has already gone to customers. Sampling is appropriate for reversible internal work.

Two checkpoint anti-patterns the exam likes:

• Sample review after auto send. Reads like quality assurance, is actually a post mortem.
• Human confirms a recommendation that has already been made. This looks like a human in the loop and behaves like a rubber stamp, because the framing has already done the deciding. Where a decision genuinely matters, the human should see the analysis, not a conclusion awaiting a signature.

Where reusable context should live

Once a workflow runs more than once, the question becomes where its knowledge and instructions live. Getting this wrong is what makes a workflow that works for its designer fail for everyone else.

Projects are available on all plans (free accounts are limited to five). Project knowledge that grows past the context window automatically switches to retrieval, which lets a project hold substantially more material. Project sharing with view or edit permissions is a Team and Enterprise capability, which matters when the exam scenario involves a team working from one configuration.

The diagnostic question for scenarios where people paste the same context repeatedly: is this a project configuration problem? It usually is. A workflow that only works when its author runs it is a workflow whose specification was never written down.

Proving it worked

The exam consistently rewards measurement and punishes impressions.

• Baseline first. Take the pre change measurement before the workflow starts. Without it there is nothing to compare against, and the outcome is necessarily "it feels faster."
• Use measures that existed before the change. Turnaround time, rework rate, first contact resolution, reopened tickets. Metrics invented alongside the new process tend to flatter it.
• Measure outcomes, not activity. Prompts sent per week, documents in project knowledge, and adoption counts are inputs. Heavy usage is equally consistent with a workflow that is struggling.
• Validate against known cases before going live. Run the workflow over historical examples whose correct handling is already known. That gives you an answer key, which live cases do not.

Two good default success criteria: turnaround time against baseline (did it deliver the speed) and proportion of drafts passing review without substantive correction (did it deliver the quality).

Rollout and stakeholder communication

Pilot narrow, then extend. One team, one workflow, refine what breaks, then extend with the refined version and a defined support path. Simultaneous rollout to four regions turns one design flaw into four escalations and damages confidence everywhere at once.

Choose the first workflow for learning, not for headlines. Frequent, checkable, low cost of error. Not the highest profile one, and not the one that saves the most senior time if it only runs quarterly.

Communicate value and limitations together. This is an explicit exam objective, and the wrong answer is always the enthusiastic one. Promising guaranteed accuracy to a sceptical audience creates a position that collapses at the first visible error. A good stakeholder explanation covers: which steps change, what they cost today, what stays human owned, what can go wrong, and how that is controlled.

Adoption failures are usually friction, not capability. If output quality is good and people went back to the old way, investigate what was harder, unclear, or untrustworthy in practice. Mandating use without removing the friction produces reluctant compliance and quiet workarounds.

Workflows need maintenance. Grounding documents drift out of date as the business changes. A defined refresh schedule with a named owner is part of the design, not an afterthought. Degradation six months in, with unchanged instructions and a changed business, is a knowledge staleness problem rather than a model problem.

How to think through the question

Domain 2 scenarios describe a process and ask you to judge a design. Work them in this order.

Step 1: Separate the steps. Mentally list the discrete stages in the described process. Most wrong answers treat the workflow as one indivisible thing that is either suitable or unsuitable. The correct answer often splits it.

Step 2: Test each step for fit. Is it language work? Is it checkable? Does it repeat? Flag any step that is deterministic computation, a live data lookup, a transactional write, or a committing decision. Those steps do not get automated regardless of how convenient it would be.

Step 3: Find the irreversible step and check where review sits. Trace forward to the point where something leaves the building or changes a system of record. If the human checkpoint is after that point, or if it is a sample rather than a gate, that is the flaw and you can usually stop there.

Step 4: Identify what the question is really asking. "What should they do first" wants the earliest correct step, which in process work is almost always understand or measure rather than build. "What is wrong with this design" wants the single structural flaw. "Which change most improves it" wants the one that addresses the bottleneck rather than a genuine improvement to a step that is not limiting anything.

Step 5: Eliminate the extremes. "Automate the whole thing" and "do not use Claude at all" are both usually wrong, because real answers are mixed. Also eliminate options that optimise a step the scenario did not identify as the constraint.

Step 6: Prefer the option that adds structure over the one that adds effort or enthusiasm. Shared project configuration beats "everyone pastes their own version." A baseline measurement beats "the team feels it is faster." A documented checkpoint owner beats "be more careful."

Worked example

A customer operations lead has designed a workflow where Claude drafts responses to refund requests, the drafts are sent automatically to customers, and a manager reviews a sample each week.

Step 1: Steps are: read the request, draft a response, send it, review a sample.

Step 2: Reading and drafting are language work and fit well. Sending a refund response is outward facing and commits the company.

Step 3: Send is the irreversible step. The review sits after it, and it is a sample. Both problems point the same way.

Step 4: The question asks what is wrong with the design, so it wants the structural flaw rather than a list of improvements.

Step 5: Eliminate "nothing is wrong, sampling is standard practice," which applies a technique suited to reversible internal work. Eliminate "the reviewer should be finance," which reassigns the reviewer without moving the checkpoint, so the same messages still go out unreviewed. Eliminate "specify the sample size," which tunes a parameter of a design that is broken at a more basic level.

Step 6: The surviving answer names checkpoint placement: review must come before send for outward facing, commitment bearing communications. That is the answer.

Exam traps

• "It is well defined, so it is easy to automate." Tempting because well specified tasks are easy to automate, just not with a language model. Deterministic calculation belongs in software that computes.
• Optimising the step that is not the bottleneck. Tempting because the proposed change is a genuine improvement. A faster first draft saves nothing when the time is spent in six revision rounds; the fix is moving requirements upstream.
• Automating a broken process. Tempting because it delivers a visible speed gain quickly. Making a redundant approval faster locks the redundancy in permanently.
• Human review after the irreversible step. Tempting because a human is genuinely involved and sampling sounds like real quality assurance. If it happens after send or publish, it detects rather than prevents.
• Human confirms a pre made recommendation. Tempting because it satisfies the letter of "human in the loop." It frames the decision and invites rubber stamping.
• Adoption mandates as a fix for low uptake. Tempting because it is decisive. Compulsion without removing the friction produces workarounds.
• Overpromising to build enthusiasm. Tempting because caveats slow adoption in the short term. Guaranteed accuracy is a claim the first visible error destroys, along with your credibility.
• Measuring activity instead of outcomes. Tempting because prompt counts and adoption rates are easy to collect. Usage is not evidence the work got better.
• Retiring the review step because it keeps catching things. Tempting because it reads as "the workflow has proven itself." Errors caught before they escape are evidence the control is load bearing, not evidence it is unnecessary.
• Starting with the hardest, most visible, or most senior-time-consuming workflow. Tempting because that is where the value looks biggest. First pilots should be frequent, checkable, and cheap to get wrong.

Quick reference

• Strong fit: language work, checkable output, repeats often.
• Poor fit: deterministic computation, live data lookups, transactional writes, committing decisions.
• Most workflows are mixed. Split the process and assess step by step.
• Understand and prune the process before automating it.
• Checkpoints go immediately before irreversible or outward facing steps, and where high risk claims enter.
• Context homes: profile instructions (account wide), project knowledge (grounding documents), project instructions (standing rules for that work), skills (a recurring task across projects), connectors (live systems of record).
• Baseline before starting; measure outcomes, not activity; validate on historical cases with known answers before going live.
• Pilot narrow, refine, then extend with a support path.
• Communicate value and limitations together. Name what stays human owned.
• Low adoption with good output is a friction problem, not a capability problem.
• Schedule knowledge refreshes with a named owner; grounding drifts as the business changes.