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
Google 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