SELF-SERVICE PORTAL · ACCESS AND ACCOUNT REQUESTS · COMPANIES OF 50-500 PEOPLE · MICROSOFT 365 · ATLASSIAN
Access to a folder sits in someone's inbox, and your admin spends another hour clicking the same thing in Entra Admin Center. Aclovo is a self-service portal for companies on Microsoft 365 and Atlassian. People pick a request from the catalogue, the resource owner clicks Approve, and the portal makes the change in Entra ID, SharePoint, Exchange, Jira and Confluence. No ticket gets raised, because there is nothing left to raise one for.
Pick one thing that still goes by email. We run it through the portal live. No company deck.
A product of Interactive Workspace Sp. z o.o.
We do not replace your ticketing system. We take the requests that would end with the same clicks in an admin console.
CUSTOMERS
SYSTEMS
REQUEST CATALOGUE
Folder access, an account for a new hire, a mailing group, time off. Today they arrive by email or as another manual job in the Microsoft console. In Aclovo they all take the same path: an employee picks a request, the resource owner approves, a connector makes the change in the target system. IT never touches it. One request can trigger several of these at once, across several systems.
One request, several approvals, several systems. The portal creates the Entra ID account, adds security and mail groups, grants SharePoint sites, adds the Jira project and the Confluence space. Each step is approved by that resource owner. Execution is automatic.
One request disables sign-in in Entra ID, revokes sessions, removes the person from security and mail groups, and takes back SharePoint, Jira and Confluence access. No checklist in Excel.
You update the manager in Entra ID. In the same run you revoke old access and request the new set: security groups, mail groups, SharePoint sites, Jira, Confluence.
Each scenario is built from the catalogue below. You compose it for your process, not our template.
Turns off sign-in when someone leaves or the account should pause. Active sessions end at once. Data stays.
You add yourself or a team to a group that grants resource access. The group owner or an administrator approves, the portal adds members in Entra ID.
You pick a site or a folder. The portal checks every file and folder and lists public shares, shares outside the company and shares inside the company: when, by whom and for whom.
You pick a service project and a list of emails or UPNs. You can also choose an organization. The portal adds the customers in Jira Service Management. No ticket to IT.
One request, one space. The portal finds pages with a public link or access without a login. The result comes by email and as CSV.
You pick a person and a license they no longer need. After approval the portal removes it in Microsoft 365. The seat goes back to the pool.
The portal lists people and groups that currently have a role on the project. You mark who to remove. Scope follows the requester permissions: without on-behalf rights a person removes only themselves. That is a control, not a product limit.
You give a name and the people who need access. The portal creates the site and sets an owner who then approves access requests.
You report that access is no longer needed. After approval the portal removes the permissions and records who took them back and when.
You report vacation, sick leave or another absence. After the manager approves, the portal sets the auto-reply and mail forwarding for that time.
You add yourself or other people to a mailing list. No helpdesk thread asking to join the team address.
You update who reports to whom. Entra ID structure and leave-approval paths in the portal switch at once.
You pick a service project and customers who no longer need access. After approval the portal removes them from Jira Service Management.
You pick a Jira group and a list of people. The group owner or an administrator approves. The portal adds the members in Jira Cloud. No ticket to IT.
You remove yourself or people who changed team. The group owner approves, the portal drops membership in Entra ID and records who took it back and when.
You pick a group, see the current owners, uncheck people and add new ones. After approval the portal saves the change in Exchange. No ticket to IT.
A security group the team no longer uses disappears together with the permissions it granted. The group owner approves.
You pick an existing project as a pattern, a name and people. After approval the portal creates the project in Jira Cloud. No ticket to IT.
You pick a person and an instance. After approval the portal shows which Jira, Jira Service Management and Confluence licenses they hold. The result comes by email and as a CSV.
You pick the Atlassian instance, the space and people, and set permissions with the same grid as in Confluence: a role or individual permissions. The space owner approves. After that the portal grants them in Confluence, with no ticket to IT.
You give a file name or a path. The portal searches every site and recycle bin in the tenant and emails the result. No more tickets that someone cannot find a file.
You pick a team, see the current owners, uncheck people and add new ones. After approval the portal saves the change in Teams. No ticket to IT.
You pick a name, a key and people. After approval the portal creates the space in Confluence. No ticket to IT.
You pick a person. After approval the portal shows which Microsoft 365 licenses they hold. The result comes by email and as a CSV.
You pick a person. The portal lists every site and folder they can access, including grants through a group. Ready material for an access review.
You remove yourself or people who changed team. After approval the portal drops them from the group in Exchange.
Remove people from a Jira group when access is no longer needed. The group owner or an administrator approves.
See which Confluence pages are open to the world: a public link or access without a login. The list is grouped by space, with a CSV to download.
You pick a team that is no longer needed. After approval the portal removes it from Microsoft Teams together with the Microsoft 365 group. No ticket to IT.
You close a project for good. The portal moves it to the Jira trash. No ticket to IT.
You pick a group in Jira Cloud. After approval the portal shows the people list. The result comes by email and as a CSV.
You report a site the team no longer uses. The owner approves, the portal deletes it in SharePoint.
You pick an existing service project as a pattern, a name and people. After approval the portal creates the project in Jira Service Management. No ticket to IT.
You close a service project that is no longer needed. After approval it leaves day to day work. No Jira Admin.
Name, job title, phone, office address. The change goes to Entra ID and shows in Outlook and people search.
You pick a site or folder, see the current owners, uncheck people and add new ones. After approval the portal saves the change. No ticket to IT.
You pick the type: a distribution list (one address, many recipients, no mailbox) or a Microsoft 365 group (its own mailbox and calendar). The portal creates it in Exchange.
You create a security group and name its owner at once. From then on that owner approves access requests, not IT.
You pick a site, library or folder and the level: read or edit. The site owner approves, the portal grants access in SharePoint. IT never touches the request.
You report an account the team no longer uses. After approval it goes to the Entra ID recycle bin, where it can still be restored.
You pick a person and a service project. After approval the portal adds them in Jira Service Management. No ticket to IT.
You enter a name, owners and members. After approval the portal creates the team in Microsoft Teams, with a group address and private or public visibility. No ticket to IT.
An address nobody uses any more leaves Exchange after the owner approves.
You pick a space, and a restricted page if needed. The portal lists only people and groups that actually have the permission. Scope follows the requester permissions: without on-behalf rights a person removes only themselves.
You close a service project for good. The portal moves it to the Jira trash. No ticket to IT.
You close a project that is no longer needed. After approval it leaves day to day work. No clicking in Jira.
You close a space that is no longer needed. After approval it leaves day to day work. No clicking in Confluence.
You pick a person and a service project they no longer need. After approval the portal removes the role in Jira Service Management.
You see how many seats are free. You pick a person and a product. After approval the portal assigns the license in Microsoft 365. No ticket to IT.
You close a space for good. The portal deletes it in Confluence. No ticket to IT.
You pick the Atlassian instance, the project, people and a role. The list shows only projects open for requests. The project owner approves, the portal grants roles in Jira.
You pick a person. The portal checks their OneDrive and lists public shares, shares outside the company and shares inside the company: when, by whom and for whom.
You pick a person and a product: Jira, Jira Service Management or Confluence. After approval the portal grants the license through an Atlassian group or through Microsoft when the group comes from an IDP. No ticket to IT.
You pick a service project and an organization. After approval the portal shows who belongs to it. The result comes by email and as a CSV.
A request for an account in Microsoft identity, formerly Azure AD: name, company-domain sign-in, manager. After approval the portal creates the account in Entra ID and sends a temporary password.
You pick a person. The portal shows the mail groups they belong to as a member or owner, including membership through another Entra group. Ready material for an access review.
You pick a person and a license they no longer need. After approval the portal removes it from the Atlassian group or from the Microsoft group when the source is an IDP.
Turns sign-in back on after an absence or after a block is cleared. One approval, execution in Entra ID.
You pick people from the directory. An administrator approves. Atlassian sends the activation email. No password in the portal and no ticket to IT.
No processes match your search.
Who asked, for what, who approved, at what time, and what the connector did in the target system. The same record is your access review evidence and the answer to who granted that access.
Cannot find your case? We take one ticket that keeps coming back to your admin and walk it in the portal from request to execution in the tenant.
Show me on my process. 30 minutesSECURITY
Aclovo is not another place where you store permissions. The connector grants them in your tenant and they live there, including the day you stop using us. The app only asks for the consents the operations you switch on actually need.
Questions about a specific consent or the data processing agreement?
Show me on my process. 30 minutesMODEL
The same flow for a single folder and for a full onboarding. The only difference is how many approvals it collects and how many systems it visits.
No hunt for who to email, and nothing left to remember on the side. They pick from the list: SharePoint site access, a security group, a mail group, an Entra ID account, a Jira project, a Confluence space, leave. The form asks only what the connector needs to make the change.
A department manager knows whether Anna should see the contracts folder. Your admin does not, and should not click Approve for someone else's data. You name who owns what once. After that each request routes itself, and your team is not on that path.
After approval nobody opens Entra ID Admin Center or the SharePoint panel. The connector grants site access, adds a group member, creates the account and mailbox, or turns on auto-reply. If an operation fails, you see it on the request with the message from the system.
Onboarding is not six separate requests to six people. It is one request: the manager approves the scope, the SharePoint site owner their site, the Jira project owner their project. The portal then creates the Entra ID account, the Exchange mailbox, adds groups, and grants SharePoint, Jira and Confluence. Each operation has its own status: done, waiting, failed.
Want to see this run on your own process?
Show me on my process. 30 minutesCOMPARE
Already on JSM or a helpdesk? Keep it as intake. We plug Aclovo underneath as the layer that executes.
Price per company
In every plan: all processes · hosting · onboarding · no per-person or per-request fee.
PLN 12.50 per person at 100 people. Less than one email to IT.
PLN 6 per person at 500 people. Support and training on the same invoice.
A fixed amount after we size the deployment. No per-seat price list.
QUESTIONS
Because JSM closes a ticket. It does not grant the permission. Someone still opens the Microsoft console and clicks. In Aclovo approval is execution: after the owner clicks, nobody enters anywhere. If you want, we keep JSM as intake and plug in underneath.
The portal sits on our servers and we run it, in the same amount, with no module upsell. On your side one thing remains: naming who owns what. After that, traffic goes without you.
You do not have to do it blindly. The app gets only the permissions needed for the operations you enable. You see the list before the contract. You can start with one process and one system, SharePoint alone.
Sync scenarios are supported, but grant order can differ. We check that on the 30-minute demo, before the contract, not after.
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.
The first process is part of onboarding included in the plan. We set the date on the 30-minute demo, before you sign. We do not leave it for later.
No. We join additively: the portal reads existing permissions and adds new ones. We do not remove anything we did not grant.
Permissions stay. They live in your systems, not ours. You get an export of request history. We remove the app from the tenant.
Yes. You compose a chain from matters already in the catalogue. A new-hire example: the person's data, a Microsoft 365 account, SharePoint, a mail group, Jira and Confluence. Each step waits for its owner. After they agree, the portal makes the change and continues.
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.
Contact
Not a company deck. Tell us which matter still goes by email: folder access, onboarding or leave. We run it through the portal live. Aclovo is run by Interactive Workspace Sp. z o.o.
Interactive Workspace Sp. z o.o.
+48 451 522 320
contact@interactive-workspace.com
interactive-workspace.com
Aclovo