Privacy Policy

Meet Buddy is used by hosts, who have accounts, and by invitees, who book a time and turn up. Almost every confusing question about a scheduling product comes from mixing the two up, so this document keeps them apart.

For hosts

We decide how the service handles account data — your login, your settings, the security around it — and we answer to you for it directly.

For invitees

The workspace you booked with decides what to ask you, what to do with your answers and whether to record the meeting. We hold that data on their behalf and act on their instructions. In data-protection language they are the controller and we are the processor.

The practical consequence: if you booked a meeting and want your data deleted, ask the workspace you booked with. They can do it themselves. We can help if they will not respond — see your rights.

Asserting that split creates an obligation, and until recently this document asserted it with nothing behind it. The terms that actually govern it — what we may do with a customer’s data, who else touches it, what happens on termination — are the data processing terms. If you are a customer whose compliance team has asked for a DPA, that is the document, and its status is stated on its own face.

Your account

Name, email address, a hashed password if you set one, your profile image if you have one, your timezone and when you last signed in. Passwords are stored as bcrypt hashes at a deliberately slow work factor; nobody here can read yours, including us.

Signing in with Google or Microsoft

We request your identity and email address, and nothing more. The record that link creates is used to recognise you at sign-in and is read by nothing else in the product. Signing in with Google does not connect your Google Calendar. That is a separate, separately-consented step, and no part of the code borrows one for the other.

Your scheduling setup

Workspaces you belong to and your role in each, event types, availability schedules, date overrides, booking rules.

Activity

An audit trail of consequential actions — who cancelled a booking, who changed an integration, who deleted a recording — with the time and the network address the request came from. It is what makes “who did this” answerable, and it is deliberately kept when the account that did it is gone.

Only what the booking needed, and it is the host’s form that decides most of it.

• Name and email address, and any guests you added.
• The time you chose, the timezone you were shown times in, and what the meeting was for.
• Your answers to the host’s questions. These are whatever they asked — we do not set the questions and we do not inspect the answers.
• The reason you gave if you cancelled or rescheduled, and whether you turned up.

There is no invitee account and no password. Rescheduling and cancelling work through a signed link in your confirmation email rather than by making you register, which means one fewer credential in the world and one more link worth not forwarding.

Before you join a meeting you are offered a photo, so the other people on the call see a face rather than your initials. It is optional and nothing asks for it twice. If you never open that screen, or open it and skip past the control, no picture of you is ever stored.

Where one is set, four things are true, and each is deliberate.

• It is saved for one workspace only. If you later book with a different organisation that also uses Meet Buddy, they get nothing — not your photo, not the fact that you set one elsewhere. This is not a rule we apply; it is how the record is stored. Setting a photo for two workspaces creates two unconnected copies, and there is no field linking them, because there is no email address on the record that holds the picture.
• It is remembered by this browser and by the booking it was set for. Two pointers, both scoped to that one workspace: a cookie in the browser you used, and the invitation itself. Book with them again from the same browser and your photo is already there; open the same invitation link on your phone and it is there too, which also means it would be there for anyone you forwarded that link to. We check that a browser presenting the cookie is the same person before carrying a photo across to a new booking, so a shared or public machine does not hand your face to whoever sits down next. On a device with neither pointer you would simply set it again — the cost of not building an account for you, and we would rather pay it than keep a profile of you across the product.
• It is shown to the people in the meeting — on your tile, in the participant list, and to a host deciding whether to let you in. It is not on any public page and it is served so that shared caches do not keep a copy. The file is rewritten before it is stored, with the metadata a camera writes into a photo — where it was taken, when, and on what — removed, because that travels inside the picture and nobody sharing a face expects to be sharing an address.
• It expires. A photo is deleted 180 days after the last meeting you used it for, and the file itself is destroyed rather than merely unlinked. Joining a meeting with it resets the clock; not using it runs it down — and it really is joining, so opening an old link to check a date does not keep the photo alive. Unlike almost everything else in this document, that limit does not depend on the workspace configuring a retention period — a workspace can make it shorter, which applies immediately to photos it already holds, and nothing can make it longer.

You can remove it yourself at the same control you set it at, before the meeting or during it, and that removes the file. A workspace deleting itself takes every photo given to it along with everything else it stored.

Audio and video are not stored unless somebody starts a recording. They pass through the media server between participants and are not written down.

Stored either way:

