Privacy Policy

Who operates Pillar

Pillar is built and operated by askHermis. This policy covers the Pillar web application and the optional Google integration inside it. Privacy questions, data requests and security reports go to [contact email]; post reaches us at [postal address].

What Pillar stores about you

Your account. An email address, a display name and a profile picture URL, held in Firebase Authentication. If you sign in with Google rather than a password, those three fields come from your Google profile and are used for nothing but identifying you inside the product. A single HTTP-only session cookie called __session keeps you signed in for fourteen days. Pillar runs no advertising, analytics or tracking scripts and sets no other cookies.

Your workspace. One company, one workspace. Inside it Pillar stores what your team writes: pillars, tasks, deals, KPI series, documents and calendar events, plus a member row per person holding their name, email, initials, job title and role.

Google user data: what Pillar asks for

The Google connection is optional and Pillar works without it. It is also personal: each member connects their own Google account to a workspace, and connecting yours gives no one else access to it. Pillar requests four scopes, two of which reach real data.

calendar.events — read and write your calendar events

Permission to read and write the events on the calendar you connect — your primary calendar unless you change it. It does not extend to your calendar settings, to other calendars in your account, or to anyone else's calendar. Pillar uses it to draw a window of your events onto the workspace week grid, and to push events created in Pillar — rituals, meetings and focus blocks — back into Google so they appear where the rest of your week already lives.

drive.file — per-file access, not your Drive

This is the narrowest Drive scope Google offers. It grants access only to files this app itself creates, plus any file you explicitly hand to it. It is not a view of your Drive: every file Pillar did not create is invisible to Pillar — it cannot be listed, searched, opened, or even known to exist.

In practice Pillar uses it for exactly one thing. The first time a workspace needs a data room, Pillar creates a single folder in your Drive named after your company (for example, Acme — Data room), lists what is inside it, creates a subfolder for each section you name, uploads files you add through the app, and moves a file to your Drive bin — never a permanent delete — when you remove its row in Pillar. Because the folder lives in one member's Drive, Pillar shares it with the email address of every member of that workspace — with no notification email — so a teammate's link opens rather than asking for access. Pillar asks for no other folder.

There is one way a file Pillar did not create reaches the room, and you drive it. Because a file you add in Drive itself is invisible under this scope, the data room offers Import from Drive, which opens Google's own file picker. Nothing is listed by Pillar and nothing is read until you choose; picking a file is what hands that one file to Pillar, and from that moment it mirrors like any file uploaded through the app. Everything you do not pick stays invisible.

openid and email — identity only

These tell Pillar which Google account completed the connection, so Settings can show you which account is attached and the sync knows whose calendar it is reading. No other profile data is requested through them.

What Pillar copies into its own database, and why

Google data is mirrored into Cloud Firestore rather than fetched from Google on every page view. Three reasons, all of them structural: the week grid draws Google events and Pillar task due dates on one surface and cannot render half of it; the workspace has to keep working when Google is unreachable or a token has gone stale; and one database listener costs a fraction of one Google API call per viewer per render.

From Calendar

For each event in the synced window Pillar stores the title, start and end times, the all-day flag, one line of context (the location if there is one, otherwise the number of attendees, otherwise the description), the event's description, the guest email addresses so an invite written in Pillar reaches the same people from Google, and the Google event and calendar ids so the two sides stay matched. Guest names and responses are not stored. Each sync replaces the whole window rather than patching it, so an event you delete in Google disappears from Pillar on the next sync instead of lingering as an orphan.

From Drive

For each file in the data-room folder Pillar stores the Drive file id, the file name, a type label derived from the MIME type, the size, the modification time and the Drive link. File contents are never copied. A document row in Pillar is a pointer; opening it opens the file in Google Drive. Files you upload through Pillar stream through the server straight into your Drive folder and are not retained on our side. A file removed from the folder loses its Pillar row on the next sync.

How the connection is secured

Connecting produces a refresh token — the long-lived credential that lets Pillar renew access without asking you again. Before it touches the database it is encrypted with AES-256-GCM using a key held only in the server environment: the key is never written to the database and never reaches a browser. The ciphertext is stored at startups/{workspace}/integrations/{your user id}, a collection whose Firestore security rules deny read and write to every client without exception. It is reachable only by Pillar's own server through the Firebase Admin SDK. Access tokens are short-lived, held in memory for the length of a single request, and never stored at all.

