Workflow Integration and Solution Design: CCAO-F domain 4 study guide

CCAO-F · Workflow Integration and Solution Design (16% of the exam)

Workflow Integration and Solution Design is domain 4 of the Claude Certified Associate Foundations exam, 16% of the scored items. It tests whether you can look at how work is done today, decide where Claude helps, fit it in without losing the checks that matter, and explain honestly to stakeholders what it will and will not do.

What the official guide covers

The Claude Certified Associate Foundations exam guide (version 1.0, effective July 2026) lists five tasks under domain 4, Workflow Integration and Solution Design:

What the guide lists	What it means in practice
Apply Claude to analyse requirements and use cases	Use Claude to turn interview notes, tickets or requests into clear requirements and open questions
Use Claude for research, planning and process optimisation	Research options, draft plans, and find slow or repeated steps in a process
Use Claude to support solution design, development and iteration	Draft and refine process designs, templates and pilots, then improve them from results
Integrate Claude into existing workflows to augment or redesign them	Decide whether Claude speeds up a step or whether the process should change
Communicate Claude's value and limitations to stakeholders	Explain the gain, the risks and the review steps in plain terms

The guide also says Associates escalate enterprise-scale architecture and technical integration to Claude Architects and Developers. Knowing where your role stops is part of this domain.

Start by mapping the current workflow

Before adding Claude, write down each step, who does it, how long it takes and what can go wrong. Then mark each step:

Step type	Example	Where Claude fits
Reading and summarising	Going through 40 supplier emails	Strong fit: summarise, extract, group
Drafting	First version of a report or reply	Strong fit, with review
Researching	Comparing three software options	Good fit with Research and cited sources
Judging or approving	Signing off a budget, rating a person	A person keeps this step
Moving data between systems	Copying figures from a system into a sheet	Connectors may help; system integration is for Architects and Developers
Recording the official figure	The finance system of record	Stays in the system of record

Decide who owns each step

Once the steps are listed, give each one an owner: Claude does it, Claude and a person do it together, or a person keeps it. Anthropic's AI Fluency framework calls this delegation. Judge every step on three questions:

Can it be undone? A draft can be revised; a sent offer letter cannot.
What does an error cost? The higher the cost, the more a person controls the step.
Who answers for the outcome? Claude can draft the work, but the accountability stays with a person.

A worked map for a purchase-order process:

Step	Owner	Why
Extract items, quantities and prices from supplier quotes	Claude	Mechanical, reversible, checked in the next step
Total the order and compare with the budget line	Claude, with code execution	A number that must be calculated, not estimated
Check each item against the purchasing policy	Claude, using a Skill that holds the policy steps	Reversible; the same procedure every time
Draft the approval note explaining any exceptions	Together	Claude drafts, the buyer edits and decides what to flag
Approve the order	Person	High cost of error; the budget holder answers for it
Send the order to the supplier	Person	Cannot be undone; commits the company

Attach the right feature to each Claude step: a Skill for a repeated procedure, code execution for numbers. Each person-owned step becomes a named review gate. Three mapping mistakes to avoid:

Halo delegation. Handing a step to Claude because the step before it went well. Judge each step on its own.
A "together" step with no reviewer. If nobody is actually assigned to review, the step is automated in practice.
Mapping the features instead of the work. Map the real steps first, then choose features. Do not build the process around a Skill you like.

Giving Claude an approval or a send step because its drafts are good is over-delegation. Good drafting is not a reason to hand over the decision.

Augment or redesign?

Anthropic's AI Fluency framework names three ways of working with AI: automation (Claude carries out a defined task), augmentation (you and Claude work on it together) and agency (you set Claude up to work on your behalf). Good delegation rests on three things: knowing the problem, knowing what the platform can do, and splitting the work deliberately.

Situation	Choose	Why
The process works, but one step is slow (drafting, summarising)	Augment that step	Lowest risk; existing checks stay in place
Steps exist only to move information between people	Redesign the flow around a shared Project or artifact	The handoffs themselves are the waste
The same procedure is repeated by many people	Put the instructions in a Project or a Skill	Everyone runs the same steps the same way
The task needs a custom app, API connection or automation at scale	Escalate to a Claude Architect or Developer	Outside the Associate's scope
The step carries legal, financial or people decisions	Keep a person as the decision maker	Accountability stays with people

Where Claude plugs in

Projects hold the instructions and reference files for a repeated process, so every chat starts from the same context. On Team and Enterprise plans they can be shared with view or edit permission.
Connectors such as Google Drive, Gmail and Google Calendar let Claude search and work with those tools, and Claude can only see what you already have access to. Sending, replying to or forwarding email asks for your approval by default.
Research handles the research step: several rounds of searching, with citations to check.
Artifacts give the workflow a shareable output, such as a one-page plan, a checklist or a small tool.
Claude Cowork, in the Claude desktop app, runs longer multi-step tasks on files in folders you connect, such as turning a folder of notes into a formatted report. You choose an approval mode, and the help centre advises reviewing Claude's planned actions before it proceeds, especially with sensitive files.

Worked prompt: turning notes into requirements

Below are notes from four interviews with our customer service team
about how refund requests are handled today, inside <notes>.

1. List the current steps in order, with who does each one.
2. List the problems people mentioned, and how many interviews raised each.
3. Write requirements for an improved process as "The process must..."
   statements. Link each one to the problem it solves.