• Attendance. Who joined, when, for how long, and across how many reconnections.
• Chat.Messages sent in the room, kept against the meeting with the sender’s name alongside so a line still reads after that account is gone.
• Captions, where somebody turned them on. Meet Buddy has live captions. They are off by default and each participant enables them for their own microphone — but once enabled, what that person says is transcribed and kept against the meeting as text, with a timestamp and their name, whether or not anything is being recorded. The recogniser is the participant’s own browser, which today means a Chromium browser, and in Chromium that audio is sent to the browser vendor’s remote recognition service to be turned into text. That processing is the browser’s and is outside this deployment’s control; it is disclosed because the word “captions” sounds local and is not.
• The meeting record. Its code, when it ran, and which booking it belongs to.

When a recording is made, the file goes to the workspace’s own area of object storage and the workspace controls it. What that means legally, exactly what captions capture, and what Meet Buddy deliberately does not do — no server-side transcription of the room’s audio, no transcription of other participants for you, no voice or face analysis, no sentiment or attention scoring — is on the recording, captions and consent page.

Connecting Google Calendar or Microsoft 365 lets Meet Buddy avoid offering a slot you are already busy in, and write your confirmed bookings into your calendar. It is the most invasive-sounding thing in the product, so here is exactly what it takes.

What is stored

The start and end of your existing events, and whether each one counts as busy. That is what a free/busy check needs and it is all a conflict check uses.

What is not stored

Event titles are never written down. The field exists in the database for a future opt-in and the code that fills the cache explicitly asks the provider not to include them. Nor are attendees, locations, descriptions or attachments.

The token

The credential that lets us re-read your calendar in the background is encrypted at rest with a key derived from this deployment’s signing secret. Rotating that secret makes existing connections unreadable, which turns rotation into a reconnect rather than into a silent loss of conflict checking.

Disconnecting

Stops the syncing and forgets the token. Events we already wrote into your calendar stay there — they are your real appointments — and we lose the ability to update them. For Microsoft we cannot revoke the grant from our side; you remove it from your own account.

There are four, and none of them is for advertising or analytics. This application contains no third-party tracking code at all — no tag manager, no pixel, no session recorder.

Session

Set when you sign in, so the next request knows who you are. Lasts up to thirty days.

Active workspace

Remembers which workspace the console is showing. It is a preference and never an assertion — it is re-checked against your actual memberships on every read, so editing it gets you nothing.

Theme

Light or dark. Deliberately readable by the page itself, because it has to be applied before the first paint to avoid a flash. Kept a year.

Sign-in protection

Short-lived cookies the sign-in flow uses to make sure a login form submission came from this site.

There is no cookie banner because there is nothing here to consent to beyond making the product work.

We do not sell personal data and we do not share it for advertising. Data reaches other companies in four ways, all of them operational:

• Infrastructure. The database, object storage, media server and mail provider this deployment runs on. The authoritative list is Sub-processors used by the Service: Google LLC (Google Cloud Platform — hosting, database and object storage) and Resend, Inc. (transactional email). Where a user connects a calendar, that provider also processes booking data: Google LLC or Microsoft Corporation. Meeting audio and video are not sent to any third party — the media server is operated by the operator on its own infrastructure. No analytics or tracking services are used. This list covers processors the Service transmits personal data to; the operator may use additional vendors in its own operations..
• Calendar providers, when a host connects one — and only for that host’s own calendar.
• Wherever a workspace sends it. A workspace can point webhooks at its own systems and use the API. What leaves that way is their configuration and their responsibility.
• Legal obligation, where we are required to disclose something and are permitted to say so.

What the software itself reaches

The list above is the operator’s to complete. This one is not — it is read off the code, so you can check it against the product rather than take it on trust: Google LLC, for Google Cloud Platform — the application, its database and its object storage. Resend, Inc., for transactional email only. Where a host connects a calendar, that provider processes their booking data too: Google LLC (Google Calendar) or Microsoft Corporation (Microsoft 365). Meeting audio and video are not sent to any of them — the media server runs on the operator's own infrastructure. There is no analytics, advertising or session-recording code in the application at all.

Treat that as a floor and not as the full list. It describes what the application transmits, and it cannot see a vendor that touches data somewhere else — a backup or disaster-recovery tool, a support desk, anyone with access to the database who is not the operator. Only the operator can complete that, which is why the two are shown separately instead of one standing in for the other.

