All articles

You Can Now Build Apps with Copilot Cowork and Copilot Studio

6 min read

Have an idea for a small internal app, but no time to turn it into a development project? Think of an equipment tracker, a team dashboard, or a simple way to follow up on requests. Microsoft's latest Copilot announcement is worth a look.

On 10 September 2026, Microsoft announced natural-language app building in Copilot Cowork and Copilot Studio.

What interests me is the space between an idea and a useful first version. In this blog, I'll explain where to start, share a prompt you can adapt, and cover the things I would check before sharing the result with colleagues.

What is actually new?

Microsoft is adding app building alongside agents and workflows. The announcement describes full-stack apps using open standards, with options to inspect the underlying code and use Git-backed source control, deployment stages and version isolation.

This is more than asking Copilot for a code snippet. You describe the business outcome, intended users, data and actions. Copilot then generates a working app scaffold that you can refine through conversation and inspect in a preview.

My take: I would use an app when people need a clear screen to view or update something. I would consider an agent when a conversation helps, and a defined workflow when the steps need to be predictable. Start with the problem, not with the ambition to put all three into every solution.

Can you use it already?

Microsoft introduced two entry points:

  • Copilot Cowork: the /app skill is available through the Microsoft Frontier program.
  • Copilot Studio: App (Preview) is rolling out in public preview following the announcement.

As of 11 September 2026, this app-building experience is still preview. Do not immediately assume a missing tile means your tenant is configured incorrectly. Availability can differ while the Copilot Studio experience is rolling out.

For the Cowork route, check both Frontier eligibility and Cowork access. Microsoft's current Cowork guidance confirms that the App skill is a preview feature and requires participation in Frontier.

Cowork access itself is controlled through usage-based billing. A spending policy must include the user and select Cowork. The older Cowork agent entry under Agents > All Agents is still visible, but Microsoft says that its configuration no longer determines who can use Cowork.

Step-by-Step: Build a useful first app

My example would be a loan-equipment tracker for an IT team. Which test laptops are available, who has borrowed one, and when should it come back?

I would start with fictional records and keep purchasing, real employee information and updates to the production asset system out of this first version.

1. Open the builder

Use /app in Copilot Cowork, or select App (Preview) in Copilot Studio when it becomes available in your environment.

2. Describe the app, not just its name

Here is a starter prompt you can adapt:

Build a loan-equipment tracker for an internal IT team. Use fictional sample data only and do not connect to company systems. Show equipment name, asset reference, availability, borrower display name and expected return date. Include an overview and an equipment detail screen. Let me test borrowing and returning equipment with the sample records. Highlight overdue items. Do not send messages, order equipment or update external systems. Explain where the prototype stores its data and which connections a connected version would need.

I would ask for the storage explanation early. Before judging the design, I want to know whether this is only a visual mock-up or a working process with saved records.

The prompt describes the intended behavior. It does not enforce security permissions; those still need to be configured and tested separately.

3. Refine it and try to break it

Cowork lets you request changes through the conversation and open the app to test it as your users would experience it.

I would ask for one change at a time: a clearer overdue view, a filter for available equipment, or a warning when a return date is missing. Then test an unavailable device and two attempts to borrow the same item.

A nice dashboard is useful. A tracker that gives the same laptop to two people is less useful.

4. Review before publishing

In Cowork, the app saves automatically while you work. Publishing makes the current version available to the people you share it with. Sharing then happens through an app link.

Before sharing, I would test the app with an ordinary user account, not only the account that created it.

Connecting business data: useful, but be deliberate

The new experience can use connectors and Work IQ to bring organizational context into an app. Microsoft also describes scenarios where an app writes results back to connected business systems.

For our equipment example, I would introduce a dedicated test data source before touching the production asset register. Check the identity used by the connection, what it can read, what it can change, and whether the app needs write access at all.

There is a specific Work IQ detail worth knowing. Microsoft's Work IQ documentation says Microsoft 365 Work IQ is read-only unless an administrator explicitly enables write operations. Work IQ also requires its own spending policy.

That is a Work IQ rule, not a guarantee about every other connector. Review each connection separately.

My recommendation: make the prototype work first, then add only the connections it actually needs.

Pay attention to what the Share button exposes

This is the part I would highlight to every pilot user. Microsoft's Cowork sharing guidance says anyone in your organization who can use Microsoft 365 Copilot and has the app link can open and use the app, including all its data.

I would not assume that sharing an app automatically recreates every permission boundary of the information used to build it. Check what has been copied into the app, what it retrieves through connections, and what a recipient can actually see.

For the equipment tracker, fictional borrowers are enough to prove the concept. Test what happens when the link is forwarded before introducing real employee data.

Where does IT manage this?

The announcement says published apps appear in the Microsoft 365 admin center, giving administrators a central inventory and operational controls.

Microsoft's billing and management guidance places Cowork-built apps under Apps in the Microsoft 365 admin center. The experience provides centralized inventory and operational health monitoring, with policies for content security, data access and app usage.

Useful controls, but I would still name an owner before sharing anything:

  • Who reviews the next generated change?
  • Who fixes a broken connection?
  • Who checks whether the app is still being used?
  • Who decides when the app should be removed?

The same principle applies when testing a new Copilot Studio agent: judge the solution against explicit requirements, not how convincing the demonstration looks.

What does it cost?

Building and using apps in Cowork follows the usage-based Copilot Credits model. In the Microsoft 365 admin center, Copilot > Cost management is where administrators configure spending policies and monitor consumption.

Also review Auto-apply new services. Microsoft documents this as enabled by default for spending policies. When left enabled, future supported Copilot services and agents can inherit the policy automatically. For a tightly controlled pilot, I would decide deliberately whether that is what you want.

Do not confuse a small spending limit with a restricted audience. Microsoft's Cowork admin documentation explicitly says that even a one-credit policy grants access to users in scope. To exclude someone, keep them out of every spending policy that selects Cowork.

I would give the pilot both an app owner and a spending owner. Measure consumption while building, revising and using the app, rather than promising a fixed cost per app. My earlier Cowork access and cost article provides more context for that rollout conversation.

Final Thoughts

What I like about this direction is the chance to make a small, useful idea tangible without starting with a blank development project. But a working first version and a well-managed business application are two different milestones.

Start with one problem, fictional data and a small pilot. Prove the process works, understand what sharing exposes, and agree who maintains the app before connecting real business data.

What would your first app be: an equipment tracker, a team dashboard, or something completely different?

Learn more

Share LinkedInX / Twitter

Comments

No account needed. Your name is optional — leave it blank to post anonymously.

0/4000

Loading comments…

Keep reading