4. List anything the notes leave unclear as questions for me to ask.
Do not invent steps or problems that are not in the notes.

<notes>
[paste interview notes]
</notes>

Check the output against the notes, then use the questions in step 4 to go back to the team. Claude speeds up the analysis; the people who do the work confirm it.

Then pressure-test the list in a second prompt: ask which requirements are ambiguous, which two people could read differently, and which the notes only imply. "The report should be easy to read" is the kind of line to flag, because two writers would produce different things from it; "each section under 150 words, figure first" is testable.

For planning, split the work by what Claude is good at. Numbers that a plan rests on (volume growth, throughput per person) should come from code execution on the real data. Claude then turns those checked figures into options and trade-offs. The final call, which weighs budget, timing and politics Claude cannot see, stays with the person who owns the plan.

Pilot, measure, iterate

Choose one step and a small sample, such as one month's report or 20 customer replies.
Record the baseline: time taken and errors found in review.
Run the new way with the existing review kept in place.
Compare time and errors, adjust the prompt or Project, and run again before widening use.

Running the iterations inside one Project keeps the constraints and earlier decisions in place, so each round builds on the last. Watch for the escalation signal: a small tracker built as an artifact for one team is fine, but once other departments depend on it daily, with needs for uptime, security or links to other systems, it is infrastructure and belongs with a Developer or Architect.

Explaining value and limits to stakeholders

Stakeholders need the gain, the limits and the controls in one view. Before and after:

Before: "Claude will automate our reporting and save loads of time."

After:

Proposal: use Claude to draft the monthly supplier report commentary.
What changes: Claude drafts the commentary from the exported figures.
  The analyst checks every figure and edits; the manager still signs off.
Expected gain: drafting time measured in a one-month pilot against
  the current baseline.
Limits: Claude can state figures or trends wrongly, so every number is
  checked against the export. It does not replace the finance system.
Data: only the approved export is used, in our company workspace.
Decision needed: approve a one-month pilot.

Match the detail to the reader. A technical stakeholder wants the steps and the known failure modes; an executive asks for the outcome, the control in place and the risk. Every version names the human gate. Phrases that quietly overstate: "fully automated", "Claude handles the reports", "as good as a person". Replace each with what Claude does and who checks it.

Rules that decide exam answers

Map before you change. The right first step is to understand the current process and pick one step, not to automate everything at once.
Augment first when the process works. Redesign is for flows where the handoffs are the problem, not a default.
Keep the existing checks during a pilot. Removing review to show a bigger time saving is the tempting wrong answer.
People keep judgement and approval. Claude drafts, summarises and researches; a person decides. Steps that cannot be undone or that someone must answer for stay with a person, however good the drafts are.
Escalate technical builds. API integrations, custom apps and large-scale automation go to Architects or Developers.
Be honest about limits. The best stakeholder message states the gain, the error risk and the review that controls it.

Where it appears in the exam

Domain 4 carries 16% of the exam, around 9 or 10 of the 60 items. Questions describe a team process, such as reporting, onboarding, research or customer replies, and ask where Claude should fit, whether to augment or redesign, what to pilot first, when to escalate, or how to describe the change to a manager.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

An operations lead produces a monthly supplier performance report: figures are exported from the company's ERP, cleaned in a spreadsheet, given written commentary and approved by a manager. She wants to use Claude. What should she do first?

A. Ask Claude to run the whole process end to end and drop the manager's approval step.B. Map the current steps, pilot Claude on the commentary step for a month, and keep the approval.C. Ask IT to build a direct connection between Claude and the ERP before any testing starts.D. Replace the manager's approval with a review that Claude carries out on its own commentary.

Answer: B. Mapping the process and piloting one drafting step keeps risk low and the existing approval in place. A and D remove the human check, and C starts with a technical build that belongs with Architects or Developers before anyone knows the step is worth it.

Question 2

A marketing director asks whether Claude can write all the company's regulated product claims so that the legal team no longer needs to review them. What is the best response?

A. Agree, as long as the team always uses the most capable model for regulated claims.B. Refuse to use Claude for any marketing content at all, since product claims are regulated.C. Agree, provided Claude is told in every prompt to follow each advertising rule that applies.D. Say Claude can draft claims faster from approved material, but legal review stays; offer a pilot.

Answer: D. It states the real gain, the error risk and the control that manages it, and suggests a way to measure the benefit. A and C assume a model or prompt removes the need for review, and B gives up a useful drafting step that legal review already controls.

Build exercise

Map one process you know well in a table: step, owner, time, what can go wrong. Give each step an owner (Claude, together, person) or mark it escalate.
Use the requirements prompt above on real notes or meeting minutes. Check every requirement against the source.
Run a small pilot on one step with the current review kept. Record time and errors before and after.
Write a stakeholder note in the format above for your pilot, including the limits and the decision you need.

Practise this topic

Claude Certified Associate practice exam: free, 20 questions, no sign-up
CCAO-F study guide: all topics
Previous topic: Product and Model Selection
Next topic: Configuration and Knowledge Management

Sources

Claude Certified Associate Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), domain 4: Workflow Integration and Solution Design
Claude Help Center: Use connectors to extend Claude's capabilities
Claude Help Center: Use Google Workspace connectors
Claude Help Center: Get started with Claude Cowork
Claude Help Center: What are projects?