A product that lives in email, and a blocked install
Your product helps fee earners file emails to matters, or draft replies, or extract dates from correspondence. It lives in Outlook, because that is where lawyers spend their day. The pilot group installed the add-in themselves. Now the firm wants to roll it out, and the IT team says no.
Their reasons: the add-in asks to read and write every item in the user's mailbox, it sends email content to a server they have not reviewed, users cannot install add-ins themselves under firm policy, and it behaves differently in the new Outlook compared with the classic desktop version many fee earners still use. The rollout is paused while you work out what to change.
Why firm IT is cautious with add-ins
A law firm mailbox holds a great deal of client confidential and privileged material. An add-in with broad access is effectively a door into all of it. IT teams manage that risk carefully.
- Add-ins request the highest permission level because it was easiest during development.
- What the add-in sends to your servers, and what you keep, is not documented clearly.
- Firms block user installation and deploy add-ins centrally to chosen groups.
- Firms run a mix of classic Outlook, the new Outlook, Outlook on the web and mobile, and behaviour differs.
- Some features rely on Microsoft Graph permissions that need admin consent, which IT is reluctant to give broadly.
What a blocked add-in costs
If your product's value is delivered in Outlook, a blocked add-in means no rollout. Pilots that went well on self-installed add-ins turn into long IT reviews. Your team gets pulled into calls about permissions and deployment instead of product work. And every change to permissions after deployment triggers a new approval at every firm, so getting it right up front matters.
Self-installed pilots also hide problems that only appear at scale. A permission that one partner accepted without reading becomes a formal risk item when IT reviews it for the whole firm. A feature that worked on the pilot users' new laptops fails on the older desktops in the litigation support team. By the time these surface, the firm has already announced the rollout internally, and the delay is visible to everyone.
How we build an add-in firm IT can approve
What we build is an add-in designed around a firm's IT policies from the start.
- A permission review: each feature mapped to the least access it needs, such as reading only the current item, rather than the whole mailbox.
- Graph permissions reduced to what features actually use, with delegated rather than application permissions where possible, and a clear list of what needs admin consent and why.
- Deployment through the Microsoft 365 admin centre's integrated apps, so IT can assign the add-in to specific groups and control updates.
- A data flow document for IT: what leaves the mailbox, when, where it is processed, what is stored and for how long, tied to what the code actually does.
- Testing across classic Outlook, the new Outlook, Outlook on the web and mobile, with features that degrade gracefully where a client lacks support.
- Firm-level settings so IT can turn specific features off, such as sending content to an AI service, without removing the add-in.
| IT concern | What we change |
|---|---|
| Access to the whole mailbox | Current item access only, where features allow |
| Unclear data flows | Documented flow tied to the code |
| User self-install | Central deployment to chosen groups |
| Different Outlook versions | Tested on each, graceful fallbacks |
| AI processing of email content | Feature switch per firm |
Every permission we keep has a reason written next to it. That list becomes part of what you send firms during their review.
The IT review, second time round
The firm's IT team receives a short pack: the permissions requested and why, the data flow, and the deployment method. The add-in now reads only the item the user has open. They deploy it through the admin centre to the litigation department first. Fee earners on classic Outlook and on the web see the same core features, and a mobile user sees a simplified version. The firm switches off one AI feature pending its own policy review, and the rest goes live.
Is your add-in stuck at IT?
- Your add-in requests read and write access to the whole mailbox.
- You cannot give IT a clear account of what email content leaves the firm.
- Pilot users installed the add-in themselves.
- The add-in behaves differently in new and classic Outlook.
- Firms cannot switch off individual features centrally.