Integration permissions

Choose the service and access you need before continuing to the provider’s consent screen. New native connections start with read access. Drafts, labels, calendar changes, and supported Microsoft file changes require a deliberate additional selection. Google Drive defaults to read/import access; explicitly selecting Upload and share files requests full Drive access. Review both Tendor’s access summary and the provider’s consent screen. Microsoft services share a Microsoft 365 account connection. Gmail, Google Calendar, and Google Drive have separate service connections, but may share an OAuth application. Separate buttons do not prove separate provider grants or independent revocation. If you grant Mail or Calendar but decline SharePoint, the authorised services can connect successfully while SharePoint remains unavailable.

​

Requested permissions

The tables below describe new permission requests. Existing grants can be broader. Microsoft adds User.Read for account identification and offline_access for background access. Google adds openid, email, and profile; Google scope names below have the prefix https://www.googleapis.com/auth/.

​

Microsoft

Read scopes can accompany write scopes where background notifications require them. No selection in this table requests application permissions, Mail.Send, Mail.Send.Shared, User.Read.All, Directory.Read.All, or FullControl. Existing consent must still be inspected separately. Microsoft distinguishes delegated access, which acts with a signed-in user, from application access without a user. OneDrive personal accounts also include files shared with that user under Files.Read and Files.ReadWrite. See Microsoft’s permission definitions.

​

Choose and manage multiple sites

1. Choose the SharePoint permission and complete Microsoft sign-in once.
2. In Microsoft 365 account settings, open Manage SharePoint sites. Browsing mode supports search and multiple checkboxes. Restricted mode accepts known approved site URLs or IDs; your Microsoft administrator must grant access first.
3. Save the sites Tendor should read. No sites are read when the selection is empty.
4. Use the same account setting to add or remove sites later, without another OAuth connection. Removing a site stops future access and syncing in Tendor; files already imported into projects are kept.

The personal account owner manages its restricted selection. Organization owners and administrators manage shared account selections. Other team members cannot enable broad consent or change those shared sites.

​

Google

Google does not provide an ordinary Gmail draft or message-modification scope that excludes sending. Tendor action availability and review rules do not reduce the authority of the provider token. See Gmail scopes and Calendar scopes. Google’s drive.file provides access to files created by or explicitly shared with an application. It is not the permission used by Tendor’s automatic Drive indexing. Selecting a folder in a workflow does not restrict a drive or drive.readonly grant to that folder. See Drive scopes.

​

Microsoft administrator setup

Before connecting a dedicated tender mailbox, an Entra administrator should:

1. Record the intended tenant, application/client ID, dedicated account, approved services, and exact permissions. Use a non-administrator account that owns the tender mailbox. A separate user’s shared mailbox is a different permission model.
2. Review the enterprise application’s existing delegated grants and application permissions. Remove obsolete broad grants through the provider’s administration process before claiming that the account has been narrowed.
3. In Entra Enterprise applications → Consent and permissions → User consent settings, disable user consent or apply an administrator-managed consent policy that disallows broader permissions. Check that the dedicated account has no role that can grant consent itself.
4. Require assignment to the enterprise application and assign only approved accounts. Approve the reviewed permission set; do not approve a suite-wide permission list without inspecting it. An admin consent workflow can collect requests without letting users approve them.
5. Connect the dedicated account in Tendor. For mailbox-only use, select Outlook Mail and leave Calendar, OneDrive, and SharePoint unselected.
6. Compare the actual grant with the approved list. Run the positive and negative access checks below before accepting the configuration.

These controls govern future consent. Existing grants are not removed by disabling user consent. See configure user consent and assignment and admin consent.

​

Dedicated mailbox and one SharePoint site

​

Configure approved-site read access

This profile uses delegated Sites.Selected and supports reading and importing documents. It does not expose SharePoint writes or tenant-wide site search. Microsoft enforces the intersection of the application’s site grant and the signed-in account’s rights. Tendor also binds discovery, tool reads, and file synchronisation to the saved site selection. Sites.Selected alone does not grant access or specify a read/write role.

1. Identify the exact Microsoft OAuth application/client ID used by this Tendor environment. An Entra administrator must review both per-user and tenant-wide grants for this app, including historical Files, Sites, Mail.Send, shared-mail and directory grants. Remove incompatible grants; selecting a narrow scope does not revoke them. The current connector uses Tendor’s registered client, not a customer-supplied client ID. If your tenant cannot remove incompatible grants for that client, do not accept this profile as isolated.
2. Using the administrator’s independent provisioning tool, resolve the approved site’s canonical ID, in the format hostname,site-collection-UUID,web-UUID. Do not grant Tendor broad site search merely to discover this ID.
3. Grant the Tendor application’s client ID a read role on exactly that site:
   POST https://graph.microsoft.com/v1.0/sites/{approved-site-id}/permissions
   Content-Type: application/json
   
   {
     "roles": ["read"],
     "grantedToIdentities": [{
       "application": {
         "id": "TENDOR-APPLICATION-CLIENT-ID",
         "displayName": "Tendor"
       }
     }]
   }
   
   This is an administrator operation performed with a separately authorised administrative identity/tool. Its provisioning permissions must never be assigned to Tendor’s runtime application. In particular, do not grant Tendor FullControl so it can provision itself. See Microsoft’s site permission creation requirements.
4. Give the dedicated tender account access only to the intended site and its own mailbox. Consent to delegated Sites.Selected plus identity/background permissions, and optionally Mail.Read. Apply the Entra consent and assignment restrictions above. Do not grant Files.*, broad Sites.*, shared-mail, sending, directory read-all or user read-all access to this profile. Tenant-wide consent to Sites.Selected does not change other connections: a managed account reads only its saved site selection.
5. In Tendor, choose Read approved SharePoint sites and continue to Microsoft. Select the approved site URLs or IDs in Tendor after sign-in. Clear Read email if only site access is needed. Existing OneDrive or broad SharePoint grants prevent selecting this profile; follow the disconnect/revoke/Add account sequence first.
6. Tendor verifies every selected site with Microsoft before saving the selection. Missing site permission or an incorrect URL/ID produces a setup error. If Microsoft declines the optional site permission but grants the requested mailbox, Mail connects while SharePoint stays unavailable. Site files synchronise through periodic delta polling; this profile does not request broader drive-notification permissions.
7. Perform the positive and negative tenant tests below. A successful read proves access to that resource; it does not prove the app has no other site grants, only the read role, or no historical broad consent. Retain the administrator’s grant inventory and provider-denial evidence.

Use Manage SharePoint sites to change the selection without reconnecting. An administrator can grant several sites to one account/app; a new grant is needed only for a site not already approved. Microsoft grant revocation stops subsequent provider reads. Existing imported copies have a separate lifecycle. Tendor does not infer write permission from Sites.Selected; assign read for provider-enforced read-only access.

​

Read-only site browsing

For the self-service experience, a Tendor organization owner/admin connects a shared Microsoft account and explicitly chooses Browse and choose SharePoint sites. Approve delegated Sites.Read.All, keep application permissions and broad file/write grants removed, then choose multiple sites in Tendor. Only administrators manage the shared selection; team members use that account’s selected files. This shared connection records the workspace’s browsing approval. Temporary credential expiry does not erase the approval; disconnecting the shared account withdraws it for future connections and reconnects. Provider consent remains a separate Microsoft administrator action. Existing mail accounts may retain already-approved read-only consent without acquiring SharePoint access. Do not combine broad consent and a claimed restricted Sites.Selected token within the same tenant/app grant.

​

Google Workspace administrator setup

Use Security → Access and data control → API controls → Manage third-party app access to inspect the OAuth client ID. Configure Specific Google data with only the approved scopes, including the required sign-in scopes, for the intended organisational unit. A Trusted designation allows broader access and is not equivalent to a scope allowlist. See Google Workspace app access controls. Connect the intended account and check its calendar sharing, shared-drive membership, and accessible files. Account restrictions are not a per-folder grant. Personal Google accounts do not have Workspace administrator policy controls. Google verification and restricted-scope security assessment requirements still apply; selecting fewer services does not replace them.

