Data Processing Terms

These terms form part of the agreement between the customer and Workflow Corporation, an Iowa corporation. They govern how the operator (the processor) handles personal data on behalf of a customer using Meet Buddy (the controller).

These terms apply whenever Meet Buddy processes customer data to provide the service, including scheduling, calendar synchronisation, meeting rooms, recordings, transcripts and related support.

The split is the same one set out in the privacy policy, restated here in the language a contract needs.

Customer data — the customer is controller

Everything the workspace decides to collect and do: invitees’ names and addresses, answers to the workspace’s own booking questions, routing-form submissions, what is said in its meetings, whether to record, whether to keep it. We process it on the customer’s documented instructions and for no purpose of our own.

Account data — we are controller

The account holder’s own login, profile, security and billing relationship with the operator. We decide how that is handled and we answer for it directly; it is not covered by these terms and is covered by the privacy policy instead.

Where a customer is itself a processor

If the customer is handling someone else’s data through Meet Buddy, they act as processor and we act as sub-processor, and these terms apply on that basis. Nothing here needs to change for it to work.

• Documented instructions only.We process customer data to provide Meet Buddy, and otherwise only on the customer’s written instruction. Using the product — publishing a booking page, configuring questions, starting a recording, connecting a calendar, calling the API — is itself an instruction, and it is how nearly all instructions will arrive.
• No secondary use. We do not sell customer data, do not share it for advertising, do not use it to build profiles, and do not use it to train any model. That last one is already in the terms and is repeated here because it is the question that now gets asked first.
• Legal compulsion. Where the law requires us to process beyond those instructions we will tell the customer first unless we are prohibited from doing so.
• We will say when an instruction looks unlawful.We are not the customer’s legal adviser and we do not police their processing, but an instruction that appears to breach data protection law gets flagged rather than silently executed.
• Confidentiality. Anyone with access to customer data is bound to confidentiality and has access only where their job requires it.

This annex describes the subject matter, duration, nature and purpose of the processing, the people it concerns and the types of personal data involved.

Subject matter and duration

Providing a scheduling and meeting service. Processing lasts for as long as the customer’s workspace exists, plus the period described under return and deletion.

Nature and purpose

Publishing availability, taking bookings, sending booking correspondence, writing events to a connected calendar, hosting live meetings, and — where the customer enables them — recording and transcription.

Categories of data subject

The customer’s own members; invitees who book time with them and any guests those invitees add; anyone who joins one of their meeting rooms, including people who never booked.

Categories of personal data

Identifiers (name, email address); scheduling data (chosen time, timezone, booking history, cancellation and reschedule reasons, attendance); free-text answers to the customer’s own booking and routing questions; meeting content (in-room chat, questions and upvotes, poll responses); speech, where recording or captions are used — audio and video in a recording, and verbatim text in a transcript; technical data (network address in audit records, connection quality, device labels); and free/busy windows from a connected calendar.

Special categories

Not requested by the product, and not restricted by it either. Nothing in Meet Buddy asks for health, biometric, religious or similar data — but the customer’s booking questions are free text and a meeting is a conversation, so what ends up in them is the customer’s decision. A customer who intends to collect special category data through this product is doing something the product does not know about, and the obligations that come with it are theirs.

Frequency

Continuous, for as long as the service is in use.

Each item below names something the code does. A measures annex that lists aspirations is a liability rather than an assurance.

• Tenant isolation by construction.Every query against workspace-owned data filters on the workspace identifier, and every stored object’s path is built by one shared helper and begins with that identifier — so cross-workspace access is prevented by the shape of the system rather than by remembering to check. A route that serves bytes resolves the path back to the row that claims it and compares the owner before reading.
• Credentials at rest.Passwords are bcrypt hashes at a deliberately slow work factor. Calendar refresh tokens are encrypted with AES-256-GCM under a key derived from the deployment’s signing secret, and a refresh token is refused storage entirely when no secret is set.
• Meeting access.Media-server tokens are minted server-side from a role the server resolved against the database; nothing in a request body can influence the permissions in one. Host controls re-read the live membership on every action rather than trusting a session snapshot, so removing someone’s access takes effect during the meeting rather than at the end of it.
• Egress controls. Outbound webhook destinations are checked and private and loopback addresses are refused, which limits what a compromised or careless configuration can reach.
• Auditability. Consequential actions are recorded with actor, target, time and network address, and those records outlive the accounts they name.
• Availability posture. Booking does not depend on the media server: a confirmed booking and its join link are written in one database transaction, so an outage in the meeting plane cannot lose a booking or invalidate a link already sent.

Two weaknesses, stated because a measures annex that hides them is worthless

