| Item | Detail |
|---|---|
| Version | 1.0 |
| Product | Umitake Outlook Connector for Kintone |
| Status | Forms part of our Privacy Policy |
The most important fact: email bodies, subjects, and attachments pass through our servers but are never stored on them. They are stored in your kintone.
It follows that we cannot retrieve your past emails.
Unlike our other plugins, which only distribute JavaScript, this product runs a continuously operating server that processes your email data. This document therefore sets out exactly what we hold and for how long.
For the CDN and license verification common to every product, see the shared infrastructure document.
This document describes what is implemented, not what is intended. Every retention period stated here is enforced by deletion code that runs daily.
1. Our Role
You — the organisation using kintone — are the controller, and we are the processor.
We receive your email data and connection details on your instructions and process them in order to write them into your kintone. You determine the purpose and scope of that processing.
If your IT department needs this document for vendor due diligence, it is written to be used directly as review material.
2. Data Flow
Your Microsoft 365 ──(1)──> Our server (Fly.io, USA) ──(2)──> Your kintone
│
├──(3)──> Sentry (error monitoring)
└──(4)──> stdout (Fly logs)
| # | What flows | Stored |
|---|---|---|
| (1) | Email bodies, subjects, attachments, recipients, calendar events | In memory only; discarded once processing completes |
| (2) | The same (written into your history app) | Stored in your kintone (you decide how long) |
| (3) | Exception types, stack traces, error codes. Bodies, attachments, subjects, and tokens are never sent. Email addresses are masked | Per Sentry's retention |
| (4) | Processing records, with the same masking and removal as (3) | Fly does not retain these persistently (no log drain is configured) |
Why the data passes through our server
Consolidating the mail of several staff members into a single record requires a server to hold each user's token and fetch across all of them. A browser-only architecture cannot deliver this feature at all.
3. What We Store
Not a single piece of email content is stored. We store only connection and synchronisation state.
| Table | Contents | Personal data |
|---|---|---|
tenants | kintone domain, Microsoft tenant ID, feature flags, consented scopes, shared token (encrypted), license key (encrypted) | Domain (organisation-identifying) |
kintone_apps | kintone API tokens for the history app and others (encrypted) | — |
user_connections | Per-connection refresh token (encrypted), kintone user ID / display name, Microsoft 365 email address, granted scopes | Name, email address |
sync_states | Last sync time per watched target, delta continuation token, consecutive failure count | — |
sync_errors | Failure records (error code, HTTP status, request ID). No bodies or recipients | — |
import_failures | The identifier of a message that failed to import, plus a failure count. No body | Message identifier |
connection_history | Connection and disconnection history (who, when) | Email address, kintone user ID |
calendar_events | Event ID and the creator's display name | Display name |
auth_nonces | Single-use token for starting a connection | kintone user ID / display name |
On encryption. All tokens are stored encrypted with AES-256-GCM. The encryption key is managed separately from the database, so a breach of the database alone would not allow decryption.
4. What Transits but Is Not Stored
| Passes through our server | Stored on our server | |
|---|---|---|
| Email body | Yes (once on import, once on send) | No |
| Attachments | Yes (same) | No |
| Subject | Yes | No |
| Recipient and sender addresses | Yes | Only the connecting user's own address (user_connections in §3) |
Everything is stored in your kintone (the history app). Reading also happens directly in kintone, so who can read an email is determined solely by kintone record permissions. We play no part in it.
5. Subprocessors and Locations
| Provider | Purpose | Data sent | Data not sent | Location |
|---|---|---|---|---|
| Microsoft (Graph API) | The feature itself | The mail you send and receive, and which items to fetch | — | Your Microsoft tenant |
| Fly.io | Server runtime | Where all of the above processing runs | — | United States (Virginia) |
| Upstash (Redis) | Throughput control | Per-tenant counters only | No email bodies, recipients, or tokens | United States |
| Sentry | Error monitoring | Exception types, stack traces, error codes, masked email addresses (t***@example.com) | Bodies, attachments, subjects, tokens, secrets | United States |
| license.umitake.com (Vercel / Neon) | License verification | kintone domain, license key | No personal data | United States |
Sentry receives doubly scrubbed data
Separately from redaction at logging time, the local variables and request context that the monitoring SDK collects automatically from exceptions are also stripped before transmission. Anything slipping past this point would leave email content in our monitoring environment, so encryption keys, bodies, and attachments are removed wholesale by key name, and any email address appearing in a string is masked.
Where the data lives
Our servers are in the United States (Virginia). Your personal data is transferred outside Japan. Moving to a Japan region is technically feasible but is not the current arrangement.
Sentry and the license verification infrastructure are also in the United States. Note that kintone itself is a service you contract for directly with Cybozu, Inc. and is outside our control.
See the cross-border transfer section of our Privacy Policy for details.
6. Retention Periods
Every period below is enforced by deletion code that runs once a day.
| Data | Retention | How this is enforced |
|---|---|---|
| Email bodies, subjects, attachments | Not stored | Memory only |
tenants (domain, tenant ID, encrypted tokens, encrypted license key) | 30 days after cancellation | Daily automated deletion (implemented) |
kintone_apps (encrypted API tokens) | 30 days after cancellation | As above |
connection_history | 30 days after cancellation | As above |
calendar_events (event ID, creator display name) | 30 days after cancellation | As above |
user_connections (name, email address, encrypted tokens) | Until disconnection (also removed when the tenant is deleted) | As above |
sync_states | Until disconnection | As above |
sync_errors (error codes only) | 30 days | As above |
import_failures (message identifiers) | Until import succeeds or retries are abandoned | As above |
auth_nonces (temporary tokens) | 1 day | As above |
| License records and verification logs | Indefinite | As described in §6 of the shared infrastructure document |
7. On Cancellation and Disconnection
Thirty days after a license becomes invalid, all data for that tenant is deleted — tokens, connection details, and synchronisation state, along with their related rows.
We do not delete immediately so that a customer whose license lapsed temporarily for billing reasons is not forced to have every user reconnect and reconfigure on resuming.
How the 30 days are counted
IT departments ask about this regularly, so we state it explicitly:
The clock starts only when license verification returns an explicit "invalid" result. It does not start when the license server is simply unreachable. If the license becomes valid again, the clock is cleared.
This is deliberate: it prevents a prolonged outage of our license server from destroying customer data.
Emails in your kintone are outside our control and we never touch them. History app records remain after cancellation.
8. What We Cannot See
Customers always check these points, so we state them plainly:
- We cannot see email content. Because it is never stored, we cannot retrieve your past emails.
- We cannot see your kintone records. You issue the API token and you decide its permissions.
- We cannot see who read which email. Reading happens entirely within kintone.
What we can see is the email addresses of connected users and whether synchronisation succeeded.
9. Your Responsibilities
History app permissions are the effective visibility scope for email
This is the single most important design decision for this product.
Because the product consolidates several staff members' mail into one app, anyone who can open the history app can read emails that are not associated with them.
If you want emails visible only through a case or deal record, you must restrict record-level view permissions on the history app itself. This is something you design, not us.
Other
- Preventing misdirected email. Verifying recipients in the send feature is something your own operating procedures must cover.
- Issuing kintone API tokens and setting permissions. You issue the token and decide what it may access.
- Microsoft 365 admin consent and scopes. The permissions this product requests are shown on the admin consent screen for your review.
10. Contact
For questions about this document or help completing a security questionnaire:
Umitake Email: [email protected]
Related: Shared infrastructure · Privacy Policy · Terms of Service