​

Existing connections, reconnecting, and revocation

Changing the selection does not revoke an existing provider grant. Reconnect requests supported stored service permissions again. Accounts retaining broad Microsoft file/write grants or unapproved site-wide read grants cannot reconnect: disconnect in Tendor, revoke the provider grants, then add the account with the approved permissions. Revoking at the provider alone does not clear Tendor’s stored scope record. The provider may return only part of the request. Tendor uses the returned grant to determine which capabilities are available. For example, Mail or Calendar can remain connected when SharePoint is not granted. Enabling another supported capability requests additional consent. Microsoft can return broader permissions from historical consent even after a new narrow request. Tendor rejects broad file/write grants and unapproved site-wide read grants on that new connection; ask an administrator to revoke them first. Existing connections are not automatically disconnected by this change. Use Reconnect on an existing account to add or restore supported access. If you use Add account and choose an identity that is already connected, Tendor keeps its existing connection and asks you to use Reconnect. Microsoft consent is cumulative for an application. Its refresh tokens are tied to the user and client, and may obtain access for other already-approved resources. See incremental consent and refresh-token behaviour. Google’s combined authorisation can include permissions granted through different clients in the same API project. Revocation can affect other connected Google services using that grant. Tendor does not opt new requests into automatic incremental scope combination, but that does not erase historical consent. Inspect actual grants when reconnecting. See Google incremental authorisation and revocation. To narrow an existing connection, plan the interruption and follow this order:

1. Disconnect the account in Tendor.
2. Revoke any remaining grant at the provider. Microsoft requires this separate administrator action; review Google grants and related service connections too.
3. Use Add account to create a new connection, selecting only the approved access.

Do not use ordinary Reconnect as the downgrade step: it retains supported stored scopes and rejects unapproved broad Microsoft scopes, including when provider consent was revoked first. Recheck related service connections after Google revocation. Disconnecting external access does not by itself delete files already imported into projects; review those copies separately. Microsoft disconnect removes Tendor’s local credentials and stops its connection; it does not remove the Entra consent grant or guarantee immediate invalidation of an already-issued provider token. Remove that grant separately in Microsoft administration. Google token revocation can also invalidate sibling service connections that share the same grant. An unconnected capability remains unavailable to Ask AI and routines until authorised. A connected read-only account does not authorise writes. For expired access, review the request before using Reconnect to restore access. To reduce permissions, use the disconnect, provider revocation, and Add account sequence above.

​

Other connected applications

Composio-brokered integrations use separate enterprise applications and consent grants. The Teams toolkit can post channel messages; Microsoft 365 native mail permissions above do not describe that application’s authority. Administrators should block unwanted Composio/Teams enterprise applications and approve them separately only when those features are intended.

​

Access verification and audit evidence

Run this checklist with an authorized test account and sites in a tenant with a SharePoint Online license. Record the results for your tenant; repository tests and provider documentation do not demonstrate its effective restrictions. Use approved test resources and a controlled recipient. Record a permitted resource and a known resource outside the approved set. A missing or invalid resource ID is not sufficient evidence of denied access. Additional exercised boundaries: For each test, record UTC time, deployment revision, tenant/account/client IDs, requested and granted scopes, resource IDs, operation, response status, and provider request ID. Retain no access tokens, refresh tokens, message bodies, or file content in this evidence sheet. Microsoft Graph activity logs include application/user identity, request URI, scopes, response status, and request identifiers. They require Entra P1/P2 and a configured Azure logging destination. Filter by the reviewed app and user, and correlate positive and denied requests. Sign-in and consent logs describe authentication and authorisation changes; they are not a complete file-access history. See Microsoft Graph activity logs. Tendor does not currently claim a complete customer-visible history or export of every integration item read and write. The assessment records above and provider logs are evidence for their recorded operations; they do not constitute that product capability.