Docs: System guides
Read Google Workspace into Maplith
On this page
Best path
Recommended: your agent fetches it. Many agents already reach Gmail and Drive, and a first map needs a few weeks of a few labels and the folders with procedures. For a daily refresh, Maplith's own Google connector reads the labels and folders a rule selects, once it is switched on for the workspace.
Try the paths in this order:
- Your agent fetches it, with the access you already gave it. Connectors a vendor or client page confirms: Gmail and Google Drive connectors in Claude; Google Drive connector in ChatGPT. The agent reads the recent mail of the labels you name, a few weeks each, and the documents of the folders that describe how work is done, and leaves out anything private or personal. It only reads; it should not send, label or edit.
- Maplith reads an MCP server you already run. No official MCP server confirmed. The agents' own connectors are the way an agent reads Gmail and Drive. Maplith reads a server that serves MCP resources and takes a token a person types under Data sources › Systems, such as one your IT runs for a database.
- Export files, the fallback that always works. See the export steps below.
- Maplith’s own integration. Built, and switched on per workspace. Ask Maplith at [email protected] to switch it on for yours. See Maplith’s integration below.
Datasets that make a good map
| Dataset | One row is | Key columns | Joins to |
|---|---|---|---|
| Mail by label | One message in a chosen label: when, from and to whom (addresses, which the masking tries to mask), its subject and body, and the thread it belongs to. | label, message id, thread id, date | The orders, cases and invoices the messages name; the processes the map finds in other systems by the same reference. |
| Documents | One Google Doc, Sheet or text file in a chosen folder: its name, when it changed, and its text or rows. | file id, folder, name, modified time | The processes the procedures describe; the systems they name. |
| Notices from other systems | One message a system sent (an invoice, a report, an alert), recognised by its sender. | sender domain, subject, date | The system that sent it, which often is a system not yet shared with Maplith. |
Columns are named, never their values. Maplith tries to mask personal data such as email addresses, but that is best effort: you decide what goes in.
The access to give
Who usually has the rights: A Google Workspace super administrator, who creates an Internal OAuth client in the organisation's Google Cloud project, and the account whose mail and Drive are read, who consents once.
Choose the narrowest access that covers the data:
gmail.readonlydrive.readonly
Where to click:
- In the Google Cloud console of the organisation, create a project or choose one, and enable the Gmail API and the Google Drive API
- Under the OAuth consent screen, choose the user type Internal, so only accounts of the organisation can consent and no Google review is needed
- Add the scopes gmail.readonly and drive.readonly, and nothing else
- Create an OAuth client of type Web application, and keep its client id and secret for the next step, never in a chat
A key or token made here stays in the tool that reads the system, never in a chat. Maplith asks for one only under Data sources › Systems in the app.
Export steps
Format: MBOX for mail and the documents' own formats for Drive, from Google Takeout Date range: The last 3 months
- Open Google Takeout with the account whose mail is to be read
- Choose Mail with only the labels that carry work, and Drive with only the folders that describe how work is done
- Create the export and download it when Google sends the link
- Remove anything private or personal before uploading the files under Data sources › Scans
How much data
About 500–10,000 messages a month (an estimate). Estimate for a small company, not a measured figure: notices from other systems add most of the volume.
An agent that reads rows through a chat reads every one of them, about one token per four characters. Above a few thousand rows a dataset, or for a daily refresh, an MCP server or an export is the better path.
Maplith’s integration
Status: Built, and switched on per workspace. Ask Maplith at [email protected] to switch it on for yours.
How to connect
- Create the Internal OAuth client with the two read-only scopes, as under “The access to give” above
- In Maplith, open Data sources › Systems and click Connect Google Workspace
- Give the client id and secret there, and sign in with the account whose mail and Drive are read to consent; Maplith seals the result and never shows it again
- Click Test connection to see which labels and folders it will read and which it leaves out
The permissions it asks for
| Permission | Why |
|---|---|
gmail.readonly | reads the messages of the labels the rule selects; it cannot send, delete or change a message |
drive.readonly | reads the documents of the folders the rule selects; it cannot change or share a file |
What it reads
- Mail in the selected labels within the scan window, as a mailbox export read during the scan and deleted when it ends
- Google Docs as text, Google Sheets as CSV, and plain text files in the selected folders, within size limits
- What reaches the map: the labels and folders as sources, the processes the mail and documents show and the systems they name; playbooks describe the process, never quote a message
What it never reads or does
- Spam, trash or drafts, a label named Private or Personal, or a file in a folder so named or in any folder below one
- Mail from, to or copied to a domain the rule denies, or a file owned by one: dropped before it is written, and only counted
- Sending, labelling, deleting or changing anything in Gmail or Drive
Choosing what is read: Maplith reads the inbox and sent mail and the documents changed within the scan window, except the labels and folders its rule leaves out (a folder with everything below it) and the denied domains. When the rule names a shared drive or folders, it reads documents only there and in their subfolders. A person changes the labels, the folders and the denied domains under Data sources › Systems; that choice is theirs from then on.
What Maplith sets up once it is connected
Maplith sets these up itself. You correct them; you never have to approve them first. If the system is disconnected, the playbooks Maplith set up and nobody changed are taken out of use, and put back when it is connected again.
Signals it raises:
- Something Maplith relies on stopped working (checked on a schedule): the daily check finds the consent withdrawn, the client deleted or a scope missing
- A connected system grew or shrank (checked on a schedule): the connection offers at least a quarter more or fewer resources than at the last check
- A process is no longer found (checked on a schedule): a recurring process the map found in the mail has not happened within its usual interval
- New finding (checked on a schedule): the mail names a system the map does not have, or a hand-off that happens out of sight of every shared system
Checks:
- Connection check (every 12 hours): checks that the consent still holds and the labels and folders are readable, never a message
- Selection rule (every scan): states which labels and folders are read and which are left out, and how many items the denied domains dropped, on every scan
Suggested playbooks:
- Reconnect Google Workspace. Starts when the Google connection's “Something Maplith relies on stopped working” signal is raised.
- Share the system the mail names. Starts when a finding says the mail names a system the map does not have.
Schedules:
- Read Google Workspace (with the workspace's scan schedule, daily or weekly): the playbooks and the processes stay current with how the work is actually done
Always
- Read-only, and never a credential sent to Maplith through a chat.
- The same recent period, a few months, from every system.
- You decide what goes in.
Sources
Written from public documentation, last checked 2026-10-14: