Skip to main content
This page is for your organization’s Microsoft 365 administrator. When you finish, the team can ask the assistant to read and analyze documents, email, calendar, and Teams, within the limits you set here. It takes about 15 minutes. You don’t have to create anything in Azure: the application already exists and is maintained by Morada.ai. You approve it and choose what to release. The product interface is currently in Portuguese, so Morada OS labels below are shown as they appear on screen, with English translations in parentheses.

​
The access model, in four guarantees

Nobody sees more than they already would

All access is delegated: the assistant acts on behalf of whoever made the request, with the permissions that person already holds in Microsoft 365. Permissions ending in .All mean “on behalf of the user, across everything they already reach”, not “access to everything in the company”.

This screen is the organization's ceiling

Whatever is checked here is the maximum anyone in the company can have. Unchecking drops access for everyone, including people who had already allowed it on their own account. It is your revocation lever, and it is immediate.

Checking is not activating

Releasing here authorizes the organization. Each person still allows it on their own account before using it and, to write (send email, create an event, save a file), approves each action at the moment it happens.

SharePoint has two paths

Either you grant access site by site in Microsoft (fine-grained control), or you check the SharePoint rows on this screen (simpler, limited to what each person already accesses). Step 3 covers both.

​
What you do

1

Enable permission management

Connect your own Microsoft account under Conectores > Microsoft 365 (Connectors) and, in the Administração (Administration) tab, enable management.Microsoft asks for your approval on two permissions:The second is the strongest on the list, so here are the safeguards, explicitly:
  • There is no permanent credential: this capability lives only in your session, on an isolated connection, and the AI tools never receive it.
  • The code only writes Morada’s own permissions. There is no path to grant anything else, or to grant it to another application.
  • Your consent policy and directory role remain the real control: without the proper role, Microsoft refuses the operation.
  • The tab does not appear for non-administrators.
On Microsoft’s consent screen the application appears as Morada OS. Managing permissions requires a role such as Cloud Application Administrator or equivalent in Microsoft Entra.
2

Release the permissions your organization will use

Still in the Administração tab, check what makes sense for your company. Each service opens into a list of individual permissions: you can turn on the whole service or pick permission by permission.OneDriveSharePointSharePoint (all sites)OutlookTeamsCheck only what the team will use now. Turning on more later takes ten seconds.
Three operational notes:
  1. Writing depends on reading. Revoking a read permission drops the write that depended on it, and the screen warns you before saving.
  2. Checking Files.ReadWrite.All turns on the SharePoint reads with it. Not a side effect: that permission already grants those reads in Microsoft, and the screen refuses a selection that pretends otherwise.
  3. Changing permissions recreates the authorization from scratch. If an error appears mid-change, check them again: nothing stays permanently half-applied.
3

Grant access to SharePoint sites

Pick one of the two paths.Path A: site by site, in Microsoft. For each site the team should reach, grant the application permission on that site, choosing the role (read, or read and write). The grant is made through the Microsoft Graph API (POST /sites/{id}/permissions). It is the only step that does not happen inside Morada OS, and that is deliberate: this is where you keep fine-grained control. Until a site is granted, it simply does not exist for the assistant.Path B: from the Morada OS screen. Check Sites.Read.All (to read) and Files.ReadWrite.All (to write) in step 2. You don’t have to touch any site: the assistant reaches the sites each person already accesses, never more than that, because access stays delegated.Path A is the most restrictive, path B the most practical. You can start with A and move later.
4

Reconnect your account

Releasing permissions for the organization does not refresh your own session. Go back to Microsoft 365 and reconnect your account once: only then do the tools show as released for you. This applies to everyone, not just you.If you release something and test before reconnecting, it will look like it didn’t work.

​
What each person on the team does

1

Connect the Microsoft account

Under Conectores > Microsoft 365 (Connectors). The first sign-in asks only for identity (name, email, and permission to keep the session). No content access.
2

Use it normally

