A request arrives
Your service desk receives a routine access request from a named client contact.
For managed service providers
Routine Microsoft 365 changes — only while they’re still authorised.
MayAct sits in front of your existing automation. Before a requested group change runs, it checks the client’s current named authority and approved scope — not a stale approval from earlier in the ticket.
The first use case
Microsoft 365 group membership changes, with a live authority check.
A client asks to add or remove someone from a group. Your service desk and automation already know how to make the change. MayAct answers the harder question: is this person still allowed to request this change, for this client and this group, at the moment it executes?
Technical access is not the same as current permission.
How it works
01
02
03
04
Keep your workflow. Add a decision point before the consequential action.
MayAct is an authority layer, not a replacement PSA or automation platform.
Authority is checked
MayAct verifies who may request which action for that client — using the current record.
Your automation acts
The existing workflow runs only if the request remains within the current approved scope.
The outcome is recorded
The ticket has a clear record of the decision, action, and verified final state.
Why it matters
Queued work should follow the latest instruction — not the oldest one.
A contact can lose authority after approving a request. Scope can change while a job is waiting. A reliable system must adapt immediately in either direction.
A simple real-world case
A verified client contact approves a Microsoft 365 group change. Before the queued job runs, their authority is removed. MayAct blocks the change. If authority is legitimately restored or revised, it follows the newest instruction — rather than stubbornly following an old approval.
What your team gets
Current authorityNo duplicate changesVerified completionClear audit record
Built for controlled scope
Each workflow is limited to explicit people, clients, actions, and groups — not an all-purpose permission to change everything.
Works beside your stack
Designed to sit between your service desk and existing automation, beginning with MSP workflows such as Rewst-backed jobs.
Deliberately narrow at launch
Start with the routine change that should never become a risky one.
The first MayAct workflow is intentionally constrained so an MSP can validate it with real client processes before expanding it.
Initial scopeNamed-user additions and removals in explicitly allowlisted, non-privileged Microsoft 365 groups. No broad tenant administration, no privileged roles, and no attempt to replace your PSA or automation platform.
Early access
Talk to ChaseDeskWe’re looking for three MSP design partners.
You are a strong fit if you handle Microsoft 365 access requests regularly and use a service desk plus automation today. Help define the first workflow around your real approvals, exceptions, and audit needs.