Everything is served over TLS, data is encrypted at rest by Google Cloud, and the tenancy boundary described below is enforced in database security rules rather than only in the interface. If you find a hole, tell us at [contact email].

Who can see what

A workspace is a hard boundary. A request carrying no membership of that workspace is refused at the database, whatever the client asks for — so no other company using Pillar can reach your records.

• You. Your Google connection — which account, which scopes were granted, the data-room folder and the sync timestamps — is shown to you under Settings → Integrations. Connections are personal: a teammate cannot see, use, or disconnect yours.
• Every member of your workspace (owner, admin or member alike) can read the mirrored events and document rows, because once synced they are workspace records like any task. What is shared is what you sync; nothing else about your Google account crosses over.
• Owners and admins can additionally delete documents, pillars, deals and KPIs, invite and remove members, change roles, and edit workspace settings.
• askHermis staff holding a platform-administrator flag can read workspace records. We use it to operate the service — investigating a fault you report, or a security or abuse issue — and for nothing else.

Limited use of Google user data

Pillar's use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Concretely: Google user data is used only to provide the calendar and data-room features described above. It is never sold, never used for advertising or to build a profile of you, never used to train machine learning or AI models, and never transferred to anyone else except as you direct, to the infrastructure providers listed below acting on our instructions, or where the law compels it. No human at askHermis reads your Google data except where you ask us to in order to resolve a problem, or where security or the law requires it.

Where the data lives

Pillar runs on Google Cloud. Firestore — which holds every workspace record, including the mirrored Google data — is provisioned in the eur3 multi-region, meaning it is stored and replicated inside the European Union (Belgium and the Netherlands). Firebase Authentication holds the account record. Cloud Storage holds workspace logos only; data-room files stay in your Drive and are never copied into ours.

Our processors are Google LLC and its EU affiliates (Firebase Authentication, Cloud Firestore, Cloud Storage, and the Calendar and Drive APIs) and [hosting provider], which runs the application servers. We do not add processors quietly: this list moves only with the Last updated date at the top of this page.

How long it is kept

• Workspace content stays until someone in the workspace deletes it, or the workspace itself is deleted.
• The Google integration record — encrypted refresh token included — is deleted the moment you disconnect.
• Mirrored events and document rows are workspace data and survive a disconnect; they simply stop updating. An owner or admin can delete them, or write to us and we will.
• Your account record stays until you ask us to delete it at [contact email].
• Encrypted backups may hold a copy for a short window after deletion before they rotate out.

Disconnecting and revoking access

There are two levers, and they do different things.

• In Pillar: Settings → Integrations → Disconnect. Pillar revokes the refresh token with Google and deletes the integration document, encrypted token and all. Syncing stops at once. Nothing in your Google Calendar or Drive is touched — the data room folder and every file in it remain yours, exactly as they were.
• In your Google account: myaccount.google.com/permissions → Pillar → Remove access. This kills the grant at Google's end, so any credential we still hold stops working immediately.

Revoking at Google alone leaves the — now useless — encrypted token in our database until you also disconnect inside Pillar, so if you want it gone, do both. Reconnecting later starts a fresh consent screen; nothing is carried over from the old grant.

Your rights

For your account record askHermis is the data controller. For the content a team puts in its workspace, askHermis acts as a processor on the instructions of the workspace owner, who decides what is stored and who may see it.

If you are in the EU, the EEA or the UK you have the right to access, correct, export, restrict or erase your personal data, and to object to processing. Write to [contact email] and we will answer within thirty days. You may also complain to your national data protection authority.

Children

Pillar is a tool for companies. It is not directed at children, and we do not knowingly collect personal data from anyone under 16.

Changes to this policy

When this policy changes, the revised version is published here and the Last updated date at the top moves. If a change materially alters what Pillar does with Google user data, we will tell you inside the product before it takes effect rather than letting you discover it.

Contact

askHermis, [postal address] — [contact email].