When a request needs something not yet released, a card appears in the conversation asking for that specific permission, and only that one, always within what you checked in step 2.
3

Approve each write

To send an email, create an event, or save a document, the person allows writing on their own account and approves each action before it happens. This applies to everyone, administrators included.
Microsoft 365 connector screen showing the state of each tool group
Reading documents does not require write permission. The assistant opens .docx, .pptx, .xlsx, .xls, and .csv files already in OneDrive or SharePoint to summarize and analyze them, with nobody having to attach anything in the conversation, and Files.Read (or SharePoint read access) is enough. That includes reading Excel spreadsheets.

​
Before you allow writing to documents

Reading never changes anything. Editing does — and it is worth knowing exactly where that happens before you check Files.ReadWrite or Files.ReadWrite.All. The general rule is reassuring: the assistant creates new files, it does not overwrite the ones that already exist. Ask it for a report based on a spreadsheet and it delivers a new spreadsheet — the original is untouched. And if the name already exists in the folder, Microsoft itself refuses the write; there is no silent replacement.
The exception is Word. The assistant can write a new version over a document that already exists, and this holds in both places: a SharePoint library and the person’s own OneDrive. Whoever asked approves before the change happens, but once approved it applies to the real file.What lands in the file differs, and it is worth knowing which of the two the card is proposing. In a SharePoint document the assistant can start from the current version and change only the part that was asked for, leaving the rest alone. In the other cases it writes over the file with the document it has just generated, and the previous content goes entirely. Either way the old version stays in history.Spreadsheets have no such exception. The assistant always delivers a new spreadsheet and never writes over one that already exists.
Where each safeguard sits, in the order things happen:
1

The assistant proposes the change

Nothing has changed yet. The approval card describes what is about to happen to the document.
2

Whoever asked approves — or doesn't

First safeguard, and it belongs to the person. It is the only moment when the change does not exist yet.
3

A new version is saved over the document

The file now shows the new content, wherever it lives: a SharePoint library or the person’s OneDrive.
4

Version history allows going back

Second safeguard, and it belongs to you. The change lands as a version of the same file, so history is exactly what recovers the previous one, as long as it is turned on where the file lives.
Confirm that version history is turned on in the SharePoint libraries where your team keeps documents. It is the safety net for this permission: with history, a change approved by mistake is a few clicks away from being undone. Without history, it is not.Under Library settings > Versioning settings. Do not assume it is already on: Microsoft lets retention be configured per library — every edit, every save, manual, or none — and your tenant is what decides.Check OneDrive too, the other place a document can be written over. There the history belongs to the file itself, under Version history in its menu, and an administrator can have turned versioning off as well.
Two things worth stating plainly:
  • Recovery is manual and done by a person, in SharePoint or in OneDrive. The assistant does not undo a change on its own, even if you ask it to.
  • Approval is your main defense. History is what exists after something went through; reading the change before approving it is what stops it going through. It is worth reading what the card describes, especially when the document is shared.
If your team only needs reports and analysis, writing delivers new files and never touches the originals — not spreadsheets, not documents. Writing over a file that already exists only happens when someone explicitly asks to change a Word document.

​
How to revoke access

Three paths, from fastest to most definitive:

​
If something doesn’t work

Reconnect your account once. If it persists, tell Morada.ai: a setting in the application is missing, and only we can change it.
Your directory role does not allow managing tenant consent. A role such as Cloud Application Administrator or equivalent is required.
Step 3 is missing: neither of the two paths was completed.
You still need to reconnect your account (step 4).
Expected: the first sign-in does not ask for content. The card that appears in the conversation is how each request unlocks what it needs.
Writing is a separate decision: check that the write permission is enabled in step 2 and that the person has allowed it on their own account.
Ask the person to unlink and connect again. If it repeats, talk to Morada.ai.
Security questions this page doesn’t answer: talk to Morada.ai before approving. One extra question beats a permission released without clarity.