Will anyone lose access they have today on go-live?
No. We join additively: the portal reads existing permissions and adds new ones. We do not remove anything we did not grant.
We have years of permission mess. Does that disqualify us?
Opposite — that is a typical starting point. The portal first shows who really has access. Cleanup is a separate decision after you see the list, not a prerequisite.
What permissions does the app need in our Microsoft 365?
The narrowest set needed for the operations you enable. You get the full list in writing before signing. If you do not enable leave, the app does not ask for calendar access.
We have hybrid AD, not Entra alone.
We check that on a call. Sync scenarios are supported, but grant order can differ and we want that clear before the contract, not after.
What if we cancel after a year?
Permissions stay — they live in your systems, not ours. You get an export of request history; we remove the app from the tenant.
Who can approve requests?
Whoever is accountable for that matter and whom you name at onboarding: a manager, a project owner, or someone in IT. The portal does not dictate who that is.
We already have a leave system. Does it make sense together?
If it works and nobody complains, keep it and we connect the rest. Value appears when leave lives in one tool, access goes by email to IT, and cover lives nowhere. Then one window with one approval saves more than a leave module alone.
Who runs this on our side: IT or HR?
Both, each their part. HR sets who approves leave and the rules. IT names resource owners. Employees see one window and do not need to know who configured what.
We already have Jira Service Management or a helpdesk. Why another portal?
Helpdesk finishes where we start. The ticket closes, but someone still had to open the Microsoft console and click by hand. Here approval is execution: after the owner clicks, nobody enters anywhere. If you have JSM, we can keep it as the intake and plug in underneath as the layer that executes.