Meet Buddy runs where its operator runs it, and that is very often not the country you or your invitees are in. An operator’s own address tells you nothing about where the servers are; the two are routinely on different continents, and a policy that quietly lets you assume otherwise is the reason this section exists.

Where this deployment runs

The United States (Google Cloud Platform, region us-east4, Northern Virginia). That covers the application, its database and its object storage. The media server that carries live audio and video may sit somewhere else again, and live media crosses whatever network path lies between the participants and it.

Who else it reaches

The infrastructure providers listed under who else sees any of it, in the locations those providers operate. A connected calendar is processed by Google or Microsoft in theirs.

Captions

If a participant enables captions in a Chromium browser, that person’s microphone audio is sent to the browser vendor’s recognition service, wherever the vendor operates it. That transfer is made by the browser rather than by Meet Buddy, and it happens whether or not this deployment is recording.

The transfer mechanism

Where personal data moves out of a region that restricts such transfers — the EEA, the UK, Switzerland and others — The Service is operated from and hosted in the United States. No Standard Contractual Clauses have been executed and the operator is not certified under the EU–US Data Privacy Framework. Customers subject to EEA or UK transfer restrictions should contact the operator before submitting personal data of individuals in those regions.is what makes it lawful. Naming the mechanism is the operator’s to do, and this document deliberately does not guess at one: an unnamed or wrongly named safeguard is not a safeguard.

If your organisation has a data-residency requirement, check the hosting locations above against it before you rely on this service, and take it up with support@workflowcorp.com. We would rather answer that question than have it discovered later.

Nothing expires unless a workspace sets a retention period, and no period is set by default. Bookings, meeting records, attendance, chat, transcripts and recordings are otherwise kept until somebody deletes them or the workspace is deleted.

One exception, and it is the one you did not choose. A photo an invitee sets before a meeting is deleted 180 days after they last used it, whatever the workspace has or has not configured — see photos. Every other class on this page belongs to a workspace’s own record of its work; that one is a picture of somebody with no account and no way to go and remove it, so it is the one thing here with a ceiling nobody has to set.

Where a period isset, it is enforced by the product rather than by somebody remembering: a scheduled job clears the personal details from records past the cutoff and marks them redacted, and deletes recording media from storage outright. The structural record — that a meeting happened, how long it ran, how many people attended — is deliberately kept, because removing it would silently change a host’s own history of their work.

The periods this deployment applies are Recordings, transcripts and meeting records are retained until the workspace is deleted or until erasure is requested; no automatic expiry is currently applied. Deleting a workspace removes its bookings, meetings, recordings and transcripts..

What is built, and what is not

Being precise about this is the difference between a policy and a claim. The database can now hold a retention period per workspace for three separate classes — bookings and what hangs off them, in-room content, and recording media — and can mark an individual person’s records as erased without destroying the counts and attendance records that other people are entitled to keep. Both are now acted on: a scheduled job enforces whatever periods your workspace has set, and an administrator sets them under Settings → Data retention. It clears the personal details from records past the cutoff and marks them redacted, and deletes recording media from storage outright. Where no period is set — the default — nothing expires.

In the meantime an erasure request is carried out by hand, through the workspace, and everything under your rights applies. If your request concerns a meeting, name the recording and any transcript — captions can leave a written record of a meeting nobody recorded.

Deleting a workspace

Deleting a workspace removes its records, and the removal of everything it stored is scheduled in the same database transaction as the deletion. That ordering is the point: the alternative leaves a window in which the rows are gone, nothing references the files, and a crash means nothing ever will — and those files are video of people’s faces. Backups age out on their own cycle afterwards.

Audit records deliberately outlive the accounts they name, with the name kept alongside so the entry still reads. An audit trail that disappears when somebody deletes their account is not an audit trail.

• Passwords are bcrypt hashes at a slow work factor. Reset links are 32 bytes of cryptographic randomness, work once, expire within the hour, and changing a password invalidates every other live reset link for that account.
• Every stored object’s path begins with its workspace’s identifier, and those paths are built by one shared helper rather than assembled by hand — so cross-workspace access is prevented by the shape of the storage, not by remembering to check.
• The media server’s API secret never reaches a browser. Join tokens are minted on the server from a role resolved on the server, so “participants may not share their screen” is enforced by the media server refusing, not by hiding a button.
• Reschedule, cancel and calendar-feed links are signed. Anyone holding one can use it, which is what makes them convenient and what makes them worth not forwarding.

