Copilot now proposes changes to the record itself
Microsoft opens public preview of Work IQ on September 30, and the part of it that belongs on your September calendar is the capability called governed actions. Copilot proposes a change, the proposal follows your approval workflows, and the change is written back to the source record within the permissions of the person who asked for it. The Dynamics 365 blog post introducing Work IQ sets that beside the grounding work.
Grounding an assistant in business data so it can answer questions about that data has become ordinary. Every vendor we cover shipped a version of it this year. Writing back to a source record puts the assistant inside your change history and your reconciliation, which makes it a different product with a different failure mode.
The grounding underneath comes from what Microsoft calls a semantic model, combining data scope, semantic indexing and application knowledge, alongside business skills, described in the post as reusable assets that pair task instructions with supporting resources. On storage, the author writes that "Dataverse acts as the secure business store for semantic models and skills in Work IQ and enables the new Dataverse Ask API". Nobody is quoted saying it. That sentence is the post's own text.
The permission boundary Microsoft picked is the right one
Two choices in that description do real work. Write-back stays inside the permissions of the signed-in user, and the proposal passes through an approval workflow before it lands. Copilot cannot touch a table the person asking could not already touch, and someone other than the model puts a name on the change.
That beats what integration projects usually settle for, which is a service account holding rights no individual has, running every change under one name in the audit trail. We have spent years telling people to stop building that. Microsoft has not built it here, and the design deserves the credit.
The preview also brings a Work IQ MCP Server, a Work IQ CLI and a Work IQ plugin for coding agents, so the thing is meant to be reached programmatically rather than only through a chat window. The same boundary has to hold across all of those entry points, and the person who ends up approving a change may never have opened the app it lands in.
Your security roles were assembled for people working at human pace
Open Dataverse security roles in an environment that has been live for five years and the same pattern shows up. A role cloned for a go-live and never narrowed afterwards. A team that picked up write access during a data fix two years ago. Two or three people holding delete on accounts because somebody had to merge duplicates one afternoon.
None of that caused much trouble while a human had to open the form, tab through the fields and press save. Volume was the limit, and the limit was a human one. A permission somebody holds and never exercises carries a different weight once an assistant can find it and use it the first time it is asked to tidy up stale opportunities.
Most organisations have never audited their roles with that question in front of them. That follows from reusing an existing model rather than from any flaw in Microsoft's design, and it still lands on the administrator. Our piece on security roles that hold up as the org grows has the cleanup pattern, and there is one question to take into it. For every role that can write or delete, would you be comfortable with an assistant making that change for everyone who holds it?
An approval only counts if someone reads it
An approval a person performs properly is a real control. The same approval at volume is a signature with nothing behind it. Forty proposals landing in one queue on a Friday afternoon get what forty approval cards have always got, which is a scroll and a click.
The number to watch is how many proposals a single approver will see in a week, and what each card puts in front of them. An amount and two buttons give nobody grounds to refuse. Which record changes, which fields change, what the values were before and what prompted the proposal give an approver something to reject.
We made the same argument about Microsoft's own procurement example, where human review sat on the exception path and nowhere else. Work IQ pushes harder on that design, because proposals now start in a conversation rather than in a form somebody had to fill in first, and conversations are cheap.
Finance and operations arrive last in October
Public preview starts September 30 and rollout continues through October. The Dynamics 365 finance and operations apps come in late October, behind the rest. The post does not lay out a firm order beyond that, and it names no general availability date, so everything here is preview behaviour.
The ordering works in finance's favour. A wrongly changed customer record can be put right by the person who owns it. A wrongly changed record that feeds the ledger brings a reconciliation and a period close with it. Finance teams get a few extra weeks, and segregation of duties is the review worth spending them on.
Pull your role assignments before September 30
Export the security role assignments for your production environment this week and sort them by the tables that would hurt. Accounts, opportunities, anything carrying a price or a quantity. For every role with create, write or delete on those tables, list the users and teams that hold it and the head count that comes to.
Then walk the list past whoever owns each table and ask one question per line. If Copilot proposed this change on behalf of this person, would you want it to go through? We put the same weight on permissions when prebuilt agents arrived with broad reach, and a preview date turns that from a theory into a deadline. Any line that takes real thought to answer is a role to narrow this month, and delete privilege is where we would start.
