Home · Solutions · Other solutions
Solution · Other solutionsThe owner approves on a card and a robot applies the change before the meeting ends
Groups, aliases and mailbox rights changed from Teams
Group membership, distribution lists, aliases, shared mailbox rights and calendar delegation are requested on a card, approved by the owner and applied in minutes, with every change recorded.
Executive summary
The service desk's largest queue by count is also the one nobody measures.
Intake comes first, because most of the administrator's time is spent recovering information the requester already had.
Changes are applied minutes after approval, because a robot has no calendar to fit them into.
Microsoft Entra ID groups; Exchange Online distribution lists, shared mailboxes, aliases and calendar delegation
Business problem
IT administration
Mailbox and group administration is high in volume, low in skill and sensitive in permission, which is the worst combination a service desk can be handed. Too frequent to ignore, too trivial to prioritise, too risky to give to just anyone. Requests arrive through Teams, email and corridors with details missing, so the first thing an administrator does is ask a question, and the second is wait for an answer.
Approval is improvised. Some groups have owners who ought to decide, some are sensitive, most belong to nobody, and the administrator guesses which is which. The guess is usually right and never recorded, so a year later nobody can say who authorised access to a client matter's mailbox.
What is granted is rarely given back. Distribution lists collect leavers because removal is never requested by anyone. Shared mailbox rights granted for a project outlive the project. Delegation for an assistant involves settings in two places and often ends in a phone call. The whole category persists because the tools are administrator tools, the policy about who may approve what was never written down, and each individual request is too small to justify fixing the pattern behind it.
How it works today
The route below is what a small permission change takes in most firms on Exchange Online.
- PersonA requester posts in a Teams channel or emails the desk, usually without the details the change needs
- PersonThe administrator asks who it is for, which list exactly, and until when
- WaitingThe administrator works out who should approve, emails the presumed owner and waits days for a reply
- SystemThe change is applied in the admin console, one setting at a time
- Risk of errorDelegation needs a second setting that is easy to miss, so the requester calls back and the ticket reopens
- WaitingTemporary access has no end date, so it stays until somebody notices it in a review
- Risk of errorLeavers are never removed from lists, because removal was never requested by anyone
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Administrator minutes are the small part. A new starter without the right lists misses the information their team runs on for a week, and the requester spends their own time chasing.
- Client-facing distribution lists that still contain people who left the firm are a data protection question dressed as housekeeping, and they only surface when somebody replies to the wrong thread.
- Shared mailbox rights granted "for the project" become permanent access to customer correspondence, and nobody is asked to review them because nobody owns them.
- Delegation applied with more rights than the request stated exposes a director's calendar detail to an assistant who never asked for it.
- Two people holding the Exchange administrator role are simultaneously a bottleneck and a concentration of privilege, which are usually treated as separate problems.
Cost of inaction
Volume here follows the organisation chart, not the IT plan. Every reorganisation renames lists, every new office adds them, every matter needs a shared mailbox, and two administrators absorb it by letting the queue wait until waiting is simply how long this takes.
The slower cost is who can read what. Client-facing lists gain leavers at the rate people leave, mailbox rights granted for a closed matter stay open, and a delegation applied with the wrong permission quietly exposes a director's calendar. None of it is a crisis, which is exactly why it is still there, and the clean-up gets more expensive every month it is deferred.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A professional services firm with 1,400 staff across six offices, running Exchange Online, Microsoft Entra ID and Microsoft Teams. Two administrators hold the Exchange role.
About 720 requests a month for group membership, distribution list changes, shared mailbox permissions, aliases and calendar delegation, arriving through Teams, email and in person.
Each request takes roughly 17 minutes of administrator time including the questions and the approval chase, and typically waits two days before anything happens.
No structure at intake and no written rule about who may approve what. A recent review found client-facing distribution lists containing people who left more than a year ago, and a shared mailbox for a closed matter still open to fourteen people.
A structured card in Microsoft Teams, a rules layer that knows which groups have owners and which are sensitive, a one-tap approval from that owner, and robots that apply the change in Entra and Exchange Online within minutes.
Three requests in four applied without an administrator, roughly 153 hours a month, and a monthly report that names every ownerless group. These are modelled figures built on the firm's own assumptions rather than measured anywhere.
Proposed solution
Intake comes first, because most of the administrator's time is spent recovering information the requester already had. A card in Microsoft Teams asks for the type of change, the group, mailbox or calendar, the person it is for, the business reason and, where the access is temporary, an end date. Nothing incomplete leaves the card, so the question-and-answer round disappears before any automation runs.
The rules layer decides the path, and we build it with the client rather than assume it. A change to a group with a named owner goes to that owner for a one-tap approval on an Adaptive Card in Teams. Groups marked sensitive by information security, finance approver lists, partner lists, client matter mailboxes, need the owner and the security lead, both recorded. Delegation on a person's own calendar and membership of low-risk internal lists are applied on request, without an approval step that adds nothing.
Robots then do what an administrator would do. Group membership is changed in Microsoft Entra ID, and mailbox permissions, aliases, distribution lists and calendar delegation in Exchange Online through Microsoft Graph, under a service account whose reach is scoped rather than tenant-wide. The requester and the owner are told when it is done. Every change is written to the Orchestrator log with the request and the approver, temporary grants expire on their date by a scheduled job, and a monthly hygiene report lists groups without owners, members who have left and shared mailboxes with no activity. Administrators keep the failures, the unusual requests and the decisions the report surfaces.
Microsoft Teams Adaptive Cards with Universal Actions and the Approvals app; Microsoft Entra ID group administration; Exchange Online administration of distribution lists, shared mailbox permissions, aliases and calendar delegation; UiPath Orchestrator queues, time triggers, credential store and audit; UiPath Action Center tasks in Teams
The request card per change type, the rules layer with its owner and sensitivity registers, the robots that apply each change, expiry handling for temporary grants, exception routing to the administrators and the monthly hygiene report
Group and directory changes through the UiPath Integration Service connector still named "Microsoft Azure Active Directory"; mailbox, alias and delegation changes through Microsoft Graph and Exchange Online administration; leaver status read from the HR system or the directory for the hygiene report
How the automated process works
- PersonThe requester completes the card in Teams: change type, target, person, reason and, for temporary access, an end date
- AutomationThe rules layer resolves the owner and the sensitivity of the group or mailbox and picks the path
- PersonThe owner approves on the card in Teams, joined by the security lead where the target is marked sensitive
- AutomationA robot applies the change in Microsoft Entra ID or Exchange Online and verifies the result rather than assuming it
- AutomationThe requester and the owner are notified, and the change is written to the audit log with its approver
- AutomationA scheduled job removes every temporary grant on its end date and confirms the removal
- Risk of errorA failure, or a request the rules do not cover, becomes an administrator task in Action Center inside Teams
- SystemA monthly hygiene report lists ownerless groups, members who have left and shared mailboxes with no activity
Human-in-the-loop model
Automation handles
- Collecting a complete request on the card, so nothing starts with a missing detail
- Working out the owner and the sensitivity of the target from the registers
- Applying membership, permissions, aliases and delegation in Entra and Exchange Online
- Notifying both sides and recording each change with its approver and result
- Expiring temporary grants and producing the monthly hygiene report
People decide
- Owner approval for owned groups and mailboxes, with the security lead for sensitive ones
- Administrator handling of failures and of requests the rules were never given
- Which team lead owns each group the hygiene report shows as ownerless
- What happens to stale lists and shared mailboxes nobody has opened for months
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- the request card in Microsoft Teams
- the owner and sensitivity registers
- leaver status from the HR system
- existing desk tickets during the transition
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- Microsoft Entra ID groups
- Exchange Online distribution lists, shared mailboxes, aliases and calendar delegation
Human touchpoints: owner approval on a Teams card; Action Center tasks in Teams; the monthly hygiene report
Technologies used
the structured request and the owner's one-tap decision, in the channel where the request used to be typed
Agroup, mailbox permission, alias and delegation changes under an application identity scoped to what it may touch
Adistribution lists, shared mailboxes, aliases and calendar delegation as the system of record
Agroups, owners and the directory attributes the rules read
Aqueue each request, apply the change, expire temporary grants, retry, log and audit
ATeams cards and notifications, and directory changes through the Microsoft identity connector
Afailures and uncovered requests as tasks the administrator completes in Teams
Arequest volumes by type, approval times by owner and the monthly hygiene report
AIllustrative economic model
The arithmetic is open, so it can be argued with.
This illustrative professional services firm counts 720 such requests a month; the calculator takes the three in four the rules and robots would handle, 540, at 17 minutes of administrator time each including the questions and the chasing, and €43 an hour fully loaded. The remaining 180 stay with people. Requester follow-up is shown as hours and deliberately left unpriced, and the control benefit on client correspondence is not in the arithmetic at all.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Changes are applied minutes after approval, because a robot has no calendar to fit them into
- The decision moves to the person who actually knows whether Marta belongs on that list, which is the owner rather than the administrator
- Sensitive lists and client mailboxes are protected by two recorded approvals instead of an administrator's judgement call
- Leavers disappear from lists and mailboxes, because the hygiene report and the expiry dates do what nobody ever requested
- The desk loses its largest queue by count and the Exchange administrator role stays in fewer hands
- A category the desk never measured becomes visible: volumes by type, waiting time, and who approves what
The management view
- A queue that was invisible in service desk reporting turns into a measured flow with volumes, waiting times and approvers
- Approval authority is written into the rules instead of improvised per request, and every change carries a name
- Group owners, usually team leads outside IT, start treating their lists and mailboxes as something they own
- Access to client correspondence has an end date rather than a review, so the audit question has an answer
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- The robot works through a dedicated service account with Exchange and directory rights limited to group membership, mailbox permissions and aliases, never global administrator, and its Exchange reach is scoped to what it may touch rather than to the whole tenant
- Credentials for that account live in an external credential store connected to Orchestrator, typically Azure Key Vault, and no person uses them directly
- Targets that information security marks as sensitive always need two recorded approvals in Teams, and a requester can never be the only approver of their own request
- Temporary permissions carry an end date and are removed by a scheduled job, so client matter access ends by design instead of by review
- Every change is logged with the request, the approver and the result, corroborated by the Exchange, Entra and Microsoft Purview audit logs; delegation is applied with the least rights the request states, and processing stays in the EU regions of UiPath Automation Cloud and Microsoft 365
Why now
Firms are being asked harder questions about who can read client correspondence and where internal lists send information, which turns a housekeeping queue into a control the partners have to answer for
Everything an administrator does in these consoles is available through Microsoft Graph and Exchange Online administration, so a robot can do the same work under a scoped account with a full record, and a card in Teams gives the owner a one-tap decision without a portal
Service desks are usually asked to absorb growth without hires, and the largest queue by count, worth a modelled €6,579 a month here, is the obvious place to look first
Relevant executive roles
The desk's biggest queue by count moves into a governed flow, and the Exchange administrator role stops being handed out to relieve pressure
A visible win with the business: a request made in Teams is done in minutes, with the owner's approval on record rather than in somebody's mailbox
Sensitive lists and client mailboxes get a written approval rule and an expiry date, and the ownerless groups finally have a list of their own
Common questions and objections
Owners respond faster than administrators chasing them by email, and the card reminds them by itself. Requests with no owner response after an agreed time fall back to the administrator, which is exactly where they are today.
For some group types they do, and we use them where they fit. Distribution lists, shared mailbox permissions, aliases and calendar delegation still need an administrator, and the rule about who may approve what has to live somewhere.
Seven hundred requests a month is the desk's biggest queue by count, and the risk sits in the client mailboxes and lists it touches. It is small only per item.
When this is not the right solution
- Fewer than about a hundred such requests a month, with one administrator who has the capacity to absorb them
- A move to another mail platform is planned within the year, in which case the target of the automation is about to change
- Group ownership does not exist and nobody will assign it, leaving the rules layer with nothing to route a decision to
- An identity governance rollout already covers group membership with owner approval, in which case it should be extended rather than duplicated
A question for the next management meeting
Every change to a client-facing distribution list last month was approved by whoever the administrator happened to ask, so which of those lists has an owner this firm could name today?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- An analysis of one month of desk requests classified by type, with the volumes and waiting times behind each
- An inventory of groups, distribution lists and shared mailboxes with their owners, which is where the first surprises appear
- Approval rules agreed with IT and information security, including the list of sensitive targets
- The request card per change type and robots for membership, permissions, aliases and delegation
- Expiry handling, exception routing to Action Center and the monthly hygiene report
- Pilot in one office on lists and mailbox permissions, then rollout with administrator review during the first weeks
We need from you
- The owner inventory, or a decision on who assigns owners to the groups that have none
- The sensitivity list from information security, naming the groups and mailboxes that need two approvals
- A service account with Exchange and directory rights scoped to membership, permissions and aliases
- A desk process owner who can change the phone script and the channel message when the card goes live
Stages
Discovery
One month of requests classified, plus the inventory of groups, mailboxes and owners
Rules
Who approves what, which targets are sensitive, what may be applied on request
Build
Request card, robots per change type, expiry job, exception routing, hygiene report
Pilot
One office on lists and shared mailbox permissions, with every automated change reviewed
Rollout
Aliases, delegation and the remaining offices, then the desk switches its intake to the card
Quick win. Effort is driven by how many groups already have owners, how many change types go in the first release, and whether the sensitivity list exists or has to be written.
Marta starts Monday, and the list she needs is owned by nobody.
Send us one week of mailbox, group and delegation requests from your desk queue. We map each one to self-service, owner approval or administrator work, and name the groups that have no owner to route to.
Send one week of desk requestsThe neighbouring process usually has the same problem
New starters wait days for access; leavers keep theirs for weeks. Both are the same missing handover.
View solution Other solutionsThe service desk request that never becomes a ticketFour IT tickets in ten follow a known procedure, and every one of them still queues for an analyst.
View solution Other solutionsApplication access granted by policy in minutes, with proofAccess is granted from interpreted emails, approvals are chased, and the auditor finds the evidence missing.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services