A worker's work account: what is it?
A Delos worker acts under an identity. The work account is that identity: the Microsoft 365 or Google Workspace account the worker uses to read and send email, manage its calendar, access its files, and talk on the company messaging.
This article explains what this account contains, how Delos links it to services, and what changes for the worker depending on whether it has one or not.
The key idea
A worker is a new arrival. Like any colleague, it needs its own account with your provider, with its own address, mailbox, calendar, and file space.
Everything it sends then carries its name, not that of the manager who configured it, and every action it takes is traced under its identity in your logs.
Three workspaces are possible:
| Workspace | What it brings | What you need to create |
|---|---|---|
| Delos (default) | A Delos email address, calendar, drive, and Ping messaging, active immediately | Nothing |
| Microsoft 365 | Outlook, Outlook Calendar, Teams, OneDrive, and SharePoint, under an account from your tenant | An account in your Microsoft admin console |
| Google Workspace | Gmail, Google Calendar, Google Drive and, under conditions, Google Chat | An account in your Google admin console |
A worker on Microsoft 365 or Google Workspace keeps its Delos address: it continues to work as a backup and recovery address.
What the work account covers
The work account is a single account that carries several services. A single connection gives Delos access to each of them, within the limits of what has been approved.
| Provider | Services carried by the work account |
|---|---|
| Microsoft | Outlook (mail and calendar), Teams, OneDrive, SharePoint |
| Gmail, Google Calendar, Google Drive, Google Chat |
Each service has its own toggle in the worker's Work account tab. Turning off a service keeps the account connected but removes the corresponding tools from the worker.
The calendar follows the mail permission: disabling Mail pauses both.
How Delos stores it
Technically, a work account consists of two objects:
- The connection: the OAuth token obtained from Microsoft or Google, with the account address, the application used, and the exact list of granted permissions. There is one connection per account, regardless of how many services it serves. Token refresh happens on this connection, once for all services.
- The bindings: one per service, which says "this worker uses this connection for Outlook", "for Teams", etc. Each binding carries its own toggle and settings (shared mailboxes, watched folders, trigger rules).
A binding has a role: workspace for the work account, connector for a shared account (see the article Work account vs shared accounts).
A worker has only one work account per provider, and an address can only be the work account of a single worker.
What runs on the work account
As soon as a work account is connected, several background mechanisms use it without the worker acting:
- The mailbox is synchronized in Delos and watched: an incoming email can trigger the worker.
- The calendar is read and written under its identity, including creating online meetings.
- The chosen file sources (SharePoint sites, Google Drive) are synchronized into its Drive, according to the mode chosen per source: resynchronized copy, offline copy, or live read.
- Teams: its conversations and channels are mirrored in the Communication tab, and messages written to it can wake it according to trigger rules.
When the worker uses a tool (send an email, post to Teams, read a file), it acts with the work account first. A shared account is only used if the service is not covered by the work account, or if the task explicitly names it.
Permissions
Delos only asks the provider for what your organization has approved.
On the Microsoft side, an administrator grants permissions once for the whole organization in Settings → Workspace policies, service by service and level by level (read, read and write). A worker's work account cannot get more than what is granted there: if a permission is missing, the connection says which service is still awaiting approval.
On the Google side, there is no organization-wide consent: the account connection is enough, unless an administrator has restricted third-party apps, in which case they must mark Delos as approved in their console.
Granted permissions are stored on the connection. When Delos starts requesting a new permission (for example after adding a Teams feature), the Policies page signals that consent needs updating. Nothing is cut off: the account keeps working with what it has, and only the new feature awaits the update.
Lending your own account: avoid it
It is possible to connect your own account as the worker's work account. Delos clearly flags it: "This work account is yours".
The worker then acts in your name, emails leave from your address, your colleagues see your name, and its actions appear as yours.
This is acceptable for a trial, not for a production worker. Give it its own account as soon as possible.
Change or disconnect
- Changing workspace does not disconnect anything by itself. Delos asks you what happens to each former account: keep it as a shared account (the worker keeps reading it, but no longer acts under that name) or disconnect it.
- Disconnecting the work account removes its mailbox, calendar, and synchronized sources, revokes the receiving subscriptions (mail, Teams), and deletes the connection. Nothing is revoked at the provider: the account still exists in your tenant, it is up to you to close or reassign it.
In summary
| Question | Answer |
|---|---|
| How many work accounts per worker? | One per provider, Microsoft or Google |
| Can one address serve two workers? | No, not as a work account |
| What does a connection cover? | All the provider's services you enable |
| Who grants Microsoft permissions? | An administrator, in Workspace policies |
| What happens without a work account? | The worker lives on the Delos Workspace, and can use shared accounts |