The person who books signed nothing with you
A booking page has one feature no other source has. The people filling in the form are outside your company. They have never heard of Kastel, they agreed to none of your internal rules, and they handed over their name and email address to get a slot with you.
Many of them write the rest as well. The free-text field on a booking form is where a prospect describes their problem, where a candidate explains why they are looking, where an unhappy client sums up what went wrong. That is valuable information, and it does not belong to you.
The Calendly connector settles this before any question of configuration comes up. Neither the identity of the person who books nor their form answers enter your Kastel. And a booking judged personal is set aside before anything is written, by a model you plug in with your own keys. Until a sorting model is plugged in, the connector refuses to start rather than write without sorting.
The connector has no method for reading invitees
In Calendly's own interface, invitee identity does not live with the meeting. It is read through a separate request, sent to a dedicated address. That separation is what allows a protection that depends on no setting at all.
The connector's read client exposes exactly two requests: checking that the access key works, and listing the meetings. The request that would return the invitees was never written. It is not switched off by an option somebody could reopen one day, it does not exist in the code.
Form answers travel with the invitees at Calendly, so they share the same fate. On the invitee side, your Kastel writes a number and nothing else, which is enough to tell a one-to-one from a group meeting and which identifies nobody.
The other booking tool we support, Cal.com, returns its attendees in the same response as the meeting. The data arrives either way, so the control there is of a different nature, and the two pages do not tell the same story.
What comes in from a meeting, and what stays at Calendly
What gets rendered from a booking is short, and short by construction. Here is what it holds, line by line.
This list of exclusions is not a filter applied after the fact. The first three lines are read at Calendly through a request the connector does not have, so there is nothing to strip out, and nothing to misconfigure.
What gets written about the location, depending on the host's choice
Every row can be checked in your own Calendly account, by opening the location setting of the event type concerned.
| Location set in Calendly | What is written in your Kastel |
|---|---|
| In-person meeting, at an address the host typed | The address, exactly as the host typed it |
| Custom location, in the host's own words | That text, as it stands |
| Zoom, Google Meet, Microsoft Teams, Webex | The name of the tool only, never the joining link |
| Phone call, inbound or outbound | The fact that it is a phone call, never the number |
| Location asked of the invitee | The fact that it is to be confirmed, never what the invitee replied |
The rule behind this table comes down to who wrote the line. An address the host typed once and for all describes a company place. A video link is an entry key, and an address given by an invitee belongs to that invitee.
Every meeting is filed in its host's department
Calendly sets no read permission on a meeting. The only signal available is the host, the person on your team whose slot was booked. Your Kastel therefore files each meeting in that host's department, where it becomes readable by the people of that department, through the AI of their choice.
Four situations make that resolution fail. In all four, the meeting is filed in no department and waits for an administrator's decision.
The unreadable co-host case is worth explaining, because it is the only one that could go unnoticed. A two-host meeting where only one host can be identified could perfectly well be filed in the department of the one we recognise. That would understate its audience. So the connector counts host slots rather than the addresses it manages to read, and when the count does not add up it abstains.
A meeting is never filed broadly by default. It lands in one named department, or it waits, which is the same discipline described in governing your knowledge.
- No host is attached to the meeting, and the owner of the event type says nothing either
- A co-host appears on the meeting with no readable address, a deactivated account for instance
- The hosts belong to several different departments
- A host is unknown to your organisation's governance
An organisation key, and a refusal at connection time
Two scopes are possible. An administrator key covers the whole organisation and sees every member's bookings. A personal key covers one member. That choice governs how many meetings come in, never who is entitled to read them, since that question is settled host by host.
Connecting carries one check that looks trivial and prevents a real accident. If the key supplied authenticates a different organisation from the one we were asked to connect, the connector refuses, and it refuses before storing anything. An agency running the Calendly accounts of several clients therefore cannot attach one client's meetings to another client's Kastel by mistake.
Calendly cannot say what has changed since last time, as its interface offers no tracking token. Every pass therefore rereads a window of dates, starting again from the moment of the last successful pass, and a second pass collects the cancellations. The first read reaches back 365 days by default and takes every future meeting.
That reread has a consequence worth knowing. A meeting booked right now shows up on the following pass rather than within the second. And when a pass fails somewhere, the window does not move on: it is reread in full next time, which costs compute and avoids losing a meeting in silence.
What this connector does not do
It does not read your calendar. Only meetings booked through Calendly enter your Kastel. A meeting you create by hand in your calendar does not come through this connector, and neither does a slot you block out to work. That is the job of the Google Calendar connector.
You will not be able to ask a plugged-in AI who you are meeting on Tuesday. It will know that a meeting exists, at what time, with which host on your team, and how many people are expected. It will not know the client's name. That is the price of the decision described above, and we pay it deliberately.
The meeting name is text your team wrote in Calendly. If a host names their event type in a way that reveals something sensitive, that name comes in with the meeting.
A cancelled meeting does not disappear from your Kastel. If it had already come in, it is marked there as gone at the source and kept, readable by the same people as before, until an administrator decides to erase it. A meeting cancelled before it was ever read never comes in at all, since a cancellation never counts as content.
See how your Kastel decides, source by source.
The product page shows what each plugged-in AI can reach depending on the person it works for, and what an administrator keeps within reach.
See the product