Two limits worth stating

The per-member calendar feed link cannot be revoked individually. It expires after a year, and the only way to invalidate one sooner is to rotate this deployment’s signing secret, which signs everyone out and invalidates every other signed link. If you think yours has leaked, say so — an operator can rotate, and that is currently the whole remedy.

A deployment with no mail provider configured writes the full text of every email it would have sent into its own server log, including reset links and invitation tokens, and reports them as delivered. That fallback exists so the product runs on a developer machine. An operator running a real deployment without a mail provider is keeping working credentials in a log file.

No system is perfectly secure and we do not claim this one is. If you find a problem, tell us at Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States — support@workflowcorp.com, +1 (563) 275-6409 before you tell anyone else, and we will not come after you for looking.

Depending on where you live you may have rights to see a copy of your data, correct it, delete it, restrict or object to what is done with it, and take it elsewhere. We do not charge for exercising them and we do not treat you differently for it.

If you have an account

Ask us at support@workflowcorp.com. Much of it you can do yourself: an owner can delete a workspace and everything in it.

If you booked a meeting

Ask the workspace you booked with first. They decided what to collect and they can delete it. Replying to your confirmation email reaches the host directly — it is sent with their address as the reply-to for exactly this reason.

If they do not respond

Come to us at support@workflowcorp.com. We will pass it on, and where we can act ourselves we will. What we can do unilaterally to a customer’s records is limited — that is what being a processor means, and it is the same limit that stops a stranger deleting your bookings by writing to us.

Two limits on those rights, stated rather than met

There is no self-service erasure and no one-click “delete everything about this person” button. A request from an individual is carried out by hand. Note the distinction, because the two are easy to confuse: erasure ON A SCHEDULE is automated — the retention job described under how long it is keptclears records past a workspace’s cutoff without anyone doing anything. Erasure ON REQUEST, for one named person ahead of that cutoff, uses the same markers but is still carried out by a person. We would rather you knew which of the two you are relying on.

Meet Buddy’s email carries no unsubscribe link. Confirmations, reminders, follow-ups and cancellation notices are transactional — they exist because you booked something — and the way to stop them is to cancel the booking, using the link in the same email. A workspace can also configure workflow emails, and those have no unsubscribe mechanism in the product either; if one is being used to send you things you did not ask for, that is the workspace breaking the acceptable use policy and you can tell us about it at Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States — support@workflowcorp.com, +1 (563) 275-6409. An unsubscribe link is something the product should have and does not.

You can also complain to your data-protection regulator. We would rather you told us first, but that is your call.

Meet Buddy is a business tool and accounts are not for children. We do not knowingly collect data from children through an account. A minor may well appear as an invitee on somebody’s booking page — a tutor, a clinic, a school — and where that happens the workspace is responsible for having whatever consent applies, which is the same split as everywhere else in this document.

When this policy changes materially we will say so through the product or by email before the change takes effect. The rule the code follows is that a clause describing behaviour and the module implementing it change in the same commit — so a stale sentence here is a bug, and you can report it as one to Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States — support@workflowcorp.com, +1 (563) 275-6409.

That rule has been broken once and it is worth knowing how, because it tells you what to distrust. Earlier versions of this policy and of the recording page said Meet Buddy did not transcribe and produced no captions, while the product had been writing transcripts from live captions the whole time. Both documents now describe what the code does. If you find another sentence here that the product contradicts, that is the report we most want.

A privacy policy with no reachable address is not a policy. These are the only routes, and they are monitored by people rather than by an autoresponder.

The operator of this deployment

Workflow Corporation, an Iowa corporation, Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States. This is the entity responsible for the service and the one a regulator would write to.

Privacy requests and questions

support@workflowcorp.com — access, correction, erasure, objection, portability, anything about this document, and any question about where data is processed. If you are an invitee rather than an account holder, start with the workspace you booked with; this address is the escalation, and it works.

Legal notices, abuse reports and security

Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States — support@workflowcorp.com, +1 (563) 275-6409. Abuse reports should carry the booking link, meeting code or workspace name, what happened, and roughly when — see the acceptable use policy. Security findings are welcome and are not treated as hostile.

Processor terms

If you are a customer and need the terms that govern data we handle on your behalf, they are the data processing terms.

There is no in-product form for any of this yet, and no ticket number comes back. Email is the whole mechanism, which is why the addresses above matter more than they look.