How to get your IT team to let you build agentic workflows

Phase 1: Scope

Every engagement starts with a scope form we provide. It names the trigger, the systems the workflow touches, and the output, so the start and the end of the workflow are written down before anything is built.

Nothing outside the form gets built, and the testing phase measures against exactly what it says. If the scope needs to grow, it grows through the form.

The worked example

The example used throughout this page is a tender agent we built for a UK construction contractor. It does one thing: when an invitation to tender arrives by email, it works out which of the company’s past proposals are closest to the new opportunity, and posts that shortlist into a chat channel where a bid manager can act on it.

That is five steps:

1. 1.A tender email lands in one monitored mailbox with a PDF attached.
2. 2.The worker notices it, downloads the attachment and extracts the text.
3. 3.A language model pulls out the structured facts, which are the contract value, the key dates, the award weighting and the site constraints.
4. 4.The worker reads the company's past-proposal library out of one document folder.
5. 5.It posts a summary into one chat channel, then replies in that same thread with the five closest past proposals, each a link plus a one-line reason, and asks a human which to build on.

From your IT team’s point of view that is four kinds of traffic: one mailbox polled, one document folder read, one outbound HTTPS call to a model API, and one channel written to. Nothing else: no inbound connection, no software on anybody’s laptop, and no access to a user’s personal files. Every workflow we build has those same four parts, so the scope form mostly names which systems fill them.

Phase 2: Access

On this route the workflow runs in your tenant, so access means a short list of scoped grants from your IT team. Everything in this phase is theirs to execute, and it is an afternoon of work, not a project.

The access steps, in order

Your IT team only does steps 3 to 5.

We shadow run in step 7 because it is the cheapest way to find out whether the agent is useful before anybody depends on it. It also means that by the time your bid team sees the agent, it has already produced a week of correct output.

What we need from your IT team

Access, per capability

The middle column is what we ask for on Microsoft 365 and Teams. The right-hand column is the broader permission that would also work, and that we are deliberately not asking for.

Scoping the mail permission actually works, but only if the broad grant is removed. Mail.Read as an application permission normally means every mailbox in the tenant, which is not a reasonable thing to ask for. Exchange RBAC for Applications fixes that: your Exchange administrator creates a pointer to the app’s service principal and assigns it the Application Mail.Read role against a resource scope covering only the one mailbox.

New-ServicePrincipal -AppId <app-id> -ObjectId <service-principal-object-id> -DisplayName "Tender Agent"
New-ManagementRoleAssignment -App <service-principal-object-id> -Role "Application Mail.Read" -CustomResourceScope "Tender Agent Mailbox"
Test-ServicePrincipalAuthorization -Identity <service-principal-object-id> -Resource <target-mailbox>

One thing silently defeats the whole exercise. Microsoft’s documentation is explicit that Entra grants and Exchange RBAC grants are combined as a union, so if the unscoped Mail.Read grant is left in place in Entra alongside the scoped RBAC assignment, the result is no effective scoping at all. The unscoped grant has to be removed. Test-ServicePrincipalAuthorization is how you confirm it, and it bypasses the permission cache, which otherwise takes between 30 minutes and 2 hours to catch up.

This feature replaces Application Access Policies. If your team already uses those, the same documentation covers the migration path.

The identity problem

IT teams usually raise this as “so you need an account on our Microsoft tenant?”.

Reading mail and reading files both work app-only, with no user account and nobody’s credentials involved. Posting into a Teams channel does not, and there is no way to make it. Microsoft Graph’s documentation for posting a channel message lists ChannelMessage.Send as a delegated permission only, and the sole application permission in that table is Teamwork.Migrate.All, which is “only supported for migration”. The obvious workaround used to be an incoming webhook, but Office 365 connectors were retired in May 2026, with the rollout beginning on 18 May and completing on 22 May. And the third instinct, a headless sign-in with the device code flow, runs into the fact that security defaults block device code flow outright as one of its basic controls, with all new tenants blocking it from 1 July 2026. Tenants on P1 or P2 licences that use Conditional Access instead are told by Microsoft to get as close as possible to a unilateral block on the same flow.

So there are three real options, and we recommend the first.

1. 1.An Azure Bot Service identity. The agent posts as a properly named bot, which is what you want if humans are going to read its messages every day. The cost to your IT team is a Teams app package and an administrator approving its upload.
2. 2.A dedicated licensed service account holding delegated ChannelMessage.Send. Pragmatic and quick, but the agent's messages appear as though sent by that user, and the sign-in flow has to be one your Conditional Access policy actually permits. This is the option that requires a licence.
3. 3.A Power Automate workflow. Lightest to stand up, and the Teams connector action does work, but messages arrive as "Flow bot" with no custom name or icon, and the HTTP request trigger is very likely a premium capability requiring a paid Power Automate licence. We list it for completeness rather than recommending it.

None of this arises on Slack, because a Slack bot posts as itself by design. If chat moves to Slack, this whole problem disappears.

Programs and infrastructure

Everything runs inside your cloud. Nothing in this list requires a VPN, a domain join, an agent installed on an endpoint, or any inbound firewall change.

The costs you should expect, so none of them are a surprise later: container compute, which for a workload like the tender agent is small; language model API usage, billed on volume; one Microsoft 365 licence only if you pick the service-account option above; and a Power Automate premium licence only if you pick that option.

What we have actually run

The demo behind this document ran with delegated authentication inside our own Microsoft tenant, because it was a demo. The architecture recommended above, which is app-only credentials scoped to a single mailbox and a single document library, is the documented least-privilege pattern rather than something we have already operated end to end in a client environment.

Step 6, the read-only smoke test, confirms the pattern against your configuration. It stays read-only so that a wrong assumption there costs nothing. We verify your access policies, your management scopes and your document library layout rather than assume them.

That discipline gives your team a check to apply to any vendor. Our demo declared six delegated Graph permissions. When we went back through what the code actually calls, two of them, Team.ReadBasic.All and Channel.ReadBasic.All, were never exercised at all, because the team and channel identifiers come from configuration rather than from a lookup. They are not in the table above. If a request asks for a permission, ask which API call needs it.

Which administrator has to do what

Most delays come from a ticket sitting with someone who does not hold the role required to action it.

Phase 3: Testing

We run the testing phase ourselves, on both routes. Model and API usage during testing is billed at cost, with no margin. It is a small amount, and it exists only to confirm the workflow behaves.

Testing has one exit condition: the workflow agreed in the scope form runs end to end on its own and gets the right answer. When it does, testing is over and the workflow goes live.

Phase 4: Aftercare

Maintenance is £1,000 per year. It covers fixes to the workflow for as long as the fee is paid, under the service levels below.

We recommend your own API key. At handover we rotate the workflow onto a key that you own. The provider bills you directly, your compliance team keeps full control of the data terms, and nothing about your usage flows through us. If your organization already runs Copilot or another AI vendor, your team has done this before.