Single path · 9 lessons
From AI work to automating your company’s processes: you’ll leave knowing how to use Copilot day to day, redesign a real process, create an agent, build an approval flow, and measure results with indicators—without writing a line of code.
The path
AI user
Augmented professional
Workflow Designer
Agent builder
Process automation tool
Lessons
Leave knowing which of the five levels you’re at today and which three of your tasks should move up first.
Leave with one of your meetings turned into decisions, owners, and deadlines—and with a prompt that finds what you’re looking for without opening ten folders.
Leave knowing how to ask a spreadsheet “what changed and why” and get an explanation you can verify.
Leave with a real process from your area mapped on a canvas—inputs, decisions, who approves, what to automate, and how to measure it.
Leave with a draft agent that answers questions using your area’s documents, tested by you with three real questions.
Leave with one of your approval workflows working in a test: a request comes in, someone approves it in Teams, and the result is recorded.
Leave knowing how to choose, for each system in your company, between a service endpoint, a workflow, screen automation, and Computer Use—and how to justify your choice.
Leave with three indicators for your area defined by target and variance, and the prompt that gets Copilot to explain why one of them got worse.
Leave with the completed canvas for your first agent project, access rules checked, and a three-phase plan to put it into action.
Copilot + Agents · Lesson 1
By the end of this lesson, you’ll be able to say which of the five steps you’re at today and identify three tasks in your work that should move up a step first—with the objective, information source, and approver written down for each.
You already ask Copilot to summarize an email or improve a piece of writing. But you still handle the heavy lifting: opening the system, copying from one spreadsheet to another, following up with people who haven’t responded, updating the metric. What your company expects isn’t “using AI better.” It’s handing repetitive work over to agents that take part in the process. If you understand that difference now, you can choose what to automate; if you don’t, you’ll keep using an expensive tool as a text editor.
↓ role to study
Until recently, AI at work did one thing: helped people do their jobs. You asked for a summary, got the summary, and the rest was up to you. That phase isn’t over, but it’s no longer the main focus. The important next step is for AI to take part in the process: receive a request, consult the right documents, make a decision within set rules, and carry out the task to completion.
The name for this second way of working is agent. Think of a very fast new employee who knows the department’s documents and can use its systems—but only does what was agreed on and shows what they did.
For the occupational safety specialist, the difference shows up in the first incident of the week. Today she asks Copilot for text to use in the report, then opens the spreadsheet, the system form, and the email to the department manager. With an agent, she says, "damaged guard on machine 14, cutting department," and it records the incident, notifies the person in charge, and creates a task with a due date. The text is still good; what changes is that the work gets finished.
The entire training follows a five-step ladder. On the first step, the AI user asks for texts, summaries, and answers. In the second, the augmented professional uses AI within real workflows: a meeting becomes a report, a report becomes a plan, a plan becomes tasks. In the third, workflow designer design the process before automating: who starts it, what comes in, who decides, what goes out.
At the fourth step, the agent builder create a specialized assistant that consults knowledge and runs automations. In the fifth, the process automation tool connects everything: agent, workflow, systems, and metrics, with human approval where it matters. No one skips a step. Each lesson in this course moves you up one.
The purchasing analyst who today asks Copilot to “improve this email to the supplier” is at the first step. When they start asking, “summarize the conversation with the supplier, list what’s still pending, and draft a follow-up,” they’ve moved to the second. When they map the entire supplier onboarding process, from request to approval, they’re at the third. The course aims to take them to the fifth: an agent that receives an onboarding request and guides the process.
Test yourself
The HR manager asks Copilot: "summarize this onboarding meeting, list each team’s tasks, and put together the new employee’s first-week schedule". Which step is she on?
Older AI training revolved around prompt: write a good prompt and get a better answer. That still applies, but it’s only the first link. Real work follows a chain: objective, context, data, analysis, decision, tool, execution, validation. When that chain repeats every week, it becomes automation. When the automation needs to look things up, make decisions, and have conversations, it becomes an agent.
An analogy helps make this stick. A prompt is a note on a colleague’s desk. A chain is the department’s written procedure: what comes in, where the information is, who decides, what comes out, and who checks it. You don’t automate a note; you automate a procedure.
The HR manager who wants to improve new employee onboarding doesn’t start with a prompt. She starts with the chain: objective (a productive new employee in two weeks), context (onboarding policy in SharePoint), data (this month’s onboarding list), decision (which training is required for each role), execution (invitations, access, tasks), validation (the manager confirms). Each link in this chain is something the course teaches you to hand off to a tool.
You won’t learn to write better prompts. You’ll learn to describe procedures so clearly that a machine can carry them out.
In the old model, a person talks directly to the system. To do that, they need to know the menus, screens, fields, and the right order to fill them in. Each new system means new training, and each screen change is a chance for error. In the new model, a person talks to an agent, and the agent talks to the systems. The person provides four things: the goal, the context, the constraints, and the success criteria. The agent coordinates data, systems, automations, and tools.
It’s the same as using a customs broker instead of going to five service counters. You hand over the documents and say what you need; they know the counters. The difference is that this broker shows you every step they took and asks for your signature at the agreed points.
The finance coordinator sees this in payment approvals. Today he opens the purchasing system, checks the purchase order, opens the contract in the network folder, compares the amounts, and records the approval on another screen. In the new model, he tells the agent: "Approve payments up to 5 thousand reais that match the contract; for anything above that, show me the comparison and wait for my decision." He still makes the decisions that matter, without visiting five screens for every payment.
Moving up the ladder doesn’t mean handing everything over. Three things stay with you at every level. Decide what the agent can do on its own and what needs human approval. Validate the result before it becomes official. And approve anything involving risk: payments, hiring, release of an area or equipment, disciplinary action, or legal interpretation. An agent that approves a machine release on its own isn’t progress; it’s a problem waiting for a date.
There’s also a rule the entire company needs to hear early: AI can’t fix a disorganized organization. If someone currently has access to a document they shouldn’t, an agent using the same permissions will find it too. Lesson 9 covers this in detail. For now, remember: automating a messy process creates mess faster.
In workplace safety, this is literal. The technician can have the agent record the incident, notify the person responsible, open the task, and track the deadline. Releasing machine 14 to resume operation remains her decision, with her signature. The agent prepares everything so that decision takes two minutes instead of an afternoon.
Before
The safety technician receives the incident in Teams, enters it in the spreadsheet, fills out the system form, writes an email to the department lead, and notes the deadline in her calendar. About two hours per incident, with the risk of forgetting to follow up.
After
She describes the incident to the agent. It asks what’s missing, records it, alerts the person in charge, creates the task with a deadline, and follows up on its own. She checks the record and decides whether to release the machine.
Practice now 0/3 done
Goal: leave with your current step identified and three tasks from your work written in the format "goal + where the information is + who validates it". ~10 min, on paper or in a Word document.
In this exercise, you only write. Nothing is sent, automated, or changed in any system. If a task seems too big, choose a smaller one — the right size is one that fits in a sentence.
You just named your first step and separated the three tasks that will move up first—in the format the next lessons will use to automate them.
Summary
Copilot + Agents · Lesson 2
By the end of this lesson, you’ll be able to turn one of your meetings into a list of decisions, owners, and deadlines using Copilot—and write a prompt that finds documents, emails, and meetings on a topic without opening ten folders.
Half your day disappears while you search for the email where the supplier confirmed the deadline, the right version of the procedure, or what was decided at Tuesday’s meeting. Your company’s Copilot can see all of it at once, but it only delivers good results when you make a good request. This lesson is the second step: AI inside your real workflow, not just in chat.
↓ role to study
O Microsoft 365 Copilot appears inside the tools you already use: in Teams, Outlook, Word, Excel, PowerPoint, and in its own chat window. There’s just one difference from a regular chat, and it’s decisive: it can access your company’s data. Emails, files in shared folders, meeting recordings, Teams conversations.
One rule prevents a lot of confusion: it sees exactly what your account can see. If you don’t have access to the executive team’s folder, it doesn’t either. If a document is on your computer and not in the company cloud, it can’t find it. That’s a safeguard, not a limitation.
The purchasing analyst opens the Copilot conversation in Teams and asks, “which packaging suppliers sent me proposals in the last 60 days?” The answer comes from their emails, with names and dates. A colleague in another department asking the same question would get only what’s in their emails. One honest heads-up: what each button does and where it appears changes often and depends on the license the company purchased. If something in this lesson doesn’t look the same on your screen, search for the feature name; the logic is the same.
The old question is "where is the machine lockout procedure?". Copilot answers that, but it wastes what Copilot does best: cross-referencing sources. The new question is "gather everything we have about machine 14 from the last six months—documents, emails, meetings—and show me the key decisions made and who’s responsible for each one". A question like that replaces a morning of searching.
A good search request has three parts: the topic by its proper name (not "the machine," but "machine 14 in the cutting department"), the time period, and what you want to see at the end (decisions, owners, open items, documents). Without all three, it returns a generic list, and it seems like the tool’s fault.
The occupational safety technician uses this before an inspection. Instead of opening the incident folder, the training folder, and her email history, she asks: “list the incidents, training, and corrective actions for the cutting department since March, with the status of each action.” She arrives at the inspection knowing what’s still open.
Common mistake
Ask “what do we have on security?” and get a generic answer. This happens because Copilot doesn’t know whether you want the policy, the incidents, or the training records, or what time period you mean. Name the subject, the period, and what you want to see at the end; the quality of the response changes immediately.
An email thread with twenty messages and five people hides three things you need: what’s already been decided, what’s still pending, and who hasn’t replied yet. Copilot in Outlook pulls out all three at once. A request that works is direct: "summarize this thread, separate what’s already been decided from what’s pending, and draft a reply to everyone involved asking them to address the open items by the deadline".
After the summary comes the tone adjustment, and it’s really good here. The same message can be cordial for the supplier, concise for leadership, and detailed for the team. You write the content once and ask for the different versions.
The purchasing analyst has an email conversation with a parts supplier that’s been going on for three weeks: proposal, counterproposal, a question about shipping, then silence. They ask for a summary with pending items and discover the supplier never confirmed the delivery date, only the price. The ready-to-send reply asks for exactly that, with a date. They review it, adjust a sentence, and send it. They do the review; Copilot doesn’t send anything on its own.
Most meetings produce minutes that no one reads. What the company needs is what comes next: decisions, owners, tasks, deadlines, and follow-up. That sequence is a method, and it works even without Copilot. Before the meeting, you gather the context and previous open items. During and after, you turn the conversation into commitments with a name and date.
With the meeting recorded in Teams, Copilot does the heavy lifting: summarizes, identifies decisions, lists tasks, and suggests owners and deadlines based on what was said. What it doesn’t do is make decisions for you or follow up for you. A person continues to track progress, or, later in the course, an automated flow does it.
The HR manager leaves the monthly onboarding meeting with a summary ready: four decisions, seven tasks, three teams responsible, and deadlines for each new employee’s first week. Before, she spent the next afternoon putting this together from memory. Now she spends ten minutes checking it and adjusting a deadline Copilot got wrong.
Post-meeting checklist
In Word, Copilot creates a first draft of a report, proposal, or procedure based on what you point it to: "use Tuesday’s meeting notes, the metrics spreadsheet, and the old procedure, and write a new version of the procedure in plain language". It also works in reverse, which is more useful than it sounds: turning technical text into an executive page, or creating a short and a detailed version of the same document.
In PowerPoint, the flow is documents, data, and meetings, which become a synthesis, which becomes a story, which becomes slides. A good request names the audience and the time limit: "eight-minute presentation for the leadership team, focused on what changed and what needs a decision". It suggests the slide sequence and key messages; you refine the story.
The finance coordinator needs to take the month-end close to the leadership team. He points to the accounting report, the budget spreadsheet, and the minutes from the results meeting, and asks for a six-slide presentation for managers outside finance. The first draft gets the story right and includes two numbers he checks against the spreadsheet before presenting.
Practice now 0/3 done
Goal: leave with the decisions, owners, tasks, and deadlines from one of your real meetings, ready to send. ~10 min, in Teams Copilot or your company’s Copilot chat window.
Copilot only reads what you can already see, and it doesn’t send anything to anyone. The result stays in the conversation until you copy it. If the meeting wasn’t recorded, paste your notes instead—it works the same way. Don’t like the result? Ask again with more details.
Use a reunião <nome da reunião e data> (ou as anotações abaixo). Faça, nesta ordem: 1. Resumo em até 10 linhas. 2. Decisões tomadas, uma por linha, sem "talvez". 3. Para cada decisão: responsável (um nome), tarefa e prazo. 4. Pendências que ficaram sem responsável. 5. Uma mensagem de acompanhamento para enviar aos participantes, em tom cordial, cobrando as tarefas com prazo. Anotações (se não houver gravação): <cole aqui>
You just turned a meeting into commitments with names and dates—the second step, in your actual work.
Summary
Copilot + Agents · Lesson 3
By the end of this lesson, you’ll be able to ask one of your spreadsheets “what changed this month and why?” and get an explanation of the factors—checking at least one number before sharing it with someone.
You don’t need to become a data analyst. You need to stop bringing a chart to the meeting that nobody can explain. The manager asks, “why did it drop?” and the answer is “I’ll check.” Copilot in Excel, Analyst, and Researcher are there to answer that question: turn numbers into insights, with you checking what matters before the information is shared.
↓ role to study
With a spreadsheet open, Copilot does what you’d ask an experienced colleague to do: create a formula you describe in Portuguese, explain what an existing formula does, flag cells with errors, compare periods, build a pivot table, and generate a chart. You talk to the spreadsheet instead of memorizing functions.
A ramp before the screen starts to look complicated: Copilot only understands a spreadsheet well when it looks like a well-organized list, with one header row and one column per piece of information. If your file has merged headings, subtotals in the middle, and colors instead of columns, it gets lost just like a new colleague would. Cleaning up the spreadsheet is half the work, and it applies to all the tools in this lesson.
The finance coordinator opens the expenses-by-cost-center spreadsheet and asks, “add a column with the percentage change for each cost center compared with the previous month, and highlight those above 10%.” Within seconds, the column is there, the formula is visible for review, and the cells are highlighted. Before, this took half an hour and a copied formula that was wrong.
A chart is an answer. Without a question, it decorates a slide and doesn’t change any decisions. A question that leads to a decision always has the same form: what changed, compared with what, and which factors contributed the most. Everyday example: "what changed this month compared with the previous three months, and which factors best explain the change?" This question makes the tool compare and rank the factors and explain them—and makes you read the explanation.
The workplace safety specialist maintains the incident spreadsheet: date, area, type, severity, corrective action, deadline. Instead of asking for a "chart of incidents by month," she asks "did the number of near misses go up compared with the previous quarter? In which area and incident type is the difference?". The answer points to the cutting area and machine guards. That becomes an agenda item for the next meeting; the chart alone wouldn’t have.
Common mistake
Asking "make a chart of these sales" and getting something pretty that doesn't answer anything. This happens because the prompt doesn’t include a question, so the tool picks any visualization. Start with the question (“what changed and why?”), then ask for a chart that illustrates the answer.
O Analyst is Copilot in the role of a data analyst. The difference from regular Excel is its reach: it cross-references different files, compares multiple spreadsheets, looks for relationships between columns no one has brought together, and explains anomalies. It also shows its reasoning, which is the most useful part for whoever will check its work.
A good request provides the files and a hypothesis to test. "Here are the delivery spreadsheet and the nonconformity spreadsheet for the semester. Are the suppliers with the most delays also the ones with the most nonconformities? Show the five worst in each list and tell me whether they overlap." A testable hypothesis gets you an actionable answer; "analyze this data" gets you a vague response.
The purchasing analyst does exactly this cross-reference before the semiannual supplier review. They discover that three of the five suppliers with the most delays also lead in nonconformities, and that a fourth is often late but delivers quality. Those are two different problems, requiring two different conversations. Without the cross-reference, they’d treat all four the same way.
O Researcher works for the question that would take a week: combining everything the company already has about a topic with what exists outside it. A typical request: "analyze everything we have internally about this vendor, combine it with relevant external information, and produce a risk report." It reads the contracts, emails, and minutes, searches for news and public records, and returns a report with sources.
The use cases are the usual ones in management, just faster: competitor comparisons, supplier evaluations, market overviews, regulatory changes, technology trends. The same guidance applies as in the previous step: the more precise the request, the more useful the report.
The HR manager needs to propose a hybrid work policy. She asks for a report combining the internal employee engagement survey, meeting minutes from leadership discussions about the topic, and practices at companies in the same industry in the country. She gets a document with all three parts and sources for each external claim. What she takes to the leadership team is the decision; the research was ready in an afternoon.
How to request research that comes back useful
This is the rule that separates people who use it well from those who get burned. The tool presents a wrong number with the same confidence as a right one. There’s no hesitation in its voice, because it has no voice. That’s why checking isn’t distrust; it’s part of the method. You don’t check everything; you check what will be shared and what could change a decision.
Three quick ways to verify. Ask for the steps: “show the formula” or “which rows did this total come from?” Test a sample: pick a value you know by heart and see if it matches. And check the source: for external claims, open the source cited in the report. Two minutes of verification are worth more than an hour of rework after the number reaches leadership.
The finance coordinator was told by Analyst that freight expenses grew 23% during the quarter. Before putting it in the report, he asked, "Which line items did this calculation come from?" and found that a return had been counted as an expense. The correct figure was 17%. The report went out correctly, and his trust in the tool increased, not decreased: it showed its work when he asked.
Test yourself
Researcher delivered a supplier risk report with the statement “company named in a labor lawsuit in 2025.” What do you do before forwarding it to your manager?
Practice now 0/3 done
Goal: leave with an explanation of a variance in one of your real spreadsheets, with the factors ranked and one number checked by you. ~10 min, in Excel with Copilot or your company’s Copilot chat, with the file attached.
Work on a copy of the spreadsheet—save it as "name-copy" before you start. Copilot won’t change anything unless you accept, and on the copy, even that doesn’t matter. If the answer is vague, the spreadsheet probably isn’t formatted as a clean list; adjust the header and ask again.
Nesta planilha, a coluna <nome da coluna com o valor> mede <o que ela mede>. 1. Compare <último mês> com os três meses anteriores: o valor subiu ou caiu, e quanto (em % e em valor)? 2. Liste os fatores que mais contribuíram para a mudança, do maior para o menor, usando as colunas <setor / categoria / fornecedor>. 3. Para o maior fator, mostre de quais linhas veio o cálculo. 4. Diga em uma frase o que um gestor deveria fazer com essa informação.
You just turned a spreadsheet into a verified explanation—the question “why did it drop?” now has an answer before the meeting.
Summary
Copilot + Agents · Lesson 4
By the end of this lesson, you’ll be able to map a real process from your department on a one-page canvas: who starts it, what comes in, what decisions are involved, what comes out, where human approval is required, and how to measure whether it worked.
No one automates what they can’t describe. The reason so many "agent" projects die in the first month isn’t the technology: it’s that no one wrote down the process first. This lesson is the third step: the workflow designer. It’s the most important lesson in the course because the next five only work if you complete this one.
↓ role to study
Before any tool, one simple definition. Process is a recurring sequence: someone or something starts it, information comes in, systems take part, decisions are made, and a result comes out. Approving a purchase, recording an incident, hiring an employee, registering a supplier. All of these are processes, whether they’re written down or only in the mind of the person who handles them.
The analogy is a family recipe. The recipe exists even when no one has written it down; the problem is that only Grandma knows how to make it. Writing the recipe lets someone else, or a machine, repeat the result. A written process is a team’s recipe: this goes in, that happens, this comes out, and someone checks it before serving.
The purchasing analyst has been onboarding suppliers for years and would say, “there’s no process; every case is different.” When they write it down, they discover it’s always the same: a request arrives by email, they ask for the documents, check the legal business name and address, verify the required fields, request the manager’s approval, add the supplier to the system, and notify whoever made the request. Seven steps, three decisions, two systems. Without this design, there’s nothing to automate.
One workflow is the area’s recipe, written to be carried out by tools. The difference from a prompt is in its nature, not its size. A prompt is a single request: goal, context, response. A workflow is the whole chain: goal, context, sources, analysis, tools, execution, validation. The prompt lives inside the workflow as one of its steps. Never the other way around.
This changes what you write. Instead of “summarize this incident,” you write: “when an incident arrives (start), the agent asks for the missing information (input), records it in the list (execution), notifies the person responsible for the department (execution), and the specialist checks it and decides its priority (validation).” Each phrase in parentheses is a place where a different tool can come in.
The occupational safety technician rewrote the incident reporting process this way. What used to be “ask Copilot for some text and then do the rest” became a sequence of six steps with two decision points for her. Only after mapping it out did it become clear that the longest step—informing the manager and creating the task—didn’t require any decisions. It was the obvious candidate for the first automation.
Before
“Summarize this incident and write the email to the manager.” A good response, and the rest of the work stays manual: log it, send it, open a task, set a due date, follow up.
After
“When an incident comes in: ask for what’s missing, log it, notify the person in charge, open a task with a due date, follow up in 5 days. I decide the priority and whether to release it.” Six steps, two of them human.
Not everything should be automated, and that decision belongs in the design, not in the tool. The rule has a name: human approval, or “person in the loop.” It’s required whenever a step involves financial, legal, or physical safety risks; deleting information; hiring and payment; disciplinary action; releasing equipment or an area; or approving a critical supplier. At these points, the agent prepares everything and stops. The person signs off.
The most costly mistake is the opposite of what you might think: it's not automating too much, it's requiring human approval for everything out of fear. A flow where the manager approves every collection email isn't safe; it's slow, and within two weeks they'll be approving without reading. Approval makes sense when it's rare and important. Choose the checkpoints using the risk list, not anxiety.
The HR manager designs an employee’s onboarding. The agent can put together the schedule, request documents, create standard access, and send training invitations. She handles confirmation of the hire, the recorded salary, and access to confidential folders. Three human checkpoints in twelve steps; the rest runs on its own.
Test yourself
In the supplier flow, which of these steps must have human approval?
The process design fits on one page, and that page has a name: the agent automation canvas. Before you see it, here's a ramp-up: it looks like a nine-field form, and that's exactly what it is. Each field is a question you answer once about your process. Once filled out, it becomes the blueprint for everything lessons 5 to 9 will build.
The nine questions. Process: what it is, by name. Objective: what result it needs to produce. Inputs: data, documents, emails, forms, or events that start or feed the process. Knowledge: where the information the agent needs to consult is stored. Decisions: which ones need to be made, and which are made by people. Actions: consult, generate, send, record, fill out, update, notify. Integration: how the agent reaches each system. Validation: who checks it. Metrics: how to measure whether it worked.
The finance coordinator fills out the payment reconciliation canvas. Inputs: bank statement and accounts payable system report. Knowledge: the approval authority policy in the finance folder. Decisions: whether a transaction matches; discrepancies over 500 reais go to him. Actions: compare, log discrepancies, notify. Validation: he reviews the discrepancies. Metric: hours spent on reconciliation per month. Twenty minutes to fill it out, and the project already has a shape.
The canvas isn’t bureaucracy before automation. It’s automation, still on paper.
The completed canvas reveals something the prompt hid: each step calls for a different type of tool. Looking up knowledge and talking with the requester is agent work. Executing a fixed sequence, with conditions and approvals, is automated flow work. Accessing an old system without a service endpoint is screen automation work. Measuring is metrics work. The next lessons introduce one tool at a time; the canvas shows where each one fits.
This is the map for the second half of the course. Lesson 5: the agent, which receives the request and consults knowledge. Lesson 6: the flow, which carries out tasks and requests approval. Lesson 7: screen automation, for systems without an access point. Lesson 8: indicators. Lesson 9: governance and your complete project.
For the purchasing analyst’s supplier registration case, the canvas divides the work like this: the agent receives the request and follows up on the documents; the flow checks required fields and requests the manager’s approval; screen automation enters the information in the company’s old system, which has no service endpoint; the metric measures the time from request to completed registration. Four tools, one process, one design. For the safety technician, the same canvas maps the incident flow, with the release decision marked as human.
Practice now 0/4 done
Goal: leave with the nine-field canvas filled in for one of the three tasks you chose in lesson 1, with the human approval points marked. ~12 min, in a Word document or on a sheet of paper.
This is just writing. No system is touched, no automation is created, and nothing changes in the real process. If a field is blank, write "I don’t know yet"—that’s a valid answer, and the next lessons will fill it in.
CANVAS — <nome do processo> Objetivo: que resultado precisa produzir? Entradas: o que inicia e alimenta (e-mail, formulário, documento, evento)? Conhecimento: onde está a informação a consultar (pasta, lista, sistema)? Decisões: quais existem? Quais são HUMANAS (marcar com *)? Ações: consultar / gerar / enviar / registrar / preencher / atualizar / notificar Integração: como chegar a cada sistema? (não sei ainda = ok) Validação: quem confere o resultado? Indicadores: como medir que funcionou?
You’ve just mapped a process in a format that tools can understand—the third step. The next lessons build directly on this page.
Summary
Copilot + Agents · Lesson 5
By the end of this lesson, you’ll be able to create a draft agent in Copilot Studio that answers questions using documents from your department—with instructions you wrote and three real questions tested before anyone sees it.
The same five questions come up every week in your department: “what’s the procedure for this?”, “what’s the deadline for that?”, “who approves it?” You answer, point them to the document, or ask them to look it up. An agent that knows your department’s documents answers for you, with sources, anytime. It’s the fourth step, and you can build it in an afternoon: Copilot Studio was made for people who don’t code.
↓ role to study
O Copilot Studio is where the company’s agents are built. It works through forms, not code. Every agent has four parts. Instructions: what it does, what it doesn’t do, and what tone to use. Knowledge: the documents, folders, and lists it can consult. Tools: the actions it can perform, such as sending a message or calling an automation. And the channel: where people talk to it, almost always Teams.
The analogy that carries through the whole lesson is a new employee. The instructions are the job description. The knowledge is the folder of documents they receive on their first day. The tools are the keys and access the company provides. The channel is the desk where they sit. Without a job description, the employee invents the work; without documents, they invent the answers. The agent does too.
The workplace safety specialist builds the "safety procedures agent". Instructions: answer questions about internal standards, PPE, and lockout procedures, always citing the document. Knowledge: the team’s procedures folder in SharePoint. Tools: none for now, it only answers questions. Channel: the production team’s Teams channel. Four screens, not a single line of code.
An agent’s quality depends almost entirely on its instructions, and instructions are plain text in Portuguese. A good job description has four parts. The role: "you are the safety team’s procedures assistant". The scope: "answer only questions about internal standards, PPE, and machine lockout". The rules: "always cite the document and section; if you can’t find it, say so and refer them to the safety specialist". And the tone: "direct, no jargon, short sentences".
The most overlooked part is what it doesn’t do and when it calls a person. Without it, the agent answers everything, including what it doesn’t know, with the same confidence as always. An agent that says "I couldn’t find that in the procedures; contact the safety specialist" is more valuable than one that invents a deadline for replacing PPE.
The HR manager writes the instructions for the benefits questions agent. Role, scope, and tone come together quickly. In the rules, she adds the line that will prevent problems: "never share salary amounts or another person’s information; for those questions, refer them to HR". One sentence turns the agent from a risk into first-level support.
Common mistake
Write “be helpful and answer employees’ questions” and assume it’s ready. This happens because vague instructions seem harmless. The result is an agent that answers everything, makes up what it doesn’t know, and talks about topics it shouldn’t. Write down its scope, what it doesn’t do, and who it should refer people to—that’s what separates a useful agent from a problem.
Knowledge is the list of places the agent can read. The most common are folders and pages in SharePoint, files uploaded directly, public websites, and tables from Dataverse. When someone asks a question, the agent searches these places, puts together an answer, and shows where it came from. You can limit it to answering only based on this knowledge, which is exactly what you want from a procedures agent.
Two practical rules. Point it to a small, relevant set of sources: a folder of up-to-date procedures is better than an entire area with old versions mixed in, because the agent doesn’t know which one is current. And remember that permissions still apply: if a folder is restricted, only people with access to it get answers based on it. That protects the company and, once again, shows that organizing folders comes before creating the agent.
The purchasing analyst points the agent to the supplier onboarding policy and the list of required documents by supplier type as its knowledge. When a colleague asks, “what do I need to request to onboard a service provider?”, the agent gives the right list and cites the policy. Before, that question came to the analyst on Teams four times a week.
An agent with only instructions and knowledge can answer. To make it act, you connect tools: ready-made actions that link to other services, such as sending a message in Teams, creating an item in a list, or calling a Power Automate flow that runs an entire sequence. This is where the "Actions" field on your canvas becomes real. Lesson 6 teaches you how to build these flows.
A ramp before the tools screen, which looks like an app store: each item is a key handed to the new employee. Hand out only the keys the job requires. A procedures agent doesn’t need the "send email to anyone" key; an incident agent needs the "create an item in the incidents list" key.
The safety technician develops her agent: in addition to answering questions about procedures, it gets one tool to log incidents in the department’s list and another to notify the department lead. When an operator writes “damaged guard on machine 14,” the agent asks for the department, severity, and whether there’s a photo, then logs the incident and sends the notification. She receives the notification with everything filled in and decides its priority.
Agent creation checklist
No one sees anything you build in Copilot Studio until you publish it. There’s a test panel beside the creation screen: you can talk to the agent as if it were a colleague and see its answer and source. Ask three questions people in your area actually ask, including one deliberately outside the scope, to see whether it redirects instead of making things up. Publish only after that, choosing who can use it.
After publishing, Copilot Studio shows how many conversations took place and which questions went unanswered. This is the improvement list: each unanswered question becomes a new document in the knowledge base or a new line in the instructions. An agent improves with weekly feedback; it isn’t a finished product.
The finance coordinator publishes an agent that answers questions about expense reimbursements for the entire company. In the first week, the dashboard shows twelve unanswered questions, all about mileage reimbursement, which wasn't covered in the linked policy. He adds the document, and in the second week the number drops to zero. Twenty minutes of maintenance, and one less email queue.
Test yourself
In the test panel, the benefits agent answered a question about vacation policy with details that aren’t in any of the documents it points to. What does this indicate?
Practice now 0/4 done
Goal: leave with an agent created in Copilot Studio, with your instructions, a knowledge source, and three questions tested — without publishing it. ~12 min, in your company’s Copilot Studio (at copilotstudio.microsoft.com, using your work account).
A draft agent isn’t visible to anyone: it exists only for you until the day you click Publish. If something goes wrong, delete it and create another one in two minutes. If your company hasn’t enabled Copilot Studio for you yet, complete steps 1 and 2 in a Word document and ask IT for access with the instructions already prepared—that’s what they’ll ask for anyway.
Você é o assistente de procedimentos da área de <sua área>. Responde apenas dúvidas sobre <os assuntos: ex. normas internas, prazos, quem aprova>. Regras: - Use somente os documentos apontados como conhecimento. Cite o documento e a seção. - Se não encontrar a resposta neles, diga "não encontrei nos procedimentos" e indique <nome do responsável>. - Nunca informe <o que ele não pode dizer: ex. dados de outras pessoas, valores>. Tom: direto, frases curtas, sem jargão.
You’ve just built your first agent, with a job description and documents, and tested it before anyone could see it—the fourth step.
Summary
Copilot + Agents · Lesson 6
By the end of this lesson, you’ll be able to build an approval flow in Power Automate and get it working in a test: a request comes in, someone approves it in Teams, and the result is recorded in a list—without writing code.
Everything you designed on the canvas needs someone to execute it: send the notice, wait for approval, record the result, follow up on the deadline. Today, that someone is you. Power Automate is the execution layer: the agent talks, the flow acts. Without this lesson, the agent from lesson 5 remains a helpful attendant who can’t leave the counter.
↓ role to study
O Power Automate is the company’s execution layer. A flow is the rule a good secretary would follow without a second thought: "when a purchase request arrives, check the fields, send it to the manager for approval, and then let the requester know." The difference is that the flow does this at three in the morning on Saturday and never forgets.
Every flow has a beginning, middle, and end. The beginning is the trigger: the event that starts it. The middle is the actions, in order. The end is the result recorded somewhere. You build it on a screen of blocks, dragging them into place and choosing from lists. No block requires code; each one is a sentence in Portuguese in the format “do this with that.”
The purchasing analyst has a supplier spreadsheet with the expiration date of each certificate. Every month, they opened the spreadsheet, filtered for upcoming expirations, and sent emails. Their flow today: every Monday, check the list; for each supplier with a document expiring in 30 days, notify the supplier, notify the internal contact, and create a follow-up task. They’re now the one getting notified instead of doing the notifying.
A ramp before the screen, which looks like an engineering diagram: each box is a sentence, and you read from top to bottom. The trigger is the first box, and comes in three flavors: event-based ("when an item is created in this list," "when an email with this subject arrives"), scheduled ("every Monday at 8 a.m."), or called by an agent ("when the agent asks"). The actions are the boxes that follow: send an email, post in Teams, create a row in a list, update Excel, write to Dataverse.
A condition is a question-shaped box: "is the value greater than 5 thousand?" It opens two paths, yes and no. A loop is the box "for each item in this list, do what’s inside here." And each action reaches the systems through a connector: a ready-made component that already knows how to connect to Outlook, Teams, SharePoint, Excel, and hundreds of other services. You choose it from a list; you don’t build it.
The HR manager sets up onboarding. Trigger: when a new row appears in the onboarding list. Actions: create the employee’s folder, send the welcome email, post in the team’s Teams channel, create onboarding tasks. Condition: if the role requires safety training, add the extra task. Five boxes and one question, and onboarding no longer depends on anyone’s memory.
Common mistake
Build a flow that works in the test and "silently dies" a month later. This happens because a flow fails now and then: a folder was renamed, someone deleted the list, or an email couldn’t be sent. Without an “if it fails, notify me” action, no one finds out and the process stops silently. Every flow you build should end with a failure notification to you; that’s step 4 of this lesson.
The most important action for businesses is approval. The flow sends a request to someone in Teams or by email, with the details and two buttons: approve and reject. It pauses and waits. When the person clicks, the flow continues along the corresponding path. It’s the person in the loop from lesson 4, implemented in one box. If approved: continue the process, record the result, update the metric. If rejected: notify the requester with the reason, and record it too.
Notice what this solves. Approval is no longer an email lost in the manager’s inbox; it becomes a time-bound item they can handle on their phone in two taps. And the record is automatic: who approved, when, and what. No one needs to ask “was this approved?” anymore.
The finance coordinator builds the out-of-budget payment request flow. Trigger: the department submits a form. Action: validate that all required fields are filled in. Approval: it goes to the coordinator if it’s up to 20 mil, and to the director above that. Then: record it in the approved payments list and notify the department. Average response time dropped from four days to one, without anyone having to work more.
Two things separate a toy flow from an enterprise flow. The first is logging: each run leaves a record somewhere saying what it did, with whom, and when. That record answers "was the supplier notified?" without opening anyone’s email inbox. The second is failure handling: when an action can’t run, the flow alerts someone instead of stopping silently.
Power Automate already shows the history of each run, including where it failed. What you add is simple: a final action to “send me a message if any previous step fails.” Two minutes to set up, and the flow now has someone responsible for it. A flow without an owner is a process that will stop one day without anyone noticing.
The occupational safety technician set up a workflow for expiring training: every week, it checks the list, and for each employee whose training expires within 30 days, it notifies their manager and creates a task. In the third week, someone renamed the list and the workflow failed. She received the failure notification that same morning, corrected the name, and no one missed a notification. Without the message, she would have found out during the audit.
Anatomy of the “expiring document” flow
This is where lessons 5 and 6 come together. In Copilot Studio, you can add a Power Automate flow as an agent tool. The agent does what it does well—conversation: it understands the request, asks for missing information, and confirms. Once it has everything, it calls the flow and passes along the data. The flow does what it does well—execution: it logs, notifies, requests approval, and updates. At the end, the flow returns the result to the agent, and the agent tells the person.
This division is the architecture of nearly every business agent, and it’s worth remembering: conversation and decisions in the agent; execution and records in the flow; data in SharePoint or Dataverse; indicators in Power BI. Each piece does one thing, which makes it easy to fix when something changes.
The safety technician closes the incident loop. The operator writes in Teams, “damaged guard on machine 14.” The agent asks for the department, severity, and a photo. With the answers, it calls the flow: log the incident in the incident list, notify the department lead, create a task due in five days, and send her a request to review it. The agent replies to the operator: “logged, incident 231, department lead notified.” Two tools, one conversation, an entire process.
Test yourself
The operator reports the incident to the agent, and the agent replies "recorded"—but nothing appears on the list and no one was notified. Where is the most likely problem?
Practice now 0/4 done
Goal: leave with a flow that triggers when an item is added to a test list, sends an approval request to you in Teams, and records the result. ~12 min, in your company’s Power Automate (at make.powerautomate.com, using your work account).
You’ll use a test list you created and approve the items yourself—no real person receives anything. The flow only runs when you create an item in the test list, and you can turn it off with a button at any time. If your account doesn’t have access to Power Automate, complete step 1 and write out steps 2 through 4; that’s the specification IT will ask for.
You’ve just built the execution layer: a request came in, someone approved it with two taps, and the result was recorded—without anyone typing in the status.
Summary
Copilot + Agents · Lesson 7
By the end of this lesson, you’ll be able to look at each system in your company and decide, with justification, which route the automation should use to access it: service endpoint, flow with a connector, screen automation, or Computer Use—and where human approval is needed before anything is recorded.
There’s a good reason the Integration field on your canvas says “I don’t know yet”: half of a company’s systems are old, don’t connect to anything, and only work through the screen. That’s where most automations die, and where the most repetitive work lives: typing into a screen what’s already in a PDF. This lesson fills in that field.
↓ role to study
The front door to a system is the screen: menus, fields, and buttons, made for people. The service entrance is the API, an entry point that other programs can use to connect directly, without going through the front desk. It’s like a building’s delivery entrance: the delivery person doesn’t take a number at the front desk; they use the service corridor and leave the package. When a service entrance exists, it’s always the best route for automation.
One connector is a service door with the key already in the lock: someone set it up, and you just choose it from a list. Outlook, Teams, SharePoint, Excel, and hundreds of commercial systems have connectors. The problem starts with legacy systems, custom-built systems, or ones bought ten years ago: they only have a front door. To automate them, you have to go through the screen, as a person would.
The purchasing analyst works with both worlds. The portal where suppliers submit documents is new and has a connector. The ERP The final entry system is twelve years old, nobody knows if it has a service door, and the only person who would know has retired. Entering each supplier's information takes forty minutes of typing, copying from the PDF to the screen.
When faced with a system, the question is "how does automation get in?" The answer follows a four-step ladder, from most reliable to most flexible. First choice: a service endpoint or connector, because it’s robust and doesn’t break when the screen changes. Second: a Power Automate flow with the available connector, when the integration is already built. Third: screen automation, when the system only has a front door and the screen is predictable. Fourth: Computer Use, when the screen changes, there’s no connector, and the agent needs to understand what it’s seeing.
The order matters because each step down is more fragile and more expensive to maintain. No one uses screen automation on a system that has a connector; it would be like going in through the lobby with the service door key in your pocket. And no one uses Computer Use for something predictable screen automation can handle: it would be like paying an employee who thinks just to press the same button every time.
Applied to each department’s systems, the ladder becomes a quick map. What the safety technician, purchasing analyst, and HR manager have in common is that each works with two or three systems at different steps. The right answer is one per system, not one per company.
Applying it to your departments
O Power Automate Desktop is the tool for the third choice. You record, or build block by block, the exact sequence a person would follow: open the system, go to the registration menu, click the company name field, type, move to the next field, attach the document, and save. Then it repeats that routine as many times as needed, the same way, without getting tired. The industry term for this is RPA.
Its strength and weakness are the same: it’s deterministic. It does exactly what was recorded, which is great for a stable screen and terrible when the screen changes. If a button moves after an update, the sequence misses a step. That’s why it’s the choice for old, unchanged systems, not portals that change every week.
The finance coordinator has eighty entries per week to type into the old accounting system, all from a spreadsheet. The screen automation opens the system and, for each spreadsheet row, opens the entry, fills in the five fields, saves it, and writes the generated number back to the spreadsheet. An afternoon of typing each week has turned into fifteen minutes of checking the return spreadsheet.
O Computer Use is the fourth choice, and it differs from screen automation in one essential way: it doesn’t replay a recording; it looks. The agent sees the screen, understands that the field is "company name" even if it has moved, and takes action. That makes it useful where screen automation breaks: sites that change their layout, systems with different screens depending on the case, and processes that require interpreting what’s displayed.
The price of this flexibility is less predictability and a higher cost per run. That's why it's the last rung, and why every recording made with Computer Use goes through human approval before it's submitted: the agent fills it out, shows what it filled in, and a person confirms the submission. It's the employee who thinks; you don't make it press the same button eighty times, and you don't let it sign off on its own.
The occupational safety technician needs to submit an accident report through an external agency’s system. The layout changes every year, and the screens vary depending on the type of incident. Screen automation would break with every change. Computer Use fills out the form from the internal record, shows her a summary of what it entered, and submits it only after she confirms. She spends her time reviewing, not typing.
Common mistake
Using Computer Use for a system that has a connector, or screen automation for a site that changes every week. This happens because the newest tool seems like the best one, or because recording the steps seemed simpler. The result is unnecessary cost in the first case and an automation that breaks with every update in the second. Climb the ladder from the bottom: connector, flow, predictable screen, and only then Computer Use.
Combine Lessons 5, 6, and 7 into one request: “register this supplier in the system.” The agent receives the documents and extracts the legal business name, identification number, address, and contact details. It checks the required fields and asks the requester for anything missing. It validates the rules in the supplier approval policy. It calls the flow, which requests approval from the purchasing manager. Once approved, the screen automation opens the ERP, goes to the supplier record, fills in the fields, attaches the documents, and saves. The flow logs the result, updates the indicator, and notifies the requester.
Notice how many tools are involved without anyone needing to know about them: an agent to chat and extract information, a flow to validate and approve, screen automation to enter data in the old system, a list to record it, and a metric to measure it. Each at its own level. The person who made the request wrote one sentence and, in the end, got “registered, code 4471.”
For the purchasing analyst, forty minutes of data entry per supplier has become three minutes of checking the approval and the record. But the bigger gain is something else: the process is now consistent for everyone. Before, each record turned out differently, depending on who entered it. Now they all turn out the same, and when something goes wrong, the record shows at which step.
An automation that fills in screens acts on someone’s behalf, and that calls for safeguards an email flow doesn’t need. First: it uses its own account, created for the automation, with access only to what it needs. Never your personal password. Second: every screen it fills in leaves a record with the date, data, and result. Third: before recording anything irreversible, such as an account registration or a submission to an external agency, a person approves it, and the record shows who approved it.
Fourth: a plan for when the screen changes. It will change sooner or later. The automation needs to stop and alert you instead of continuing to fill in the wrong field. And someone must be named as responsible for fixing the routine. Screen automation without an owner is a time bomb set to go off with the next system update.
The HR manager automated leave entry in the old timekeeping system. The automation has its own account, with access only to the leave screen. Each entry is logged in a list. She approves entries for leaves longer than fifteen days before they’re saved. And when the timekeeping system is updated, the automation stops at the first unfamiliar screen and alerts her in Teams. Four safeguards, one afternoon to set up, and leave entry is no longer the team’s most hated task.
Before automating a screen
Practice now 0/3 done
Goal: read the case, decide which of the four choices applies to each of the three systems, where human approval comes in, and what record is kept — then compare your answers with the answer key. ~10 min, on paper or in a document.
This is analysis, not execution: no system is touched. Doing it for real would require an old company system and the tool’s license, and making a mistake in either could have real consequences; that’s why this lesson’s practice is to make a sound decision. If your answer differs from the answer key and you have a reason, write it down—it may be right for your situation.
CASO — Renata, analista de compras Renata precisa automatizar o cadastro de fornecedores. Os documentos chegam pelo portal de fornecedores, que é novo e aparece na lista de conectores do Power Automate. O cadastro final é feito no ERP da empresa, que tem doze anos, tela igual desde 2019 e nenhuma porta de serviço conhecida. Antes de cadastrar, ela precisa consultar a situação do fornecedor no site de um órgão público, que mudou o layout três vezes nos últimos dois anos. Perguntas: 1. Para cada sistema (portal, ERP, site do órgão), qual das quatro escolhas? 2. Em que ponto do processo entra a aprovação humana, e de quem? 3. Que registro precisa existir para responder "o fornecedor X foi cadastrado?" sem abrir o ERP?
1. Supplier portal: connector, first choice; it’s the most robust and already available. ERP: screen automation, third choice; there’s no service endpoint, and the screen has been stable for years—the ideal case for a recorded routine. Agency website: Computer Use, fourth choice; the screen changes often, and a recording would break with every change. Anyone who answered “Computer Use” for the ERP wasn’t completely wrong, but would pay more and get less predictability.
2. The purchasing manager’s approval comes after the documents are validated and before the record is saved in the ERP, because saving the record is the irreversible step, and supplier approval is on the risk list. If the supplier is critical to production, a second approval from the manager of the team that will use them is also reasonable.
3. A list of completed registrations, populated by the flow: vendor, date, who approved it, code generated in the ERP, result. With it, "was vendor X registered?" can be answered in SharePoint, and the metric for time from request to registration comes from that same list.
You’ve just decided on the "Integration" field for three different systems, with justification, approval, and a record—the decision that holds up most automation projects.
Summary
Copilot + Agents · Lesson 8
By the end of this lesson, you’ll be able to define three metrics for your department, each with a goal, an owner, and a data source—and write a prompt that gets Copilot to explain why one of them missed its goal instead of just showing a chart.
Everything the agent and the flow record turns into a list full of rows. On its own, it changes nothing. What the company expects is for the manager to open a dashboard, ask "what’s getting worse and why?", and get an answer that leads to action. Without a target, a metric is just a number; without an explanation, it’s just a scare. This lesson closes the loop: data, metric, target, variance, explanation, action.
↓ role to study
The sequence that turns data into management has six links, and most dashboards stop at the second. Data: the rows the flow records. Indicator: the number that summarizes these rows. Target: the value the team agreed is acceptable. Variance: the distance between the metric and the target. Explanation: the factors that caused the variance. Action: what someone will do, with a name and deadline.
Think of a car dashboard. The speedometer is the metric; the speed limit sign is the target; the illuminated warning light is the deviation. A speedometer without a sign doesn't tell you if you're in the wrong. A warning light without knowing the cause only scares you. A driver can take action when they know all three: how much, compared against what, and why.
The workplace safety specialist tracks the average time to resolve incidents. Data: the incident list with opening and closing dates. Metric: the average number of days between the two. Target: seven days. Variance: twelve this month. Explanation: four incidents in the cutting area are waiting for a replacement part. Action: the maintenance manager will move up the purchase, deadline Friday. Without the last two links, the dashboard would only show a red number.
Every department has its own metrics. Workplace safety: accidents, near misses, inspections completed, corrective actions completed on time, overdue training, repeat incidents by department. Suppliers: on-time deliveries, nonconformances, response time, expired documents, approval time, dependence on a few suppliers. Purchasing: procurement lead time, price changes, emergency purchases. Operations: rework, downtime, cycle time. The full list is long; yours should be short.
Three rules for choosing. Keep the number small: between three and seven per area; beyond that, no one looks at them. Assign an owner: someone responsible for explaining the variance and proposing an action. Include the source: the list or table the number comes from, preferably the same one already feeding the workflow. An indicator without an automatic source requires someone to type it in, and people forget.
The purchasing analyst had a dashboard with thirty charts that management praised but never opened. They cut it down to five: on-time deliveries, nonconformities, expired documents, onboarding time, and concentration. Each has a goal, their name as its owner, and a source in the supplier list maintained by the lesson 6 flow. The new dashboard is opened every Monday at the purchasing meeting.
Common mistake
Build a dashboard with thirty charts, no targets, and no owners, and call it "metrics". This happens because charts are easy to make and goals are hard to agree on. The result is a dashboard people praise but don’t use. Start with three metrics, each with a goal, an owner, and an automatic data source. Add a fourth only when people are checking the first three every week.
O Power BI is the visualization layer. A ramp before the screen, like an airplane cockpit: you’ll use two things. The dashboard, which shows your metrics with the target marked and updates automatically from the list the flow feeds. And the Copilot question box, where you write in Portuguese, "why did the correction deadline increase this month?" and get an explanation of the factors.
Building the dashboard is a one-time task, and increasingly Copilot itself creates the first version from the list and targets. After that, daily use is simple: compare periods, see who missed the target, and ask for an executive summary to paste into the leadership team’s email. If your company hasn’t enabled Power BI yet, the same approach works in Excel with Copilot, using the spreadsheet instead of the list.
The finance coordinator connected the dashboard to the approved payments list maintained by the approval flow. Metrics: average approval time, payments over budget, amount approved by department. Every Friday, they ask Copilot, “what changed this week, and which department contributed the most?” and paste the summary into a message to the director. Ten minutes, and the weekly report is no longer an afternoon’s work.
The test of a good metrics system is the list of questions a manager can ask without calling anyone. "Which critical incidents are still open today?" "Which corrective actions are overdue?" "Which department has the most repeat incidents?" "Why did the metric drop this month?" "Which suppliers performed worst?" "Which suppliers have documents expiring soon?" "Which metrics have worsened the most in the last ninety days?" If the dashboard and Copilot answer these, the system is ready.
The next step is a metrics agent in Copilot Studio, with the dashboard as its knowledge source and Teams as its channel. The manager writes in Teams, "What's getting worse?" and the agent responds with the metrics below target, each variance, and an explanation. It's the fourth project in the program, and it reuses everything: the flow list, the dashboard, and the agent you already know how to build.
The HR manager built the onboarding and training dashboard: onboarding time, overdue required training, turnover in the first ninety days. The director asks the agent on a phone, "which team has the most overdue training?" and gets an answer with the list and the name of the manager responsible. She’s no longer the person who answers that question by email.
The minimal dashboard, in five steps
The last link is making the deviation trigger action on its own. A flow from lesson 6 can read the metric every morning and, when it's out of range, notify the owner in Teams with an explanation and create an action task. The manager doesn't have to remember to open the dashboard; the dashboard alerts them. And the task it creates goes back on the list, which is where the next metric comes from: actions completed on time. The loop closes, and each cycle leaves a record.
There’s also a second set of indicators, about the automation itself: hours saved, process time before and after, errors and rework, number of automated tasks, agents in use, and user satisfaction. These are what justify the next project to leadership. Measure from day one; measuring later is guesswork.
The workplace safety specialist set up the alert: when the average resolution time exceeds seven days, the area owner gets a message with the overdue incidents and a task due in two days. Alongside that, she tracks her own time: incident logging dropped from two hours to fifteen minutes, and that’s on the dashboard too. That number convinced leadership to approve the second project.
Test yourself
The dashboard shows "on-time deliveries: 82%" in red. The manager asks what to do. Which answer follows the complete chain?
Practice now 0/3 done
Goal: leave with three metrics for your area written down with a target, an owner, and a source, and with Copilot explaining a real variance using your list or spreadsheet. ~10 min, in Power BI Copilot, Excel Copilot, or your company’s Copilot chat with the file attached.
Nothing changes: Copilot reads the list or spreadsheet and responds in the chat. Use the same copy from lesson 3 if you like. If you don’t have a list populated by a flow yet, the spreadsheet your area already uses will work — the approach is the same; only the source is manual for now.
Indicador: <nome: ex. prazo médio de correção> Fonte: <lista ou planilha, com a coluna que mede> Meta: <valor combinado, ex. 7 dias> Dono: <nome de quem explica o desvio> Pedido ao Copilot: Nesta <lista/planilha>, calcule <o indicador> para <último mês> e para os três meses anteriores. Compare com a meta de <valor>. Se estiver fora da meta, liste os fatores que mais contribuíram (por <setor / fornecedor / tipo>), do maior para o menor, e sugira uma ação para o maior fator, com um prazo.
You’ve just completed the full chain for a real metric: target, variance, explanation, and an action with an owner and deadline—what the executives expected from the dashboard but never got.
Summary
Copilot + Agents · Lesson 9
By the end of this lesson, you’ll be able to deliver the complete canvas for your first agent project, with the governance checklist reviewed item by item and a three-phase plan with dates—ready to present to the decision-makers.
Everything you built in the eight lessons works as a draft. Putting it into production is a different matter: the agent starts acting on behalf of the company, with the access the company has, and a permissions error becomes a data leak. The question in this lesson isn’t "does the technology work?" It’s "is the company ready to turn this on?", and then "where do I start?". This is the fifth step.
↓ role to study
The rule that opens the lesson is the most important in the training for anyone putting an agent into production. If someone has unauthorized access to a document, an agent with the same permissions can find it too. This is called excessive sharing, and it existed before any agent. The difference is that nobody was going to look for the wrong spreadsheet in a folder with two thousand files, but the agent will.
A short case settles the question for good. Cláudia, an HR manager, published the benefits FAQ agent for the entire company. During the first week, an intern asked how much the sales director earned, and the agent answered because the payroll spreadsheet was in a folder that, due to a mistake made years earlier, was visible to everyone. The agent didn’t leak anything: it showed what any curious employee could already access. The fix was to the folder, not the agent, and took ten minutes.
For the occupational safety specialist, the lesson is the same, with a different focus. Before turning on the incident agent, she reviews who can see the incident list and the attached photos. She discovers that the photo folder is open to the entire company, including images of accidents involving identifiable people. Closing off the folder came before publishing the agent, and it would have been necessary even without an agent.
Governance sounds like a legal department issue, but in practice it’s a short list that the team itself can check. Permissions: who can access what, following the principle of least privilege. Groups: who belongs to each Teams and SharePoint group, because the agent inherits group membership. Folders: the agent’s sources are closed to anyone who doesn’t need them. Data: where confidential information is stored, and whether the agent can access it. Owners: one named person for each agent and flow. Audit trail: every action by the agent is logged with a date and account. Approval: the human checkpoints are built into the design and working.
There’s also a separation between draft and production, which Copilot Studio and Power Automate already offer: you build and test somewhere no one can see, and publish only afterward. And there’s the automation’s own account from Lesson 7: the agent acts through an account created for it, with the least access needed, never using someone’s password. None of this requires new technology; it requires an afternoon of checking and someone to take responsibility.
The purchasing analyst runs through the list before publishing the supplier agent. They find two problems: the contracts folder is in the wrong group, and the onboarding flow was running under their personal account. They fix both in one morning. Without the list, the agent would have gone into production and the problem would have surfaced in the first audit, or the first time they changed their password.
Before publishing: the seven checks
Every action by an agent happens on behalf of a person or an area: the email is sent, the record is saved, the payment is approved. Responsibility doesn’t pass to the machine. That’s why having a person in the loop isn’t an optional design choice; it’s a governance rule for financial, legal, or safety risks, information deletion, hiring, payments, disciplinary action, equipment or area releases, and critical vendors. In these cases, the record shows who approved it, and that person is accountable for the decision just as they would be without an agent.
This changes the conversation with leadership. The question “what if the agent makes a mistake?” has an answer: it prepares the work, a person signs off on anything risky, and the log shows the entire process. That’s more traceable than the manual process, where no one knows who approved what over email. Good governance supports automation; it doesn’t oppose it.
The finance coordinator presents the payment flow to the director using this logic. Up to 20 mil, the flow validates and the coordinator approves; above that, the director approves; everything is recorded in the list with a name, date, and amount. The director, who feared “a robot paying bills,” understands they now have more control than they had with the email inbox. They approved the project in the same meeting.
The company as a whole follows a long path: build skills, identify processes, prototype agents, add flows, integrate systems, automate screens, measure, govern, and expand to other departments. For your first project, this condenses into three phases with dates. Phase 1, prototype: the agent with knowledge and a list, in draft form, tested by three people on the team. Phase 2, execution: the flow with approval connected to the agent, its own account, and logging, running for the whole team. Phase 3, scale: the metric on the dashboard, the variance alert, the seven checks completed, and the presentation to the next team.
Each phase has a completion criterion and a metric that justifies it. The prototype is ready when three people have used it and the number of unanswered questions has dropped. Execution is ready when the record shows a month of operation without silent failures. Scaling is ready when the hours saved metric appears on the executive dashboard. Phases without completion criteria turn into never-ending projects.
The purchasing analyst plans the supplier agent. Phase 1, four weeks: an agent for onboarding questions, with the policy as its knowledge, tested by the three buyers. Phase 2, six weeks: a flow for expiring documents and an onboarding flow with manager approval, its own account, and a logging list. Phase 3, four weeks: five dashboard metrics, an expired document alert, a governance review, and a presentation to the quality department. Fourteen weeks, one project at a time.
You won’t roll out “AI at the company.” You’ll improve one process at a time, with a record and an owner—and the second is easier than the first.
The training suggests four projects, and each one uses all the components from lessons 5 to 8. The workplace safety agent: records incidents and near misses, receives photos, creates the action plan, routes it, follows up on deadlines, and updates the metric. The supplier management agent: onboarding, documents, approval, expiration dates, performance, alerts. Automatic system entry: a PDF, email, or form comes in, the agent extracts and validates the information, a person approves it, and the automation fills in the screen and records it. And the metrics agent: the manager talks to the dashboard.
Each department has its natural candidates. HR: onboarding, questions, documents, requests. Finance: reconciliations, approvals, collections. Purchasing: quotes, suppliers, price analysis. Quality: nonconformities, audits, action plans. Sales: proposals, customer follow-up. Operations: incidents, maintenance, productivity. The selection criteria are from lesson 1: repetitive, verifiable, a real pain point, and an owner who wants it.
The HR manager chooses new employee onboarding because it generates the most complaints and depends most on one person’s memory. Her canvas has been filled in since lesson 4; governance was checked in this lesson; the three-phase plan starts Monday. What really changes by the end of the training isn’t the tool, it’s her role: she’s no longer the person who answers questions; she’s the person who designs the process, builds the solution, and measures the result. It’s a new skill, called AI work engineering.
Practice now 0/4 done
Goal: leave with a page you can present to decision-makers — the complete canvas, all seven checks marked done or pending, and three phases with dates and completion criteria. ~12 min, in the canvas document from lesson 4.
This is planning on paper: nothing is published, no permissions are changed, and no agent leaves the draft stage. The pending checks are not failures—they’re the list of what to ask IT and the manager before publishing. If you can’t yet fit a phase into specific dates, write "after X is approved"; that’s a valid date.
PROJETO — <nome do processo> · dono: <seu nome> · substituto: <nome> CANVAS (da aula 4, agora completo — Integração preenchida na aula 7): Objetivo / Entradas / Conhecimento / Decisões (✱ humanas) / Ações / Integração / Validação / Indicadores GOVERNANÇA (feito · pendente · com quem): 1 permissões 2 grupos 3 pastas e fontes 4 dados confidenciais 5 responsáveis 6 trilha de registro 7 aprovação humana FASES: 1 protótipo — até <data> — pronto quando: 3 pessoas usaram; perguntas sem resposta caíram 2 execução — até <data> — pronto quando: 1 mês de registro sem falha silenciosa 3 escala — até <data> — pronto quando: indicador no painel da diretoria
You’ve just completed your first agent project with governance and a plan—the fifth step, on paper and ready to become reality on Monday.
Summary