• Rate limiting is per process and in memory. Behind more than one instance the effective ceiling multiplies by the number of instances and a deployment resets every counter. It is a brake on ordinary misuse, not a security boundary, and there is no rate limiting at all on in-room actions.
• A deployment with no mail provider configured writes the full text of every message it would have sent to its own log, including one-time links and invitation tokens, and reports them delivered. Those links are bearer credentials. This matters to a customer because it is an operator configuration error that turns a log file into a credential store.

Breach notification

We will notify the customer without undue delay after becoming aware of a personal data breach affecting their data, with what we know at the time and updates as we learn more, so that the customer can meet their own notification deadlines. We do not notify the customer’s data subjects or their regulator on their behalf — that is the controller’s call and their obligation.

The customer gives general authorisation for the sub-processors we use to run the service.

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.

A connected calendar provider is not on that list and is not a sub-processor of ours: connecting Google Calendar or Microsoft 365 is the host’s own act, authorising their own provider, and the data flows under the host’s relationship with them.

Changing the list

We will give the customer notice by email before a new sub-processor starts processing their data, and the customer may object on reasonable data-protection grounds. If we cannot resolve an objection, the customer may terminate the affected part of the service.

Sub-processor change notices are sent to the customer by email using the contact details associated with the workspace.

Each sub-processor is engaged under terms no less protective than these, and we remain responsible to the customer for their performance.

Where the service runs: The United States (Google Cloud Platform, region us-east4, Northern Virginia). That is very likely not where the customer or their invitees are. Where data moves out of a region that restricts such transfers, the applicable transfer position is set out below.

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.

The customer is responsible for assessing whether the stated transfer arrangements meet the requirements that apply to its use of the service and for contacting us before transferring data where additional safeguards are required.

One transfer happens outside our control and is disclosed rather than covered: where a participant enables live captions, their browser sends their microphone audio to the browser vendor’s recognition service. See the recording, captions and consent page — a controller whose participants use captions should account for it.

Data subject requests

Where a data subject writes to us about a customer’s data, we pass it to the customer rather than acting on it ourselves — the same limit that stops a stranger deleting somebody’s bookings by writing to us. We assist the customer in responding.

What that assistance looks like today

A person does it.There is no self-service export of one invitee’s data and no per-subject erasure routine — the database now carries the markers such a routine would use, and nothing reads them yet. An erasure request is met by locating and deleting the records by hand, which is slower and worth knowing before a deadline rather than during one.

Impact assessments and consultation

We will provide the information we reasonably hold to help with a data protection impact assessment or a prior consultation. This document and the privacy policy are written to be most of that input.

Records

We maintain records of the processing we carry out for the customer and make them available on request.

We will make available the information reasonably needed to demonstrate compliance with these terms, and allow an audit by the customer or an auditor they mandate, on reasonable notice, during business hours, no more than once a year unless a regulator or a breach requires otherwise, and subject to confidentiality.

Two limits worth stating plainly.An audit may not extend to other customers’ data or to systems shared with them. And there is currently no third-party certification or audit report — no SOC 2, no ISO 27001 — to offer instead of an audit; a customer who needs one should say so before relying on this service rather than after.

The product also has no per-workspace API request log, so a customer cannot inspect their own API traffic in the product. Request logs are held by the operator and can be provided on request.

On the customer’s instruction, and in any case at the end of the service, we delete or return their personal data.

• Deleting a workspace is the act that deletes.The rows go and the removal of everything the workspace stored is scheduled in the same database transaction, so a crash cannot leave a workspace’s recordings sitting in storage with nothing left pointing at them.
• Export is what the customer does before that.The product’s API and its calendar feeds are the export path; there is no single “download everything” button, so a customer intending to leave should export first and delete second.
• Backups age out on their own cycleafter deletion rather than being edited, which is ordinary and is stated because it means “deleted” and “gone from every medium” are a short distance apart in time.
• Audit records are kept, with the name of the person who acted, deliberately outliving the account. An audit trail that vanishes with the account is not an audit trail. Where the law requires that to end, it ends.
• Events already written to a host’s connected calendar stay there. They are the host’s own appointments in the host’s own calendar and we lose the ability to touch them when the connection is removed.

These terms form part of the terms of service and, on questions of how personal data is processed for the customer, take precedence over them. The liability provisions of the terms of service apply here too, including the cap at the greater of (a) the total fees paid by the customer in the twelve months preceding the claim and (b) US$100, and these terms are governed by the laws of the State of Iowa, United States, without regard to its conflict-of-laws rules, with exclusive venue in the state and federal courts sitting in Scott County, Iowa.

For a countersigned copy, a sub-processor question, an audit request or anything else in this document, write to support@workflowcorp.com. Legal notices go to Workflow Corporation, 210 Emerson Pl, Suite 300, Davenport, IA 52801, United States — support@workflowcorp.com, +1 (563) 275-6409.